La CLI Ansible AWX dans vos pipelines Gitlab CI/CD

Nous continuons l’exploration d’Ansible AWX avec au menu du jour l’utilisation de CLI Ansible Tower. Cette CLI peut être utilisé au sein de vos pipelines de CI/CD comme Gitlab-CI. C’est ce que je vous propose de voir dans ce billet.

Pour ceux qui non pas encore installé Ansible AWX, c’est par là que ça se passe.

Installation de la CLI Ansible TOWER

La CLI Ansible Tower est comme tous les autres produits Ansible écrit en python et donc l’installation se fait avec pip :

pip3 install --user https://releases.ansible.com/ansible-tower/cli/ansible-tower-cli-latest.tar.gz

Une fois installée cette CLI est invoquée par la commande awx :

awx --version
3.8.5

Utilisation de la CLI Ansible TOWER

La première chose à faire est de s’authentifier sur Ansible TOWER ou AWX avant de pouvoir lancer d’autres actions :

Il suffit d’utiliser la commande suivante login :

awx login -k --conf.host http://192.168.1.74:30932 --conf.username admin
--conf.password 4QZfWjot1JkrleSXvGnLZDXjr6oXWeoF -f human
export TOWER_OAUTH_TOKEN=dUX0kATWTdIKREhWfoKDPttfkjII7R

L’option -k est utilisé pour autoriser les connexions à l’API d’AWX sans la couche SSL.
L’option -f human génère une sortie qui peut être utilisé directement pour lancer les autres commandes.

Utilisation d’un jeton d’accès personnel

Je vais vous montrer comment générer un token dans l’interface d’AWX. Il suffit de cliquer sur son compte utilisation puis détails de l'erreur (oups mauvaise traduction.)

AWX environnement d'exécution

Ensuite cliquez sur l’onglet [Jetons], [Ajouter] :

Champ d’application : Lecture ou Écriture

Pour finir, cliquer sur [Enregistrer]. Copiez le token dans un lieu sûr. Il est valide 1000 ans, vous avez le temps avant qu’il expire.

AWX environnement d'exécution

Comme pour le token OAUTH il suffit d’exporter la variable TOWER_OAUTH_TOKEN avec ce token avant d’utiliser les autres commandes de la CLI :

export TOWER_OAUTH_TOKEN=f5XTht5JVqh1x3XrN5P1Jnu28orUak

Accéder aux ressources d’AWX

Maintenant que nous savons nous identifier nous allons pouvoir accéder aux ressources que nous avons créées dans AWX.

Pour simplifier les commandes nous utiliser la variable d’environnement TOWER_HOST :

export TOWER_HOST=http://192.168.1.74:30932

Par exemple, nous pouvons demander à lister les jobs (j’ai tout supprimé dans l’interface d’AWX) :

awx jobs list
{
     "count": 0,
     "next": null,
     "previous": null,
     "results": []
}

On pourrait aussi lancer le modèle de job que nous avons créé dans le billet précédent qui remontait la liste des pods avec le status running :

awx job_template launch "Get Running Pod" --monitor -f human
------Starting Standard Out Stream------
Identity added: /runner/artifacts/28/ssh_key_data (root@devbox2.robert.local)

PLAY [all] *********************************************************************

TASK [install kubernetes python client] ****************************************
ok: [devbox2.robert.local]

TASK [Get namespace kubernetes] ************************************************
ok: [devbox2.robert.local]

TASK [Display Pod] *************************************************************
ok: [devbox2.robert.local] => {
    "runningpods": {
        "api_found": true,
        "changed": false,
        "failed": false,
        "resources": [
            {
                "apiVersion": "v1",
                "kind": "Pod",

 ...

PLAY RECAP *********************************************************************
devbox2.robert.local       : ok=3    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

------End of Standard Out Stream--------

id name
== ===============
28 Get Running Pod

L’option monitor permet à la commande de renvoyer des codes de sortie. C’est cette option qui permet d’utiliser la CLI d’Ansible Tower dans Gitlab.

Allez dans l’interface de votre serveur AWX dans le menu affichages / Jobs, vous devriez retrouver l’exécution de votre modèle de Job.

Je ne vais pas vous expliquer toutes les autres commandes. La documentation complète de la CLI se trouve ICI ↗.

Intégration de la CLI Ansible Tower dans vos pipelines

Vous aurez compris finalement, c’est assez simple à mettre en place. Il suffit de :

Créer dans les paramètres CI/CD de votre projet Gitlab une variable TOWER_OAUTH_TOKEN masquée et protégée contenant le TOKEN généré dans AWX.
Créer une seconde variable TOWER_HOST avec l’url de votre serveur AWX

AWX environnement d'exécution

D’utiliser ensuite une image de container (ex ci-dessous) contenant la CLI dans un des stages de votre pipeline.

FROM python:3.9-alpine
RUN pip install "https://releases.ansible.com/ansible-tower/cli/ansible-tower-cli-latest.tar.gz"

Il y a moyen d’optimiser la taille de l’image.

Et comme fichier .gitlab-ci.yml.

stages:
  - test-cli

 test-cli:
  stage:  test-cli
  image: awx_cli
  script:
    - awx job_template launch "Get Running Pod" --monitor -f human

Pour obtenir le code de retour lors de l’exécution d’un modèle de job par exemple, il faudra absolument ajouter l’option —monitor. Sinon votre stage sera toujours en successfull.

Conclusion

Cette méthode est transposable à tous les outils de CI/CD comme travis-ci, github actions, jenkins, … Cela ouvre la porte à plein de possibilités, comme provisionné une infra de test avec du terrafrom sur le cloud, puis de configurer le tout avec de l’ansible.