J’ai écrit un article sur Ansible et le projet DebOps en décembre dernier.
Le projet DebOps (qui repose sur Ansible) me semble intéressant pour les CHATONS pour les raisons suivantes :
l’infrastructure est représentée comme du code donc versionnable
l’infrastructure peut être reproduite donc réinstallée facilement
les fichiers représentant l’infrastructure peuvent être partagée entre plusieurs chatons. Ce qui permet de gagner du temps dans la configuration et la mise à disposition de services
l’infrastructure est documentée
Par ce sujet, je voulais savoir si certains CHATONS utilisent déjà Ansible et/ou DebOps et seraient intéressé pour administrer leurs systèmes avec ce type d’outils.
On utilise Ansible ainsi que DebOps au travail pour gérer certaines infrastructures composées de machines sous Ubuntu.
Dans l’ensemble les rôles DebOps sont plutôt bien pensés et les intégrations bien réalisées, je regrette cependant le choix de certains outils comme Ferm pour la gestion du pare-feu local.
L’utilisation de EncFS et GPG pour le chiffrement des secrets est aussi contestable.
Sinon de manière plus globale, l’Infrastructure As Code est de nos jours une pratique incontournable qui s’inscrit dans une approche moderne de gestion des infrastructures et de développement.
Nous utilisons aussi Ansible mais je ne connaissais pas DebOps.
Tu as raison c’est important d’avoir une infra maîtrisée et homogène.
On gère tout le versionnage dans notre GitLab et on publie nos rôles ici : https://github.com/lefilament/ansible
Pour reflexlibre, je déploie les serveurs avec le rôle ansible-yunohost, pour des maintenances qui affectent tous les serveurs je le fait via ansible aussi (mais juste en cli). Par contre pour résoudre un dysfonctionnement, faire une optimisation particulière que je ne referais pas, je le fais à la main.
Enough utilise ansible et debops pour postfix. J’appréhende un peu la transition vers la version 2 Initialement molecule était utilisé pour les tests d’intégration. Mais depuis que l’auteur originel a passé la main le projet n’a pas vraiment retrouvé sa dynamique alors c’est tox qui est utilisé à la place. L’infrastructure as code c’est bien mais l’outillage fait parfois un peu défaut, surtout pour les tests d’upgrade.
Pour mon petit chaton en gestation, j’utilise Ansible. Par contre, je découvre DebOps.
Mon niveau est encore débutant. Peut-être que j’utilise mal Ansible, mais je n’en suis pas complètement satisfait. En gros, je trouve qu’il faut souvent ruser avec Ansible pour faire en sorte que cela soit rapide. Par exemple, je fais des tests pour savoir si la configuration a changé et ne déclenche que l’action changeante pour éviter de tout faire d’un bloc. Au final, beaucoup de description de tâches qui semblent complexes pour pas grand chose.
Autre remarque, je trouve que copier un fichier avec LXC prend trop de temps alors que en ligne de commande, c’est + rapide, plein de petits détails comme ça qui me chiffonnent, etc…
Tout dépend de comment tu t’y prends pour détecter les changements d’un fichier de config. Cela ne me semble pas quelque chose de compliqué et ça se règle facilement.
La courbe d’apprentissage est longue, de mon expérience. Pour trouver comment utiliser Ansible j’ai du passer beaucoup de temps à apprendre une façon de faire qui fonctionne et éviter de tomber dans des patterns qui ne fonctionnent pas (pour moi en tout cas ). Bon courage
Attention à la configuration de ton ssh qui peut jouer. Je t’invite à regarder ControlMaster, ControlPath et associés. Après sur un grand nombre de noeuds tu as des choses comme mitogen mais je ne l’ai pas testé.
En fait je voulais savoir si tu utilisais le projet DebOps via le programme python debops (présenté dans l’article mentionné ci-dessus) ou uniquement les collections DebOps depuis Ansible Galaxy. D’après ton dernier post, je pense que tu utilises uniquement les collections.
Selon moi, le projet DebOps prend tout son sens quand on utilise le programme python debops car on bénéficie, en plus des rôles, :
de playbooks extrêmement bien pensés et architecturés.
d’une organisation par projets
d’un respect des bonnes pratiques Ansible
d’une gestion des secrets
Cependant, si on s’en sert pour « bootstrapper » des nœuds, l’utilisation du programme debops peut être un peu déroutante au début car il gère énormément de services sur un hôte et il faut être prêt à basculer sur une utilisation complète d’Ansible.
Je suggère aux personnes qui débutent de commencer par utiliser la collection debops puis de tendre vers une utilisation du programme python debops. J’ai écrit l’article mentionné précédemment comme un pas à pas pour démarrer avec.
Ok, c’est bien noté.
Merci pour les TP, ils ont l’air bien pratiques en effet.
De mon côté, je pense avoir sous-estimé mon niveau avec Ansible, plutôt intermédiaire. Il faudrait que je reprenne certains de mes playbooks, mais de mémoire, j’avais l’impression de jongler avec certaines particularités de Ansible, prévoir des tableaux de variables, créer des variables intermédiaires pour tester des conditions, etc… et au final, ça devenait difficilement lisible et maintenable dans la longue durée.
Voila, je ne sais pas si certains d’entre vous ont déjà ressenti ce type de problème, ou si c’est uniquement moi qui a du mal à raisonner sous forme déclarative.
Actuellement, j’ai plutôt l’idée de sortir de Ansible et de restructurer mes playbooks/roles existants vers quelque chose de + léger et + proche d’un langage de programmation, peut-être à base de ION Shell, un truc comme ça… Ça reste un projet en état de gestation…
Mon ressenti sur Ansible : il est très simple à prendre en main, on peut vite faire des choses intéressantes mais il faut avoir de bonnes bases et bien connaître les fonctionnalités disponibles.
Non non, nous utilisons le wrapper debops et les platebook de base (les common notamment), mais bon comme je te disais l’outil n’est pas parfait :
Le PKI qui ne génère pas nativement le renouvellement des certificats expirés (on a solutionné ça avec le système de hook).
L’utilisation de Ferm pour le firewall est problématique lorsque des outils tierces génèrent des règles pare-feu, comme c’est le cas avec Docker.
L’utilisation de EncFS pour le chiffrement du répertoire contenant les secrets n’apportent pas une sécurité suffisante, cette technologie étant d’un point de vue cryptographique dépassée. J’aurais aimé pouvoir configurer DebOps pour qu’il stocke les fichiers générés (passwords et PKI) sur un backend de type S3.
Après franchement l’outil en lui même n’apporte pas grand chose, on peut très bien se contenter d’ansible.
De plus, comme on ne travaille pas qu’avec de debian-like, on ne peut se contenter de debops uniquement. Et franchement, plus le temps passe plus je préfère bosser sur du CentOS ou équivalant, je trouve plus qualitatif et plus stable.
Juste une petite pierre à l’édifice, attention aux installations avec un latest explicite (ou implicite sans préciser de versions) comme vu dans les TP des liens, une de mes plus grosse crise en prod est venue de là, ça induit des comportements non déterministes qui ne sont pas forcément visibles sur les environnements hors prod (si les dépôts configurés ne sont pas les mêmes ou que des paquets ont été ajoutés entre temps).
Merci pour ta remarque qui est tout à fait justifiée. Lorsque je réalise les TP avec les apprenants, je pose toujours la question de la différence entre latest et present pour amener à la réflexion.
Sur tes conseils, je vais ajouter une note dans la corrigé pour les personnes qui réaliseraient les TP en autonomie.
Chez Pâquerette on utilise ansible et Yunohost pour nos déploiement.
J’ai fait un peu de nettoyage dans le projet pour pouvoir le partager et le voici : https://git.paquerette.eu/paquerette/infrastructure/ansible-paquerette
Il y a des utilitaires et les rôles que nous utilisons.
J’espère avoir le temps de faire un article sur notre site pour donner un peu plus d’explication.
En attendant, n’hésitez pas à commenter cela nous permettra certainement de nous améliorer.
Initialement 
). Bon courage 