Journal Déploiement et automatisation avec Ansible - partie 1

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
52
7
jan.
2017

Sommaire

Au programme de cette année : l'automatisation ! Il existe plusieurs outils connus pour ça, vous en avez sans aucun doute entendu parler si vous êtes adminsys : Puppet, Chef, Salt et le petit dernier : Ansible.

Ansible a la réputation d'être le plus "accessible" avec une courbe d'apprentissage assez basse. Il peut être pertinent de l'utiliser à partir d'un seul serveur pour faciliter des déploiements selon les besoins (configuration des outils basique, serveur web, BDD…).

Au contraire des trois autres, il n'utilise pas d'agents (agentless), c'est à dire que rien n'a besoin de tourner côté serveur pour le faire fonctionner, ce qui le rend de facto plus facile à mettre en place. Il requiert seulement un accès SSH et python sur les serveur.

Toujours concernant Ansible (bien entendu), on parle souvent d'idempotence, ce qui signifie qu'une opération a le même effet qu'on l'applique une ou plusieurs fois.

Les recettes utilisent du YAML et Jinja2 pour les templates. L'utilisation de YAML permet d'avoir des recettes normalement facile à lire et à comprendre. À noter aussi que grâce au (ou à cause du) YAML, l'indentation est primordiale et source de bug si elle n'est pas respecté comme on le verra plus tard.

Au programme aujourd'hui :

  • installation d'Ansible (v2.2.0.0)
  • tests de connexions aux serveurs
  • installation de quelques paquets
  • debug et tests

Installation

Si vous avez besoin d'autre chose, ça devrait être dans la documentation.

sur Debian

Vous pouvez l'installer directement via les dépôts, mais ce sont évidemment des versions anciennes (cf. packages.debian.org), pour avoir une version plus récente, ajouter la ligne suivante à /etc/apt/sources.list.d/ansible.list :

deb http://ppa.launchpad.net/ansible/ansible/ubuntu trusty main

Puis il suffira de lancer les commandes suivantes :

sudo apt-get update
sudo apt-get install ansible

sur Ubuntu 

sudo apt-get install software-properties-common
sudo apt-add-repository ppa:ansible/ansible
sudo apt-get update
sudo apt-get install ansible

Il suffit ensuite d'aller dans /etc/ansible/ pour la suite :

cd /etc/ansible/

nous avons normalement 2 fichiers et un dossier :

  • ansible.cfg : la configuration d'ansible, celle par défaut nous convient parfaitement bien pour le moment, mais ça peut valoir le coup d'y jeter un coup d'oeil pour voir ce que l'on peut faire.
  • hosts : c'est dans ce fichier que nous allons indiquer nos serveurs, étape obligatoire pour la suite.
  • roles : ce dossier nous servira surtout par la suite quand on commencera à avoir plusieurs rôles à nos playbooks.

Inventory / hosts

Dans /etc/ansible/, donc, éditons notre fichier hosts. Nous pouvons y déclarer nos serveurs individuellement ou par groupe, par exemple :

serveur1.exemple.org
serveur2.exemple.org
preprod.elysee.org
8.253.9.125

[web]
skhn-web-nginx-01
skhn-web-nginx-02

[seedbox]
skhn-seedbox-01

Voici ma configuration actuelle, à noter que j'ai modifié mon /etc/hosts et mon .ssh/config pour que ça pointe vers les bons serveurs avec les bonnes clés SSH :

[scaleway]
skhn-001
skhn-002

[seedbox]
sb

Par la suite, je pourrai ainsi lancer des tâches sur tous les serveurs avec l'option générique all ou par groupe selon vos besoins (web, bdd, wordpress, etc…). Si vous vous posez la question, le premier groupe s'appelle scaleway car j'ai pris 2 serveurs chez eux pour tester Ansible ).

ping

  • Avant toute chose, est ce que l'on arrive bien à joindre les serveurs :
ansible -m ping all --one-line

Ce qui me donne :

skhn-002 | SUCCESS => {"changed": false, "ping": "pong"}
skhn-001 | SUCCESS => {"changed": false, "ping": "pong"}
sb | SUCCESS => {"changed": false, "ping": "pong"}

test SSH

Mais est ce que l'on arrive à se connecter au groupe scaleway ? On va en profiter pour récupérer quelques infos :

ansible scaleway -m setup --tree /tmp/facts_servers/

La sortie de cette commande sera recopiée pour chaque serveur dans /tmp/facts_servers/, vous devriez avoir toutes les informations que vous souhaitez avoir sur vos serveurs ;-)

et mon uptime ?

ansible all -m command -u root --args "uptime" --one-line

résultat :

sb | SUCCESS | rc=0 | (stdout)  17:33:14 up 410 days, 21:59,  1 user,  load average: 0.21, 0.16, 0.14
skhn-001 | SUCCESS | rc=0 | (stdout)  16:33:14 up 1 day,  2:05,  1 user,  load average: 0.00, 0.00, 0.00
skhn-002 | SUCCESS | rc=0 | (stdout)  16:33:14 up 1 day,  2:05,  1 user,  load average: 0.00, 0.00, 0.00

Installation d'une liste de paquets

J'aime bien avoir certains paquets installé sur tout mes serveurs, Ansible me permet de l'automatiser facilement. On commence par éditer notre nouveau fichier /etc/ansible/roles/skhn_common.yml pour y mettre le bloc suivant :

---
- hosts: all
  remote_user: root

  tasks:
  - name: install common packages for all servers
    apt: 
      update_cache=yes
      state=latest
      name={{item}}
    with_items: 
    - curl
    - htop
    - ncdu
    - pwgen
    - strace
    - sudo
    - tar
    - unzip
    - vim
    - wget
    - whois
    - screen

Après l'avoir enregistré, il suffira de lancer la commande suivante pour installer cette liste de paquets sur tout les serveurs :

ansible-playbook -i hosts /etc/ansible/roles/skhn_common.yml

Et c'était donc notre premier rôle, yay \o/

Vous avez peut être remarqué 2/3 trucs :

  • un rôle commence toujours par ---,
  • hosts: all est ici directement dans le fichier et non dans la commande,
  • on nomme ensuite nos tâches (tasks) avec name, ça permet de s'y retrouver plus facilement et d'avoir un libellé humainement compréhensible à lire pendant le déroulement du rôle (on sait donc plus facilement où on en est et ce qui est en train de se passer).
  • update_cache=yes permet de faire un apt-get update
  • j'ai choisi de mettre state=latest et non state=present, j'ai envie que ce genre de paquet soit à jour sans que j'ai besoin de m'en occuper.

