Ansible : typo, syntax…
This commit is contained in:
parent
821b738a25
commit
da03cf427b
|
|
@ -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'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
|
|||
|
||||
<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…
Reference in New Issue