
Ansible 101 by Jeff Geerling – new series on YouTube - geerlingguy
https://www.jeffgeerling.com/blog/2020/ansible-101-jeff-geerling-new-series-on-youtube
======
geerlingguy
In addition to announcing this new streaming series (hope it's helpful if you
don't know Ansible yet!), I wanted to also remind anyone who hasn't taken me
up on the offer yet: Ansible for DevOps[1] and Ansible for Kubernetes[2] are
available free on LeanPub the rest of this month!

[1] [https://www.ansiblefordevops.com](https://www.ansiblefordevops.com)

[2]
[https://www.ansibleforkubernetes.com](https://www.ansibleforkubernetes.com)

~~~
YPCrumble
Thank you for your incredible contributions to Ansible. I help maintain an
Ansible script for Django applications ([https://github.com/jcalazan/ansible-
django-stack](https://github.com/jcalazan/ansible-django-stack)) and your blog
and repos have been invaluable. Your blog posts on testing using Molecule,
your htpasswd role, and so many others have come in handy.

I'll add these links and your YouTube channel to our README now :).

------
BiteCode_dev
I'm hopping someday people will provide a friendly Python API on top of
ansible so that I don't have to write its YAML DSL anymore.

The "it must be idempotent" argument lead to putting conditional into a a
language that was never meant to be, doing the whole "store" danse that could
be done with simple function calls and whole lot of conventions instead of a
proof tested import system.

It's calling python code behind the scene anyway, and nothing reads the
playbook apart from ansible itself.

Ansible is a great tool, but I strongly believe the experience would be 100%
better without learning, crafting and debugging those twisted .yml.

~~~
jerrya
What I find interesting & frustrating with ansible is that it is idempotent,
but not everything is reversible (or is it? I am a noob with ansible.)

So how do people test their ansible playbooks if they can't easily reverse
their state?

~~~
notabee
Ansible seems to be better at declaring a particular configuration at build
time, which should be repeatable and tested, and then perhaps running limited
updates in a more controlled fashion later. The destination hosts should be
disposable and recreated for any significant changes. If you write playbooks
to change existing state frequently you have to be very careful to write in
tasks that check the previous state. If you can version the roles and
playbooks carefully then you can have some idea of the systems' state. For
simple idempotency, like changing an app's config template and restarting a
daemon, the modules have you covered, but for more complex dependencies
between services it can get hairy. Some unpredictable things can happen.
Example story: systemd-tmpfiles on CentOS 7 has a poorly documented behavior
of skipping files in /tmp or /var/tmp that are both root-owned and read-only.
It's not something in the options or config, just a default behavior (that was
removed in later versions). We had a playbook that would clone a git repo into
/var/tmp and then copy the required files into their appropriate place. The
git module worked fine to update the repo each run, until several weeks passed
and systemd-tmpfiles blew away most, but not all, of the repo files. Some
files with just read permission remained. The module could handle either all
the repo files existing or having the repo disappear just fine, but not a
partially deleted repo. It would error out on that task. So now there's a new
dependency on a changed systemd-tmpfiles config to skip that directory, and
the partially deleted mess must be deleted for a run to work on existing hosts
with the old config. There's lots of stuff like that that can accrue.