Debug

Le plus gros problème que j'ai eu pour le moment concerne l'indentation qui est vicieuse et la syntaxe YAML.

L'indentation

Si vous voulez vous éviter des prises de têtes qui vous font perdre quelques heures facilement, faites des indentations de DEUX espaces ! Pourquoi ? Parce que :

  • ça, c'est VALIDE (DEUX espaces) :
---
- hosts: all
  remote_user: root

  tasks:
  - name: install common packages for all servers
    apt: 
      update_cache=yes
      state=latest
      name={{item}} 
    with_items: 
    - curl
    - htop
  • ça, c'est INVALIDE (QUATRE espaces) :
---
- hosts: all
    remote_user: root

    tasks:
    - name: install common packages for all servers
      apt: 
        update_cache=yes
        state=latest
        name={{item}} 
      with_items: 
      - curl
      - htop
  • et ça, c'est VALIDE (QUATRE espaces) :
---
-   hosts: all
    remote_user: root

    tasks:
    - name: install common packages for all servers
      apt: 
        update_cache=yes
        state=latest
        name={{item}} 
      with_items: 
      - curl
      - htop

VOUS LA VOYEZ LA DIFFÉRENCE ? C'EST CE #### D'ESPACEMENT ET D'ALIGNEMENT AVEC LE RESTE DE hosts: all ! Bon, une fois qu'on le sait, pourquoi pas, mais à cause de ça j'ai perdu plus d'une heure hier après-midi, merci le message ERROR! Syntax Error while loading YAML. absolument pas parlant…

La syntaxe YAML

Si vous avez un doute sur ce que vous avez fait, ou si vos collègues sont des adeptes de la fameuse méthode "gruiiiiiik et je me casse en vacances sans vérifier si ça marche en prod", l'utilisation de yamllint est recommandée (ça, et le non moins fameux coup-de-clavier-dans-la-gueule). Idéal en pré-commit (yamllint, pas le clavier).

Ansible propose aussi un check : --syntax-check, que l'on peut utiliser de cette manière là : 

