Rethink the nginx vhost fragments system

[ansell]

The biggest issue right now for nginx server/location configurations is the requirement to be able to deploy to the same domain name from different playbooks at different times.

The second biggest issue is that we are not declaring the domain name(s) in the original call to the webserver role (which calls the nginx role), only in calls to the nginx_vhost role. This could be improved, but there is no urgency at this point so it is fairly low priority.

The third biggest issue is the sporadic use of tag to isolate parts of a playbook for partial use, in which case we can't guarantee that a previous element will always be called. Novice users of tags may think the system is broken because we appear to be supporting tags even though they are always going to be broken in strange and unusual ways if used by non-experts due the complex dependencies between roles due to the way nginx_vhost is pulled in by applications and the domaon .

Some users also merge multiple applications that could easily be supported in separate domain names into single playbooks which make them more cumbersome to support than they should be. Unfortunately there is no technical direction at this point to fix those issues so they are also a complicating factor in being able to manage the nginx configuraiton at a higher level than the nginx_vhost+vhost_fragments persistence level.

In the multiple playbooks case, we can't touch any of the previous nginx configuration for fear of removing an essential element, or duplicating an essential element.

In the nginx_vhost case, it is too late to be able to clean up previous fragments automatically at that stage, as a previous call to nginx_vhost may have already modified current fragments.

Using include to pull in separate parts of the configuration would make it cleaner, but it wouldn't fix the requirements that we need to allow for in this case.

The current requirement is for users who know they are deploying from a single playbook to setup the vhost fragments they want to clear in their inventory file, which is picked up by the high level nginx role:

nginx_vhost_fragments_to_clear=["demo.livingatlas.org"]

This step is optional as it can't be implemented any other way at this point without users having other complaints which we would then need to deal with individually to verify the cause for them.

This issue is open for suggestions on how to improve the overall nginx setup while keeping to the current (and likely future) requirements of different playbooks, and partial executions.

cc @vjrj

[vjrj]

I'm my experience using other nginx roles like:
https://github.com/nginxinc/ansible-role-nginx
or the puppet nginx module they allow incremental adding of vhost but they don't care about removing vhosts.

So they create a vhost file in /etc/nginx/sites-* when you configure a new vhost proxy or web server.

They don't take care or cleans or deletions, so you have to add additional remove tasks for old vhost configurations if you, for instance, don't need some vhost proxy configuration you were using in the past.

They create a vhost-some-domain.conf for each vhost also.

As we want to configure some domain with several /services-context that can change in time, maybe we can use include in demo.livingatlas.org.conf and a structure like:

root@la:/etc/nginx/sites-available# ls -1 demo.livingatlas.org-includes/
demo.livingatlas.org-includes/-images.conf
demo.livingatlas.org-includes/-logger.conf
demo.livingatlas.org-includes/-species.conf
demo.livingatlas.org-includes/-species-ws.conf

To use include is in general the strategy that uses apache and ningx to manage a variable web server configuration.

[ansell]

Adding an overall label to each call into the nginx_vhost role will help with redeploying specific applications and wiping out just the fragments that are relevant to each of the applications. We have been lacking that so far, so there isn't any overriding label that we can attach to the fragments that are created. Thanks, I will look into doing this

[vjrj]

Great @ansell . I think that this can fix one of the issues of this generator: https://github.com/vjrj/generator-living-atlas when you configure several standalone services in the same machine and the same domain.

[vjrj]

I return to this enhancement.

Let me give some samples of our current situation in nodes like Austria (production), and Tanzania (demo). Both nodes are using few VMs (2 and 3 respectively).

With the current nginx_vhost implementation we need to use different hostnames for each service even if the services are in the same host.

This is counter-intuitive and error-prone. For instance this error in Austria was caused by the use of the same hostname for bie and bie-ws in the same host. We suffer similar errors in the Tanzania's demo til we started to use different hostnames for each service.

The usual strategy in webservers to configure vhosts is the use of the service name, let's say, the https://serverdomain.org is configured in /etc/WHATEVERWEBSERVER/sites-enabled/serverdomain.org.conf vhost configuration. With the current nginx_vhosts configuration we are using hostname.conf.

And this hostname.conf is overwritten in each standalone or tag execution in the same host.

The serverdomain.org.conf strategy should work well with subdomains like collectory.ala.org.au but not so well with paths like demo.gbif.es/ala-collectory.

My proposal to solve this is that every service role configures a common serverdomain.org.conf with an nginx include directive to a directory where each /service-path location are included. Not the use of per-execution-vfragments that are assembled at the end of the ansible execution.

For instance if in some hosts we use biocache.serverdomain.org and biocache-ws.serverdomain.org this will produce:

• biocache.serverdomain.org.conf (with a include to ../thisdomain/*locations)
• biocache-ws.serverdomain.org.conf (with a include to ../thatwsdomain/*locations)

For instance biocache.serverdomain.org and biocache.serverdomain.org/ws will produce:

• biocache.serverdomain.org.conf (with a include to ../thisdomain/*locations)

Or bioatlas.se/biocache and bioatlas.se/biocache-ws will produce

• bioatlas.se.conf (with a include to ../thisdomain/*locations)

So every role that needs a vhost, configures the common serverdomain.conf (and overwrites without pain) and copy its /service-path locations to that directory of locations that serverdomains.conf includes.

Vhosts deletions are not handled by ansible but the addition and modifications or vhosts (like others vhost plugins do).

For us that we are using the LA ansible generator, this enhancement is quite important because will permit us to install a complete national node with all basic services (including CAS, Spatial and https) in multiple hosts without errors. Example of command we are using:

./ansiblew --alainstall=../ala-install all --nodryrun

For others portals we'll permit to exec tags or standalone playbooks in a hosts without nginx issues.