Tools/Ansible/Best Practices - Historique des versions

Admin : /* Variables d'inventaire spéciales */

2020-05-11T14:37:41Z

Variables d'inventaire spéciales

Admin : /* Penser ré-utilisabilité ! */

2020-05-11T14:27:24Z

Penser ré-utilisabilité !

Admin : /* Séparation des variables de l'inventaire */

2020-05-11T14:18:49Z

Séparation des variables de l'inventaire

Admin : /* Séparation des variables de l'inventaire */

2020-05-11T14:14:58Z

Séparation des variables de l'inventaire

Admin : /* Penser ré-utilisabilité ! */

2020-05-11T14:12:21Z

Penser ré-utilisabilité !

Admin : /* Outils de test */

2020-05-11T09:35:11Z

Outils de test

Admin : /* Test des résultats des tâches */

2020-05-11T09:33:15Z

Test des résultats des tâches

Admin : /* Test des résultats des tâches */

2020-05-11T09:28:03Z

Test des résultats des tâches

Admin : /* Test des résultats des tâches */

2020-05-11T09:22:19Z

Test des résultats des tâches

Admin : /* Tester régulièrement */

2020-05-11T09:18:02Z

Tester régulièrement

@@ Ligne 224 : / Ligne 224 : @@
 |{{CODE|ansible_python_interpreter}}
 |Chemin d'accès à l'exécutable Python qu'Ansible doit utiliser sur l'hôte géré. Sur Ansible 2.8 et versions ultérieures, cette valeur par défaut est {{CODE|auto}}, qui sélectionne automatiquement un interpréteur Python sur l'hôte exécutant le playbook en fonction du système d'exploitation qu'il exécute. Ainsi, il n'est plus autant nécessaire d'utiliser ce paramètre que dans les versions antérieures d'Ansible.
 |}

@@ Ligne 195 : / Ligne 195 : @@
 Cette structure d'organisation pour un projet vous permet de voir rapidement les types de variables définis pour chaque groupe d'hôtes.
 Toutes les variables présentes dans des fichiers figurant dans des répertoires situés sous le répertoire group_vars sont fusionnées avec le reste des variables. La séparation de variables en fichiers regroupés par fonctionnalité rend  l'ensemble du projet de playbook plus facile à comprendre et à gérer.
 == Penser ré-utilisabilité ! ==

← Version précédente		Version du 11 mai 2020 à 14:18
Ligne 145 :		Ligne 145 :

	Mais à mesure que les playbooks gagnent en complexité, la taille de ces fichiers augmentent et ils peuvent devenir difficiles à comprendre.		Mais à mesure que les playbooks gagnent en complexité, la taille de ces fichiers augmentent et ils peuvent devenir difficiles à comprendre.
		+
		+	Une approche encore meilleure pour les environnements importants et diversifiés consiste à créer des sous-répertoires pour chaque groupe d'hôtes sous le répertoire group_vars.
		+
		+	Ansible analyse n'importe quel YAML dans ces sous-répertoires et associe les variables à un groupe d'hôtes basé sur le répertoire parent :
		+
		+	<syntaxhighlight lang="bash">
		+	[user@demo project2]$ tree -F group_vars
		+	group_vars/
		+	├── db_servers/
		+	│ ├── 3.yml
		+	│ ├── a.yml
		+	│ └── myvars.yml
		+	├── lb_servers/
		+	│ ├── 2.yml
		+	│ ├── b.yml
		+	│ └── something.yml
		+	└── web_servers/
		+	└── nothing.yml
		+	</syntaxhighlight>
		+
		+	Dans l'exemple précédent, les variables du fichier {{CODE\|myvars.yml}} sont associées au groupe d'hôtes '''db_servers''', car le fichier est contenu dans le sous-répertoire {{CODE\|group_vars/db_servers}}.
		+
		+	Cependant, les noms de fichiers de cet exemple ne permettent pas de savoir facilement où trouver une variable particulière.
		+
		+	Si vous choisissez d'utiliser cette structure d'organisation pour les variables, regroupez celles-ci selon un thème commun dans le même fichier et utilisez un nom de fichier pour indiquer ce thème commun.
		+
		+	Lorsqu'un playbook utilise des rôles, une convention courante consiste à créer des fichiers de variables nommés selon chaque rôle du playbook.
		+
		+	Un projet respectant cette convention peut ressembler à ceci :
		+	<syntaxhighlight lang="bash">
		+	[user@demo project3]$ tree -F group_vars
		+	group_vars/
		+	├── all/
		+	│ └── common.yml
		+	├── db_servers/
		+	│ ├── mysql.yml
		+	│ └── firewall.yml
		+	├── lb_servers/
		+	│ ├── firewall.yml
		+	│ ├── haproxy.yml
		+	│ └── ssl.yml
		+	└── web_servers/
		+	├── firewall.yml
		+	├── webapp.yml
		+	└── apache.yml
		+	</syntaxhighlight>
		+
		+
		+	Cette structure d'organisation pour un projet vous permet de voir rapidement les types de variables définis pour chaque groupe d'hôtes.
		+	Toutes les variables présentes dans des fichiers figurant dans des répertoires situés sous le répertoire group_vars sont fusionnées avec le reste des variables. La séparation de variables en fichiers regroupés par fonctionnalité rend l'ensemble du projet de playbook plus facile à comprendre et à gérer.

	== Penser ré-utilisabilité ! ==		== Penser ré-utilisabilité ! ==

