Execution Environments et Ansible

Rédigé par Nicolas Sulek Aucun commentaire
Classé dans : Système Mots clés : ansible, rundeck, CentOS, Fedora, python, RHEL
Un Execution Environment est une image de conteneur qui contient les dépendances système et les collections nécessaires pour exécuter des playbooks Ansible.

Il apporte :
  • l'isolation des dépendances logicielles
  • la portabilité entre les équipes et les environnements
  • la séparation des autres contenus et outils d'automatisation.
Il peut être intégré dans une chaîne CI/CD par exemple.

Un Execution Environment comporte au moins :
  • ansible-core
  • ansible-runner
  • Python
  • les dépendances relatives à Ansible.
Il est ensuite possible de rajouter du contenu :
  • une collection Ansible et ses dépendances
  • du contenu personnalisé.

Pré-requis

Pour utiliser un Execution Environment, il faut au moins un runtime d'exécution de conteneur (podman ou Docker) et Python 3, le tout est en général déjà disponible sous forme de paquets.

Il faut également ansible-navigator, outil en ligne de commande avec une interface textuelle permettant de créer, d'examiner, débugguer du contenu Ansible, tels que les inventaires, playbooks, collections et les images de conteneurs (les Execution Environments).
L'installation se fait via pip :
python3 -m pip install ansible-navigator --user
Est également installé ansible-builder qui sert à la construction des control nodes Ansible packagés en tant que conteneur, ça tombe bien.

Images communautaires

Il existe des images fournies par la communauté Ansible qui peuvent répondre à pas mal de besoins. Elles peuvent être exécutées ainsi :
ansible-navigator exec "ansible localhost -m setup" --execution-environment-image ghcr.io/ansible-community/community-ee-minimal:latest --mode interactive
pour des commandes Ansible ad hoc ou
ansible-navigator run test_localhost.yml --eei ghcr.io/ansible-community/community-ee-minimal:latest --pull-policy missing  --mode stdout
pour l'exécution d'un playbook.

Création d'Execution Environment personnalisé

Toutefois, un des intérêts des Execution Environments est de pouvoir créer celui qui correspond à nos besoins propres.
Dans mon cas, j'ai deux attentes :
  • avoir une version d'Ansible basique mais assez vieille pour gérer les vieux OS, pour lancer des commandes Ansible ad hoc, et éviter le message ansible-core requires a minimum of Python2 version 2.7 or Python3 version 3.5. Current version: 2.6.6
  • avoir une version d'Ansible récente pour bénéficier des nouveaux modules et avec les collections que nous utilisons (notamment community.postgresql, community.vmware et vmware.vmware_rest) et la bibliothèque SOLIDserverRest.
Le tout pouvant être exécuté :
  • via Rundeck avec un compte dédié sur un control node
  • sur des control nodes servant pour le développement avec différents logins nominatifs.
  • sur des control nodes de production avec différents logins nominatifs.
La solution précédente était basé sur les environnements virtuels Python, mais posait des problèmes de complexité et de maintenance.

Execution Environment basique avec Ansible 2.11

Pour créer un Execution Environment avec Ansible 2.11 qui est la dernière version à ne pas exiger un Python 2.7, je vais créer un répertoire ansible-2.11 et à l'intérieur définir le fichier execution-environment.yml suivant :
version: 3

images:
  base_image:
    name: quay.io/fedora/fedora:38

dependencies:
  ansible_core:
    package_pip: ansible-core==2.11.12
  ansible_runner:
    package_pip: ansible-runner
  system:
  - openssh-clients
  - sshpass
et je vais ensuite créer l'image avec
ansible-builder build --tag ansible:2.11 --container-runtime docker
car je veux une image pour Docker.
Pour l'image de base, il est possible d'utiliser d'autres bases comme Rocky Linux, CentOS Stream ou Red Hat Universal Base Image. Dans tous les cas, ça ne fonctionnera qu'avec des distributions RedHat like.

On obtient alors un répertoire context avec :
  • le fichier Dockerfile généré
  • les artefacts et scripts de construction
et bien sûr l'image Docker :
REPOSITORY                                       TAG       IMAGE ID       CREATED         SIZE
ansible                                          2.11      d461496cd2e0   9 minutes ago   259MB

Execution Environment avec le dernier Ansible et du contenu personnalisé

Pour construire l'Execution Environment plus à jour et avec les collections nécessaires, je vais créer un répertoire ansible-latest et y définir le fichier execution-environment.yml suivant :
version: 3

images:
  base_image:
    name: quay.io/fedora/fedora:latest

dependencies:
  ansible_core:
    package_pip: ansible-core
  ansible_runner:
    package_pip: ansible-runner
  system:
  - openssh-clients
  - sshpass
  - git
  galaxy:
    collections:
    - name: community.postgresql
    - name: community.vmware
    - name: vmware.vmware_rest
  python:
    - SOLIDserverRest
Comme précédemment, il ne reste plus qu'à le construire avec
ansible-builder build --tag ansible:latest --container-runtime docker
On obtient une image nettement plus volumineuse.
REPOSITORY                                       TAG       IMAGE ID       CREATED          SIZE
ansible                                          latest    ea4ec1b1b074   2 minutes ago    461MB

Utilisation

Je peux ensuite les utiliser avec :
ansible-navigator exec "ansible localhost -m setup" --execution-environment-image ansible:2.11 --mode interactive
pour des commandes Ansible ad hoc ou
ansible-navigator run test_localhost.yml --eei ansible:latest --pull-policy missing  --mode stdout
pour l'exécution d'un playbook.
Il ne reste plus qu'à les pousser sur un registre Docker pour les déployer sur les autres control nodes et assurer un versionning des images.

Les commentaires sont fermés.