Ajouter de noeuds d'exécution externes à Ansible AWX

Cela faisait un moment que j’avais envie de poursuivre sur la publication de billets sur AWX et entre temps des nouveautés sont apparues comme la possibilité d’ajouter des nœuds d’exécution déportés. Ce sera l’objet de ce billet.

Introduction

L’objectif est de pouvoir ajouter des nœuds d’exécution à mon instance AWX. Cela peut être pratique comme par-exemple installer un de ces nœuds dans une DMZ. C’est depuis ces nœuds que seront lancés les playbooks Ansible.

Principes

Sur Automation Platform, on retrouve ce concept sous le nom d’automation mesh qui permet rendre plus facile l’exécution des jobs ansible sur des datacenters distants ou dans le cloud. Les nœuds d’exécution peuvent ainsi être installés au plus près des machines cibles. La communication ne se fait plus en SSH mais avec un protocol TCP crypté utilisant le port 27199. Le protocole SSH est simplement utilisé pour assurer l’installation du daemon appelé receptor sur le noeud d’exécution.

Ajout de noeuds d’exécution à AWX.

La procédure d’installation d’AWX en utilisant une BDD externe est expliqué ici ↗.

Attention, pour le moment, je n’ai réussi à ajouter des noeuds tournant sur du CentOS. J’ai donc installé une nouvelle machine de server sans GUI, sur laquelle j’ai créé un compte ansible avec droits sudo sans mot de passe. J’ai ajouté ma clé SSH d’administration dessus afin de pouvoir lancer les playbooks depuis mon poste de travail ou depuis AWX.

Dans l’interface d’AWX, il faut se rendre dans la section Administration / Instances. Vous ne devriez voir qu’un seul noeud de type control. C’est le fameux controller !

Cliquez sur [Ajouter] et dans nom d’hôte mettez soit l’IP (si la machine n’est pas enregistrée dans votre DNS), soit le nom de la machine. Pour finir cliquez sur [Enregistrer].

Installation d’Ansible Receptor sur le nœud d’exécution

AWX fourni tout ce qu’il faut pour installer le daemon sur le noeud d’exécution. Ouvrez le détail de votre instance et cliquez sur [Installer Bundle].

En fait, c’est un playbook généré automatiquement par AWX contenant tout ce qu’il faut pour installer et configurer receptor sur votre noeud d’exécution. Décompressez l’archive !

tar xvfz 192.168.1.67_install_bundle.tar.gz
192.168.1.67_install_bundle/receptor/tls/ca/receptor-ca.crt
192.168.1.67_install_bundle/receptor/work-public-key.pem
192.168.1.67_install_bundle/receptor/tls/receptor.key
192.168.1.67_install_bundle/receptor/tls/receptor.crt
192.168.1.67_install_bundle/install_receptor.yml
192.168.1.67_install_bundle/inventory.yml
192.168.1.67_install_bundle/group_vars/all.yml
192.168.1.67_install_bundle/requirements.yml
cd 192.168.1.67_install_bundle/

Dans un premier temps, éditez le fichier inventory.yml et modifier les valeurs ansible_user et ansible_ssh_private_key_file :

---
all:
  hosts:
    remote-execution:
      ansible_host: 192.168.1.67
      ansible_user: admuser
      ansible_ssh_private_key_file: ~/.ssh/id_ed25519

On teste que cela fonctionne :

ansible -i inventory.yml all -m ping
remote-execution | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

Avant de lancer il faut aussi modifier le fichier group_vars/all.yml. En effet le package python39-pip sous centos 9 s’appelle python3-pip comme ceci.

receptor_user: awx
receptor_group: awx
receptor_verify: true
receptor_tls: true
receptor_work_commands:
  ansible-runner:
    command: ansible-runner
    params: worker
    allowruntimeparams: true
    verifysignature: true
