- Créé en 2012 (2015 repris par Redhat) par Michael DeHaan (Cobler, outil de provisionnement)
- Ansible = Infrastructure as code + déploiement de configurations + installations
- à base de python
- Documentation : https://docs.ansible.com/
- orchestrateur basé sur du push > pas d’agent = serveur distant pousse les informations à la différence des outils à base d’agents > pull (puppet etc…)
- puppet
- chef
- saltstack
- capistrano
- simplicité lié à l’utilisation de SSH
- intégration facile dans les outils de CI/CD
- facilité d’utilisation à base de fichiers yaml
- de très nombreux modules et une très forte communauté (notamment via ansible galaxy)
- différentes notions et déinitions : inventory + playbook + rôles (inventory > playbook < rôles)
- système de templating = jinja2 (python) (équivalent à erb pour puppet (ruby))
- également utilisable pour récupérer les données de vos serveurs
- ansible vault
- ansible playbook
- ansible galaxy
- ansible doc
- via les sources
- via les paquets
- via librairie python (pip)
- postgres
- vmware
- aws
- libvirt (kvm)
- network
- grafana
- postgresql
- mysql
…
- noeud disposant de ansible et permettant de déployer
- accès ssh aux autres machines (bastions…)
- password ou clef ssh
- sécurité importante
- serveurs cibles
- permet la connexion ssh
- élévation de privilèges via le user
- inventaires des machines (ip, dns)
- format ini (plat) ou format yaml
- et les variables (host_vars et group_vars)
- statique (fichiers) ou dynamique (api via script)
- utilisation de patterns possible (srv-pg93-0[0-2])
- dans un inventaire les machines peuvent être regroupées (serveur web, databases…)
- possibilité de créer différents niveaux > arbre (parents/enfants)
- groupe racine = all
- variables d’un même groupe
- définie dans le fichier central d’inventory
- ou dans un répertoire spécifique (reconnu par ansible)
- variables spécifiques à un serveur en particulier
- surcharge d’autres variables définies plus haut dans l’arbre - ex - groupe
- actions variées (user, group, command, module)
- format yaml
- ensemble d’actions ciblées sur une utilisation commune
- pour un outil donnée : ex. postgres, mysql, vmware…
- chacune de ses actions est utilisable via une task
- chaque action prend des options
- les actions peuvent fournir un retour (id, résultat…)
- fournis par ansible pour l’essentiel
- peuvent être chargés spécifiquement
- contribution possible auprès des mainteneurs
- ensemble d’actions coordonnées pour réaliser un ensemble cohérent (installer nginx et le configurer etc)
- organisé en différents outils (tasks, templates, handlers, variables (default ou non), meta)
- peuvent être partagés sur le hub ansible galaxy
- il vaut mieux les versionner
- un fichier (et rien d’autres…)
- applique des rôles à un inventory
- partie cruciale inventory > playbook < rôles
- peut contenir des variables (à éviter)
- peut contenir des tasks (à éviter)
- peut contenir des conditions (à éviter)
- modifie ou augmente les capacités de ansible
- de différentes manières : output, inventory dynamique, strategy, tests…