Bearbeiten von „KIF490:Einführung in Ansible (einfach wartbare, reproduzierbare Systemkonfigurationen)“

The [https://docs.ansible.com/ansible/latest/collections/ansible/builtin/stat_module.html <code>stat</code> module] never changes anything. It just retrieves status information about a file. But by registering the result of the task to a variable, we can use it for other parts of our playbook.

Be careful though, '''if you find yourself programming in a playbook, you're doing something wrong.''' Mostly you're either over-engineering/procrastinating on other problems or you really need a module that does that complicated stuff instead.

</div><hr>

There's not always a module for everything. Sometimes the usecase is too obscure, sometimes there is no meaningful way to ensure Ansible principles like idempotence.<ref>not changing stuff if the desired state is already met</ref><br>

The above example is trying to build minetest for maximum control over the installed version. After resetting the git repository to the desired version, the binary is built. For this, we use the [https://docs.ansible.com/ansible/latest/collections/ansible/builtin/command_module.html <code>command</code> module] – but it has no idea whether the desired state is already met or whether the command has to be run again. We manually tell it to skip this task if the repository did not change in the previous task.

There is a minor gotcha with this: Assume you abort the playbook while its running the build task because you forgot to do something else. If you run it again, the git update will be skipped, as it is already in its desired state. But now the build task will not be run again. If you have this in your playbooks, you need to be aware of this edge case.<br>

This is another reason why logical links in playbooks should be kept to a minimum.

There is also the <code>shell</code> module that feels very similar. But in contrast to <code>command</code>, it runs the specified command in a shell. This opens up the use of shell features like piping, but comes at an increased security risk, especially if building the command from variables.<br>

Using <code>shell</code> is ''not'' recommended.

It is common practice to store important variables alongside playbooks and roles in even public repositories by encryping them with [https://docs.ansible.com/ansible/latest/cli/ansible-vault.html Ansible Vault].

These are production secrets, but never management access to the target machines. Jump hosts are one popular solution to grant access to many machines to various actors: Only this host stores the admins pubkeys, while the target machines only have the key from jump host.

</div>