custom_worksign_public_keyfile: receptor/work-public-key.pem
custom_tls_certfile: receptor/tls/receptor.crt
custom_tls_keyfile: receptor/tls/receptor.key
custom_ca_certfile: receptor/tls/ca/receptor-ca.crt
receptor_protocol: 'tcp'
receptor_listener: true
receptor_port: 27199
receptor_dependencies:
  - python3-pip

podman_user: "{{ receptor_user }}"
podman_group: "{{ receptor_group }}"

Attention

Ne désactivez pas la partie TLS sinon cela ne fonctionnera pas !

Et pour finir installons les dépendances :

ansible-galaxy install -r requirements.yml --force
Starting galaxy collection install process
Process install dependency map
Starting collection install process
Downloading https://galaxy.ansible.com/download/ansible-receptor-1.1.0.tar.gz to /home/bob/.ansible/tmp/ansible-local-14100579r65t17/tmp7p4_45ig/ansible-receptor-1.1.0-t1417erf
Installing 'ansible.receptor:1.1.0' to '/home/bob/.ansible/collections/ansible_collections/ansible/receptor'
ansible.receptor:1.1.0 was installed successfully

Tout être on lance le playbook :

ansible-playbook -i inventory.yml install_receptor.yml
PLAY [all] *******************************

TASK [Gathering Facts] *******************************
ok: [remote-execution]

TASK [Create the receptor user] *******************************
ok: [remote-execution]

...

TASK [Install ansible-runner] *******************************
ok: [remote-execution]

PLAY RECAP *******************************
remote-execution           : ok=42   changed=8    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0

Et voilà tout est prêt ! Enfin presque, il faut ouvrir le flux.

```bash
ssh admuser@192.168.1.67
sudo -i
firewall-cmd --zone=public --add-port=27199/tcp --permanent
firewall-cmd --reload

Et voilà. Petit contrôle des ports ouverts :

netstat -tlnp
(Tous les processus ne peuvent être identifiés, les infos sur les processus
non possédés ne seront pas affichées, vous devez être root pour les voir toutes.)
Connexions Internet actives (seulement serveurs)
Proto Recv-Q Send-Q Adresse locale          Adresse distante        Etat        PID/Program name
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp6       0      0 :::22                   :::*                    LISTEN      -
tcp6       0      0 :::27199                :::*                    LISTEN      -
tcp6       0      0 ::1:631                 :::*                    LISTEN      -

Petit retour dans l’interface et au miracle le noeud est prêt !

Création d’un groupe d’instance

Dans la section [Groupes d’instances], cliquez sur [Ajoutez / Ajoutez un groupe d’instances]. Il faut juste définir un nom, distants et cliquez [Enregistrez] !

Dans la page suivante cliquez sur [Instances] puis sur [Associé]. Sélectionnez le noeud et [Enregistrez].

Test de lancement d’un job sur le noeud d’exécution distant

Tout est prêt. Mais il faut encore déclarer node comme hôte, la clé SSH dans les crédentials

Ajout d’un Hote

Créons un hote avec ce node lui-même, puis ajoutons-le à l’inventaire Demo Inventory:

Ajout d’un crédential

Dans la section [Ressource / Informations d’identification] créez un crédential de type machine: Remplissez le nom d’utilisateur, copiez la clé privé SSH.

Finissez par [Enregistrez].

Modification du modèle

Dans la section [Ressources / Modèles], cliquez sur le modèle [Demo Job Template] puis sur [Modifiez]. Ajoutez votre clé dans la section [Informations d’identification] et changez le [groupe d’instances].

Finissez par [Enregistrez].

Lancement du playbook

Il suffit de cliquer sur [Lancez]

Normalement, vous devriez voir voir le playbook s’exécuter sur le noeud d’exécution distant !

Un petit coup d’oeil sur le process tournant sur le noeud distant et on voit bien ansible-runner tourner.

Plus loin

Une bonne chose de faite. Pour cette démonstration, j’ai utilisé l’interface d’AWX ! Mais personnellement je préfère tout faire avec du code, Ansible bien sur ! Ce sera l’objet du prochain billet.