Resources attached to the Road To DevOps tutorial
https://blog.noobtoroot.xyz/road-to-devops/
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
86 lines
2.5 KiB
86 lines
2.5 KiB
2 years ago
|
<!-- .slide: data-state="nologo-slide" style="text-align: center" -->
|
||
|
![Logo Ansible](images/logo-ansible.svg)
|
||
|
# Bonnes pratiques
|
||
|
|
||
|
|
||
|
## Rester simple !
|
||
|
|
||
|
|
||
|
## Rester clair !
|
||
|
|
||
|
- Apporter tout le soin nécessaire à la lisibilité du code Ansible.
|
||
|
|
||
|
- Nommer toujours vos Plays et Tasks de manière précise et significative.
|
||
|
|
||
|
- Privilégiez la syntaxe YAML native.
|
||
|
<small>(Pas de : `name=httpd state=started enabled=yes`)</small>
|
||
|
|
||
|
- Ainsi fait, le code Ansible peut devenir la documentation de référence de votre workflow.
|
||
|
|
||
|
|
||
|
## Penser "déclaratif"
|
||
|
|
||
|
- Ansible permet de décrire un _état désiré_.
|
||
|
|
||
|
- Si vous essayez d'écrire du code dans vos playbooks et rôles, vous augmentez le risque d'échec.
|
||
|
|
||
|
- Utilisez prioritairement les Modules Ansible chaque fois que c'est possible.
|
||
|
|
||
|
|
||
|
## Utiliser les Roles
|
||
|
|
||
|
- Utilisez les Roles !
|
||
|
|
||
|
- Ils permettent un très bon découpage du code Ansible.
|
||
|
|
||
|
- Ils permettent de gérer des variables par défaut pour les composants.
|
||
|
|
||
|
|
||
|
## Attention aux variables !
|
||
|
|
||
|
- Ansible permet de déclarer des variables dans une grande variété d'emplacements. Il devient facile de s'y perdre !
|
||
|
|
||
|
- Évitez de trop disperser les déclarations de variables dans le code Ansible.
|
||
|
|
||
|
- Limitez les déclarations de variables à deux ou trois emplacements clés :
|
||
|
|
||
|
1. variables de groupes
|
||
|
2. variables de rôles
|
||
|
|
||
|
- Documenter précisément les variables que vous déclarez dans votre code Ansible.
|
||
|
|
||
|
|
||
|
## Eviter autant que possible les Modules "Commands"
|
||
|
|
||
|
- Les modules de commandes génériques tels que `shell` ou `command` peuvent conduire à certains dysfonctionnements. En effet les commandes Shell :
|
||
|
|
||
|
- ne sont pas toujours idempotentes.
|
||
|
|
||
|
- s'exécuteront toujours et retourneront l'état `changed` (à moins de spécifier `changed_when`).
|
||
|
|
||
|
- Les modules plus spécifiques sont souvent prévus pour être agnostique du système d'exploitation, ce qui permet d'augmenter la ré-utilisabilité du code.
|
||
|
|
||
|
|
||
|
## Eviter le module "lineinfile"
|
||
|
|
||
|
- Utiliser les modules `copy` ou `template` plutôt que `lineinfile` ou `replace`
|
||
|
|
||
|
- Pas besoin de connaître la syntaxe `regex`.
|
||
|
|
||
|
- Permet de contrôler exactement le contenu du fichier final.
|
||
|
|
||
|
|
||
|
## Créer des fichiers d’inventaires séparés
|
||
|
|
||
|
- Si vous devez gérer plusieurs environnements, créez des fichiers d'inventaires séparés afin d'éviter les problèmes !
|
||
|
|
||
|
|
||
|
## Les bonnes pratiques selon Ansible
|
||
|
|
||
|
<small>https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html</small>
|
||
|
|
||
|
|
||
|
## Autres bonnes pratiques
|
||
|
|
||
|
<small>https://www.serverraumgeschichten.de/2018/04/ansible-best-practices/</small>
|