Présentation d'Ansible et version 2 à venir

39
5
avr.
2015
Technologie

Ansible est un outil de la mouvance actuelle autour du DevOps. J'ai commencé à aborder son fonctionnement il y a maintenant quelques mois et force est de constater que sa prise en main est beaucoup plus simple que d'autres produits ayant la même finalité, ceci pour plusieurs raisons :

  • l'apprentissage du langage est très rapide ;
  • il n'y a pas d'infrastructure à gérer : pas de serveur central (j'y reviendrai un peu plus tard) et surtout pas d'agent.

logo Ansible

Sommaire

Pas d'agent

Et oui, ni agent Puppet/Chef et ni Puppet master/server à installer. À partir du moment où vous avez un serveur SSH sur votre machine à gérer, elle est potentiellement éligible à la gestion via Ansible. Même la machine permettant de lancer les opérations Ansible peut n'être qu'un banal poste Linux avec les ouvertures de flux qui vont bien.

L'autre gros point positif vient du langage en lui même qui est très simple à aborder. Pour faire une analogie, on retrouve le pouvoir descriptif d'un Puppet sans l'aspect prise de tête (les dépendances). En effet, un playbook Ansible exécute ses opérations séquentiellement. Pas besoin de dire que la création de l'utilisateur tif dépend du groupe poil : il suffit de le déclarer en premier et le groupe sera créé en premier.

Les seuls aspects que je trouve perfectibles viennent de l'expressivité du langage (qui reste pour l'instant inférieur à Puppet par exemple) et la vitesse d'exécution qui est là encore en deça d'un Agent Puppet (surtout sur les tâches complexes).

Pour info, avant de faire de l'Ansible, j'ai fait pas mal de choses avec Puppet pour industrialiser des déploiements de serveurs d'application (type java J2EE). Là où l'agent Puppet ne repassera pas sur les éléments déjà présents et/ou conformes, Ansible procédera à une vérification séquentielle qui peut être significativement plus longue. Mais bon, je vous rassure, ça reste généralement très acceptable.

Installation

Plusieurs solutions possibles pour l'installation :

  • via l'utilisation de package rpm ou deb ;
  • via l'utilisation de pip install ;
  • enfin directement à l'aide du code source.

Sous RHEL/CentOS, après avoir activé les ressources epel, il suffira de l'installer avec la commande suivante :

yum install ansible

Sous Ubuntu, il faut ajouter la source ppa ansible avec la commande suivante :

sudo apt-add-repository ppa:ansible/ansible

Suivi du traditionnel apt-get update/install :

apt-get update && apt-get install ansible.

Pour l'installation à l'aide de pip, il faut utiliser la commande suivante :

pip install ansible

Enfin, pour l'utilisation via le code source, il vous faudra exécuter un git clone :

git clone git://github.com/ansible/ansible.git
cd ansible
make install

Première utilisation

Nous allons créer un fichier hosts dans le répertoire courant de l'utilisateur avec la liste des machines que nous allons gérer :

localhost ansible_connection=local

[backup]
robert

[desktop]
gertrude

Ce fichier d'inventaire indique que robert servira à faire des sauvegardes et gertrude sera une bête machine desktop (mon poste de travail). Pour la machine localhost, nous avons ajouté l'option ansible_connection=local pour indiquer qu'il s'agit d'une machine accessible directement en local sans passer par une connexion SSH.

Il nous faut maintenant configurer la communication SSH avec les machines à gérer. Pour ce faire, nous allons échanger les clés SSH avec les différentes machines distantes. Pour ma part, j'utilise beaucoup la commande ssh-copy-id pour initier cet échange de clés, mais rien ne vous empêche de le faire par le mécanisme qu'il vous plaira (et bien sûr, on peut aussi le faire avec Ansible pour peu que l'on dispose de l'utilitaire sshpass).

Exemple d'échange de clés entre mon utilisateur et la machine distante robert en tant que root :

ssh-copy-id root@robert

NB : pour éviter d'ajouter root@ devant robert, je fais souvent appel au fichier ~/.ssh/config. En effet, il est possible de spécifier l'utilisateur par défaut. Ci-dessous un exemple pour la machine robert :

Host robert
  User root

Maintenant que notre échange de clés est réalisé, il est possible de faire un test de création de fichier avec la commande suivante :

ansible -i hosts -l localhost -m file -a "path=/tmp/test state=touch" all