@@ Ligne 125 : / Ligne 125 : @@
 Les sources d'inventaire définissent les hôtes et les groupes d'hôtes utilisés par Ansible, qu'il s'agisse de fichiers statiques ou d'un script d'inventaire dynamique. Si vous gérez votre inventaire en tant que fichiers statiques, vous pouvez définir des variables dans le ou les fichiers d'inventaire, dans les mêmes fichiers qui vous servent à définir vos listes d'hôtes et de groupes d'hôtes.
 Cependant, il ne s'agit pas de la meilleure pratique. À mesure que votre environnement augmente en taille et en diversité, le fichier d'inventaire devient volumineux et difficile à lire.
 De plus, vous souhaiterez probablement migrer vers des sources d'inventaire dynamique plutôt que des fichiers d'inventaire statique afin de faciliter la gestion de votre inventaire. Toutefois,vous souhaiterez peut-être continuer à gérer de façon statique des variables d'inventaire, indépendamment de la sortie du script d'inventaire dynamique ou en plus de celle-ci.
 Une meilleure approche consiste à déplacer les définitions de variables du fichier d'inventaire vers des fichiers de variables distincts, un pour chaque groupe d'hôtes. Chaque fichier de variable est nommé d'après un groupe d'hôtes et contient des définitions de variables pour le groupe d'hôtes :
-{{CODE|
+<syntaxhighlight lang="bash">
 [user@demo project]$ ''tree -F group_vars''
 group_vars/
@@ Ligne 135 : / Ligne 138 : @@
 ├── lb_servers.yml
 └── web_servers.yml
-}}
+</syntaxhighlight>
 == Penser ré-utilisabilité ! ==

@@ Ligne 121 : / Ligne 121 : @@
 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é ! ==
@@ Ligne 148 : / Ligne 164 : @@
 A l'éxécution de ce playbook, le service apache2 sera installé sur les serveurs <code>webservers</code> pour écouter sur le port 8000/tcp.
 == Exécution centralisée des playbooks ==

@@ Ligne 217 : / Ligne 217 : @@
 |contenu=
 Cette vérification ne garantit pas une précision parfaite, étant donné que le playbook peut avoir besoin d'exécuter réellement certaines tâches avant que les tâches ultérieures du playbook ne fonctionnent correctement. Certaines tâches peuvent être marquées avec la directive check_mode: no. Ces tâches s'exécutent même en mode vérification.
 }}

@@ Ligne 184 : / Ligne 184 : @@
-== Utilisation de block/rescue pour effectuer une récupération
+== Utilisation de block/rescue pour effectuer une récupération ou une restauration  ==
 La directive <code>block</code> est utile pour regrouper des tâches ; lorsqu'elle est associée à la directive
@@ Ligne 207 : / Ligne 206 : @@
          status: restarted
 </syntaxhighlight>

@@ Ligne 168 : / Ligne 168 : @@
-{{EXAMPLE
+Exemple :
 <syntaxhighlight lang="yaml">
@@ Ligne 210 : / Ligne 195 : @@
 <syntaxhighlight lang="yaml">
 - block:
-- name: Check web site from web server
+  - name: Check web site from web server
-uri:
+    uri:
-url: http://{{ ansible_fqdn }}
+      url: http://{{ ansible_fqdn }}
-return_content: yes
+      return_content: yes
-register: example_webpage
+    register: example_webpage
-failed_when: example_webpage.status != 200
+    failed_when: example_webpage.status != 200
-rescue:
+  rescue:
-- name: Restart web server
+    - name: Restart web server
-service:
+      service:
-name: httpd
+        name: httpd
-status: restarted
+        status: restarted
 </syntaxhighlight>

@@ Ligne 166 : / Ligne 166 : @@
 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 :