As of Ansible 2.4 and 2.5 the behavior for importing tasks has changed
to introduce the notion of static imports and dynamic includes. If the
tasks doing the import is using variable interpolation or conditionals
then the task should be dynamic. This results in quicker playbook runs
due to less importing of unneccessary tasks.
One side effect of this is that child tasks of dynamic includes do not
inherit their parents' tags so you must tag them explicitly or a block.
Also, I had to move the letsencrypt tasks to the main task file so the
tags were available (due to dynamic tasks not inheriting tags).
As of Ansible 2.4 and 2.5 the behavior for importing tasks has changed
to introduce the notion of static imports and dynamic includes. If the
tasks doing the import is using variable interpolation or conditionals
then the task should be dynamic. This results in quicker playbook runs
due to less importing of unneccessary tasks.
One side effect of this is that child tasks of dynamic includes do not
inherit their parents' tags so you must tag them explicitly or a block.
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
There are currently no nginx.org builds for Debian 9, so we need to
use the package from Debian's repository. This package provides a
www-data user and group instead of an nginx one.
We can revert some of this after Debian 9 is released and official
builds come from nginx.org (though it might be useful to keep the
main nginx.conf as a template).
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.
When you give Ansible the key id it will check if the key exists
before trying to download and add it. I got the long fingerprint
from `sudo apt-key finger`.
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.
The creation of the fastcgi cache dir is part of the nginx role and
should be labled as such. In situations where you only run nginx
tasks with `-t nginx` nginx will fail to start due to the missing
cache dir.
For security and predictability clients should only get a reponse
if they request a hostname we are actually hosting.
If TLS is in use then this will use a self-signed snakeoil cert for
an HTTPS-enabled blank, default vhost.
Signed-off-by: Alan Orth <alan.orth@gmail.com>
A template is better than ansible's `apt_repository` module because
we can idempotently control the contents of the file based on vari-
ables.
Signed-off-by: Alan Orth <alan.orth@gmail.com>
Bypasses caching for logged in users (right now only for sessions
where the "wordpress_logged_in" cookie is set. Doubles the trans-
actions per second as measured by siege:
$ siege -d1 -t1M -c50 https://mjanja.ch
Signed-off-by: Alan Orth <alan.orth@gmail.com>
