Instead of iterating over fifteen packages with a loop that does fifteen
separate apt transactions, it is better to give the apt module a list so
it can install them all in one transaction. This is both quicker and te-
chnically more safe for dependency resolution.
Instead of iterating over fifteen packages with a loop that does fifteen
separate apt transactions, it is better to give the apt module a list so
it can install them all in one transaction. This is both quicker and te-
chnically more safe for dependency resolution.
Use dynamic includes instead of static imports when you are running
tasks conditionally or using variable interpolation. The down side
is that you need to then tag the parent task as well as all child
tasks, as tags only apply to children of statically imported tasks.
Basically, when using conditionals or variables in your tasks you should
use include_tasks instead of import_tasks. The down side is that you now
need to tag all included tasks individually or with a block, unlike when
using static imports (tags are applied to all imported child tasks).
I would actually like to reduce this task to a single one that uses the
host's ansible_distribution variable, but Ansible 2.5.1 currently gives
the following error: ansible_distribution is undefined.
Vanilla Ubuntu (and Debian actually) defaults to using the official
mirror for security updates rather than country or regional mirrors.
Also, for what it's worth, Ubuntu mirrors didn't always sync these
security archives. I'd prefer to stay closer to vanilla Ubuntu but
also it kinda makes sense to get security updates from the official
source than a mirror (in case of delay or errors).
We stopped being able to do dynamic includes from the playbooks around
Ansible 2.4.0.0 if I recall correctly. Instead we can create a task to
include the variables and make it always run by using the special tag.
For now the Debian and Ubuntu vars files are the same, but I will keep
them separate so that it is more flexible in the future.
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
I have zero idea if we have IE6 clients any more, but according to the
H5BP community IE6 actually did support gzip and only represents 0.1%
of Internet traffic in 2015 (!) anyways.
See: https://github.com/h5bp/server-configs-nginx/issues/125
You should only use the "shell" module when you need shell functions
like flow control and redirects. Also, the "command" module is safer
because it is not affected by the user's environment.
