¶ Présentation
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
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.
¶ Mises à jour de l'état des tâches en temps réel
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.
¶ Qui ? Quoi ? Quand ?
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.
¶ Scale Capacity avec AWX clusters
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.
¶ Notifications intégrées
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 :
¶ Planification des playbooks Ansible
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.
¶ Gérez et suivez votre inventaire
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.
¶ Self-service simplifié
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.
¶ Exécution de commande à distance
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.
¶ Installation
¶ Almalinux 8 (RHEL 8 / Centos 8)
¶ Pré-requis
Commençons tout d'abord par installer les pré-requis.
Je vais commencer avec l'ajout du dépôt EPEL sur ma machine afin d'installer une grande partie des paquets nécessaires à AWX :
https://fedoraproject.org/wiki/EPEL
Pour information, je suis connecté à ma machine avec un compte utilisateur standard : awx. J'ai ajouté ce compte au groupe sudo au préalable.
L'ajout du dépôt EPEL :
sudo dnf install epel-release -y
On installe les pré-requis, dont Ansible :
sudo dnf install git gcc gcc-c++ nodejs gettext device-mapper-persistent-data lvm2 bzip2 python3-pip python3 ansible -y
Nous allons ensuite pouvoir installer Docker. Afin de réaliser cette installation, on commence tout d'abord par ajouter le dépôt docker-ce :
sudo dnf config-manager --add-repo=https://download.docker.com/linux/centos/docker-ce.repo
On installe docker avec le choix nobest :
sudo dnf install docker-ce --nobest -y
Explication rapide sur l'installation avec l'option nobest :
Red Hat seems to have somehow blocked the installation of containerd.io > 1.2.0-3.el7, which is a dependency of docker-ce. Because of this, simply running the sudo dnf install docker-ce command, won't work. As we will see in a minute, it's still possibile to workaround this problem; once docker-ce is installed, however, another problem becomes evident: as long as firewalld, the system firewall manager is enabled, DNS resolution inside docker containers does not work.
This is, of course a critical problem. However, if you still want to proceed with the installation, here are the possible methods that can be used to avoid the dependencies issues:
Install a specific version of docker-ce which requires an installable version of the containerd.io package;
Force the installation providing the --nobest option
Install the latest available containerd.io rpm manually;
https://linuxconfig.org/how-to-install-docker-in-rhel-8
On démarre le daemon et on s'assure qu'il est configuré pour se lancer au démarrage de notre machine :
sudo systemctl start docker
sudo systemctl enable --now docker.service
Pour faciliter l'installation, j'ajoute mon compte au groupe docker :
sudo usermod -aG docker awx
Attention pour des raisons de sécurité, je déconseille d'ajouter le compte courant au groupe Docker en production
Pour ne rencontrer aucun souci d'interpréteur :
sudo alternatives --set python /usr/bin/python3
Et finalement j'installe docker-compose pour mon utilisateur :
pip3 install --user docker-compose
Nous avons installé tout les pré-requis et nous allons pouvoir passer à l'installation d'AWX à l'aide du playbook fourni.
¶ Awx
Dans un premier temps, il faut cloner le dépôt Git du projet :
cd /temp
wget https://github.com/ansible/awx/archive/refs/tags/17.1.0.tar.gz
tar -xf 17.1.0.tar.gz
mv awx-17.1.0/ awx
Rendez-vous dans le dossier awx/installer afin de configurer votre environnement :
cd awx/installer
Pour configurer votre installation, il faut modifier le fichier inventory :
nano inventory
Quelques variables sont à modifier :
pg_username=awx
# pg_password should be random 10 character alphanumeric string, when postgresql is running on kubernetes
# NB: it's a limitation of the "official" postgres helm chart
pg_password=awxpass
...
# This will create or update a default admin (superuser) account in AWX, if not provided
# then these default values are used
admin_user=admin
admin_password=password
Enfin vous pouvez générer votre "secret" :
openssl rand -base64 30
Et modifiez celui-ci dans le fichier **inventory **:
# AWX Secret key
# It's *very* important that this stay the same between upgrades or you will lose the ability to decrypt
# your credentials
#secret_key=awxsecret
secret_key=xv3geKd4dF8XwRGRIXdLYqgU+kL9c+KWtuz/Rx3t
Sauvegardez votre fichier de configuration.
Avant de lancer l'installation, je vous conseille de modifier firewalld avec ces quelques règles :
sudo firewall-cmd --zone=public --add-masquerade --permanent
sudo firewall-cmd --permanent --add-port=80/tcp
sudo firewall-cmd --reload
Lancez enfin le playbook qui va automatiquement configurer votre installation :
ansible-playbook -i inventory install.yml
Voici le résultat :
Enfin connectez-vous sur l'interface d'AWX http://"MON-IP"/ !
Si vous tombez sur une page vous indiquant un upgrade de version d'AWX, aucune inquiétude.
L'installation n'est peut-être pas terminée. Vous pouvez vérifier ceci avec la commande suivante :
docker logs -f awx_task
Enfin après quelques minutes, vérifiez que tout fonctionne correctement :
