Au fil de mes différentes missions et sorties dans la communauté, j’ai une question qui revient souvent : peut-on piloter de l’infrastructure Amazon avec Ansible ? Et comme c’est souvent le cas, ce genre de question en apporte de nombreuses autres : si oui, comment ? Comment maintenir son infrastructure ? Peut-on tout faire ?
Je vais tenter de synthétiser dans ce billet quelques éléments de réponses, tirés de mon expérience.
La réponse la plus simple est que : oui, il est possible de gérer de l’infra AWS avec Ansible. Cependant, suivant ce que vous cherchez à faire, ce n’est pas forcément l’outil le mieux adapté.
À ce jour, il existe 98 modules Ansible dédiés aux opérations AWS. Ces modules couvrent différents services du catalogue : EC2, ECS, IAM, RDS, ElastiCache et d’autres.
Pour tout ce qui n’est pas intégré sous forme de module python Ansible, rappelez-vous qu’Ansible est avant tout un orchestrateur. Vous pouvez donc piloter des actions complexes basées sur les outils CLI Amazon au milieu de vos playbooks, pour combler les manques.
Tout fanatique d’Ansible que je puisse être, il me faut avouer une chose : Ansible n’est PAS le bon outil pour bâtir une infrastructure. La syntaxe nécessaire pour démarrer une architecture de zéro est bien trop verbeuse pour en faire un outil confortable pour cette tâche. La logique d’Ansible est basée sur la gestion de tâches, par conséquent, il n’y a pas de calcul de cohérence ou de plan d’exécution à l’échelle de votre infrastructure. Les mécanismes Ansible à utiliser pour vous prémunir des erreurs sont des usages avancés, longs à mettre en place et qui nécessitent une attention continue dans le temps.
Le meilleur outil à mon avis à ce jour est Terraform. Il vient avec des mécanismes de calcul de plan d’exécution, une syntaxe plus compacte et adaptée à ce cas d’usage. Si vous ne connaissez pas encore, prenez le temps de lui accorder un peu de temps.
Si vous disposez déjà d’une infrastructure en place, Ansible peut vous rendre de grands services. Toute opération de maintenance un peu complexe mérite de se pencher sur Ansible pour voir si un playbook bien senti pourrait être une solution. Par exemple, j’ai fait un billet il y a quelques temps sur un rolling upgrade des serveurs d’un autoscaling group AWS. Pour orchestrer des actions sur vos serveurs, couplées à des actions sur l’infrastructure AWS, Ansible est clairement un bon outil.
L’orientation d’Ansible par défaut est l’idempotence des modules, ce qui en d’autres termes signifie que leur résultat sera le même, peu importe le nombre d’exécutions. Cependant, certains modules ne peuvent le garantir par défaut. La famille des modules AWS fait partie de ceux-là.
La nature versatile de l’infrastructure rend la détection de l’état du compte AWS hasardeuse. Chaque module a ses propres mécanismes pour arriver à gérer l’idempotence. Le module EC2 par exemple, peut s’utiliser de plusieurs façons pour éviter de recréer des serveurs à chaque appel.
La première option est de jouer sur les attributs count_tags et instance_tags. Le module va interroger les API AWS pour lister toutes les machines et compter combien parmi elles ont une correspondance sur les valeurs de tags spécifiées en count_tags. Au besoin, il lancera des machines en leur attribuant les tags listés dans instance_tags. Par conséquent, il faut que tous les tags de count_tags soient présents dans les instance_tags.
La seconde option est de forger un token de votre cru, qui identifie un groupe de machines. Ce token est une chaîne de caractères, sensible à la casse, de 1 à 64 caractères de votre choix. Il doit être fourni via l’attribut id du module EC2 et identifie de façon unique un serveur ou un set de serveurs.
Ce genre de mécanique est très bien expliqué dans la documentation de chacun des modules, aussi, prenez la peine de lire attentivement (RTFM). Cela vous évitera de payer une heure d’instance pour un playbook mal maîtrisé.
Ansible n’est clairement pas l’outil le plus pertinent pour construire une infrastructure Amazon, mais il peut vous faciliter la vie au quotidien. Son rôle d’orchestrateur généraliste vous rendra bien des services.
Pour ce qui est de la construction, tournez-vous plutôt vers du Terraform, voire son homologue propriétaire AWS : CloudFormation.