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...

Avantages des groupes

Dans un inventaire, les hôtes peuvent appartenir à plusieurs groupes ce qui permet de les catégoriser. (géographiquement, type environnement prod/qual/..., services et/ou fonctionnalités rendus....)

IMPORTANT Rappelez-vous que les hôtes hériteront des variables de tous les groupes auxquels ils appartiennent. Si deux groupes ont des paramètres différents pour la même variable, et qu'un hôte est membre des deux, alors la valeur utilisée est la dernière qui a été chargée. S'il existe des différences entre des paramètres de deux groupes distincts qui peuvent être utilisés simultanément, prenez soin de déterminer la manière dont ces variables doivent être définies.

Penser ré-utilisabilité !

Les rôles permettent de créer des playbooks simples et de réutiliser du code commun à plusieurs projets. Un role doit porter sur un objectif ou une fonction spécifique. Idéalement, il est préférable de créer des rôles génériques configurables par le biais de variables. Ces variables sont le plus souvent définies par défaut dans le fichier YAML roles/[nom_role]/default/main.yml De cette façon, un rôle disposant de son propre paramétrage et ensemble de tâches peut facillement être intégré dans un autre playbook.

Si un playbook doit modifier le contenu d'une variable définie par un rôle, il suffit :

• soit inclure un fichier de définition de variables au niveau du playbook (cf var_files)
• soit définir une zone tasks vars: qui remplace le contenu de cette variable. (cf Ordre de précédence des variables dans un playbook ansible)

Exemple

- hosts: webservers
  vars:
    apache2_config: true
    apache2_default_port: 8000
  roles:
    ansible-apache2

Ce playbook utilise le rôle ansible-apache2 en modifiant 2 variables utilisées par ce rôle : apache2_config & apache2_default_port.

A l'éxécution de ce playbook, le service apache2 sera installé sur les serveurs webservers pour écouter sur le port 8000/tcp.

Exécution centralisée des playbooks

Pour contrôler l'accès aux systèmes et auditer l'activité d'Ansible, il est nécessaire d'envisagez l'utilsiation d'un serveur de contrôle dédié à partir duquel tous les playbooks Ansible sont exécutés. Les administrateurs système doivent toujours disposer de leurs propres comptes sur le système, ainsi que des informations d'identification permettant de se connecter aux hôtes gérés et d'augmenter les privilèges, si nécessaire. Lorsqu'un administrateur système cesse de travailler sur le projet, sa clé SSH peut être supprimée du fichier authorized_keys de l'hôte géré et ses privilèges de commande sudo peuvent être révoqués, sans répercussion sur les autres administrateurs.

Ce serveur central peut avantageusement héberger les services awx ou la version supportée par Red Hat Ansible Tower

Tester régulièrement

Il est bien évident qu'il faut tester les playbooks aussi bien au cours de la phase de développement que pendant l'exécution des playbooks eux-même. En effet, Ansible offre cette possibilité de s'auto-valider en définissant des tâches spécifiques permettant de vérifier une étape précédente d'un playbook.

Test des résultats des tâches

Si on a besoin de confirmer la réussite d'une tâche, vérifiez le résultat de la tâche au lieu de faire confiance au code de retour du module. Il existe plusieurs moyens de valider une tâche, en fonction du module concerné.

Exemple : {{{{contenu}}}}

exemple :

- Start web server
  service:
    name: httpd
    status: started
- name: Check web site from web server
  uri:
    url: http://{{ ansible_fqdn }}
    return_content: yes
  register: example_webpage
  failed_when: example_webpage.status != 200

== Utilisation de block/rescue pour effectuer une récupération ou une restauration ==

La directive block est utile pour regrouper des tâches ; lorsqu'elle est associée à la directive rescue, elle est utile lorsqu'il s'agit d'effectuer une récupération après des erreurs ou des pannes.

Exemple :

- block:
- name: Check web site from web server
uri:
url: http://{{ ansible_fqdn }}
return_content: yes
register: example_webpage
failed_when: example_webpage.status != 200
rescue:
- name: Restart web server
service:
name: httpd
status: restarted