Browse Source

Ansible : typo, syntax…

master
Jérémy Lecour 4 years ago
committed by Jérémy Lecour
parent
commit
da03cf427b
1 changed files with 38 additions and 33 deletions
  1. +38
    -33
      HowtoAnsible.md

+ 38
- 33
HowtoAnsible.md View File

@ -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
<http://docs.ansible.com/ansible/playbooks.html>
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
<http://docs.ansible.com/ansible/playbooks_roles.html>
@ -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 : <https://forge.evolix.org/projects/ansible-roles/repository?rev=unstable>
### 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'ecuter 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
<https://docs.ansible.com/ansible/playbooks_delegation.html#delegation>
~~~
~~~{.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`.
<https://docs.ansible.com/ansible/playbooks_delegation.html#run-once>
~~~
~~~{.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 }}
~~~


Loading…
Cancel
Save