4.3 Règles

Cette page décrit les régèles et normes de développement dans le projet IAC avec Ansible

4.3.1 - Conception générale

Ansible est un outil de préparation/rédaction de “scripts”. Il permet, avec ses modules natifs d’exécuter un très grand nombre d’actes différents sur un ensemble de machines Unix distantes.

Un projet Ansible est constitué : de tâches, de rôles et de playbook. Cette organisation peut être utilisée, fonctionnement, de plusieurs manières et est donc assez maléable.

Le projet ias de la nouvelle PSL s’organise ainsi :

  • une tâche (task) est une geste unitaire (copier un fichier, générer un fichier depuis un template, créer un répertoire)
  • un rôle (role) est un ensemble de tâches
    • un rôle commun est un ensemble mutualisé de tâches permettant de limiter la duplication dans les véritables rôles
    • un véritable rôle mène à un objectif précis comme préparer/installer/déployer/démarrer/statuer/arrêter un applicatif
  • un scénario (playbooks) rassemble tous les rôles ayant un même objectif mais pour tous les applicatifs

Nativement, Ansible permet de limiter l’exécution

  • des rôles à un groupe de machines avec le paramètre --limit xxxxx
  • de tout rôle ou tâche avec un ou plusieurs tag

Sur ce projet, l’usage de tag est limité aux rôles avec le nom d’un applicatif.

4.3.2 - A savoir

  • toutes les variables sont obligatoires et Ansible échoue si une vient à manquer.

4.3.3 - Règles à respecter

Sur la conception :

  • pas de tâche pour mutualiser une unique étape (même complexe et dupliquer plusieurs fois)
  • les tags ne se définissent que sur les rôles et donc dans les playbook
  • chaque applicatif peut être déployé séparément grâce au tags (même si cela nécessite un peu de duplication dans les playbook (cf. 03_deployer)
  • un même playbook exécuté deux fois de suite ne doit déclarer aucun changement (libellé changed) la seconde fois (pas de commande inutile, de redémarrage en trop, …). Cette règle s’applique particulièrement sur l’étape 1.

Sur la rédaction :

  • chaque déclaration de variable pointant sur un répertoire doit se terminer par un ‘/’.
  • un commentaire est obligatoire pour chaque tâche

Sur les tests :

  • toujours rejouer deux fois consécutives un rôle créé/modifié
  • à la fin d’un ensemble de modifications, rejouer absolument tous les rôles :
ansible-playbook ansible/99_detruire.yml -i ansible/inventory/local -K --extra-vars "ansible_user=ubuntu"
ansible-playbook ansible/01_preparer.yml -i ansible/inventory/local -K --extra-vars "ansible_user=ubuntu"
ansible-playbook ansible/02_installer.yml -i ansible/inventory/local
ansible-playbook ansible/03_deployer.yml -i ansible/inventory/local
ansible-playbook ansible/04_demarrer.yml -i ansible/inventory/local
ansible-playbook ansible/05_statuer.yml -i ansible/inventory/local
ansible-playbook ansible/06_arreter.yml -i ansible/inventory/local

4.3.4 - Commandes utiles

Quelques commandes utiles :

  • apt et apt-get :
# pour lister les paquets installés
apt list --installed

# pour supprimer tous les paquets désinstallés et leurs dépendances
sudo apt autoremove
  • réseau :
# pour afficher le nom de la machine
hostname

# pour les configurations réseau
ip a

# pour les ports écoutés et processus associés
sudo lsof -i -P -n
  • ldap :
# lister le contenu du LDAP avec le compte d'administration
ldapsearch -H ldap://localhost:389 -D cn=DirectoryManager -w password
  • logs :
# pour suivre les modifications dans les logs de l'applicatif service-config
tail -f /psl/logs/log_*service-config*
  • Java :
# pour lister les versions de Java installées
ls -al /usr/lib/jvm/
# pour trouver le CACERT par défaut de l'OS
ls /etc/ssl/certs/java/cacerts
# pour extraire la version d'un binaire
lejar="/psl/applicatifs/service-config/service-config.jar"
fichierPom=`unzip -l ${lejar} | grep pom.properties | sed 's/.*META/META/'`
unzip -p ${lejar} $fichierPom | grep version | sed 's/.*=//g'