Journal Ansible: la version 2.7 beta 1 est disponible

Posté par  . Licence CC By‑SA.
Étiquettes :
20
4
sept.
2018

Cher journal,

Comme tu le sais déjà, je coorganise un atelier Contribuer à Ansible qui se déroulera à Paris le week end du 15/16 septembre. Les inscriptions sont ouvertes jusqu'au 10 septembre, toutes les informations sont disponibles ici.

J'en profite pour te parler de la prochaine version d'Ansible et également d'autres projets liés :)

Nouvelle version beta

La ROADMAP de la version 2.7 est pour l'instant respectée. Le paquet Python de la première beta est disponible sur PyPI. La prochaine branche stable d'Ansible est dorénavant gelée jusqu'à la publication prévu le 4 octobre: cette branche n'accepte plus que les correctifs. Les nouvelles fonctionnalités continuent d'être ajoutées dans la branche devel.

Quelques projets liés à Ansible

Projets existants depuis un certain temps

  • mitogen: une partie du projet est une extension pour Ansible qui améliore les performances, entre autre en utilisant un interpréteur Python persistant sur les nœuds managés. Suite à un crowdfunding, une première version stable numérotée 0.1 a été publiée mi-juillet.

    Les playbooks du projet openshift-ansible fonctionnent avec mitogen. Un déploiement d'OpenShift OKD sur un seul serveur (ok=599 changed=224) hébergé dans un centre de données depuis une connexion ADSL nécessite ~30 minutes; avec mitogen ce temps passe à ~19 minutes (depuis une connexion très haut débit les durées sont respectivement de ~24 min et ~19 min).

    Le support d'openstack-ansible est en cours de développement.

    L'auteur de mitogen a proposé un temps relativement court des modifications upstream, un fork semblerait dorénavant en préparation.

  • molecule: indispensable, ce projet facilite le test de playbooks et de rôles.

    À noter que l'initiative Collaborate together to bring in Molecule de retr0h, principal auteur du projet a été accueillie sans enthousiasme par la core team

    gregdek: I don't think we're going to do that (#ansible-community)
    abadger1999: But I could see us collaborating more in the docs. Not sure what else we'd do (#ansible-devel)

    et n'a pas abouti, retr0h indiquant fin juillet:

    I don't have the time or effort to deal with it (#molecule-users)

  • ARA, permet d'enregistrer et centraliser les journaux d'exécution via un plugin Ansible de type callback et de les rendre accessibles à l'aide d'une interface Web;

  • ansible-container, permettant de créer et orchestrer des containers Docker et dont le développement qui était à l'arrêt depuis février 2018 a repris avec l'acceptation de demandes d’intégration et un nouveau mainteneur. Des limitations d'ansible-container sont listées dans ce retour d'expérience (en anglais).

  • je ne te parlerais pas d'AWX, ce projet nécessitant d'être réinstallé à chaque nouvelle version.

Projets récents

Ces projets ne sont pas encore mentionnés dans la documentation d'Ansible.

  • ansible-runner, issu du projet AWX/Tower, permet de s'interfacer avec Ansible via une API stable. Le projet fournit un outil en ligne de commande, un container Docker et une bibliothèque Python.
  • mazer: un outil expérimental, il nécessite une branche particulière d'Ansible, facilite la gestion des rôles - et à l'avenir des modules ? - différemment de la commande ansible-galaxy.
  • ansible-bender: permet de créer des images Docker à l'aide de la commande ansible-playbook et de buildah.

  • # Cool.

    Posté par  (site web personnel) . Évalué à 7.

    Et sinon, pour les moules trop flemmardes pour cliquer des liens, Ansible, c'est quoi ?

    • [^] # Re: Cool.

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      un programme qui permet d’exécuter des tâches sur une autre machine (ou sur la machine locale), sachant que ces tâches sont programmées dans des fichiers Yaml et qu'elles sont idempotent, c'est à dire que si on relance le script de tâches, elles ne seront pas exécutées une nouvelle fois si il n'y a pas besoin.

      Typiquement Ansible sert à configurer des machines.

      • [^] # Re: Cool.

        Posté par  . Évalué à 10. Dernière modification le 04 septembre 2018 à 18:26.

        qu'elles sont idempotent, c'est à dire que si on relance le script de tâches, elles ne seront pas exécutées une nouvelle fois si il n'y a pas besoin.

        Idempotent ne veut pas dire cela. Ça veut dire que les exécuter une ou N fois mène au même résultat.

        Le fait de chercher à ne pas exécuter une tâche si on peut prouver (pour moins cher) qu'elle a déjà été exécutée est une optimisation. Si c'est plus cher autant simplement la relancer.

        Autrement Ansible c'est un outil de configuration management permettant de définir ses actions en yaml enrobé d'un moteur de template Jinja2. Ca a du vouloir etre déclaratif mais t'as un pseudo langage de programmation (boucles etc.) tout pourri et tout buggé qui ferait passer PHP des années 2000 pour une merveille. Un régal…

        • [^] # Re: Cool.

          Posté par  . Évalué à 4. Dernière modification le 04 septembre 2018 à 18:46.

          Un régal…

          La gueule du code et la façon de transmettre les tâches sur le serveur distant sont eux aussi un régale.

          • [^] # Re: Cool.

            Posté par  (site web personnel) . Évalué à 2.

            et la façon de transmettre les tâches sur le serveur distant sont eux aussi un régale.

            Tu peux développer stp ?

        • [^] # Re: Cool.

          Posté par  (site web personnel) . Évalué à 7.

          t'as un pseudo langage de programmation (boucles etc.)

          Il faut tout de même pondérer par le fait que l'on ne fait pas la même chose avec un langage de programmation classique et avec un langage pour déployer/configurer. En termes d'algorithmes, le second a en gros besoin de boucles pour faire x fois une tâche sur chaque machine, et parfois de trouver où est le serveur maître dans un cluster. Le premier peut gérer des structures mémoire complexes, des exécutions parallèles entrecroisées concurrentes, etc., etc. Une des explications du succès d'Ansible, c'est que c'est assez facile à installer, utiliser et apprendre (ie courbe d'apprentissage à pente douce), par rapport aux premiers outils du genre (comme puppet par exemple).

          Ceci étant dit, le langage Ansible (comme PHP apparemment) s'améliore peu à peu, à condition d'utiliser les versions récentes. Et une partie de l'intérêt est aussi dans la diversité des modules présents.

          • [^] # Re: Cool.

            Posté par  . Évalué à 3.

            En termes d'algorithmes, le second a en gros besoin de boucles pour faire x fois une tâche sur chaque machine, et parfois de trouver où est le serveur maître dans un cluster.

            Alors il n'y en a pas trop besoin pour ça avec ansible. La description de ton infra se fait autrement (et c'est l'un des gros avantage). Par contre dans la pratique tu va potentiellement vouloir prendre chaque fichier de tel dossier et lancer une commande pour chacun.

            Une des explications du succès d'Ansible, c'est que c'est assez facile à installer, utiliser et apprendre (ie courbe d'apprentissage à pente douce), par rapport aux premiers outils du genre (comme puppet par exemple).

            Puppet est un langage de programmation classique ? Ce qui déchire tout avec ansible, c'est sa mise en place douce. Non seulement tu peut commencer à t'en servir facilement (pas besoin de rôle, de comprendre les modules, même pas besoin de comprendre l'idempotence), mais en plus il n'est pas nécessaire de demander à qui que ce soit avant de commencer à t'en servir. Tu n'a pas besoin de serveur ni d'agents. Donc les gens qui s'y intéressent peuvent commencer dans leur coin et montrer l'intérêt que ça a après coup.

            Ceci étant dit, le langage Ansible (comme PHP apparemment) s'améliore peu à peu, à condition d'utiliser les versions récentes.

            Ça restera toujours un langage bancale au dessus de yaml et vaguement inspiré par jinja2. On ne peux pas s'attendre à des choses incroyables quand on pars avec ce genre de base (et ça empire en fait avec loop). Ça donne vraiment l'impression que le projet a commencé en se disant que tout déclaratif c'était bien, puis s'est rendu compte qu'en fait il fallait quand même un peu de procédural…

            Je ne me suis pas lancé dans la création de module, si c'est vraiment simple ça pourrait être une bonne façon de faire je trouve.

            • [^] # Re: Cool.

              Posté par  . Évalué à 6.

              C'est vrai qu'il est très facile de se mettre à Ansible. On commence pas l'utilisé pour mettre à jour un fichier. Puis on rajoute l'install d'un paquet et sa configuration.

              Puis on devient capable d'installer un serveur de zéro avec Ansible.

              On commence alors à l'utiliser pour autre chose comme gérer son ~/.ssh/config, la déclaration des services à surveiller dans le monitoring, l'équipement réseau et bien d'autres.

              Au final, on vire tout le reste et le listing des hosts d'ansible devient la bible.

            • [^] # Re: Cool.

              Posté par  (site web personnel) . Évalué à 3.

              Alors il n'y en a pas trop besoin pour ça avec ansible.

              C'est un des cas les plus courants/basiques :

              hosts: serveurs
tasks:
  - copy:
    (...)
    with_items: (...)

              Je fais x fois une tâche (ici copie de fichier) sur chaque serveur. Donc une boucle sur les serveurs et une autre sur les fichiers.

              • [^] # Re: Cool.

                Posté par  . Évalué à 1. Dernière modification le 05 septembre 2018 à 11:56.

                Justement c'est pas la boucle sur les serveurs qui pose problème, mais la seconde. La première est purement déclarative. Ce n'est pas ce que tu gère avec les loops et si ansible ne gérait pas ça bien on en discuterait pas aujourd'hui. Le problème (les boucles tels qu'elles sont décrites dans la doc d'Ansible) c'est les with_items/loops.

            • [^] # Re: Cool.

              Posté par  . Évalué à 1.

              Je ne me suis pas lancé dans la création de module, si c'est vraiment simple ça pourrait être une bonne façon de faire je trouve.

              Note qu'un module peut être implémenté dans n'importe quel langage (supporté par les hôtes sur lesquels il est utilisé). Exemples: en Go, en PowerShell.

            • [^] # Re: Cool.

              Posté par  . Évalué à 1. Dernière modification le 07 septembre 2018 à 08:28.

              J'ai créé quelques modules simples pour Dokku et franchement, c'est loin d'être facile.
              - C'est difficile à tester, pas évident à déboguer.
              - Chaque module est dans un fichier séparé et indépendant ; je n'ai toujours pas trouvé s'il y a un moyen pour mutualiser du code à part de générer le code avec un préprocesseur ou un moteur de template.

              Bref, autant, en tant que sysadmin du dimanche, c'est bien, mais quand tu commences à vouloir factoriser tes scripts et à remplacer des copier-coller de tâches par des modules, la fête est finie. Il manque vraiment une philosophie de modules en fractales, façon Terraform.

              • [^] # Re: Cool.

                Posté par  . Évalué à 2.

                C'est difficile à tester, pas évident à déboguer.

                Pour les tests: il y a des tests d'intégration qui sont composés de playbooks et des tests unitaires. La commande ansible-test (celle dans le dépôt, pas le dépôt GitHub du même nom) permet de les lancer dans différents containers Docker (Fedora, Ubuntu, etc); la doc pour les tests et celle pour le débogage.

                Chaque module est dans un fichier séparé et indépendant ; je n'ai toujours pas trouvé s'il y a un moyen pour mutualiser du code à part de générer le code avec un préprocesseur ou un moteur de template.

                Le code commun à plusieurs modules doit être mis dans lib/ansible/module_utils, par exemple dans le cas des modules scaleway: https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/scaleway.py

          • [^] # Re: Cool.

            Posté par  . Évalué à 5.

            Il faut tout de même pondérer par le fait que l'on ne fait pas la même chose avec un langage de programmation classique et avec un langage pour déployer/configurer. En termes d'algorithmes, le second a en gros besoin de boucles pour faire x fois une tâche sur chaque machine, et parfois de trouver où est le serveur maître dans un cluster.

            Bien sur.

            Enfin pour un outil de configuration management être capable de stocker de la config sous la forme 

            conf:
  - foo: x1
    bar: y1
    baz: z1
  - foo: x2
    bar: y2
    baz: y3

            puis vouloir appliquer une action pour chaque élément de la liste en utilisant foo et bar. Ne semble pas inconcevable. Pourtant l'année dernière tu tombais encore sur des bugs liés aux loops pour le faire…

            Ansible semble toujours rempli de bug comme ça. Je suis un petit utilisateur et pourtant je suis déjà tombé sur plus de 10 bugs dans les boucles, when & co. Je parle de trucs ou tu finis par identifier une entrée dans le bug tracker qui te confirme que c'est un bug qui est du au fait qu'on a utilisé X pour faire Y mais qu'en fait c'est incompatible avec la sémantique alors si on patche ces trois lignes ca va le faire C'est juste effrayant de bricolage. En regardant les dernières issues ça à toujours l'air d'être la cas.

            Après on peut disserter sur le fait que tu deviens un expert Jinja2 avant de devenir vaguement compétent en Ansible. La plaisir des templates de templates de templates.

            Une des explications du succès d'Ansible, c'est que c'est assez facile à installer, utiliser et apprendre (ie courbe d'apprentissage à pente douce)

            C'est là ou je suis à la fois d'accord et pas d'accord.

            On peut rapidement bricoler quelque chose qui tombe en marche. D'ailleurs la doc n'est constituée que d'exemples. Par contre si tu veux comprendre le truc la doc donne envie de te tirer une balle. La sémantique précise des choses n'est jamais spécifiée tout est exemple et débrouille toi pour inférer la spec. Dans mon monde, ça tombe dans la catégorie des joe le bricolo, ie. nan mais c'est du (json|yaml) c'est simple cough.

            Le nivellement part le bas, hello devops, est totalement en marche :D

            Finalement exposer une API utilisable dans n'importe quel langage de programmation semble à postériori plus viable. Ça permet permet de construire le plan logique avec un outil expressif et robuste qui sera ensuite compilé et exécuté par l'outil spécialisé. Des approches comme https://pulumi.io/ plutôt que les bricolages type Ansible ou Terraform qui mènent à des kilomètres de (Yaml|JSON|HCL) anti-DRY.

            • [^] # Re: Cool.

              Posté par  . Évalué à 3.

              En regardant les dernières issues ça à toujours l'air d'être la cas.
              https://github.com/ansible/ansible/issues/45189
              https://github.com/ansible/ansible/issues/43449
              https://github.com/ansible/ansible/issues/43016

              Les deux premiers bogues ont été corrigés par la même demande d'intégration ;)

              Des efforts ont été faits avec la version 2.6 qui était une version dite de stabilité se concentrant notamment sur les correctifs et les tests: peu de fonctionnalités supportées par la core team ont été ajoutées.

              Historiquement le projet n'a pas une culture des tests: les tests sont insuffisants et non systématiques mais cela va tout de même dans le bon sens. Le comportement de certaines fonctionnalités changent parfois de manières importantes sur plusieurs versions, je pense notamment à include_tasks qui a été ajouté en 2.4:

              À noter que le module import_tasks est toujours en preview: la rétro compatibilité n'est pas garantie.

              D'ailleurs la doc n'est constituée que d'exemples.

              Cette affirmation me semble incorrecte, au hasard une page de la doc. Depuis la version 2.5, la qualité de la documentation a été grandement améliorée (table des matières à plusieurs niveaux, réorganisation, recherche).

              • [^] # Re: Cool.

                Posté par  . Évalué à 0.

                Correction: apply sera disponible avec la 2.7.

          • [^] # Re: Cool.

            Posté par  (site web personnel) . Évalué à 2.

            Si on veut un vrai langage, puppet est peut-être une meilleure solution : les template se codent en ruby.

  • # fork?

    Posté par  . Évalué à 4.

    un fork semblerait dorénavant en préparation.

    J'ai lu rapidemment mais je n'ai pas compris qui forkait quoi et pourquoi. Je crois que je manque de contexte.

    Sinon, merci pour le journal.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: fork?

      Posté par  . Évalué à 1.

      un fork semblerait dorénavant en préparation.

      J'ai lu rapidemment mais je n'ai pas compris qui forkait quoi et pourquoi. Je crois que je manque de contexte.

      L'auteur de mitogen, qui en parle dans ce texte - que je trouve pas très clair, d'où le conditionnel.

      Sinon, merci pour le journal.

      De rien :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.