Intérêt pour Ansible

#1

Bonjour,

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.

Merci pour vos retours.

2 Likes
#2

Salut,

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.

1 Like
#3

Bonjour,

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

2 Likes
#4

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.

1 Like
#5

Merci pour ta réponse @aselkim.

Par curiosité, est-ce que tu utilises l’ensemble des rôles DebOps pour administrer tes nœuds ou uniquement certains rôles ?

1 Like
#6

On utilise de DebOps les roles de base (secret, ferm, sysctl, PKI) ainsi que certains rôles plus spécialisés (Docker, Elasticsarch,…).

On utilise en plus de ça des rôles tierces ou fait-maison lorsqu’il n’y pas de role DebOps répondant à nos besoins.

Il y a certains patterns intéressants dans DebOps que nous reprenons dans nos rôles développés en interne.

Je ne sais pas si je réponds correctement à ta question, n’hésites pas si tu as besoin d’avantage d’infos.

1 Like
#7

Enough utilise ansible et debops pour postfix. J’appréhende un peu la transition vers la version 2 :stuck_out_tongue: 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.

1 Like
#8

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…

1 Like
#9

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.

1 Like
#10

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 :wink: ). Bon courage :strawberry:

1 Like
#11

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é.

#12

Quelques liens intéressants pour améliorer les performances d’Ansible :

#13

Bonjour @aselkim,

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.

#14

Bonjour @pvincent,

Si ça peut t’aider à y voir plus clair, je publie les travaux pratiques que j’utilise lors des formations Ansible que je réalise :

Tu peux normalement réaliser les TP en utilisant Vagrant et Virtualbox sur ta machine.

Bon courage.

3 Likes
#15

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…

1 Like
#16

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.

2 Likes
#17

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.

1 Like