Ansible fonctionne sur Python, et avec Ansible Tower, Python est également le moteur sous le capot. En travaillant avec mes clients, j'ai rencontré des questions pratiques qui semblent être relativement courantes. Cet article fournit quelques conseils pour configurer et dépanner les virtualenvs dans un scénario Ansible Tower.
1. Qu'est-ce qu'un environnement virtuel ?
Un environnement virtuel Python est essentiellement un répertoire créé avec le virtualenv commande (qui, comme vous pouvez le deviner, est un script Python).
Une fois cet environnement virtuel "activé", vous pouvez y ajouter des modules Python spécifiques et disposer d'un environnement isolé pour expérimenter et développer sans affecter vos principaux scripts et playbooks Python/Ansible.
Ansible Tower a deux virtualenvs sous le répertoire par défaut :awx et ansible .
Le premier est : /var/lib/awx/venv/awx. awx virtualenv est à l'usage exclusif d'Ansible Tower lui-même et ne doit pas être modifié .
L'autre virtualenv est : /var/lib/awx/venv/ansible . Ce virtualenv est ce que Tower utilise pour exécuter les modèles (playbooks).
Quelqu'un pourrait demander :si j'ai besoin d'ajouter des modules Python requis par mes playbooks Ansible Tower, dois-je les ajouter sous la valeur par défaut ansible virtualenv ?
Eh bien, vous pourriez.
Mais c'est probablement une meilleure idée d'en créer un autre virtualenv si :
- Vous souhaitez conserver le virtualenv par défaut comme environnement de développement stable et souhaitez expérimenter de nouveaux modules dans un autre virtualenv.
- Vous avez différents groupes de développeurs qui travaillent sur divers projets nécessitant des modules Python/Ansible spécifiques.
2. Conseils pour configurer un environnement virtuel
Il existe d'excellentes explications et exemples dans la documentation Ansible Tower et Python sur la configuration d'un virtualenv.
Je suis normalement la documentation d'Ansible Tower lorsque je crée un nouveau virtualenv, mais il y a certains sujets que j'ai tendance à négliger (ce qui finit plus tard par me gratter la tête en demandant, "Hmm... pourquoi cela n'agit-il pas comme je m'y attendais ?").
Autorisations sur les modules Python
Assurez-vous de respecter la recommandation de définir umask 0022 , pas seulement lorsque vous créez votre virtualenv, mais aussi lorsque vous ajoutez Modules Python.
La raison en est qu'Ansible Tower s'exécute en tant qu'utilisateur awx , donc cet utilisateur doit pouvoir lire les modules Python dans le virtualenv.
Si les autorisations ne sont pas définies correctement, vos modèles/playbooks peuvent vous donner des erreurs telles que le module XYZ n'est pas installé ou le module XYZ n'a pas d'attribut ABC lorsque le problème est en fait un simple problème d'autorisation.
[ Les lecteurs ont également apprécié : Comment créer un Playbook Ansible ]
Installez Ansible dans votre environnement virtuel
Les playbooks que vous souhaitez exécuter à l'aide de virtualenv auront besoin de vos modules Python spécifiques installés dans votre virtualenv. Il est logique que le moteur Ansible s'exécute également à partir de cet environnement virtuel.
Vous pouvez utiliser la commande suivante pour installer une version spécifique d'Ansible :
sudo /opt/my-envs/xyz/bin/pip install ansible==2.9.15
Remarque :Si vous ne précisez pas la version, pip installe la dernière version. Il y a des changements de comportement entre Ansible 2.9 et Ansible 2.10, il est donc conseillé de vérifier ce document avant d'autoriser l'installation de 2.10 ou d'une version plus récente.
Utilisez Pip pour lister les modules Python
Supposons que vous souhaitiez créer une réplique de votre virtualenv dans un autre environnement, ou que vous ayez plusieurs nœuds Ansible Tower et que vous deviez répliquer le virtualenv sur tous les nœuds. Pour capturer la liste des modules à des fins de comparaison ou de documentation, vous pouvez utiliser :
pip list > pip_list.txt
head -5 /tmp/pip_list.txt
Package Version
------------- ---------
ansible 2.9.15
certifi 2020.12.5
cffi 1.14.4 Vous pouvez également générer une liste dans un format permettant l'installation des mêmes versions de module ailleurs :
pip freeze > /tmp/pip_freeze.txt
head -3 /tmp/pip_freeze.txt
ansible==2.9.15
certifi==2020.12.5
cffi==1.14.4 Vous pouvez ensuite utiliser ce fichier freeze pour installer les mêmes modules avec exactement les mêmes versions en utilisant :
sudo /opt/my-envs/xyz/bin/pip install -r pip_freeze.txt 3. Rendre les environnements virtuels disponibles dans les projets/modèles Tower
Par défaut, Ansible Tower ne connaît que ses propres environnements virtuels.
Afin d'informer Tower des environnements virtuels supplémentaires, vous avez deux options :
- Utilisez les appels d'API REST comme décrit dans la documentation d'Ansible Tower
- Utilisez l'interface Web et accédez à PARAMÈTRES -> SYSTÈME :
Après avoir effectué l'une de ces deux étapes, vous pourrez sélectionner les nouveaux environnements virtuels lorsque vous travaillerez avec des organisations, des projets et des modèles dans Tower :
Remarque :Assurez-vous que le répertoire virtualenv est lisible par l'utilisateur awx . Si ce n'est pas le cas, Tower ne listera pas le virtualenv.
"La chose la plus importante à laquelle il faut faire attention est de savoir quel virtualenv est actif et quels binaires vos playbooks utilisent."
4. Sauvegarder et restaurer un virtualenv
Si vous effectuez une sauvegarde complète de Tower (à l'aide de setup.sh -b script), les virtualenvs y seront automatiquement sauvegardés, et vous pourrez les restaurer avec setup.sh -r ). Bien sûr, restaurer de cette manière signifie que tout le reste sera également restauré.
Si vous avez besoin de sauvegarder/restaurer le virtualenv, vous pouvez toujours utiliser des outils comme tar pour faire ça.
De plus, si vous avez enregistré la sortie de votre pip freeze commande, vous pouvez recréer la structure du répertoire et utiliser la commande pip install commande avec le -r argument comme indiqué ci-dessus.
Assurez-vous que la structure de répertoires restaurée est lisible par awx user afin que Tower puisse reconnaître le virtualenv et le lister sous l'ENVIRONNEMENT ANSIBLE champ dans Organisations, Projets et Modèles.
Remarque :Dans un scénario avec Ansible Tower exécuté sur OpenShift, les choses sont différentes lorsqu'il s'agit de virtualenvs. C'est un sujet pour un autre article.
5. Dépannage des versions
Quelle version de Python utilisez-vous ?
Une source de problèmes potentiels est liée à la version exacte de Python et de Pip utilisée, ou à la version que les outils voient .
Parfois, vous devez utiliser la ligne de commande pour installer/vérifier les modules Python, il est donc toujours bon de vérifier quelle version de Python vous utilisez.
Par exemple, après avoir activé le virtualenv, vérifiez la version :
source /opt/my-envs/xyz/bin/activate
(xyz) [admin@control my-envs]$ which python
/opt/my-envs/xyz/bin/python
(xyz) [admin@control my-envs]$ which python3
/opt/my-envs/xyz/bin/python3
(xyz) [admin@control my-envs]$ python -V
Python 3.6.8
(xyz) [admin@control my-envs]$ which pip
/opt/my-envs/xyz/bin/pip
(xyz) [admin@control my-envs]$ pip3 -V
pip 20.2.4 from /opt/my-envs/xyz/lib/python3.6/site-packages/pip (python 3.6) Comme vous pouvez le voir dans l'exemple ci-dessus, après l'activation, toutes les commandes pointent vers des chemins dans my virtualenv, ce à quoi vous devriez vous attendre, à moins que vous n'ayez d'autres versions dans votre chemin, et ça pourrait créer des problèmes.
Ceci est particulièrement important si vous faites avoir d'autres versions de Python sur votre serveur. Parfois, vous voudrez peut-être exécuter le pip commande en tant qu'utilisateur root, et ce que root voit comme Python par défaut peut ne pas être ce que votre compte non root voit. Cela entraînerait l'installation du module dans le mauvais environnement Python et les modèles que vous exécutez à partir de Tower ne trouveraient pas le module.
Au lieu d'exécuter sudo pip install module-name , utilisez le chemin complet pour pip pour éviter ce problème. En utilisant mon scénario précédent comme exemple, ce serait :
sudo /opt/my-envs/xyz/bin/pip install module-name Quelle version d'Ansible utilisez-vous ?
Si vous voyez toujours des erreurs comme Aucun module nommé XYZ , vérifiez quelle version d'Ansible vous utilisez à partir de la sortie du modèle :
Correspond-il à la version/l'emplacement que vous avez dans votre environnement virtuel ?
Vous n'avez pas besoin d'installer Ansible dans votre virtualenv, mais gardez à l'esprit que si les playbooks Ansible sont exécutés par une autre instance d'Ansible, il se peut qu'il ne voie pas les modules Python installés dans votre virtualenv.
[ Un guide gratuit de Red Hat :5 étapes pour automatiser votre entreprise. ]
Récapitulez
Virtualenvs est un excellent moyen de créer des scénarios isolés dans lesquels vous pouvez expérimenter différents modules Python/Ansible sans interférer avec les autres modules installés. Les environnements virtuels sont faciles à recréer à partir de zéro. La chose la plus importante à laquelle il faut faire attention est de savoir quel virtualenv est actif et quels binaires vos playbooks utilisent.