Ansible best practices

What?

Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates.

→ docs.ansible.com

Source code type

Two types of Ansible git repositories:

  • Components

    • Plugins
    • Playbooks
    • Roles

  • Static inventories

    • Host
    • Variables

Source code sharing

Ansible component repositories can be used from another repository as Ansible collections (preferred) or git submodules.

Source code granularity

🔴 1 repository for all roles

✅ 1 repository for all the roles of the same perimeter

🔴 1 repository for 1 role

Git repository structure

├─ playbooks
├─ plugins
└─ roles
.ansible-lint
.editorconfig
.galaxy.yml
LICENCE
README.md

Ansible role folder

└─ roles
   └─ <myrolename>
      ├─ handlers
      │  └─ main.yml
      └─ tasks
         ├─ main.yml
         └─ <mysubtask>.yml

Work on branch

🔴 Commit on main only

✅ Create a feature branch and submit a Pull|Merge Request

🔴 Create my branch and commit on it only

Continuous integration pipeline (CI)

  • CI badge must be present at the top of the README.md file

  • CI must run on every commit of main branch

  • CI must run on every commit of a Pull|Merge Request

  • CI must block the completion of a Pull|Merge Request if there is an error

Ansible lint

ansible-lint MUST be ran in the CI pipeline

# installs ansible-lint
pip install "ansible-lint[yamllint]"

# validates the source code
ansible-lint

Ansible inventories

Inventories can be:

  • Dynamic (preferred)

    • HTTP call
    • Cloud providers

  • Static

    • Git repository
    • Shared folder

💡 yaani can be used to merge multiple sources

Readability

  • Name all the things explicitly: plays, tasks, variables
  • Use native YAML: avoid key=value shorthand
  • Prefer modules over commands
  • Clean up debug messages

References

Samples

Bye for now

You can go back to the presentation home page