Apr\u00e8s avoir r\u00e9organis\u00e9 l’ensemble de mes r\u00f4les Ansible, j’avais en t\u00eate de trouver un moyen de tester leur ex\u00e9cution dans un environnement vierge. L’id\u00e9e n’est pas nouvelle. Le but : v\u00e9rifier l’ex\u00e9cution du r\u00f4le plus facilement, c’est-\u00e0-dire, sans savoir \u00e0 installer une nouvelle VM, ou \u00e0 louer un serveur \u00e0 cette occasion, m\u00eame si cette derni\u00e8re solution est, par exp\u00e9rience : pratique, assez rapide \u00e0 mettre en \u0153uvre et d’un faible co\u00fbt en utilisant un serveur factur\u00e9 \u00e0 l’heure.<\/p>\n\n\n\n
Ayant parcouru quelques d\u00e9p\u00f4ts de r\u00f4le Ansible pr\u00e9sent sur Ansible Galaxy et ayant sauvegard\u00e9 quelques articles \u00e9voquant le sujet, j’avais donc une id\u00e9e des outils disponibles et des exemples fonctionnels. Il ne restait plus qu’\u00e0 se retrousser les manches, et \u00e0 tenter l’impl\u00e9mentation sur l’un de mes r\u00f4les les plus simples consistant \u00e0 installer fail2ban.<\/p>\n\n\n\n
Premi\u00e8re \u00e9tape avant configuration, l’installation des outils qui permettront de tester le r\u00f4le en ex\u00e9cutant une seule commande, \u00e0 savoir : Molecule<\/a> et virtualenv<\/a>. Avec python3 install\u00e9, je commence donc par installer \u00c9tape suivante, l’installation de molecule via pip.<\/p>\n\n\n\n Maintenant que les outils sont install\u00e9s, je g\u00e9n\u00e8re la configuration de base<\/a> avec la commande: Comme j’utilise docker pour la gestion de l’instance de test, je suis les pr\u00e9conisations de la documentation pour v\u00e9rifier que docker fonctionne correctement.<\/p>\n\n\n\n Une fois l’environnement pr\u00eat, je peux passer \u00e0 l’ex\u00e9cution du test.<\/p>\n\n\n\n En th\u00e9orie, ce premier test devrait au minimum r\u00e9ussir jusqu’\u00e0 l’\u00e9tape de v\u00e9rification, en fonction des modifications effectu\u00e9es dans Il convient de noter que, si le r\u00f4le ansible utilise La configuration que je d\u00e9crite \u00e0 la suite permet donc de tester un r\u00f4le relativement simple, que j’utilise pour installer fail2ban \u00e0 partir de l’un des paquets deb du projet. Paquet distribu\u00e9 dans la partie release du projet GitHub. Commen\u00e7ons par le fichier Cette configuration pr\u00e9sente quelques adaptations par rapport \u00e0 la configuration par d\u00e9faut. En particulier, du c\u00f4t\u00e9 de Apr\u00e8s quelques tentatives de tests et d’erreur au d\u00e9marrage du service fail2ban, derni\u00e8re \u00e9tape de mon r\u00f4le, je constate que ssh ne semble pas install\u00e9 par d\u00e9faut dans l’image docker choisie. Probl\u00e8me, fail2ban sous debian active par d\u00e9faut une jail pour ssh et se plaint donc de ne pas trouver les fichiers de logs pour ssh. Ces quelques lignes ont donc pour but d’installer ssh et de d\u00e9marrer le service associ\u00e9. On pourrait discuter du fait que ces v\u00e9rifications devraient \u00eatre port\u00e9es par le r\u00f4le, mais cela ne me semble pas pertinent, \u00e9tant donn\u00e9 que mon utilisation du r\u00f4le se fait toujours dans le cas d’une installation sur une machine \u00e0 laquelle j’acc\u00e8de via ssh. Le service est donc toujours pr\u00e9sent dans ma situation.<\/p>\n\n\n\n Vient ensuite le fichier Enfin Voil\u00e0 pour la configuration du test de mon r\u00f4le d’installation de fail2ban.<\/p>\n\n\n\n Apr\u00e8s une premi\u00e8re soir\u00e9e pass\u00e9e sur le sujet du test d’un r\u00f4le ansible, je suis plut\u00f4t satisfait du r\u00e9sultat. Bien que le r\u00f4le soit l’un de mes r\u00f4les les plus simples, cela ne devrait pas \u00eatre trop compliqu\u00e9 de g\u00e9n\u00e9raliser cette m\u00e9thode \u00e0 l’ensemble de mes r\u00f4les, mais cela n\u00e9cessitera sans aucun doute de nombreuses heures de d\u00e9veloppement. Comme souvent, c’est un processus it\u00e9ratif qui sera effectu\u00e9 progressivement sur les prochains mois. La simplicit\u00e9 de r\u00e9aliser un test sur un syst\u00e8me vierge est vraiment appr\u00e9ciable et permettra de v\u00e9rifier qu’un r\u00f4le modifi\u00e9 fonctionne toujours, et cela, sans avoir \u00e0 passer par le d\u00e9ploiement d’un serveur vierge. Prochaines \u00e9tapes : \u00e9tudier l’int\u00e9gration avec le syst\u00e8me d’actions GitHub et tester le playbook permettant le d\u00e9ploiement automatique d’Unicoda.<\/p>\n\n\n\n Apr\u00e8s avoir r\u00e9organis\u00e9 l’ensemble de mes r\u00f4les Ansible, j’avais en t\u00eate de trouver un moyen de tester leur ex\u00e9cution dans un environnement vierge. L’id\u00e9e n’est pas nouvelle. Le but : v\u00e9rifier l’ex\u00e9cution du r\u00f4le plus facilement, c’est-\u00e0-dire, sans savoir \u00e0 installer une nouvelle VM, ou \u00e0 louer un serveur \u00e0 cette occasion, m\u00eame si cette … Continuer la lecture de « Test d’un role Ansible »<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[337,316,31],"tags":[522,575,576,246],"class_list":["post-4520","post","type-post","status-publish","format-standard","hentry","category-auto-hebergement","category-configuration","category-installation","tag-ansible","tag-molecule","tag-role","tag-test"],"_links":{"self":[{"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/posts\/4520","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=4520"}],"version-history":[{"count":14,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/posts\/4520\/revisions"}],"predecessor-version":[{"id":4548,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/posts\/4520\/revisions\/4548"}],"wp:attachment":[{"href":"https:\/\/www.unicoda.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=4520"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=4520"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=4520"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}virtualenv<\/code> via: pip install virtualenv<\/code>. J’initialise ensuite un environnement virtuel python avec virtualenv dans le dossier contenant mon r\u00f4le ansible, soit les commandes :<\/p>\n\n\n\n$ pip3 install virtualenv\n$ virtualenv -p python3 .venv\n$ source .venv\/bin\/activate<\/pre>\n\n\n\n
$ pip3 install --upgrade setuptools\n$ pip3 install 'molecule[ansible,docker,lint]'<\/pre>\n\n\n\n
Configuration basique<\/h4>\n\n\n\n
molecule init scenario<\/code>. Cette commande a pour effet de cr\u00e9er quatre fichiers.<\/p>\n\n\n\nINSTALL.rst<\/code> : contient des instructions pour l’installation d’autres d\u00e9pendances, ou des \u00e9tapes de configuration \u00e0 r\u00e9aliser. Dans mon cas, installation de molecule[docker]<\/code>, que j’ai donc directement int\u00e9gr\u00e9 dans la commande cit\u00e9e pr\u00e9c\u00e9demment.<\/li>molecule.yml<\/code> : fichier principal d\u00e9crivant les outils utilis\u00e9s pour le test. <\/li>converge.yml<\/code> : le playbook ansible charg\u00e9 de d\u00e9ployer le r\u00f4le test\u00e9.<\/li>verify.yml<\/code> : un fichier ansible permettant de d\u00e9crire les v\u00e9rifications \u00e0 effectuer apr\u00e8s d\u00e9ploiement du r\u00f4le.<\/li><\/ul>\n\n\n\n$ docker run hello-world<\/pre>\n\n\n\n
$ molecule test<\/pre>\n\n\n\n
verify.yml<\/code>. En cas d’erreur, je trouve tr\u00e8s utile d’ex\u00e9cuter manuellement les diff\u00e9rentes \u00e9tapes de molecule test<\/code>. A savoir:<\/p>\n\n\n\nmolecule create<\/code> : Cr\u00e9ation de l’instance.<\/li>molecule converge<\/code>: D\u00e9ploiement du r\u00f4le.<\/li>molecule login<\/code> : Connexion \u00e0 l’instance pour aller explorer son \u00e9tat, tr\u00e8s pratique en cas d’erreur.<\/li>molecule verify<\/code> : Ex\u00e9cuter les v\u00e9rifications.<\/li>molecule destroy<\/code> : Nettoyage.<\/li><\/ol>\n\n\n\nservice<\/code> pour v\u00e9rifier l’\u00e9tat d’un service, la configuration par d\u00e9faut pr\u00e9sente dans le fichier converge.yml<\/code> n’est pas suffisante. J’ai \u00e9t\u00e9 bloqu\u00e9 un bon moment avant de trouver des pr\u00e9cisions \u00e0 ce sujet au d\u00e9tour d’une issue sur Github. C’est pourquoi je vais maintenant d\u00e9crire la configuration que j’ai mise en place.<\/p>\n\n\n\nCas concret<\/h4>\n\n\n\n
molecule.yml.<\/code><\/p>\n\n\n\n---\ndependency:\n name: galaxy\ndriver:\n name: docker\n<\/em>platforms:\n - name: instance\n image: geerlingguy\/docker-debian10-ansible:latest\n command: ${MOLECULE_DOCKER_COMMAND:-\"\"}\n volumes:\n - \/sys\/fs\/cgroup:\/sys\/fs\/cgroup:ro\n privileged: true\n pre_build_image: true\nprovisioner:\n name: ansible\n playbooks:\n prepare: prepare.yml\nverifier:\n name: ansible<\/pre>\n\n\n\nplatforms<\/code>, o\u00f9 les instructions command<\/code> et volumes<\/code> sont n\u00e9cessaires pour que l’instruction service<\/code> dans ansible soit fonctionnelle. Notons aussi l’ajout de prepare<\/code> dans provisioner<\/code>. Cet ajout a pour but d’effectuer quelques actions suppl\u00e9mentaires sur l’instance juste apr\u00e8s son installation et avant de commencer le d\u00e9ploiement du r\u00f4le. Le contenu du fichier prepare.yml<\/code> est le suivant :<\/p>\n\n\n\n---\n- name: Prepare\n hosts: all\n become: true\n tasks:\n - name: Install ssh\n apt:\n name: [ 'ssh' ]\n state: present\n update_cache: yes\n cache_valid_time: 3600\n - name: restart ssh\n service:\n name: ssh\n state: restarted<\/pre>\n\n\n\n
converge.yml<\/code>. Pas de modification de ce c\u00f4t\u00e9 l\u00e0.<\/p>\n\n\n\n---\n- name: Converge\n hosts: all\n become: true\n tasks:\n - name: \"Include role-install-fail2ban\"\n include_role:\n name: \"role-install-fail2ban\"<\/pre>\n\n\n\n
verify.yml<\/code> dernier fichier de configuration. Pour un premier test, j’ai fait au plus simple et je me contente de v\u00e9rifier que fail2ban fait bien partie des paquets install\u00e9s sur le syst\u00e8me.<\/p>\n\n\n\n---
- name: Verify
hosts: all
tasks:
- name: Gather package facts
package_facts:
manager: auto
- name: Verify Packages
assert:
that: \"'{{ item }}' in ansible_facts.packages\"
with_items:
- fail2ban<\/pre>\n\n\n\nConclusion<\/h4>\n\n\n\n
Sources<\/h4>\n\n\n\n