diff --git a/HowtoAnsible.md b/HowtoAnsible.md index bc600c1b..74cbf59e 100644 --- a/HowtoAnsible.md +++ b/HowtoAnsible.md @@ -52,7 +52,7 @@ Exemples d'utilisation basique : ~~~ $ ansible localhost -m ping localhost | SUCCESS => { - "changed": false, + "changed": false, "ping": "pong" } @@ -135,7 +135,7 @@ Voici quelques exemples de modules que nous utilisons : regexp: "^IS_APTICRON=" ~~~ -*Note:* _replace_ vs _lineinfile_ ? Le fonctionnement exacte de _replace_ et de _lineinfile_ peut être déroutant. Voici quelques constatations : +*Note:* _replace_ vs _lineinfile_ ? Le fonctionnement exact de _replace_ et de _lineinfile_ peut être déroutant. Voici quelques constatations : * avec _lineinfile_, si l'argument _regexp_ n'est pas matché… il insère quand même la ligne ! _regexp_ n'est pas une condition pour l'insertion mais pour remplacer au lieu d'insérer ! * avec _lineinfile_, sauf cas tordus, l'argument _regexp_ doit matcher l'argument _line_ (sinon il va insérer la valeur de _line_ à chaque exécution !) @@ -194,9 +194,9 @@ Voici quelques exemples de modules que nous utilisons : state: latest update_cache: yes cache_valid_time: 3600 - with_items: - - vim - - htop + with_items: + - vim + - htop ~~~ * Module [apt_repository](http://docs.ansible.com/ansible/apt_repository_module.html) : @@ -257,13 +257,13 @@ Pour avoir plus d'infos sur un module : (…) ~~~ -> *Note* : c'est pratique pour avoir la documentation exacte pour votre version d'Ansible. En effet, celle du site corespond à la dernière version et n'indique pas toujours toutes les différences. +> *Note* : c'est pratique pour avoir la documentation exacte pour votre version d'Ansible. En effet, celle du site correspond à la dernière version et n'indique pas toujours toutes les différences. ### playbook -Un playbook va ensuite dérouler des _actions_ qui seront organisées en _tasks_, [roles](#roles) et [handlers](#handlers). +Un playbook va ensuite dérouler des actions qui seront organisées en _tasks_, [roles](#roles) et [handlers](#handlers). Exemple de playbook simple : @@ -320,7 +320,7 @@ On lance des playbooks ainsi : ~~~ $ ansible-playbook PLAYBOOK.yml --limit HOSTNAME --forks 1 -$ ansible-playbook PLAYBOOK_WITH-SUDO.yml --limit HOSTNAME --ask-become-pass +$ ansible-playbook PLAYBOOK_WITH_SUDO.yml --limit HOSTNAME --ask-become-pass ~~~ Options utiles pour [ansible-playbook](https://manpages.debian.org/cgi-bin/man.cgi?query=ansible-playbook&apropos=0&sektion=0&manpath=Debian+unstable+sid&format=html&locale=en) : @@ -333,7 +333,7 @@ Options utiles pour [ansible-playbook](https://manpages.debian.org/cgi-bin/man.c #### Limiter l'exécution à certaines machines -Quelques exemples d'utilisation de l'option `--limit` (ou l`) : +Quelques exemples d'utilisation de l'option `--limit` (ou `l`) : * limiter aux groupes _www_ et _sql_ (qui peuvent être indifféremment des groupes ou des serveurs) : @@ -390,6 +390,8 @@ Dans des rôles longs, nous conseillons de purger les handlers de temps en temps - meta: flush_handlers ~~~ +NB : n'importe quel module peut être utilisé comme handler. + ### roles @@ -416,6 +418,8 @@ foo └── main.yml ~~~ +Cette sutructure permet à Ansible de retrouver automatiquement les fichiers et de les rendre disponibles dans l'exécution du rôle. + À titre d'exemple, voici des rôles Ansible que nous utilisons : ### inventory @@ -424,7 +428,7 @@ foo La partie **inventory** correspond à la description de l'inventaire des serveurs à configurer et inclus un mécanisme de configuration individuelle et par groupe. -Permet d'indiquer la liste des machines concernées par Ansible (peut être limité lors de l'exécution de la commande par l'option `-l`) et de pouvoir les regrouper dans des groupes. +Il permet d'indiquer la liste des machines concernées par Ansible (peut être limité lors de l'exécution de la commande par l'option `-l`) et de pouvoir les ranger dans des groupes. Exemple: @@ -502,16 +506,17 @@ Les variables peuvent être définies à de multiples niveaux, chacun ayant une * task vars (only for the task) * extra vars (always win precedence) -Pour gérer de nombreuses variables dans un projet, on peut stocker toutes celles qui correspondent à un groupe de serveur dans un fichier portant le nom du groupe, ainsi que toutes celle d'un serveur en particulier dans un fichier du nom du serveur. Voici l'arborescence conseillée : +Pour gérer de nombreuses variables dans un projet, on peut stocker toutes celles qui correspondent à un groupe de serveur dans un fichier portant le nom du groupe, ainsi que toutes celles d'un serveur en particulier dans un fichier du nom du serveur. Voici l'arborescence conseillée : ~~~ └── inventory -    ├── group_vars - │   └── group1.yml - │   └── group2.yml -   └── host_vars -    └── hostname1.yml -    └── hostname2.yml +    ├── hosts # fichier d'inventaire +    ├── group_vars # dossier regrouppant … + │   └── group1.yml # … les variables du groupe "group1" + │   └── group2.yml # … les variables du groupe "group2" +   └── host_vars # dossier regrouppant … +    └── hostname1.yml # … les variables du serveur "hostname1" +    └── hostname2.yml # … les variables du serveur "hostname2" ~~~ Les groupes sont définis dans le fichier d'[inventaire](http://docs.ansible.com/ansible/intro_inventory.html). @@ -535,7 +540,7 @@ On peut également utiliser les tags pour limiter/exclure des tâches : $ ansible-playbook (…) --skip-tags "message" ~~~ -On peut aussi n'éxecuter que certains tags : +On peut aussi n'exécuter que certains tags : ~~~ $ ansible-playbook (…) --tags "configuration,packages" @@ -545,8 +550,8 @@ $ ansible-playbook (…) --tags "configuration,packages" ### Register -`register` est un attribut d'action que l'on peut rajouter pour tout type de tâche et qui initialisera la variable (par le nom donné) avec les valeurs retour du module. -Pour `shell`, on a le droit à `.stdout`, `.stderr`, `.rc`… Mais cela dépend bien des valeurs de retour du module. +`register` est un attribut d'action que l'on peut rajouter pour tout type de tâche et qui initialisera la variable (par le nom donné) avec les valeurs retournées par le module. +Pour `shell`, on a le droit à `.stdout`, `.stderr`, `.rc`… mais cela dépend des valeurs de retour du module. Il est possible de consulter le contenu détaillé de la variable avec `debug` : @@ -786,7 +791,7 @@ C'est beaucoup plus simple et rapide que de tester le fichier par le module `sta -~~~ +~~~{.yaml} - name: /etc/hosts command: cat /etc/hosts register: tmp @@ -802,7 +807,7 @@ Pour une exécution locale, on peut aussi utiliser l'attribut `local_action`. -~~~ +~~~{.yaml} - name: Début installation, envoie email run_once: true (…) @@ -831,15 +836,15 @@ Par exemple pour l'installation de plusieurs nouveaux paquets : - hosts: localhost tasks: - - apt: + - apt: name: '{{ item }}' state: present - with_items: - - cmatrix - - tetrinet-server - - tetrinet-client - - xtel - - xtell + with_items: + - cmatrix + - tetrinet-server + - tetrinet-client + - xtel + - xtell ~~~ Même si il y aura plusieurs paquets installés, cela ne comptera que pour *un* changement (`changed=1`). @@ -849,7 +854,7 @@ Cette tâche appellera un par un les éléments de la liste (présents dans `wit Pour croiser les éléments des items : -~~~ +~~~{.yaml} tasks: - include: "./ajout_utilisateur_sur_machine.yml" vars: @@ -866,7 +871,7 @@ Cela a pour effet d'exécuter l'inclusion pour `alice` pour chacune des 3 machin Avec hash : -~~~ +~~~{.yaml} users: bob: name: Bob @@ -924,14 +929,14 @@ Pour des modules comme `shell`, `command`… Ansible ne peut savoir si un change Il est possible de forcer le statut du changement : -~~~ +~~~{.yaml} - command: date changed_when: False ~~~ Ou donner une condition -~~~ +~~~{.yaml} - shell: cat > {{ fichier }} < /dev/null changed_when: {{ fichier.stats.exist }} ~~~