Comme pour les systèmes d’exploitation Fedora et RHEL, ou encore OpenShift Enterprise et OKD, les releases d’Ansible Tower (à partir de la 3.2), sont créées à partir d’une branche d’un projet Open-Source sponsorisée par RedHat : AWX.
Ansible Tower est donc considéré comme la version entreprise d’AWX et offre ainsi les mêmes fonctionnalités techniques.
Le tableau de bord d’AWX fournit un affichage de style “tête haute” (toutes les informations importante au premier coup d’oeil) pour tout ce qui se passe dans votre environnement Ansible.
Une fois connecté, vous verrez l'état de votre hôte et de votre inventaire, ainsi que toute l'activité récente des jobs et des snapshots des exécutions réalisées.
On peut ainsi retrouver au premier coup d’oeil toutes les informations importantes et pertinentes de nos tâches en cours. Par exemple, on voit un graphique sur l'état des jobs ou sur le nombre de jobs en “réussi” ou en “échec” par jour. Nous pouvons bien sûr modifier les paramètres d’affichage du graphique en choisissant la période (dernières 24h, dernière semaine ou dernier mois). On peut aussi sélectionner les types de jobs (tous, synchronisation des inventaires, mise à jour des projets Source Code Management ou exécution des playbooks) et afficher leur statut “réussi” ou “échec”.
Nous pouvons voir le nombre de workers disponibles qui exécuteront nos différents jobs, les hôtes en échec sur les dernières exécutions de playbooks, le nombre d’inventaires, le nombre de projets SCM, les erreurs de synchronisation des projets SCM ou des inventaires.
Tous ces indicateurs permettent d’avoir un état global et détaillé de la santé de notre orchestration au sein d’AWX, d’un simple coup d’oeil.
Multi-Playbook Workflows
Dans la vie de tous les jours, nous n’exécutons pas qu’un seul job, nous déployons des pipelines de job. Le système est le même avec le multi playbook workflows : il permet d'enchaîner différents playbook Ansible, que ce soit pour du test, du déploiement, ou d’autres besoins.
Le système de workflow multi-playbooks d’AWX permet de faire des pipelines de jobs Ansible afin de paralléliser l’exécution des playbooks et d’utiliser des configurations différentes pour chacun d’eux (inventaire, utilisateur, etc.).
Vous pouvez utiliser cette fonctionnalité comme une CI/CD qui crée une application, la déploie dans un environnement test, exécute des tests et promeut automatiquement l’application en fonction des résultats des tests.
Au sein d’AWX, les playbooks sont lancés au fur et à mesure qu’Ansible est exécuté à travers votre infrastructure. On peut suivre l’exécution de ces playbooks, l’avancement des tâches (succès ou échecs de celles-ci), les outputs, et même filtrer le tout par machine.
Nous pouvons donc visualiser facilement le statut de notre automatisation et la suite de la file d’attente.
D’autres types de tâches, tels que les mises à jour du contrôle de source ou de l’inventaire dans le Cloud, apparaissent dans la vue des jobs courants.
Avec AWX, toute l’activité des exécutions de playbooks Ansible est journalisée avec les informations indiquant : “qui” a exécuté le playbook, comment il a été personnalisé, quand il a été lancé, etc…
Le tout peut être sauvegardé et visible ultérieurement ou exporté via l’API.
Afin de récupérer les flux d’activités correspondant à son compte, rien de plus simple via l’API. Il suffit de faire la commande curl suivante avec user et mot de passe :
$ curl -u $USER:$PASSWORD http://$URL/api/v2/activity_stream/
Vous aurez alors le résultat suivant en stdout :
Les flux d’activités affichent un journal d’audit complet de toutes les modifications apportées à AWX comme la création de tâches, les modifications d’inventaire ou le stockage des informations d’identité.
On peut également récupérer ces flux d’activité via la demande d’un token API.
Vous avez aussi la possibilité dans AWX de connecter plusieurs noeuds à un cluster afin d’ajouter de la redondance et de la capacité. Plus vous aurez d’utilisateurs, d’inventaires, de projets SCM à synchroniser, de workflows et de playbooks à exécuter au sein de votre orchestration AWX, plus cela vous demandera de ressources, que ce soit en RAM ou en CPU.
Il vous faudra donc augmenter les capacités de votre serveur, ou créer un cluster afin que, même si un serveur exécutant les différents jobs réalisés par AWX tombe, ils puissent continuer à tourner, ce qui assure ainsi la redondance. Vous pourrez, comme nous avons pu le voir plus haut, créer un cluster de serveurs exécutant les différentes tâches pour les environnements DEV, TEST ou PROD.
AWX intègre aussi la fonctionnalité de notification. Cela permet de rester informé sur les différentes exécutions de vos playbooks grâce à des notifications via Grafana, Slack, Hipchat, Mattermost, IRC, SMS, email, etc…
Par exemple pour Slack, il vous faudra créer :
Un bot sur Slack en suivant la procédure suivante.
Un système de notification dans AWX en allant dans la section notifications.
Vous n’aurez plus qu’à remplir les différents champs, comme le ou les noms des canaux de communication, ainsi que le jeton API du bot, donné lors de la création du bot sur Slack.
Cela vous donnera le résultat suivant :
L'exécution de playbooks Ansible, les mises à jour de l’inventaire dans le cloud et du contrôle de source, peuvent être planifiés dans AWX.
On choisira ainsi de les exécuter immédiatement, plus tard ou en continu. Cette fonctionnalité se base sur la technologie du cron.
AWX vous aide à gérer toute votre infrastructure. Extrayez facilement votre inventaire auprès de fournisseurs de cloud publics tels qu’Amazon Web Services, Microsoft Azure, Google Cloud Platform, etc…, ou synchronisez-le à partir de votre environnement OpenStack ou VMware local.
AWX vous permet de lancer un playbook d’un simple clic. Pour cela, il peut vous demander des variables ou remplir un formulaire au lancement du playbook Ansible. Il vous permet de choisir parmi les informations d’identification sécurisées disponibles et de surveiller les déploiements résultants.
À partir de l’interface web, vous pouvez déléguer des tâches d’automatisation à des utilisateurs de l’entreprise, en les synchronisant directement par LDAP, Active Directory ou l’authentification déléguée SAML.
Cette fonctionnalité permet d’exécuter des tâches simples en mode ad hoc Ansible sur n’importe quel hôte ou groupe d’hôtes de l’inventaire que vous avez défini sur AWX.
Par exemple, cela permet d’ajouter des utilisateurs ou des groupes, réinitialiser les mots de passe, redémarrer un service défectueux ou corriger rapidement un problème de sécurité critique.
Comme toujours, l'exécution de commandes à distance utilise le moteur de contrôle d'accès basé sur les rôles de AWX et enregistre toutes les actions.
Pré-requis
Avant de commencer à déployer AWX, il vous faudra d’abord installer ces différentes dépendances sur votre environnement local :
Pré-requis système
AWX n’est pas trop gourmand en ressources, que ce soit pour la RAM ou le CPU. Normalement, 4 GB de RAM et 2 CPU sont bien suffisants à son bon fonctionnement.
Cependant, dû à la génération de data assez conséquente, il vous faudra 20 GB au minimum.
Attention : AWX n’a pas de système d’upgrade de prévu, il faut rebuild les sources.
Le code source de AWX est cloné depuis Github.
AWX peut être actuellement déployé comme application de conteneurisation, en utilisant une image Docker avec Openshift Cluster, docker-compose, Kubernetes, Helm, ou via Docker local.
Dans notre exemple, pour rester au plus simple, nous allons choisir l’installation sur des containers Docker avec un docker-compose.
Pour cela, il vous faudra aller dans le dossier AWX > installer.
Attention : par défaut la variable “postgres_data_dir” est set dans le fichier inventory. Le fichier inventory situé dans Awx/installer/inventories contient toutes les variables utilisées par le playbook Ansible, afin de déployer les containers Docker nécessaires au bon fonctionnement d’AWX dans /tmp.
Donc, quand vous allez redémarrer votre machine, cela va entraîner une nouvelle création des containers Docker, écraser vos données et vous allez récupérer un AWX comme s’il venait d’être installé.
Les différentes variables se situant dans le fichier inventory sont toutes détaillées dans le guide d’installation d’AWX et vous retrouverez les différentes solutions de déploiement de la solution ici.
Au niveau du dossier AWX, vous lancez le playbook d’installation d’AWX :
$ ansible-playbook -i inventory install.yml
Pour vérifier que l’installation s’est bien déroulée, il suffit de faire un docker ps :
Si le playbook Ansible de déploiement d’AWX s’est bien exécuté jusqu’à la fin, l’image ci-dessus illustre les différents containers Docker nécessaires au bon fonctionnement de cette solution.
Accéder à AWX
Pour accéder à l’interface graphique AWS, il suffit de taper l’url par défaut http://localhost, et de saisir les login/password par défaut (admin/password). Il est recommandé de changer les informations login (admin_user) et password (admin_password) au niveau de l’inventory :
AWX facilite l’exécution de playbooks Ansible depuis un point central, notamment grâce à la sécurisation et à la possibilité de déléguer à diverses équipes, que ce soit en production ou non. Il permet aussi de disposer de fonctionnalités très intéressantes comme le REST API ou les notifications.
Le seul point négatif que je vois est le manque d’un système d’upgrade intégré comme avec Ansible Tower.