How can you avoid common mistakes when working with Ansible?

Using linter is great to sync the format of yaml code base. It is kinda required in today's world where engineers come and go in projects. I do want to emphasize that using ansible linters and their recommendations are much since engineers will likely learn from public available information instead of specific companies creating their own standards.

Let’s make Playbooks and Tasks Idempotent The other error to be cautious of is that tasks and playbooks will be allowed to be impotent. The playbooks and tasks also use idempotent functionality to avoid unintended errors and changes by enabling them to run multiple times without causing any new errors. It is of the utmost importance for safety and desired outcome to ensure that the effect is completely and equally distributed throughout the body. But schedule regular and reiterate playbooks or roles since it’s not defensive. A means of testing the scripting or the role is to run it before the final development process such as running the playbook or the role repeatedly.

What i would recommend is that integrate ansible-lint with your code editor or integrated development environment (IDE) for real-time feedback as you write Ansible code. Popular editors like Visual Studio Code (VS Code) offer extensions that support ansible-lint integration, highlighting issues directly in the editor as you type. Further, i would recommend to incorporate ansible-lint into your continuous integration (CI) or continuous delivery (CD) pipeline. This ensures that linting checks are automatically performed whenever changes are made to Ansible code. Popular CI/CD platforms like Jenkins, GitLab CI, and GitHub Actions support ansible-lint integration.

Variables in Ansible are amazing but they become complex to understand as well. For example, in Ansible there is approx. 22 ways of defining variables so it easily becomes annoying and complex to understand how. Last, please use prefixes for the variables when using variables like role name: redis then all its variables must start with redis_xxx so that when engineers see these variables they can understand where these variables are being used.

I have seen that Ansible modules have exploded in number from the very beginning of Ansible. Here is my rule for modules with decreasing precedence 1. Use ansible.builtin modules. 2. Use community.xxx modules (maintained by Ansible). 3. If you know Python then create custom modules. 4. Use shell modules. Last thing if you need to support a wide variety of configurations then please use Python virtual environments so that module dependencies don't affect others.

1. Most people will use a couple of roles and one monolith playbook to do all of the things. (Kinda Worse Way) 2. Do the same previously but this time, put 10s of tags with no documentation to control what part of the monolith playbook should run. ( Again worse ) 3. What do I like to do in my projects? (somewhat less worse) * Be explicit about everything * Be consistent with writing if you want to use tags then use tags don't use variables to control the flow of execution. * Write documentation about all common use cases of the playbooks * Create several playbooks like ** One to start from scratch ** One to allow updates of specific components in the chain of events. ** One to perform common/day-to-day changes

What i have seen is that failing to test playbooks thoroughly before deploying them to production can lead to unforeseen issues and downtime. Use Ansible's testing frameworks such as molecule or ansible-lint to validate playbooks, roles, and modules. Automated testing helps catch errors early in the development process. I would strongly recommend to test the playbooks.

In the end i would like to add that ansible manages infrastructure configurations and can potentially access sensitive information. So, i would recommend that observe all important security practices such as securing credentials, restricting access to ansible control nodes, and auditing ansible activities to prevent security breaches. Security can not be introduced later, introduce it in the scheme as early as possible.