Ansible en production : structurer un dépôt d’exploitation avant de l’exposer dans AWX

AWX ne rend pas un dépôt Ansible propre par magie. Il rend surtout son contenu plus visible, plus facile à lancer et parfois plus facile à mal utiliser. Avant d’exposer des playbooks dans une interface, il faut donc structurer le dépôt comme un outil d’exploitation : périmètres clairs, inventaires séparés, rôles réutilisables, variables compréhensibles et documentation minimale.

Le scénario est simple : une équipe administre un parc Linux avec quelques playbooks déjà présents dans Git. Les exécutions se font encore depuis des postes d’administration. AWX doit centraliser les actions récurrentes, pas devenir le lieu où l’on improvise la structure manquante du dépôt.

Séparer playbooks, rôles et inventaires

Un dépôt exploitable doit permettre de comprendre rapidement ce qui est exécutable, ce qui est réutilisable et ce qui décrit les cibles. Les playbooks exposés dans AWX doivent être peu nombreux et orientés action. Les rôles portent la logique réutilisable. Les inventaires décrivent les environnements et les groupes.

ansible-operations/
playbooks/
  check-linux-baseline.yml
  check-disk-usage.yml
  restart-approved-service.yml
  patch-selected-package.yml
  apply-linux-baseline.yml
roles/
  linux_baseline/
  ssh_hardening/
  package_management/
  monitoring_agent/
inventories/
  preprod/hosts.yml
  production/hosts.yml
group_vars/
  all.yml
  production_web.yml
  production_tools.yml
collections/requirements.yml
README.md

Cette structure n’est pas sophistiquée, mais elle rend la revue possible. Un template AWX pointe vers un playbook identifiable. Le playbook appelle un rôle. L’inventaire limite la cible. Les variables sont versionnées.

Garder les playbooks exposés courts

Un playbook utilisé comme job AWX doit être une entrée contrôlée. Il ne devrait pas contenir toute la logique technique. Il prépare le contexte, vérifie les paramètres et appelle les rôles nécessaires. Cela réduit le risque de duplication et rend le comportement plus facile à relire.

---
- name: Apply Linux baseline
hosts: "{{ target_group }}"
become: true
gather_facts: true
pre_tasks:
  - name: Reject restricted groups
    ansible.builtin.fail:
      msg: "This playbook cannot target restricted hosts"
    when: target_group in ['restricted', 'production_databases']
roles:
  - role: linux_baseline
  - role: monitoring_agent
post_tasks:
  - name: Show kernel and distribution
    ansible.builtin.debug:
      msg: "{{ inventory_hostname }} {{ ansible_distribution }} {{ ansible_distribution_version }} kernel {{ ansible_kernel }}"

Le rôle peut évoluer avec ses tests et ses defaults. Le playbook reste lisible pour l’équipe qui valide le template AWX.

Nommer les inventaires pour empêcher les erreurs

Les inventaires doivent être explicites. Un fichier hosts.yml unique finit souvent par contenir trop de groupes et trop de cas particuliers. Séparer préproduction et production évite déjà une classe d’erreurs. Séparer les groupes sensibles évite qu’un job standard les touche par accident.

all:
children:
  production_web:
    hosts:
      web01.example.local:
      web02.example.local:
  production_tools:
    hosts:
      tools01.example.local:
  production_databases:
    hosts:
      db01.example.local:
  restricted:
    children:
      production_databases:

Dans AWX, un template de maintenance doit pointer vers l’inventaire attendu. Si un inventaire peut être choisi au lancement, il faut avoir une raison forte et une validation côté playbook.

Versionner les collections

Un playbook qui fonctionne aujourd’hui peut changer de comportement après une mise à jour de collection. Pour une exploitation stable, les collections doivent être déclarées et installées de manière prévisible. AWX peut utiliser des execution environments, mais le dépôt doit tout de même dire ce dont il dépend.

---
collections:
- name: ansible.posix
  version: "1.5.4"
- name: community.general
  version: "8.6.0"

La version exacte dépend du contexte, mais l’intention doit être claire : l’exécution AWX ne doit pas dépendre d’un environnement implicite que personne ne sait reconstruire.

Documenter les jobs publiés

Le README ne doit pas être un manuel complet. Il doit surtout décrire les playbooks exposés, leurs effets et leurs limites. C’est ce qui permet à un reviewer de comprendre ce qu’un bouton AWX va réellement faire.

Job : check-disk-usage
Effet : lecture uniquement
Cibles : preprod, production_web, production_tools
Credential : read-only

Job : restart-approved-service
Effet : redémarre nginx, telegraf ou chronyd
Cibles : production_web, production_tools
Credential : maintenance
Validation : service_facts après redémarrage

Job : apply-linux-baseline
Effet : applique les rôles linux_baseline et monitoring_agent
Cibles : préproduction par défaut, production sur changement validé
Credential : restricted-admin

Cette documentation sert aussi de contrat. Si un playbook commence à faire plus que ce qui est écrit, la revue doit le voir.

Prévoir les branches AWX

Le dépôt peut être propre mais dangereux si AWX pointe sur une branche instable. Une pratique simple consiste à exposer la production depuis une branche stable ou un tag, et à réserver les branches de travail aux tests. Le choix exact dépend du workflow Git, mais il doit être volontaire.

main
Revue et intégration des changements validés

production
Branche suivie par les templates AWX production

feature/*
Développement et tests sur projet AWX séparé

Tags
Points de retour possibles pour un changement sensible

AWX doit synchroniser le bon projet au bon moment. Une exécution production ne devrait pas partir d’un commit non relu simplement parce qu’un projet suit une branche trop vivante.

Conclusion

Structurer un dépôt Ansible avant AWX n’est pas une question esthétique. C’est une condition d’exploitation. Les playbooks exposés doivent être courts, les rôles réutilisables, les inventaires explicites, les dépendances versionnées et les effets documentés.

AWX devient alors un exécuteur contrôlé de code versionné. Sans cette base, il devient une interface qui donne une apparence de gouvernance à des automatisations encore trop libres. Le bon ordre reste simple : rendre le dépôt lisible, borner les actions, tester les rôles, puis seulement publier les templates.