AdminSysGNULinux

Outils pour utilisateurs

Outils du site

Piste :
tech:bonnes_pratiques_ansible_-_temp

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
tech:bonnes_pratiques_ansible_-_temp [2025/11/25 12:47] – modification externe 127.0.0.1tech:bonnes_pratiques_ansible_-_temp [2025/12/02 11:47] (Version actuelle) – Jean-Baptiste
Ligne 1: Ligne 1:
 +<!DOCTYPE markdown>
 +{{tag>Brouillon Ansible}}
 +
 +# Bonnes pratiques Ansible - temp
 +
 +Follow Consistent Naming: Use descriptive names for playbooks to indicate their purpose, e.g., deploy_app.yml
 +
 +## Run_once (Pièges)
 +
 +
 +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 !
 +
 +
 +https://github.com/ansible/ansible-lint/issues/1026#issuecomment-685849603
 +
 +Ansible ignores ''run_once'' with the free strategy which means your tasks are run many times, once for each valid inventory host
 +
 +Si ''run_once'', toujours préciser le ''delegate_to'' ou ''when: inventory_hostname == ''
 +
 +Il est aussi possible de faire quelque chose comme :
 +~~~yaml
 +- command: /opt/application/upgrade_db.py
 +  when: inventory_hostname == webservers[0]
 +~~~
 +
 +Les tâches marquées comme ''run_once'' seront exécutées sur un hôte dans chaque série de lot. Si la tâche ne doit s'exécuter qu'une seule fois quel que soit le "serial" mode , utilisez
 +~~~yaml
 +when: inventory_hostname == ansible_play_hosts_all[0] 
 +~~~
 +
 +
 +
 +
 +
 +
 +
 +## Bonnes pratiques AWX
 +
 +
 +* 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.
 +* 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)
 +* Ne pas faire de ''command: ansible-galaxy'' ni de ''shell: ansible-galaxy'', mais utiliser la manière native de AAP / AWX (RA_QUA_N1)
 +
 +
 +
 +
 +
 +## Bonnes pratiques code
 +
 +* Éviter le code spaghetti
 +* Assert sur les cibles (RA_SEC_N2)
 +* Faire les contrôle de plus tôt possible.
 +
 +Exemple :
 +Contrôle avant d'effectuer la connexion : playbook localhost avec gather_facts=false
 +Playbook dédié : ''ansible.builtin.import_playbook: _assert_extra_vars.yml''
 +
 +
 +
 +
 +Timeout après 5s (''async'')
 +~~~yaml
 +---
 +
 +- name: Test
 +  hosts: localhost
 +
 +  tasks:
 +    - name: Sleep
 +      ansible.builtin.command: /bin/sleep 60
 +      async: 10
 +      # poll: 5
 +~~~
 +
 +
 +Voir : https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_checkmode.html#check-mode-dry
 +
 +Éviter ''command: cat''. Préférez :
 +~~~yaml
 +- name: get actual effective params
 +  slurp:
 +    src: /proc/cmdline
 +  become: true
 +  register: all_current_activ_params
 +
 +- name: show effective params
 +  debug:
 +    msg: "{{ all_current_activ_params.content | b64decode }}"
 +~~~
 +
 +
 +
 +## Contrôler que la cible correspond bien
 +
 +Exemple : 
 +* Bonne version OS
 +* Agent pas déjà installé via autre autre procédure...
 +* Espace disque et autres ressources disponibles sur la cible
 +
 +
 +
 +
 +## Portée des variables
 +
 +''DEFAULT_PRIVATE_ROLE_VARS''
 +
 +M(ansible.builtin.include_roles) and M(ansible.builtin.import_roles)
 +C(public)
 +
 +
 +## Import vs include
 +
 +Modules :
 +* ansible.builtin.import_playbook
 +* ansible.builtin.import_role
 +* ansible.builtin.import_tasks
 +* ansible.builtin.include_role
 +* ansible.builtin.include_tasks
 +* ansible.builtin.include_vars
 +
 +~~~
 +You cannot use loops on 'import_tasks' statements. You should use 'include_tasks' instead.
 +~~~
 +
 +
 +
 +
 +## Sécurité
 +
 +Mettre les ''become'' que sur les tâches nécessitant les privilèges, et non sur tous le playbook (RA_SEC_N1)
 +
 +
 +* RBAC CRUD
 +* Logs
 +  * AWX
 +  * Callback
 +    * https://toshio.fedorapeople.org/ansible/latest/plugins/callback.html
 +    * https://docs.ansible.com/ansible/latest/collections/index_callback.html
 +    * community.general.syslog_json
 +
 +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 
 +<https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_12.html>
 +
 +export _ANSIBLE_TEMPLAR_UNTRUSTED_TEMPLATE_BEHAVIOR=fail
 +
 +https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_core_2.19.html#untrusted-templates
 +export ANSIBLE_DISPLAY_TRACEBACK=always
 +
 +
 +## Performance
 +
 +Voir :
 +* https://www.reddit.com/r/ansible/comments/11jc4c0/mitogen_speedup_the_actual_value/
 +* https://prohoster.info/fr/blog/administrirovanie/uskoryaem-ansible-s-pomoshhyu-mitogen
 +* https://docs.redhat.com/fr/documentation/red_hat_ansible_automation_platform/2.6/html-single/performance_tuning_for_ansible_automation_platform/index
 +
 +* Mettre en cache les facts (fact_caching) (mais sur les noeuds, pas en DB) (RA_PERF_N3)
 +* Analyser les temps d’exécution anormalement long ''callback_whitelist = timer, profile_tasks''
 +* Utiliser Mitogen
 +* Garder les tunnels SSH ouverts
 +
 +
 +### Limiter l'usage des ressources
 +
 +~~~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']
 +~~~
 +
 +
 + 
 +## Convention de nommage
 +
 +
 +Convention pour les variables, il doit être possible de distinguer deux types (fonctionnel) de variables : 
 +* Entrées utilisateurs
 +* Variables internes
 +
 +Préférer les variables a plat plutôt que les variables dictionnaires (RA_CONV_OPT)
 +~~~yaml
 +endpoint_url:
 +endpoint_port:
 +~~~
 +
 +plutôt que
 +
 +~~~yaml
 +endpoint:
 +  url:
 +  port:
 +~~~
 +
 +
 +## Boucles
 +
 +De préférence nommer la variable de boucle (''loop_var'') à la place d'utiliser le nom par défaut ''item'' (RA_CONV_OPT)
 +C'est plus lisible, et cela permet un fonctionnement non équivoque en cas de boucles imbriqués.
 +
 +Il est recommandé de définir une convention de nommage pour la variable de boucle. Par exemple d'avoir toujours un suffixe **_item**
 +
 +
 +Utiliser ''label'' dans ''loop_control'' pour rendre l'affichage plus lisible
 +
 +
 +
 +## Fichiers
 +
 +* Devraient être dans <role_name>/files/ (ou dans files/ si appelé directement depuis un playbook ?)
 +
 +
 +
 +## Keep vaulted variables safely visible
 +
 +You should encrypt sensitive or secret variables with Ansible Vault. However, encrypting the variable names as well as the variable values makes it hard to find the source of the values. To circumvent this, you can encrypt the variables individually using ansible-vault encrypt_string, or add the following layer of indirection to keep the names of your variables accessible (by grep, for example) without exposing any secrets:
 +
 +1. Create a group_vars/ subdirectory named after the group.
 +2. Inside this subdirectory, create two files named vars and vault.
 +3. In the vars file, define all of the variables needed, including any sensitive ones.
 +4. Copy all of the sensitive variables over to the vault file and prefix these variables with vault_.
 +5. Adjust the variables in the vars file to point to the matching vault_ variables using jinja2 syntax: db_password: "{{ vault_db_password }}".
 +6. Encrypt the vault file to protect its contents.
 +7. Use the variable name from the vars file in your playbooks.
 +
 +When running a playbook, Ansible finds the variables in the unencrypted file, which pulls the sensitive variable values from the encrypted file. There is no limit to the number of variable and vault files or their names.
 +
 +Note that using this strategy in your inventory still requires all vault passwords to be available (for example for ansible-playbook or AWX/Ansible Tower) when run with that inventory.
 +
 +
 +
 +## Update in batches
 +
 +Use the serial keyword to control how many machines you update at once in the batch.
 +
 +Voir :
 +https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_delegation.html#playbooks-delegation
 +
 +
  
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki