Tools/Ansible/Best Practices

Accueil	SysAdmin	Hobbies

Ansible - Best Practices

Sites Références

• Ansible ALL modules documentation
• ansible-tutorials-courses

Miser sur la simplicité

Lisibilité

Il est préférable d'utiliser la syntaxe YAML "native". ex :

- name: Postfix is installed and updated
  yum:
    name: postfix
    state: latest
    notify: update_postfix
- name: Postfix is running
  service:
    name: postfix
    state: started

et NON la forme suivante, moins lisible :

- name: Postfix is installed and updated
  yum: name=postfix state=latest
  notify: restart_postfix
- name: Postfix is running
  service: name=postfix state=started

Utilisation des modules

Une fois qu'un playbook fonctionne comme prévu, essayer de le divisez en composants plus petits et logiques à l'aide d'importations et d'inclusions.

Lorsque cela est possible, utiliser des modules à usage spécial fournis avec Ansible, plutôt que les modules command, shell, raw ou autres modules similaires.

Faire preuve d'organisation

nommage des variables

Le nom des variables peut être particulièrement important, car Ansible dispose d'un espace de noms assez plat. Utilisez des variables descriptives telles que apache_tls_port, plutôt qu'une variable moins descriptive comme p.

En ce qui concerne les rôles, il est recommandé de préfixer les variables de rôle avec le nom de rôle. Par exemple, si votre rôle est nommé myapp, vos noms de variables peuvent commencer par myapp_ pour les distinguer en fonction de leur espace de noms des variables figurant dans d'autres rôles et le playbook.

structuration d'un projet

Utiliser un modèle cohérent lors de la création de la structure des fichiers d'un projet Ansible sur un système de fichiers. Il existe un certain nombre de modèles utiles, mais le modèle suivant est un bon exemple :

 .
 ├── dbservers.yml
 ├── inventories/
 │   ├── prod/
 │   │   ├── group_vars/
 │   │   ├── host_vars/
 │   │   └── inventory/
 │   └── stage/
 │       ├── group_vars/
 │       ├── host_vars/
 │       └── inventory/
 ├── roles/
 │   └── std_server/
 │
 ├── site.yml
 ├── storage.yml
 └── webservers.yml

Le fichier site.yml est le playbook maître qui inclut ou importe les playbooks assurant des tâches spécifiques :

• dbservers.yml,
• storage.yml
• webservers.yml.

Les rôles se trouvent dans des sous-répertoires du répertoire roles, tels que std_server. Il existe deux inventaires statiques dans les répertoires inventories/prod et inventories/stage avec des fichiers de variables d'inventaire distincts, de sorte que vous puissiez sélectionner différents ensembles de serveurs en modifiant l'inventaire que vous utilisez. La structure du playbook permet de diviser un grand playbook en fichiers plus petits afin d'en améliorer la lisibilité. De plus, ces sous-playbooks de taille inférieure peuvent contenir des plays destinés à tâches précises de manière indépendante.

Inventaires et avantages des groupes

Inventaires pseudo-dynamiques : module group_by

Il est possible d'utiliser le module group_by pour générer de manière dynamique l'appartenance à un groupe en fonction d'un fait. L'appartenance à un groupe est valide pour le reste du playbook.

exemple:

- name: Generate dynamic groups

 hosts: all
 tasks:

- name: Generate dynamic groups based on architecture

 group_by:
   key: arch_"{{ ansible_facts['architecture'] }}"

- name: Configure x86_64 systems

 hosts: arch_x86_64
 tasks:
 - name: First task for x86_64 configuration
   ...output omitted...

Penser ré-utilisabilité !

Tester régulièrement