Collective config validation & "extra options" #36
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 8 commits
December 22, 2015 16:05
Re-ordering the tasks in this way (having the vhosts deployed first) allows the 'validate' param to collectively check the deployed Nginx config. Deploying vhosts after makes it hard to check their validity, as Nginx's config checking will operate on a "master" configuration that includes others (checking those included, also) but would error out when checking these individual configs if they do not contain a fully working Nginx config (which they often don't, due to their nature).
Defining a new variable (defaults to empty) that allows users to define extra configuration options in the top-level 'http' block. This allows for (optionally) finer grain control.
Although the 'validate' param was added for the deployment of /etc/nginx.conf - this validation process will only be triggered upon changes. So, if a vhost config is updated, but the main config isn't, the collective config will not be verified. I've added a new handler 'validate nginx configuration' and added this to the 'notify' param as a first list item for vhost config changes. Unfortunately, this will not protect against the deployment of malformed configuration, however it will prevent the restart of Nginx in such a situation (as the 'validate nginx configuration' handler should error out before the 'restart nginx' handler is called).
geerlingguy
added a commit
that referenced
this pull request
Dec 28, 2015
Collective config validation & "extra options"
geerlingguy
added a commit
that referenced
this pull request
Dec 28, 2015
geerlingguy
added a commit
that referenced
this pull request
Dec 28, 2015
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey Jeff!
Thanks for the great role 馃憤
Hoping you'll happily accept these contributions (with any modifications you see fit, of course).
These changes bring a collective validation of the deployed Nginx configuration and the option to define arbitrary "extra" configuration options for the top-level
httpblock in/etc/nginx.conf.validateparam on the deployment of the/etc/nginx.conffile. This will ensure the Nginx config (including any included configs) are valid, according tonginx -t. I had to move the deployment of vhosts above the deployment of thenginx.conffile, to ensure all config was in place before testing (see my commit message on cc5114d for more details).restart nginxwas being called.If an invalid configuration is deployed, it will run this notifier first, so, in the case that
/etc/nginx.confdoesn't change, but a vhost config does, and as such does not trigger the above mentionedvalidateparam, and it introduces some bad config, Ansible will fail upon running the validate handler, so it'll exit before it has a chance (fail) to restart the Nginx service - meaning, you're at least not left with a broken web server :)nginx_extra_optionsvariable that will allow the user to define (literally, using Nginx syntax) extra configuration they want to add to thehttpblock. I elaborate on this in the commit: c5a2143, in the README, and lastly in an example comment indefaults/main.yml.