Dans ce test, nous allons appeler le module file afin de créer un fichier vide /tmp/test sur la machine localhost (grâce à l'option de restriction -l localhost). Si tout se passe bien, nous devrions avoir le résultat suivant sur la ligne de commande :

$ ansible -i hosts -l localhost -m file -a "path=/tmp/test state=touch" all 
localhost | success >> {
    "changed": true, 
    "dest": "/tmp/test", 
    "gid": 1000, 
    "group": "yannig", 
    "mode": "0644", 
    "owner": "yannig", 
    "size": 0, 
    "state": "file", 
    "uid": 1000
}

Rien de particulier à signaler, mais vous pouvez maintenant lancer n'importe quel module Ansible. Vous pourriez tout à fait imaginer lancer un arrêt/relance de démon ou la mise à jour d'un paquet système suite à la découverte d'une nouvelle faille SSL/NTP/DNS/noyau (rayer la mention inutile).

Pour faire une analogie avec Puppet, il s'agit de l'équivalent de mcollective (sans l'aspect middleware de communication puisque tout passe par SSH).

Création d'un premier playbook

Nous avons maintenant la possibilité de lancer des opérations unitaires. Passons alors à l'écriture d'un premier playbook qui va nous permettre de chaîner un ensemble d'opérations.

Notre premier playbook

Pour ce faire, nous allons écrire un playbook qui va mettre à jour la configuration du serveur de temps de notre machine. Les opérations sont assez simples et vont consister à :

  • s'assurer de la présence du package ntpd sur la machine ;
  • mettre à jour le fichier /etc/ntp.conf ;
  • faire un arrêt/relance le cas échéant.

Vous vous en doutez, ces opérations se réalisent en trois lignes de description Ansible. Pour simplifier les choses, nous nous mettrons uniquement dans le contexte d'une distribution de type RHEL/CentOS/Fedora. Voici cette première version :

---
# Playbook de gestion de NTP
- name: "NTP configuration"
  hosts: all
  remote_user: root
  tasks:
    - name: "NTP package"
      yum: name=ntp state=installed
    - name: "NTP configuration"
      template: src=ntp.conf.j2 dest=/etc/ntp.conf
    - name: "NTP restart"
      service: name=ntpd state=restarted enabled=yes

Il faudra également stocker le fichier ntp.conf.j2 au même emplacement. Ci-dessous son contenu :

#{{ ansible_managed }}

driftfile /var/lib/ntp/drift
restrict default nomodify notrap nopeer noquery
restrict 127.0.0.1 
restrict ::1
{% for i in ntp_servers %}
server {{ i }}
{% endfor %}

includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys
disable monitor

Nous allons également ajouter un fichier group_vars/all (au même niveau que le fichier hosts) avec le contenu suivant afin de pouvoir gérer la liste de serveur NTP :

---
ntp_servers: [ "192.168.0.1", "192.168.0.2" ]

Lancement du playbook

Un rapide lancement pour voir ce que ça donne :

$ ansible-playbook -i hosts -l robert ntp.yml

PLAY [NTP configuration] ****************************************************** 

GATHERING FACTS *************************************************************** 
ok: [robert]

TASK: [NTP package] *********************************************************** 
changed: [robert]

TASK: [NTP configuration] ***************************************************** 
changed: [robert]

TASK: [NTP restart] *********************************************************** 
changed: [robert]

PLAY RECAP ******************************************************************** 
robert                     : ok=4    changed=3    unreachable=0    failed=0   

Comme on peut le voir, ça semble bien fonctionner. Relançons notre playbook pour voir le comportement d'Ansible :

$ ansible-playbook -i hosts -l robert ntp.yml

PLAY [NTP configuration] ****************************************************** 

GATHERING FACTS *************************************************************** 
ok: [robert]

TASK: [NTP package] *********************************************************** 
ok: [robert]

TASK: [NTP configuration] ***************************************************** 
ok: [robert]

TASK: [NTP restart] *********************************************************** 
changed: [robert]

PLAY RECAP ******************************************************************** 
robert                     : ok=4    changed=1    unreachable=0    failed=0   

Petit problème : le serveur NTP est systématiquement relancé alors que notre fichier de configuration n'a pas bougé…

Introduction du handler

Pour éviter cet arrêt/relance intempestif, la méthode la plus naturelle est de passer par un mécanisme de handler. Voici ce que ça donne dans notre cas :

---
# Playbook de gestion de NTP
- name: "NTP configuration"
  hosts: all
  remote_user: root
  tasks:
    - name: "NTP package"
      yum: name=ntp state=installed
    - name: "NTP configuration"
      template: src=ntp.conf.j2 dest=/etc/ntp.conf
      # Notification du handler de redémarrage
      notify: "NTP restart" 

  # Section handler
  handlers:
    - name: "NTP restart"
      service: name=ntpd state=restarted enabled=yes

Relançons maintenant notre playbook :

$ ansible-playbook -i hosts toto.yml 

PLAY [NTP configuration] ****************************************************** 

GATHERING FACTS *************************************************************** 
ok: [robert]

TASK: [NTP package] *********************************************************** 
ok: [robert]

TASK: [NTP configuration] ***************************************************** 
ok: [robert]

PLAY RECAP ******************************************************************** 
robert                     : ok=3    changed=0    unreachable=0    failed=0

Nous voyons que le redémarrage n'a plus lieu, évitant des opérations inutiles.

Nouveautés v2

La progression du projet Ansible a été très rapide et, comme souvent, l'évolution a été un peu anarchique. Partant de ce constat, les auteurs ont donc eu besoin de remettre les choses à plat. Il s'agit pour l'essentiel d'une réécriture, mais la version 2 apportera également quelques nouveautés. À noter que les auteurs assurent qu'il ne devrait pas y avoir de régression sur les playbooks existants.

Bloc d'instructions

Un des plus gros défauts du langage d'Ansible vient de la gestion des boucles. Prenons un exemple tout simple en créant une liste d'utilisateurs. Cette opération peut se réaliser à l'aide du playbook suivant :

---
# Playbook de création d'utilisateurs
- name: "Création d'utilisateurs"
  hosts: all
  remote_user: root
  vars:
    - users_to_create: [ 'alain', 'gerard' ]
  tasks:
    - name: "Creation des utilisateurs"
      user: name={{item}}
      # Boucle sur les utilisateurs
      with_items: users_to_create

Maintenant, si nous voulons en profiter pour mettre à jour le fichier bash profile, nous allons devoir procéder avec une seconde boucle :

  tasks:
    - name: "Creation des utilisateurs"
      user: name={{item}}
      # Boucle création utilisateurs
      with_items: users_to_create
    - name: "MAJ profile"
      template: src=profile.j2 dest=/home/{{item}}/.bash_profile
      # Boucle MAJ profile utilisateurs
      with_items: users_to_create

Bref, il manque une notion d'itération sur un ensemble d'instructions. Cette prochaine version devrait y répondre. Ci-dessous un exemple de ce que devrait pouvoir offrir la version 2 d'Ansible :

  tasks:
    - include: instructions.yml user={{item}}
      with_items: users_to_create

Avec le fichier instructions.yml contenant les instructions suivantes :

- name: "Creation des utilisateurs"
  user: name={{item}}
- name: "MAJ profile"
  template: src=profile.j2 dest=/home/{{item}}/.bash_profile

Ci-dessous un exemple de lancement avec la version actuelle d'Ansible v2 :

$ ansible-playbook test/bloque.yml -l localhost -c local

PLAY: Création d'utilisateurs ****************************************************

TASK [setup] ********************************************************************
ok: [localhost]

TASK [include user={{item}}] ****************************************************
{'item': u'alain', 'include': u'instructions.yml', 'include_variables': {u'user': u'alain'}, 'changed': True}
{'item': u'gerard', 'include': u'instructions.yml', 'include_variables': {u'user': u'gerard'}, 'changed': True}
included: instructions.yml for localhost

TASK [Creation des utilisateurs] ************************************************
ok: [localhost]

TASK [MAJ profile] **************************************************************
ok: [localhost]

TASK [Creation des utilisateurs] ************************************************
ok: [localhost]

TASK [MAJ profile] **************************************************************
ok: [localhost]

PLAY RECAP **********************************************************************
localhost                  : ok=6    changed=1    unreachable=0    failed=0

Gestion des exceptions

Dans la même idée, Ansible devrait voir arriver la gestion des exceptions. Ci-dessous un exemple faisant appel à cette nouvelle notion :

---
# Playbook d'exception
- name: "Test exception"
  hosts: "all"
  tasks:
  - block:
      - command: "/bin/false"
      - debug: msg="Ceci n'est pas lance"
    rescue:
      - debug: msg="Nous avons eu une exception"
      - command: "/bin/false"
      - debug: msg="Nous ne pouvons pas etre ici"
    always:
      - debug: msg="Dans tous les cas, nous passons ici"

Ci-dessous le résultat de l'exécution de ce playbook :

$ ansible-playbook exception.yml -l localhost -c local

PLAY: Test exception ************************************************************

TASK [setup] ********************************************************************
ok: [localhost]

TASK [command] ******************************************************************
fatal: [localhost]: FAILED! => {"changed": true, "end": "2015-04-05 10:44:04.632739", "stdout": "", "cmd": ["/bin/false"], "start": "2015-04-05 10:44:04.631280", "delta": "0:00:00.001459", "stderr": "", "rc": 1, "invocation": {"module_name": "command", "module_args": {"_raw_params": "/bin/false"}}, "stdout_lines": [], "warnings": []}

TASK [debug msg=Nous avons eu une exception] ************************************
ok: [localhost] => {
    "msg": "Nous avons eu une exception", 
    "changed": false
}

TASK [command] ******************************************************************
fatal: [localhost]: FAILED! => {"changed": true, "end": "2015-04-05 10:44:05.031018", "stdout": "", "cmd": ["/bin/false"], "start": "2015-04-05 10:44:05.028723", "delta": "0:00:00.002295", "stderr": "", "rc": 1, "invocation": {"module_name": "command", "module_args": {"_raw_params": "/bin/false"}}, "stdout_lines": [], "warnings": []}

TASK [debug msg=Dans tous les cas, nous passons ici] ****************************
ok: [localhost] => {
    "msg": "Dans tous les cas, nous passons ici", 
    "changed": false
}

PLAY RECAP **********************************************************************
localhost                  : ok=3    changed=0    unreachable=0    failed=2
  • # Ansible / Puppet

    Posté par (page perso) . Évalué à 2.

    Salut,

    Ça fait un petit moment que je suis devenu assez fada de Ansible, et n’ayant fait que assez peu de Puppet (et pas du tout de Chef), je me demande quels sont les arguments qui feraient pencher la balance pour le choix de l’un ou de l’autre. Du moins, dans un environnement Linux/Unix s’entend.

    La lourdeur d’apprentissage de Puppet a fait que pour un usage perso, j’ai vite abandonné. Trop consommateur de temps et pas assez de temps. Mais en supposant qu’on ai le temps de se pencher vraiment dessus, on y gagne quoi par rapport à Ansible ou même SaltStack ?

    Love – bépo

    • [^] # Re: Ansible / Puppet

      Posté par (page perso) . Évalué à 10.

      En général, le premier argument, ça va être les compétences et les affinités. Si tu as des gens dans ton équipe qui sont familier avec un outil, alors il vaut mieux le prendre.

      Sinon, j'ai fait du puppet (beaucoup, mais y a longtemps), je fait beaucoup d'ansible et en ce moment, pas mal de salt, donc j'ai un avis forcément éclairé et valide sur le sujet (non pas que ça change grand chose, je l'aurais donné même si non fondé bien sur, on est sur l'internet).

      Déja, ça depend de ce que tu as comme besoin. Puppet ne fait que de la gestion de configuration, donc si tu doit déployer ou orchester des choses, il te faut un deuxième outil (mcollective, func, fabric, ansible, saltstack, etc). Ansible par contre à la base fait du déploiement et de l'orchestration, et ça a été étendu à la gestion de configuration, et ça change tout.

      Ça change tout parce que Ansible, étant sans agent, est plus ou moins obligé de faire des aller/retours sans arrêt et ça reste assez lent. Pour un projet, on a une infra de 10 machines, ça mets 10 à 15 minutes à tout appliquer à chaque commit git sur le dépôt. À coté de ça, Puppet était pas super rapide dans mon souvenir à cause de ruby ( notamment les allocations d'objets ) , mais c'était une infra plus compliqué, et au final, c'était quand même bien plus acceptable.

      Du point de vue des fonctions, Puppet est bien plus mature et son DSL propose vraiment plus de choses, la ou Ansible pêche un peu ( le fait de pas avoir de fonction, par exemple, même si un équivalent va revenir avec la version 2 du moteur, via le fait d'avoir des includes dynamiques ). Puppet a un ecosystéme plus riche qu'ansible ( genre foreman, r10k, etc ), plus de modules et plus de gens qui connaissent. Et forcément, il y a aussi des bonnes pratiques à tort et à travers, des patterns, etc.

      Puppet est plus complexe à installer, pas forcément à apprendre. Tu es pas obligé de tout connaitre, tout comme dans ansible, tu as pas forcément besoin de connaitre tout les modules.

      Mais c'est vrai qu'avec ansible, tu arrives plus rapidement à obtenir un résultat utile, et l'outil est plus versatile.

      Donc pour un usage perso, je pense qu'ansible fait l'affaire.

      Pour une infra plus conséquente, je regarderais peut être plus du coté de puppet ou saltstack pour le moment.

      De ce que j'ai vu, ansible est assez populaire chez les codeurs (ce qui n'est pas étonnant, vu qu'au final, c'est une suite de pas à suivre pour déployer ou obtenir un état), la ou puppet va plus correspondre à l'état d'esprit d'un packageur ou d'un architecte (le fait d'avoir des bouts d'état interdépendant pour obtenir un état général de ton infra, et de converger vers cet état). Donc en fonction de tes affinités, l'un va te paraitre plus naturel que l'autre.

      • [^] # Re: Ansible / Puppet

        Posté par . Évalué à 4.

        De ce que j'ai vu, ansible est assez populaire chez les codeurs (ce qui n'est pas étonnant, vu qu'au final, c'est une suite de pas à suivre pour déployer ou obtenir un état), la ou puppet va plus correspondre à l'état d'esprit d'un packageur ou d'un architecte (le fait d'avoir des bouts d'état interdépendant pour obtenir un état général de ton infra, et de converger vers cet état). Donc en fonction de tes affinités, l'un va te paraitre plus naturel que l'autre.

        J'ai du mal à comprendre pourquoi c'est ansible qui a tant de succès là où fabric est un vrai pur outil de développeur qui reprends les même propriétés qu'ansible (pas de serveur centrale ni d'agent, description d'une suite d'instructions) sans un certains nombre d'inconvénients (un langage connu par beaucoup et complet, mise en place encore plus simple je trouve,…).

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Ansible / Puppet

          Posté par (page perso) . Évalué à 3.

          Je ne connais pas bien Fabric mais après un rapide coup d'oeil, il semblerait qu'il s'agisse d'un mécanisme permettant d'exécuter des commandes à distances. Ansible est plus dans un descriptif de ce qu'on souhaite réaliser laissant de côté la gestion des cas (ressource déjà présente, dans un état déjà correct, etc.).

          Un autre aspect pratique sur Ansible vient du fait que tu n'as pas forcément besoin de connaître un langage pour l'utiliser (même si pour être honnête, je pense que ça reste un pré-requis si tu veux faire des choses un tant soit peu complexe).

        • [^] # Re: Ansible / Puppet

          Posté par (page perso) . Évalué à 3.

          Je peux pas répondre pour les autres, mais j'ai toujours vu fabric comme étant juste un gros wrapper autour de ssh, et pas trés "haut niveau"

          Par exemple, y a pas d'emphase sur le fait d'avoir des actions idempotentes, c'est quasiment equivalent à un script shell, mais en python.

          Ansible a une tonne de module, donc tu vois de suite ce que tu peux faire. Fabric semble laisser le fait de connaitre la ligne de commande à l'utilisateur, donc je peux comprendre que ça paraisse plus complexe et moins attrayant.

          • [^] # Re: Ansible / Puppet

            Posté par . Évalué à 1. Dernière modification le 20/06/15 à 16:01.

            Pour des actions idempotentes avec fabric il y a l’extension fabtools (son module require est fait pour ça).

            Aujourd’hui j’hésite encore entre fabric + fabtools et Ansible mon coté developpeur m’oriente un peu plus vers fabric.

  • # Syntaxe de la ligne de commande

    Posté par . Évalué à 4.

    Petite précision :

    ansible -i hosts -l localhost -m file -a "path=/tmp/test state=touch" all

    Normalement, on l'écrit :

    ansible -i hosts -m file -a "path=/tmp/test state=touch" localhost

    C'est plus dans l'esprit de la commande ansible. Par contre, dans le cas de ansible-playbook, on est obligé d'utiliser -l localhost puisque qu'il n'y a pas d'équivalent. C'est un peu incohérent, mais bon…

    Je me suis mis à utiliser ansible après avoir codé un outil qui permettait de lancer la même commande sur plusieurs serveurs. Et je me suis retrouvé avec un outil qui marchait, mais bon, pour la maintenance, autant passer sur quelque chose d'utilisé par tout le monde qui remplit également mon besoin. Et y a pas à dire, mettre seulement 1 minutes pour obtenir la différence de synchronisation NTP sur plus de 500 serveurs, c'est efficace.

    Le côté sans agent est un plus non-négligeable quand on ne maîtrise pas l'administration des machines.

  • # alt et p-

    Posté par . Évalué à 2.

    Pour les aspects rôles ajoutés à Fabric:
    https://github.com/sebastien/cuisine#readme

    Pour éditer sérieusement les fichiers de configuration (modif' légère sur un fichier de configuration à la syntaxe structurée et qu'on utilise pas les templates jinja2):
    https://github.com/paluh/ansible-augeas

    Et citons dans les alternatives (plus flexibles) à Ansible: https://propellor.branchable.com/
    de Joey Hess (etckeeper, mr, git-annex et git-remote-gcrypt)

    L'un des défaut que je trouve à Ansible est la piètre ré-utilisabilité effective des rôles.
    D'un part peu de rôles offrent la possibilité de spécifier son chemin de template de fichier de configuration, à la place c'est souvent une liste très sommaire d'options

    D'autre part un rôle n'est souvent intéressant que par les commandes (templates) qu'il offre, plus que par les directives d'installation (ex: rôle fail2ban qui permet d'écrire facilement des tâches lisibles pour rajouter des filtres, mais dont la manière d'installer est insatisfaisante). Il n'est pas possible à ma connaissance de profiter des fonctionnalités d'un rôles sans qu'il n'impose aussi l'installation à sa manière.

    Un autre problème est la duplication souvent d'apparence inutile des modules Ansible.

    Enfin l'approche role-based est intéressante, mais les choses ne sont parfois pas aussi simples.
    Par exemple une machine peut faire office de reverse-proxy supportant le SSL dans certains cas, mais pas dans d'autres et d'autres tâches et/ou variables en dépendront (monitoring, chemins, …)
    Je ne suis pas certain que Ansible se prête à se niveau de flexibilité.

    Sur l'aspect future-proof, une config' Ansible dépendant d'une paire de modules est-elle plus pérenne qu'un paire de shell-scripts… hum. On verra jusqu'où le support et la compatibilité suivra au fil des années et des changements de version majeure.

    • [^] # Re: alt et p-

      Posté par (page perso) . Évalué à 3.

      Et citons dans les alternatives (plus flexibles) à Ansible:
      https://propellor.branchable.com/
      de Joey Hess (etckeeper, mr, git-annex et git-remote-gcrypt)

      Alors, j'ai croisé pour le moment personne qui utilise propellor. Et pourtant, je passe mon temps à zoner dans les meetups et ce genre de choses. Pour dire, j'ai croisé plus de gens avec cfengine, ou bcfg2 que propellor.

      Dire "y a pas besoin d'apprendre un langage particulier, suffit juste de connaitre haskell" est un chouia trompeur :)

      L'un des défaut que je trouve à Ansible est la piètre
      ré-utilisabilité effective des rôles.
      D'un part peu de rôles offrent la possibilité de spécifier son
      chemin de template de fichier de configuration, à la place
      c'est souvent une liste très sommaire d'options

      D'une manière générale, tu peux difficilement avoir la configurabilité que propose la configuration d'un logicial sous forme d'une liste d'options, donc tu va jamais aller très loin avec les roles/formules/modules/cookbooks des autres. Si tu veux réutiliser, il faut construire au dessus, ou prendre des trucs de bases ( example, ntpd me parait le truc qu'on peut réutiliser sans souci, vu que les gens vont changer au mieux 2/3 trucs )

      Et pouvoir injecter tes propres fichiers, c'est globalement chercher les emmerdes, car le fichier deviens parti intégrante de l'interface du soft avec le reste du monde.

      Exemple, tu veux déployer mediawiki. Dans un monde idéal, tu devrais pouvoir reprendre un role apache et voila. En pratique, vu que mediawiki doit toucher à la config apache ( pour se placer dans un vhost, ou avec une url particuliére ), il y a un couplage entre les 2. Et pire encore, le couplage est non exprimé de façon formel donc risque de casser à tout moment. J'utilise une convention d'avoir /etc/httpd/conf.d/$vhost.conf.d/ pour qu'un soft dépose un fichier de configuration apache, qui s'applique à $vhost.

      Si tu décides de prendre une autre convention ou de changer le templates, tu peux casser ça. Mais comme c'est pas exprimé comme le serait une fonction ( ce que puppet propose ) avec verification à la compilation, tu dois déployer et voir que ça ne marche pas. Et même, une fois que tu as une fonction, tout ce que tu peux rajouter comme argument doit être supporté à jamais, donc les gens évitent d'en mettre trop. Et du coup, tu es limité.

      C'est la ou Puppet a un avantage, via le fait d'avoir une phase de compilation capable de vérifier ce genre de choses. Mais ça ne rends pas les choses beaucoup plus réutilisables si tu veux sortir du cadre décidé par le créateur du module, et si un module puppet fait pas ce que tu veux, tu as pas le choix, il faut forker.

      Tout le jeu est de trouver le bon niveau d'abstraction.

      Il n'est pas possible à ma connaissance de profiter des
      fonctionnalités d'un rôles sans qu'il n'impose aussi
      l'installation à sa manière.

      C'est du défoncage de porte ouverte. Encore une fois, tu as des interfaces non exprimés ( exemple, le chemin d'un fichier de configuration ), et soit tu gères ça dans le rôle lui même ( exemple, tu choisi l'emplacement du fichier de configuration via la méthode d'installation ), soit c'est un standard qui ne va pas bouger et que tu ne pas configurer sans tout casser. Donc soit le role impose la façon de faire, soit elle est imposé de façon externe. C'est comme un paquet de distrib, si tu veux le binaire d'apache dans "/usr/bin/sioux", tu peux pas ( sauf à tout refaire, et/ou modifier les choses à un autre niveau ). Il y a une cohérence interne au paquet/role à garder.

      Un autre problème est la duplication souvent d'apparence
      inutile des modules Ansible.

      Comme ?

      Enfin l'approche role-based est intéressante, mais les choses
      ne sont parfois pas aussi simples.
      Par exemple une machine peut faire office de reverse-proxy
      supportant le SSL dans certains cas, mais pas dans d'autres et
      d'autres tâches et/ou variables en dépendront (monitoring,
      chemins, …)
      Je ne suis pas certain que Ansible se prête à se niveau de
      flexibilité.

      Bah, tu peux mettre passer des arguments à un rôle ou un include ( http://docs.ansible.com/playbooks_roles.html#task-include-files-and-encouraging-reuse et plus bas ). J'ai un role httpd qui le fait que j'utilise sur 3 projets indépendants, donc je vois pas en quoi ça serait pas faisable.

      Sur l'aspect future-proof, une config' Ansible dépendant d'une
      paire de modules est-elle plus pérenne qu'un paire de shell-
      scripts… hum. On verra jusqu'où le support et la compatibilité
      suivra au fil des années et des changements de version majeure.

      La, ça semble un peu du FUD…

  • # Peut-on considérer Python comme un agent ?

    Posté par (page perso) . Évalué à 1.

    D'après la documentation, Ansible utilise Python.

    Managed Node Requirements
    On the managed nodes, you only need Python 2.4 or later, but if you are running less than Python 2.5 on the remotes, you will also need: python-simplejson

    Donc, peut-on dire que Python est un agent ?

    • [^] # Re: Peut-on considérer Python comme un agent ?

      Posté par (page perso) . Évalué à 2. Dernière modification le 07/04/15 à 16:50.

      Non, un agent serait un processus qui tournerait de façon périodique sur la machine cible (soit via un cron, soit qu'il se mette en attente d'une façon ou d'une autre).

      Python n'est qu'un langage de programmation… + un écosystème.

      Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

    • [^] # Re: Peut-on considérer Python comme un agent ?

      Posté par . Évalué à 2.

      C'est une dépendance. D'ailleurs, ssh n'est qu'un des transports possibles pour exécuter les scripts python produit par ansibe.

  • # Ton avis comparé à Salt ?

    Posté par . Évalué à 7.

    Tu dis dans des précédents commentaires que tu fais aussi pas mal de Salt, comment tu comparerais les deux aujourd'hui ?

Suivre le flux des commentaires

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