ansible-playbook  --syntax-check example-playbook.yml
ansible-playbook  --syntax-check roles/*

Oh, et évidemment, je vous conseille beaucoup de lire les best practices.

  • # plein de questions :)

    Posté par  . Évalué à 3.

    à noter que j'ai modifié mon /etc/hosts et mon .ssh/config pour que ça pointe vers les bons serveurs avec les bonnes clés SSH

    1. Quelles modifications ont été faites dans le fichier hosts exactement ?
    2. Le fichier hosts est utilisé à cause d'une absence de serveur DNS dans ton environnement, ou ansible a spécifiquement besoin que les serveurs soient déclarés dedans ?
    3. Le .ssh/config de quel utilisateur est modifié ?
    4. Est-ce qu'on se connecte aux clients avec un utilisateur particulier ou en root ?
    5. on peut utiliser n'importe quelle clé ou il y a des contraintes à respecter (format, passphrase, etc.) ?

    Merci.

    Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr

    • [^] # Re: plein de questions :)

      Posté par  . Évalué à 3.

      Je pense qu'il est vide par défaut.
      Tu dois forcément le remplir ce n'est pas une question de DNS, il est là pour lister les machines que tu veux gérer et y associer des variables de configuration que tu souhaites (par exemple l'utilisateur à utiliser pour se connecter, la méthode d'évaluation de privilège (su ou sudo),…).
      Ici il s'appuie sur sa conf ssh, donc l'utilisateur utilisé est défini à ce niveau là. C'est évidemment la configurant ssh de l'utilisateur qui lance ansible qu'il faut modifier).
      Ansible n'impose rien dans la conf ssh, ni d'utiliser une clef, ni la forme de la clef.

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

    • [^] # Re: plein de questions :)

      Posté par  (Mastodon) . Évalué à 0.

      Il n'a pas modifié /etc/hosts, mais /etc/ansible/hosts

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: plein de questions :)

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

        Voici ma configuration actuelle, à noter que j'ai modifié mon /etc/hosts et mon .ssh/config pour que ça pointe vers les bons serveurs avec les bonnes clés SSH :

        • [^] # Re: plein de questions :)

          Posté par  (Mastodon) . Évalué à 2.

          Oups ! Au temps pour moi :)

          Alors pour moi c'est juste un confort, mais ça peut sans pb être fait par un DNS local bien paramétré.

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: plein de questions :)

      Posté par  . Évalué à 3. Dernière modification le 08 janvier 2017 à 09:44.

      1. il a dû ajouter une ligne du genre dans sont /etc/hosts 37.37.7.3 skhn-001 car il n'a pas pas mis un nom résolvable dans le fichier hosts
      2. le fichier hosts est obligatoire comme dit dans l'article
      3. il parle du .ssh/config de la machine où il lance ansible
      4. on peut se connecter avec un autre utilisateur que root et même utiliser sudo avec l'option become
      5. tu peux te connecter avec n'importe quelle clé, port, utilisateur, si il y a une passphrase il te la demandera, si il y a un problème avec ton known_hosts il te le dira aussi

    • [^] # Re: plein de questions :)

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

      En pratique, tu peux tout définir dans un fichier quelconque. Personnellement, si je fais un projet avec Ansible, j'ai un dossier avec mes playbooks, mais aussi un dossier avec un fichier de conf' par plate-forme ciblée : absolument hors de question de modifier un fichier global (au système ou à l'utilisateur).

      Tu peux préciser qu'il faut se connecter avec un utilisateur et faire un sudo après.

    • [^] # Re: plein de questions :)

      Posté par  . Évalué à 2.

      1 . c'est pas necessaire
      2. ansible a specifiquement besoin que les serveurs soient déclarés dans l'inventory (ou alors on peut juste lancer des commandes en live mais on perd l'interet du playbook)
      3. pas necessaire
      4. l'utilisateur que tu veux. Tu peux aussi definir un utilisateur sudo
      5. n'importe quelle méthode d'authentification du moment que ca marche avec SSH

    • [^] # Re: plein de questions :)

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

      On peut avoir des IP dans l'inventaire ansible. On peut aussi avoir un inventaire dynamique (calculé par un script) si on est dans une infrastructure changeante de VM ou de conteneurs. Tu choisis dans ta config ansible ou ton playbook ou en ligne de commande ou… quel est l'utilisateur distant qui sera utilisé pour la connexion ssh, et l'utilisateur local est celui qui lance la commande ansible. Clé et/ou phrase de passe pour le ssh (par contre faut passer l'acceptation de l'empreinte de la nouvelle clé ssh d'une manière ou d'une autre).

      • [^] # Re: plein de questions :)

        Posté par  . Évalué à 1.

        Clé et/ou phrase de passe pour le ssh (par contre faut passer l'acceptation de l'empreinte de la nouvelle clé ssh d'une manière ou d'une autre).

        On peux faire (non que ça soit recommandé, mais si l'infra est ultra dynamique et les clefs changent à chaque fois, alors ça ne réduit pas la sécurité):

        export ANSIBLE_HOST_KEY_CHECKING=False

  • # YAML beurk

    Posté par  . Évalué à 6. Dernière modification le 08 janvier 2017 à 07:45.

    Je déteste YAML, bien que super puissant, je trouve ce format très peu pratique en modification.
    Je ne sais jamais s'il faut indenter avec plus d'espace ou non, mettre un tiret ou non… Bref c'est la misère pour ma part.

    J'imagine le pauvre exploitant seul devant son clavier en pleine nuit dans un incident et avec une modification d'un fichier YAML à effectuer avec son vi.

    Je préfère largement utiliser TOML.

    • [^] # Re: YAML beurk

      Posté par  . Évalué à 2.

      Les spécifications du yaml sont pourtant assez simples et intuitives…

      Je viens de regarder un peu le toml que je ne connaissais pas et je trouve ça particulièrement fouillie, y'a plein de caractères dont on a pas besoin pour la compréhension de la structure ce qui rend sa lecture et doit rendre sa rédaction assez pénible…

      L'indentation du yaml a l'avantage d'être vraiment clair visuellement et permets de saisir la structure du document d'un seul coup d'œil, et concernant la taille de l'indentation à faire, c'est assez simple, elle doit juste être relative à l'élément parent et aligné avec ses frères…

      • [^] # Re: YAML beurk

        Posté par  . Évalué à 1.

        Oui, visuellement YAML c'est clair.
        Par contre, le modifier sans un éditeur/ide qui t'assiste, à mon humble avis, c'est l'enfer et c'est la majorité des cas pour les exploitants qui accèdent à leurs serveurs en SSH via vi/emacs.

        Pour moi, TOML a l'avantage de s'appuyer sur des caractères facilement identifiables pour définir ses structures.
        Avec TOML, tu peux indenter si tu souhaites pour clarifier (comme dans les langages de programmation) ta configuration mais ce n'est pas obligatoire.
        Donc, tu peux dans les moments critiques (e.g. incident de production en pleine nuit) modifier "à l'arrache"® ton fichier et y revenir plus tard.

        • [^] # Re: YAML beurk

          Posté par  . Évalué à 4.

          Avec TOML, tu peux indenter si tu souhaites pour clarifier (comme dans les langages de programmation)

          À part python, qui est justement le language dans lequel est écrit ansible ;-)

          Et puis, d'après https://github.com/toml-lang/toml TOML est encore noté en version 0.4.0, donc la syntaxe peut encore changer de façon incompatible.

          • [^] # Re: YAML beurk

            Posté par  . Évalué à 2. 

            À part python, qui est justement le language dans lequel est écrit ansible ;-)

            Effectivement, quand j'ai écrit ça je me suis dit que j'avais un peu trop généralisé et que je m'exposais à un retour de bâton rapide de la part lecteurs de linuxfr aux yeux impitoyables ;)

        • [^] # Re: YAML beurk

          Posté par  . Évalué à 5.

          Moi qui suit plutôt pythoniste, je dois t'avouer que baser la structure du code sur l'indentation est sans doute la meilleur idée qu'on ait pu avoir dans l'histoire des langages. Je suis extrêmement à l'aise avec ça, tant est si bien que je ne supporte pas qu'un langage m'oblige à écrire des caractères qui pourraient être simplement substituable par des retours à la ligne et de l'indentation.

          Pour avoir eu sous les yeux du code d'universitaire dont la structure était juste impossible a déchiffrer à cause de l'anarchie complète dans le formatage, j'apprécie tout les langages dont la structure se base sur l'indentation.

          J'édite très régulièrement du yaml avec vim et emacs, et ces derniers sont tout à fait en mesure de mettre en surbrillance le yaml et de réaliser les indentations qui vont bien (il faudra au préalable les configurer un peu, mais c'est le lot de tout utilisateur de vim/emacs dès l'instant que tu veux éditer un truc un tant soit peu structuré).

          • [^] # Re: YAML beurk

            Posté par  . Évalué à 5.

            baser la structure du code sur l'indentation est sans doute la meilleur idée qu'on ait pu avoir dans l'histoire des langages

            Si c'est pas hyperbolique, ça ! :)

            Plus sérieusement, un truc que je trouve vraiment sympa, et qui n'est pas possible avec cette approche, c'est l'indentation automatique à chaque sauvegarde du fichier, comme c'est l'usage en go avec gofmt. Ça permet de faire des choses comme bouger deux lignes en dehors d'une boucle et puis, plutôt que de les réindenter manuellement, sauvegarde, et hop, c'est fait.

            • [^] # Re: YAML beurk

              Posté par  . Évalué à 1. 

              Plus sérieusement, un truc que je trouve vraiment sympa, et qui n'est pas possible avec cette approche, c'est l'indentation automatique à chaque sauvegarde du fichier, comme c'est l'usage en go avec gofmt.

              Je n'ai pas osé aborder le sujet de Go avec gofmt (et goimports) car après je suis intarissable.
              Ce langage est, de mon point de vue (back-end), une véritable tuerie <troll>largement meilleur que le couple Java/Spring Boot</troll>.
              C'est un sujet assez chaud au sein de mon équipe.

              • [^] # Re: YAML beurk

                Posté par  . Évalué à 3.

                Ce langage est, de mon point de vue (back-end), une véritable tuerie largement meilleur que le couple Java/Spring Boot.

                Bof, je suis pas fan de sa gestion du json et je n'ai rien vu qui remplace la bean validation. Les connexions aux bases sont nettement plus rustiques aussi. Mais si tu fais du Spring Boot, je comprends que tu veuille changer ^_^

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

            • [^] # Re: YAML beurk

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

              Cette pratique est monnaie courante en Elm, où elm-format fait des merveilles. Ne plus jamais avoir à se soucier de l'indentation, c'est de la tranquillité d'esprit.

          • [^] # Re: YAML beurk

            Posté par  . Évalué à 6. Dernière modification le 08 janvier 2017 à 19:04.

            Moi qui suit plutôt pythoniste, je dois t'avouer que baser la structure du code sur l'indentation est sans doute la meilleur idée qu'on ait pu avoir dans l'histoire des langages. Je suis extrêmement à l'aise avec ça, tant est si bien que je ne supporte pas qu'un langage m'oblige à écrire des caractères qui pourraient être simplement substituable par des retours à la ligne et de l'indentation.

            Tu veux dire qu’empêcher de pouvoir facilement copier / coller du code est la meilleur idée qu'on ait pu avoir dans l'histoire des langages ?

            /me sort sur la pointe des pieds :)

            • [^] # Re: YAML beurk

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

              Bah quand on voit certains résultats de "bah on m'a dit de copicoler ça" (dans le code, et dans la future façon de travailler de la personne formée comme ça), c'est peut-être pas un mal.

            • [^] # Re: YAML beurk

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

              Je pratique pas mal le Python, et l'indentation ne m'a jamais posé de problème. Rien n'empêche de décaler comme il faut juste après le coller.

              Peut-être que ça nécessite d'avoir un IDE adapté, en échange.

        • [^] # Re: YAML beurk

          Posté par  . Évalué à 1.

          "et y revenir plus tard" = "laisser en l'état à jamais"?
          Dans ce monde de brut où l'agilité, le time to market et la haute dispobilité te mettent une pression intense pour résoudre tes bugs et mettre en place de nouvelles fonctionnalités, si tu ne travailles pas proprement dès le départ, tu crées de la dette technique que le boss ne te laissera jamais rattrapper! ;-)

          • [^] # Re: YAML beurk

            Posté par  . Évalué à 1.

            Oui, c'est toujours l'histoire du temporaire qui dure ;)
            Mais après c'est un choix des équipes/projet.

      • [^] # Re: YAML beurk

        Posté par  . Évalué à 4.

        Encore un point sur YAML, là où je travaille nous utilisons beaucoup Java/Spring Cloud (en plus d'Ansible d'ailleurs).
        La configuration de Spring Cloud est faite via le fichier bootstrap.yml qui, comme son extension l'indique, est fichier YAML.

        La configuration de Spring Cloud est assez complète (pour ne pas dire assez complexe ;) ) et l'exploitant doit parfois activer des configurations particulières qui ne sont pas livrées par défaut.

        Il est parfois nécessaire d'ajouter des configurations supplémentaires qu'il ne connait pas, alors il nous demande le bloc YAML à ajouter.
        Et là, ça devient assez pénible car il faut prendre en compte les indentations des lignes précédentes pour que cela fonctionne.
        Si l' exploitant l'a modifié (ce qui est normal), alors il ne peut pas copier/coller la section sans tout ré indenter.

      • [^] # Re: YAML beurk

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

        Les spécifications du yaml sont pourtant assez simples et intuitives…

        Sur ce point je ne suis pas vraiment d'accord.

        YAML semble être simple au premier abord… mais il est tout sauf simple en pratique…. Écrire un parseur complet YAML n'a rien de trivial.

        YAML a des notions comme les réferences, les tags, les documents imbriqués, les scalaires, le multi-ligne et plusieurs format d'encoding. Il supporte également les graphes cycliques que seul les formats style XML supportent.

        Le spécification YAML fait plus de 70 pages….. Ceci à comparer à la demi-page de la grammaire du JSON.

        YAML a rien de trivial. Son seul avantage a mes yeux est sa lisibilité due à ses choix faits pour l'indentation…. Ce même choix qui rend les documents YAML complexe un cauchemars à valider….

        Je vais me faire des ennemis en disant ça, mais à mon humble avis : YAML n'est PAS un bon format de configuration…. Il tend juste à être plus "lisible" que XML et supporte les commentaires contrairement à JSON….

    • [^] # Re: YAML beurk

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

      Même si je n'ai pas de souci particulier avec YAML, je regrette qu'il n'y ait pas d'éditeur spécifique à Ansible (pour détecter automatiquement les paramètres invalides dans les templates, par exemple)

      • [^] # Re: YAML beurk

        Posté par  . Évalué à 1.

        Moi, j'utilise principalement Intellij IDEA et le plugin Ansible.
        Il t'apporte un peu d'aide mais il y a encore des manques (notamment au niveau des templates Jinja2).

    • [^] # Re: YAML beurk

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

      Pour Yaml, j'étais d'accord … puis j'ai découvert ce plugin

      • [^] # Re: YAML beurk

        Posté par  . Évalué à 1.

        Merci pour l'info.
        Malgré tout, il n'est pas toujours possible d'installer ce que l'on souhaite sur des environnements de production (e.g. conteneur Docker)

        • [^] # Re: YAML beurk

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

          Un hack à deux francs belges est de monter le répertoire ou se trouve ton fichier à éditer via SSHFS.

        • [^] # Re: YAML beurk

          Posté par  . Évalué à 3.

          C'est parce qu'il ne faut pas le faire !
          Tu modifie pas ton code en prod, c'est pareil avec tes scripts ansible/chef/puppet/…

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

        • [^] # Re: YAML beurk

          Posté par  (Mastodon) . Évalué à 3.

          D'une part, le but d'un truc comme ansible, puppet ou autre, c'est justement de pouvoir balancer ce qu'on veut sur l'ensemble de sa prod.

          D'autre part tu ne vas pas démarrer un vim sur ton serveur ansible (enfin j'espère).

          • [^] # Re: YAML beurk

            Posté par  . Évalué à 1.

            Non, mais la remarque porte plus sur le YAML en général que sur la modification des playbooks via vi.

            • [^] # Re: YAML beurk

              Posté par  . Évalué à 4. Dernière modification le 09 janvier 2017 à 17:56.

              Quelque soit la fonction du fichier, une modification manuelle d'un fichier dans un environnement de prod n'est pas une bonne idée. Pour tous les autres cas, tu modifie en local avec un éditeur adapté.

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

    • [^] # Re: YAML beurk

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

      Je déteste YAML, bien que super puissant, je trouve ce format très peu pratique en modification.
      Je ne sais jamais s'il faut indenter avec plus d'espace ou non, mettre un tiret ou non… Bref c'est la misère pour ma part.

      [troll mode on]

      YAML est le produit de quelqu'un qui s'est dit que d'associer la complexité inutile du XML, les opérateurs de Perl et l'indentation de Python serait une sacré bonne idée.

      [mode troll off]

  • # .

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

    VOUS LA VOYEZ LA DIFFÉRENCE ? C'EST CE #### D'ESPACEMENT ET D'ALIGNEMENT AVEC LE RESTE DE hosts: all ! Bon, une fois qu'on le sait, pourquoi pas, mais à cause de ça j'ai perdu plus d'une heure hier après-midi, merci le message ERROR! Syntax Error while loading YAML. absolument pas parlant…

    Du coup dans la version deux espaces c'est aligné avec hosts pareil que dans la "quatre qui marche", alors j'ai tendance à penser que ça n'a juste rien à voir avec le nombre d'espaces. Ou alors c'est le rendu sur DLFP/ma CSS/… ?

    • [^] # Re: .

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

      Tu n'es pas assez attentif :). En plus concis et donc en plus visible en un seul coup d’œil :

      ça, c'est VALIDE (DEUX espaces) :

      - hosts: all
  remote_user: root

      ça, c'est INVALIDE (QUATRE espaces) :

      - hosts: all
    remote_user: root

      et ça, c'est VALIDE (QUATRE espaces) :

      -   hosts: all
    remote_user: root

      • [^] # Re: .

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

        Ah oui en effet. Ceci dit ça me parait un peu de sa faute hein ; s'il considère que le "- " est de l'indentation, alors forcément ça n'est pas une indentation "4 espaces" valides puisque ne faisant que 2 caractères… si hosts et remote_user doivent être des frères, dans un éditeur correct (monospace, etc.), le fait qu'ils ne soient pas alignés doit être assez flagrant.

  • # salt-ssh

    Posté par  . Évalué à 2. Dernière modification le 08 janvier 2017 à 09:41.

    Il est possible d'utiliser Salt sans agent via salt-ssh. Cela s'utilise comme Ansible et j'ai une petite préférence pour celui-ci notamment car il est plus agnostique sur l'utilisation de ses modules (il saura configurer un service avec la même configuration quelque soit le système d'init, ou encore installer un paquet selon la distribution).

    Il est également par défaut idempotent, ce que n'est pas forcément Ansible.

    • [^] # Re: salt-ssh

      Posté par  . Évalué à 1.

      il saura configurer un service avec la même configuration quelque soit le système d'init, ou encore installer un paquet selon la distribution)

      Ansible abstrait ça aussi, bien que le module "package" (successeur de "yum", "apt" et consorts) soit relativement récent (Ansible 2.0) :
      http://docs.ansible.com/ansible/service_module.html
      http://docs.ansible.com/ansible/package_module.html

      Il est également par défaut idempotent, ce que n'est pas forcément Ansible.

      Ansible est idempotent et encourage l'écriture de modules qui le sont aussi ; mais avec Ansible on peux facilement - plus facilement qu'avec Puppet je trouve - écrire du mauvais code qui casse cette propriété.

  • # Python 3

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

    À noter qu'Ansible est maintenant compatible Python 3, même si ça ne semble pas être totalement officiel : https://docs.ansible.com/ansible/python_3_support.html

    De son côté, Salt ne l'est pas encore mais le portage est bientôt fini.

    • [^] # Re: Python 3

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

      Ansible est comme indiqué dans le lien dans une version de transition.
      Il y a beaucoup de mieux, mais pas mal de plugins peuvent poser problème encore.

      • [^] # Re: Python 3

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

        Alors, ayant fait une partie du portage:

        Dans la mesure ou tester la version git et tester python 3 sont assez simple ( git clone ; cd ansible ; source hacking/env-setup )
        et -e ansible_python_interpreter=/usr/bin/python3, j'invite les gens à tester et à remplir des rapports de bugs. J'ai vraiment testé tout les modules des playbooks que j'utilise, j'ai mếme été jusqu'à installer un openbsd et un freebsd pour trouver des bugs potentielles avec python3.

        Mais pour moi, ça marche sans souci dans la version git.

  • # roles et playbooks

    Posté par  . Évalué à 10.

    L'exemple que tu donne n'est pas un role, c'est un playbook normal que tu as mis dans le répertoire roles, mais n'importe où d'autre aurait fait l'affaire (puisque tu donne son chemin complet à ansible-playbook).

    Les roles sont des répertoires (placés par défaut dans le répertoire roles que tu indique) avec une structure de sous-répertoires conventionnelle pour limiter les boilerplate. cf
    http://docs.ansible.com/ansible/playbooks_roles.html

    Voici comment restructurer ton exemple en un vrai role (je fais ça de tête, je n'ai pas testé):

    Tu crée un répertoire /etc/ansible/roles/common (common sera donc le nom de ce role), dedans tu fais un répertoire tasks dans lequel tu met un fichier mail.yml avec le contenu

    - name: install common packages for all servers
  apt: 
      update_cache=yes
      state=latest
      name={{item}}
  with_items: 
    - curl
    - htop
    - ncdu
    - pwgen
    - strace
    - sudo
    - tar
    - unzip
    - vim
    - wget
    - whois
    - screen

    Ensuite, dans un fichier skhn.yml (que tu met où tu veux) tu met ceci:

    - hosts: all
  remote_user: root
  roles: [ common ]

    Avec un exemple aussi simple, l'intérêt d'un role est simité par rapport à l'instruction include, ça devient plus intéressant quand tu y ajoute des handlers, des templates, des fichiers, des variables, car ça permet de regrouper les choses logiquement.

  • # Ansible Semaphore

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

    En plus, il existe une interface graphique pour rassurer les rois du clicodrome : https://github.com/ansible-semaphore/semaphore

    Installé récemment et je ne vois pas l'interet pour moi, mais ca interessera peut être d'autres personnes

  • # inventory

    Posté par  . Évalué à 3.

    Voici ma configuration actuelle, à noter que j'ai modifié mon /etc/hosts et mon .ssh/config pour que ça pointe vers les bons serveurs avec les bonnes clés SSH :

    C'est pas nécessaire de bricoler son host, toutes les options existent pour donner les informations utiles dans l'inventory directement : user de connexion, port, ip, user "become" (sudo), clé, etc

  • # Agentless, danger

    Posté par  . Évalué à 3.

    Au contraire des trois autres, il n'utilise pas d'agents (agentless), c'est à dire que rien n'a besoin de tourner côté serveur pour le faire fonctionner, ce qui le rend de facto plus facile à mettre en place. Il requiert seulement un accès SSH et python sur les serveur.

    C'est le point qui me bloque un peu. Avec Puppet (c'est ce que j'utilise), si jamais je me plante sur la configuration du démon SSH, ou du firewall, ou du authorized_keys, je sais que l'agent continue de tourner. Donc je pourrais toujours rattraper le coup. Avec Ansible, c'est perdu…

    Alors oui, j'ai des environnements de dev et de preprod, mais ça n'empêche pas que parfois on loupe un truc parce qu'il y a une subtile différence entre la preprod et la prod (oui, c'est mal, mais nul n'est parfait).

    Et bien sûr, je ne prod jamais en même temps une modification de configuration de l'agent Puppet et une modification qui risquerai de me faire perdre la main sur les serveurs :)

    • [^] # Re: Agentless, danger

      Posté par  . Évalué à 3.

      L'avantage des agents ne se situe carrément pas là. Que ce soit Puppet ou Ansible, si tu fais une erreur avec la conf de ton firewall ou un autre truc sensible alors tu dis au revoir à ton serveur. Je vois pas de différence fondamentale à ce niveau.

      Non, la GROSSE différence entre Puppet et Ansible, c'est la vitesse d'exécution : Ansible est leeeeeeeeent à coté de Puppet…
      Mais bon, le coté plus "facile" et l'absence d'install d'agent d'Ansible le rend quand même vachement pratique mais c'est affreusement leeeeeeeent.
      Un autre truc aussi mais c'est pas tellement lié à l'agent mais plutot à la façon dont le machin est branlé, c'est quand on fait un "dry-run" en Puppet, c'est une vraie simulation relativement propre et assez fiable dans son ensemble. Un "--check" sous Ansible (qui est l'équivalent) va quand même faire certains trucs pour de vrai (notamment les installs de packages - hé oui ! surprise ! ). C'est absurde mais c'est comme ça.
      Idem pour les messages d'erreur ou d'alerte, Ansible s'est amélioré mais il reste quand même assez nul globalement…

      Mais bon, malgré tout ça, j'utilise Ansible quotidiennement et j'ai laché Puppet depuis plus d'1 an (car il fallait bien choisir à un moment)…

      • [^] # Re: Agentless, danger

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

        Un autre truc aussi mais c'est pas tellement lié à l'agent mais plutot à la façon dont le machin est branlé, c'est quand on fait un "dry-run" en Puppet, c'est une vraie simulation relativement propre et assez fiable dans son ensemble. Un "--check" sous Ansible (qui est l'équivalent) va quand même faire certains trucs pour de vrai (notamment les installs de packages - hé oui ! surprise ! ). C'est absurde mais c'est comme ça.

        Alors c'est intéressant car j'ai eu un problème inverse. C'est sur une infra que je ne maitrisais pas et je faisais une petite modif' (donc je ne m'attendais pas à telle difficulté (et j'étais dev. "fonctionnel" et pas "devops" mais je faisais un peu de devops quand même parce que "capable" et intéressé)), mais j'ai eu le cas d'un dry-un puppet qui échoue car une étape "wget" n'est en effet pas faite et donc l'étape d'après échoue (alors qu'en réalité, au final, tout était valide une fois exécuté). Peut-être que la "fausse simulation pas propre" d'Ansible aurait réussi ?

        • [^] # Re: Agentless, danger

          Posté par  . Évalué à 2.

          Puppet fait du dry-run relativement propre mais ne peut pas faire de magie non plus. Si une étape a besoin d'un élément généré ou récupéré par l'étape précédente, forcément, ça va finir en erreur. Encore plus si c'est une commande qui est exécutée et non pas une directive interne.
          Mais Ansible aurait fait la même chose…

        • [^] # Re: Agentless, danger

          Posté par  . Évalué à 1.

          Disons que ce même problème peux survenir quel que soit l'outil de configuration management utilisé.

          Ansible rends ce phénomène plus fréquent et visible, car le mécanisme de notifications (via les handlers) est très spécialisé et pas utilisable en toutes circonstances (par opposition au notify/subscribe de puppet, qui permet de coordonner n'importes quelles actions).

          On doit souvent recourir à des enchainements register (ou set_fact+lookup, etc) sur une première task, puis "when: lavariableregistred[.something]" dans une seconde task, ce qui n'est évidement pas génial pour le --check.

          Un autre aspect qui rends Ansible un peu plus frustre pour les tests (mais je l'aime pour d'autres raisons ;), par opposition à Puppet

          Un autre aspect où Puppet se montre moins frustre pour les tests, c'est la notion de catalogue: l'état complet du système cible (tout ce qui est "à vérifier et à faire" avec Puppet) est construit avant toute connexion sur la machine cible (et avant execution par l'agent). On dispose d'un paquet d'outils permettant de se brancher sur la sortie du catalogue, pour faire du test unitaire et vérifier tout ce que Puppet compte faire, sans jamais avoir besoin de la machine cible.

          Cela dit j'aime beaucoup Ansible sur d'autres aspects que les tests.
          En particulier pour l'aspect dynamique, la souplesse et le controle qu'il offre sur le flux d'execution et les ensembles de machines: par ex. avec serial, delegate_to, local_action, group_by, add_host, les inventaires dynamiques, …

          • [^] # Re: Agentless, danger

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

            Ansible rends ce phénomène plus fréquent et visible, car le
            mécanisme de notifications (via les handlers) est très
            spécialisé et pas utilisable en toutes circonstances (par
            opposition au notify/subscribe de puppet, qui permet de
            coordonner n'importes quelles actions).

            Pour compléter ça, il y a aussi le système de listener maintenant:
            https://github.com/ansible/proposals/issues/11

            J'ai pas encore utilisé, mais ça rajoute un peu de souplesse dans la gestion des handlers.

      • [^] # Re: Agentless, danger

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

        Ansible est leeeeeeeeent à coté de Puppet…

        bah, y a pas de secret, ansible fait les opérations une par une, puppet envoie tout sur l'agent pour qu'il fasse 1) juste ce qu'il faut 2) en même temps. Puppet (et les autres) seront sans doute toujours plus rapide qu'Ansible.

        Ensuite, James Shubin, estimé collègue et auteur de mgmt (https://github.com/purpleidea/mgmt) n’arrête pas de présenter l'outil (mgmt) partout en expliquant comment il arrive à faire un truc qui converge plus vite que Puppet et sans les soucis de Puppet (notament de version), et comment ça va révolutionner les choses. Y a des vidéos de lui sur youtube, et il va être présent au FOSDEM à Bruxelles, au config mgmt camp à Gent, et à Devconf à Brno. Son design a l'air en effet correct, et je sais qu'il a passé beaucoup de temps dessus pour avoir un bon truc.

        Un "--check" sous Ansible (qui est l'équivalent) va quand même
        faire certains trucs pour de vrai (notamment les installs de
        packages - hé oui ! surprise ! )

        Si c'est le cas, c'est un bug. Le code du module yum n'est pas censé le faire, par exemple, pkgin non plus, apt, etc, etc.

        Si tu as un cas précis, je peux essayer de regarder.

      • [^] # Re: Agentless, danger

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

        , la GROSSE différence entre Puppet et Ansible, c'est la vitesse d'exécution

        La grosse différence c'est que dans puppet ce sont les clients qui viennent chercher leur conf alors qu'ansible pousse la conf sur les clients.

        C'est la base de l'enforcement.

        Ansible, ou fabric ou rex ou pssh, sont de très bons outils de script, très pratique pour faire du déploiement de masse, des mises à jour, des installations. Puppet c'est autre chose, d'autres concepts et d'autres objectifs : un moyen de gérer un parc dans la durée, avec un agent, une pki, une cmdb, les facts …

        Par exemple, je suis capable aujourd'hui grâce aux trusted facts de définir complètement un serveur rien qu'en émettant un certificat. À quoi il va servir ? Pour quel client ? Quoi installer dessus … Le cycle : définir, tester, enforcer, rapporter est tout a fait adapté à un processus industriels de gestion des serveurs. C'est la grande force de puppet.

        • [^] # Re: Agentless, danger

          Posté par  . Évalué à 3.

          Par exemple, je suis capable aujourd'hui grâce aux trusted facts de définir complètement un serveur rien qu'en émettant un certificat. À quoi il va servir ? Pour quel client ? Quoi installer dessus … Le cycle : définir, tester, enforcer, rapporter est tout a fait adapté à un processus industriels de gestion des serveurs. C'est la grande force de puppet.

          Tu peux en dire plus ?

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

    • [^] # Re: Agentless, danger

      Posté par  . Évalué à 3.

      Moi j'avais installé du puppet; mais la gestion des agents et les contraintes de compatibilité entre le serveur et les agents m'ont fait complètement abandonner la chose.

      De mémoire, il faut impérativement avoir le serveur dans une version supérieur aux agents. Ce qui empêche d'installer une machine avec le dernier agent tant qu'on n'a pas mis à jour le serveur.

      Du coup je vois un gros avantage à Ansible qui se contente du SSH.

      • [^] # Re: Agentless, danger

        Posté par  . Évalué à 3.

        Après, y'en qui gèrent les agents Puppet avec Ansible :D

        • [^] # Re: Agentless, danger

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

          C'est mon cas :-)

          Parce qu'avant d'installer puppet, il faut faire un minimum de chose pour qu'il puisse fonctionner, comme par exemple la configuration réseau pour atteindre le puppet master, ou encore sécuriser un minimum la machine quand elle est à poil sur internet.

          J'ai donc des scripts ansible pour "bootstrapper" les nouvelles machines. Ces scripts configurent le minimum vital pour que puppet puisse fonctionner et qu'on puisse se connecter en toute sécurité sur la machine (et tout les trucs bas niveau qui sont trop chiant à faire en puppet) : lancent apt-update/upgrade,, installent les paquets de "survie" (comme vim :), configure les interfaces réseaux (en particulier tout ce qui est lan pour le vrack chez ovh etc), le /etc/hosts, resolv.conf, config du serveur ssh, et au final configurent l'agent puppet.

          Les scripts puppet se chargent du reste.

          On va me demander pourquoi ne pas faire tout en ansible (surtout que je ne suis pas super fan de puppet) : pour des raisons historique, c'est puppet qui avait été choisi au départ (par rapport à chief et quelques autres) et à l'époque ansible n'existait pas (ou alors n'était pas encore très stable/très connu/très fonctionnel). Et puis un jour j'en ai eu marre de préparer les nouvelles machines à la main pour pouvoir les "puppetiser". Et j'ai donc utilisé ansible puisqu'il a le bon gout de ne pas avoir une archi agent-serveur (idéal donc pour bootstraper une machine vierge), et très simple à utiliser dans sa philosophie (il serait encore plus simple si il utilisait autre chose que cette connerie de syntaxe Yaml).

          J'aurais pu tout mettre au final en ansible, mais il y a des obstacles à ça :

          • ansible est lent
          • trop de modules puppet à migrer, pas le temps de le faire
          • le système d'agent de puppet, couplé avec un puppet-dashboard, permet de savoir en permanence que tes machines sont toujours configurée comme prévu, et que tu sais quand il y a des trucs qui sont modifiés à ton insu (ce qui peut arriver si il y a une appli qui fait de la merde). Alors qu'avec Ansible, c'est plus compliqué, même si des solutions existent.

          Bref, le couple Ansible (pour le bootstrapping) + puppet me va très bien.

          PS: ce que j'aime bien dans ansible, c'est la facilité de créé des plugins. On peut en faire aussi dans puppet, mais j'ai horreur de ruby et ça semble plus complexe.

          • [^] # Re: Agentless, danger

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

            Personnellement, je pense partir sur du salt (pour configurer des postes clients) + salt-ssh (pour configurer les serveurs).
            L'intérêt est de pouvoir partager un maximum de fichiers entre les deux outils, tout en s'adaptant aux contraintes différentes sur les deux environnements.

    • [^] # Re: Agentless, danger

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

      Alors, c'est pas parce que par défaut, c'est agentless que tu dois t'y tenir.

      Par exemple, tu peux mettre func ou salt qui ont des plugins de connexion ansible ( https://github.com/OSAS/ansible-role-salt_transport ), ( https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/connection/funcd.py ) à la place de ssh.

      Tu peux aussi utiliser le mode pull, ou tu as un cron qui va faire un git pull et execution local via ansible -c local.

      Tu peux vérifier que la config de ssh est bonne avant de relancer, par exemple.

      Et bon, si tu vautres le réseau ou le firewall (genre paf, tu mets OUTPUT en DROP au lieu d'ACCEPT), en fonction de comment tu te vautres, Puppet ne va pas te sauver même si il a un agent, le risque n'est pas non plus nul.

  • # Idempotence

    Posté par  . Évalué à 6.

    Toujours concernant Ansible (bien entendu), on parle souvent d'idempotence, ce qui signifie qu'une opération a le même effet qu'on l'applique une ou plusieurs fois.

    Tu va très vite là dessus alors que c'est un point crucial de ces outils (c'est pas spécifique à ansible).

    L'idempotence est très utile pour appliquer un principe simple mais puissant, utiliser exactement la même configuration lors d'une mise à jour ou lors d'une installation initiale. Ça permet de ne pas prendre de risque et d'avoir des machines que l'on sait correctement configurée. On ne maintiens pas 2 versions de scripts etc… Ça réduit drastiquement les risques tout en étant bien plus simple.

    Et c'est pour avoir cette idempotence que l'on ne fait plus de scripts, mais que l'on décrit l'état objectif. Au lieu de dire : « ajoute la ligne "foo" au fichier bar » on dit : « je souhaite qu'il y ait la ligne "foo" dans le fichier bar ». Ce changement de paradigme est très important. Il est gratuit avec pas mal de module d'ansible (je ne sais pas pour les autres), par exemple si on lui demande d'envoyer un fichier sur le serveur, il vérifie s'il n'y ai pas déjà. Mais il y a pleins d'autres cas où il faut soit même le prendre en compte notamment lors de l'utilisation des modules command et shell. Il y a aussi des modules qui ne peuvent pas faire ce genre de vérification (demander un redémarrage de service) dans ces cas là il faut des fois ajouter sois-même ce qu'il faut pour (vérifier que l'on a bien modifié le fichier de configuration du deamon par exemple).

    C'est entre autre ce qui peut rendre vraiment compliqué la création d'un bon role ansible.

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

    • [^] # Re: Idempotence

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

      Un autre aspect qui est souvent plus difficile qu'il n'y paraît est le découpage des rôles. Comment faire pour découper la configuration de chaque machine en morceaux, afin d'avoir le maximum de fichiers en commun (et donc le moins de lignes au total), et d'avoir un minimum de conflits entre ces rôles.
      Par exemple, si j'ai une machine qui fait à la fois LDAP et Apache, je peux bien sûr faire un seul rôle Ansible. Seulement, si je veux ensuite faire un LDAP tout seul, c'est bien mieux d'avoir découpé en deux rôles différents.

      Si au contraire je pars d'un LDAP et d'un Apache sur deux machines différentes, c'est mieux si les rôles Ansible ne génèrent pas de conflit quand j'applique ces deux rôles sur la même machine…

      Ça semble facile, mais ça peut devenir un vrai casse-tête quand on a un très grand nombre de rôles à appliquer.

      • [^] # Re: Idempotence

        Posté par  . Évalué à 3.

        Je suis d'accord, mais je pense que chercher à utiliser les roles dispo dans ansible galaxy doit pas mal aider (je m'y suis pas mis encore).

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

  • # elysee ???

    Posté par  . Évalué à 2.

    Au milieu du fichier de conf on voit:

    Dans /etc/ansible/, donc, éditons notre fichier hosts. Nous pouvons y déclarer nos serveurs individuellement ou par groupe, par exemple :
    serveur1.exemple.org
    serveur2.exemple.org
    preprod.elysee.org

    preprod.elysee.org? C'est un copier/coller un peu rapide d'un vrai fichier de conf? Ansible sert à pousser des confs sur le site de l'élysée?

    • [^] # Re: elysee ???

      Posté par  . Évalué à 3.

      J'ose imagine que l'Elysée a le bon gout d'utiliser un .fr quand meme.
      Et aussi d'avoir le bon gout de retourner autre chose qu'un 200 OK sans contenu :)

      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

  • # PyInfra

    Posté par  . Évalué à 2.

    Perso après avoir utilisé Ansible sur un projet important. Je me trouve un peu limité par ce qu'il propose avec YAML / Jinja (pour les itérations, les valeurs par défaut, etc…). Et, détail, je suis un peu perdu dans mon éditeur avec 100 fichiers qui s'appellent main.yaml !

    pyinfra reprend la structure et les termes de Ansible, mais les fichiers sont en python. On a aussi l'aspect idempotent. Je trouve ça vraiment tentant (mais n'ai pu encore tester).
    Un autre aspect intéressant est que contrairement à Ansible, il envoie des commandes shell (et non uniquement des scripts python exécutés sur la machine distance comme Ansible) ce qui semble plus efficace pour pas mal de tâches simples.

    Je ne sais pas si l'un de vous à pu tester sur des projets un peu importants ?

    • [^] # Re: PyInfra

      Posté par  . Évalué à 3.

      Perso après avoir utilisé Ansible sur un projet important. Je me trouve un peu limité par ce qu'il propose avec YAML / Jinja (pour les itérations, les valeurs par défaut, etc…).

      Pour l'itération le fait de pouvoir simplement itérer sur des structures complexes et faire des conditions me paraît déjà assez puissant. Pour les valeurs par défaut la hiérarchie de variables me semble déjà assez complexe comme ça.

      Et, détail, je suis un peu perdu dans mon éditeur avec 100 fichiers qui s'appellent main.yaml !

      Tu peux le découper autant que tu veux et faire des include.

      Un autre aspect intéressant est que contrairement à Ansible, il envoie des commandes shell (et non uniquement des scripts python exécutés sur la machine distance comme Ansible) ce qui semble plus efficace pour pas mal de tâches simples.

      C'est surtout pratique pour les tests.

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

  • # CVE-2016-9587

    Posté par  (site web personnel) . Évalué à 9. Dernière modification le 13 janvier 2017 à 13:44.

    Et n'oubliez pas de mettre à jour vos Ansible 2.1.x et 2.2.x (a priori pas les 1.9.x) : "CVE-2016-9587: an unpleasant Ansible vulnerability" (article LWN) "a compromised remote hosts can lead to running commands on the Ansible controller" (l'attaque est dans la remontée des facts apparemment)
    Voir aussi l'annonce sécurité Red Hat

    Nouvelles versions en préparation :

    (source)
    "Ansible 2.2.1 RC3 and 2.1.4 RC1 were released today, which contain fixes for the security bugs above."

    puis

    (source)
    "We've just released the following release candidates to address a few more corner cases found after the release of the previous RCs for CVE-2016-9587:

    2.1.4 RC2
    2.2.1 RC4"

  • # Erreur de français

    Posté par  . Évalué à 1.

    Après l'avoir enregistré, il suffira de lancer la commande suivante pour installer cette liste de paquets sur tout les serveurs :

    "tous" et pas "tout"

    Je n'ai pas compris quelque chose, ou il est impossible mettre une lettre en gras en Mardown sur LinuxFr ?

  • # Une base de travail pour Ansible

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

    Pour ceux qui sont un peu habitués à Ansible 2.2, je me suis fait un petit Squelette de base pour directement commencer à travailler sur le métier plutôt que sur la mise en place de la structure et des bonnes pratiques. Le code est dispo ici, et je serait curieux d'avoir des retours constructifs si ça intéresse des gens: https://github.com/mrjk/ansible-skel. Je l'utilise la plupart du temps chez mes clients.

    PS: Si ce message est considéré comme de la pub, n'hésitez pas à le supprimer.

Suivre le flux des commentaires

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