Update Nginx Configuration to use Microservice after updating OMERO-Web

[khaledk2]

This PR fixes the issue #436 .
I have added a check on the idr-omero-web playbook for Micros-services user existence, i.e., omero-server. If so, it runs the omero_ms_image_region role to update the Nginx configuration file for MS.
The MS deployment cannot be moved to this playbook as the MS user is created after running this playbook.

The molecule test failed without modification due to the failure of starting iptables service
https://github.com/khaledk2/deployment/actions/runs/11316428331/job/31468697284#step:5:1497
I have checked this issue and found out that it failed due to this error:
/sbin/iptables does not exist
I have checked the iptables_raw role and successfully ran the molecule test. I compared the installation packages on the role molecule test and the installation package on the deployment playbook, and they are not identical; more packages are installed on the role which are related to iptables-nft.
I have changed the installation package on the iptables_raw from iptables-services to iptables-nft-services and updated the deployment requirements to point to this modified branch (https://github.com/khaledk2/ansible-role-iptables-raw/tree/refs/heads/upgrade_package_name).
Then I ran the molecule tests in the deployment repo and it passed.
I will open PR for the iptables_raw role shortly

[sbesson]

Thanks for looking into these issues, there are at least three separate issues here:

• the ome.iptables_raw service startup error I can reproduce in https://github.com/sbesson/deployment/actions/runs/11435648689/job/31811454141. I have left a few comments on Change package name ome/ansible-role-iptables-raw#13 (review) about the underlying change. We might need a full testing environment to check the firewall rules are working as expected
• the ome.omero_web/ome.omero_ms_image_region dependency. As shown in Micro-service deployment & NGINX configuration #436 although the two roles are built separately, there is a strong dependency between the two as the second one patches the NGINX configuration file created by the first one. In practice, they should always be run at the same time with the current architecture design. For future additions, this should probably be rethought to either separate the NGINX configuration from the application roles or allow to specify NGINX extension points.
• the ome.omero_ms_image_region/ome.omero_server dependency. The default user of the former role is the omero-server user created by the latter. Although the proposed check introduced in this PR might work, I think we need to find a different solution as this is adding another layer of complex logic to workaround the fact we have a circular dependency.

I think the order in

deployment/ansible/idr-01-install-idr.yml

Lines 9 to 12 in 87c6210

	- import_playbook: idr-omero.yml
	- import_playbook: idr-omero-web.yml
	- import_playbook: idr-omero-readonly.yml

is currently incorrect. Based on the dependencies expressed above, my understanding is that this would be the required steps:
1- idr-omero.yml i.e. install OMERO.server on the read-write servr
2- idr-omero-readonly.yml i.e. install OMERO.server on the read-only servers
3- idr-omero-web.yml i.e. install OMERO.web on all servers and the image-region micro-service on the read-only services

[dominikl]

I get past the iptables issue, but now stuck at:

PLAY [Deploying search engine] ******************************************************************************************************************************************************************************

TASK [Gathering Facts] **************************************************************************************************************************************************************************************
fatal: [19cd7a52-3664-4ed9-8c5f-f0b880e28221]: UNREACHABLE! => {"changed": false, "msg": "EOF on stream; last 100 lines received:\n", "unreachable": true}

PLAY RECAP **************************************************************************************************************************************************************************************************
19cd7a52-3664-4ed9-8c5f-f0b880e28221 : ok=0    changed=0    unreachable=1    failed=0    skipped=0    rescued=0    ignored=0