Différences

Ci-dessous, les différences entre deux révisions de la page.

--- tech:bonnes_pratiques_ansible [2025/11/03 13:53] – Jean-Baptiste
+++ tech:bonnes_pratiques_ansible [2025/11/20 16:27] (Version actuelle) – Jean-Baptiste
@@ Ligne 74: / Ligne 74: @@
 Éviter d'utiliser les **M(script)** et **M(command)** \\
 Privilégier **M(command)** à **M(shell)** \\
-Si variables Jinja en argument à M(command) ou M(shell) : utiliser ''quote'' pour échapper les caractères spéciaux.
+Si variables Jinja en argument à M(shell) : utiliser ''quote'' pour échapper les caractères spéciaux.
 Pour **M(command)**, **M(shell)**, **M(script)**, contrôler le code de retour avec
 * ''register''
@@ Ligne 193: / Ligne 193: @@
 ==== Run_once
+run_once will be executed at each serial execution in the play. That means, if you choose serial = 1, it will be asked to confirm as many times as the quantity of targets on the play.
+Check Ansible docs: https://docs.ansible.com/ansible/latest/user_guide/playbooks_strategies.html#running-on-a-single-machine-with-run-once
 When used together with serial, tasks marked as run_once will be run on one host in each serial batch. If the task must run only once regardless of serial mode, use ''when: inventory_hostname == ansible_play_hosts_all[0]'' construct.
 Attention aux slicing !
+=== Limiter l'usage des ressources
+<code yaml>
+- name: Installation d'un logiciel sur plusieurs serveurs avec throttle
+  ansible.builtin.apt:
+    name: nginx
+    state: present
+  async: 600  # Exécution en mode asynchrone avec un délai maximum de 10 minutes
+  poll: 5     # Vérification toutes les 5 secondes
+  throttle: 3  # Limite à 3 installations simultanées
+  when: inventory_hostname in groups['webservers']
+</code>
@@ Ligne 214: / Ligne 236: @@
 Variable Management for Inventory - Keeping variable data along with the hosts and groups definitions (see the inventory editor) is encouraged, rather than using group_vars/ and host_vars/
-Autoscaling - Using the “callback” feature to allow newly booting instances to request configuration is very useful for auto-scaling scenarios or provisioning integration.
+Autoscaling - Using the “callback” feature to allow newly booting instances to request configuration is very useful for auto-scaling scenarios or provisioning integration.$
 Larger Host Counts - Consider setting “forks” on a job template to larger values to increase parallelism of execution runs. Voir : Strategy, Mitogen, Slicing, Async (Asynchronous) (RA_PERF_N3)
@@ Ligne 220: / Ligne 242: @@
 Ne pas utiliser Verbosity à 4 ou 5. Eviter d'augmenter la verbosité si l'inventaire est conséquent
-Ne pas mettre les facts des noeuds dans la base de données - Ne pas activer "Enable Fact Storage"
+Ne pas mettre les facts des nœuds dans la base de données - Ne pas activer "Enable Fact Storage"
 Le cache des facts doit être sur les managed_hosts et non coté serveur (RA_GEN_N1)
+Ne pas faire de ''command: ansible-galaxy'' ni de ''shell: ansible-galaxy'', mais utiliser la manière native de AAP / AWX (RA_QUA_N1)
@@ Ligne 424: / Ligne 450: @@
 Utiliser ''no_log: true'' pour les taches utilisant des secrets (RA_SEC_N1)
+Pour les données sensibles utiliser ansible-vault ou les Crendential AWX (RA_SEC_N1)
 Troubleshooting untrusted templates
@@ Ligne 513: / Ligne 541: @@
 Source : https://ansible.readthedocs.io/projects/lint/rules/var-naming/
-=== Files
-Si beaucoup de templates dans le role : utiliser une arborescence du style :
-* files/etc/nginx/sites-available/plop
 === Extra_vars