First, we cannot do a global check for has_wordpress or needs_php,
as those are defined per nginx vhost. Second, I realized that this
was only working in the past because vhosts that had WordPress or
needed PHP were listed first in the nginx_vhosts dict.
This changes the logic to first check if any vhosts have WordPress
or need PHP, then sets a fact that we can use to decide whether to
run php-fpm tasks or not.
ansible-lint told me not to test equality with booleans using literal
"True" and "False", but it Ansible complains if I use "is True" also.
It seems that I need to adjust the syntax slightly.
Instead of looping over a list of items to install, we can actually
just give a list directly to the apt module. This allows the module
to install all packages in one transaction, which is faster as well
as slightly safer for some dependency resolution scenarios.
This tag is no longer reachable after switching to the new dynamic
includes in Ansible 2.4 and 2.5. Anyways, I've been questioning my
decision to add the "packages" tag to any task that uses the apt
module.
These tasks are conditional and mutually exclusive due to the "when"
clause. Using import_tasks means that these are imported before the
playbook execution and then skipped during evaluation of the test.
It makes sense in this case to use include_tasks so that the tasks
are only imported during playbook execution if the condition is met.
Ansible 2.4 and 2.5 are moving away from specialized loop functions
and the old syntax will eventually be deprecated and removed. I did
not change the with_fileglob loops because I'm not sure about their
syntax yet.
See: https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html
Ansible 2.4 changes the way includes work. Now you have to use "import"
for playbooks and tasks that are static, and "include" for those that
are dynamic (ie, those that use variables, loops, etc).
See: http://docs.ansible.com/ansible/devel/playbooks_reuse_includes.html
Using www-data was a temporary measure while I was waiting for the
official nginx.org packages to be released for Debian 9 and we had
to use Debian's own nginx package.
Sync with latest packaged version from Debian 9. Effectively this
only updates comments and disabled options, but having less changes
to look at during an apt upgrade is nice and reduces the chance of
adding errors.
Debian 9 is still in beta and doesn't have nginx.org builds yet, so
we need to use the nginx package in Debian's repositories, and that
required a bit of a different configuration.
After official nginx.org builds are released we can revert this.
Only vhosts running WordPress, etc need PHP. Make sure to set the
appopriate variables for each vhost in the host's vars, ie:
nginx_vhosts:
- domain_name: example.com
has_wordpress: True
- domain_name: example.net
needs_php: True
You can set either of them, but not both—needing WordPress implies
needing PHP.
This reverts commit 201165cff6.
Turns out this actually breaks initial deployments, because the
cache gets updated in the first task, then you add sources for
nginx and mariadb, but it doesn't update the indexes because the
cache is < 3600 seconds old, so you end up getting the distro's
versions of nginx and mariadb.
I have added cache_valid_time=3600 for the first task in each
tag that could be possibly running apt-related commands. For ex,
the "nginx" tag is also in the "packages" tag, but sometimes you
run the nginx tag by itself (perhaps repeatadely), so you'd want
to limit the update unless the cache was 1 hour old
For idempotence we need to run all apt-related tasks, like editing
source files, adding keys, installing packages, etc, when running
the 'packages' tag.
