En quoi Ansible est-il différent de simplement exécuter un shell bash d'approvisionnement dans Vagrant?


39

Une équipe d’administrateurs informatiques expérimentés dans l’utilisation de scripts shell pour résoudre leurs problèmes envisagent de commencer à utiliser Ansible.

Existe-t-il des différences substantielles et de bonnes raisons pour commencer à utiliser Ansible ou pour continuer à écrire des scripts shell?

Réponses:


29

Je n'ai jamais utilisé Ansible, mais depuis quelques semaines, j'essaie de comprendre ce que pourrait bien Ansible par rapport aux scripts shell - ce qui prouve, du moins dans mon cas, que les campagnes publicitaires obsédantes qu'elles dirigent sont efficaces! Après de nombreuses tentatives infructueuses - ce qui prouve à quel point leur documentation échoue à répondre à l'une des questions les plus évidentes -, je pense que je l'ai enfin comprise:

Maintenant, regardons la vidéo d’introduction et passons au hasard en tant que nouvel utilisateur potentiel dans le matériel d’introduction à Ansible et comparons-le à ce qu’un programmeur shell expérimenté peut produire directement.

Ma conclusion est que sur les scripts shell, Ansible offre essentiellement: 1. La possibilité de vérifier qu'un système est conforme à un état souhaité, 2. la capacité à s'intégrer à Ansible Tower, qui est un système payant qui semble inclure des capacités de surveillance. Dans certains cas importants, comme lors de l’implémentation du modèle de serveur immuable, le point 1 n’est probablement pas très utile, la liste est donc plutôt mince.

Ma conclusion est que les avantages offerts par Ansible par rapport au shell-scripting, tels que présentés par la documentation, pourraient être raisonnables dans quelques cas optimistes bien couverts par les modules disponibles, mais sont modestes voire hypothétiques dans le cas général. Pour un programmeur expérimenté, ces avantages sont probablement contrebalancés par d'autres aspects du compromis.

Mais cela prouve peut-être à quel point le matériel d’introduction est mauvais!

La vidéo de démarrage rapide:

Il y a une vidéo de démarrage rapide . Cela commence par une page affirmant que… bien ce ne sont pas vraiment des revendications, ce sont des listes à puces, un artefact couramment utilisé pour suspendre le jugement critique dans les présentations (puisque la logique n'est pas montrée, elle ne peut pas être critiquée!)

1. Ansible est simple:

1.1 Automatisation lisible par l'homme - Les spécifications sont des documents techniques, comment

  name: upgrade all packages
  yum:
    name: '*'
    state: latest

être plus facile à lire que l' invocation yum correspondante trouvée dans un script shell? De plus, quiconque a eu un contact avec AppleScript meurt de rire en lisant «automatisation lisible par l'homme».

1.2 Aucune compétence particulière en codage n'est requise - Qu'est-ce que le codage sans la rédaction de spécifications formelles? Ils ont des conditions, des variables, alors, comment ne codent-ils pas? Et pourquoi aurais-je besoin de quelque chose que je ne puisse pas programmer, qui serait désormais inflexible? La déclaration est heureusement inexacte!

1.3 Tâches exécutées dans l’ordre - Certains aficionados de code-golf sont peut-être au courant des langages qui exécutent des tâches en désordre, mais l’exécution de tâches dans l’ordre semble à peine exceptionnelle.

1.4 Soyez productif rapidement - Les programmeurs de shell qualifiés sont maintenant productifs. Ce contre-argument est aussi sérieux que le premier argument.

2. Ansible est puissant

Une astuce de vente populaire pour vendre des artefacts est de tromper les gens en leur faisant croire qu'ils vont acquérir le «pouvoir» de ces artefacts. L'histoire de la publicité pour les voitures ou les boissons isotoniques devrait fournir une liste convaincante d'exemples.

Ici, Ansible peut faire le «déploiement d'applications» - mais le script shell le fait sûrement, la «gestion de la configuration», mais il ne s'agit que d'un énoncé de la fonction de l'outil, pas d'une fonctionnalité, et d'une «orchestration de flux de travail» qui a l'air un peu prétentieux, mais aucun exemple ne va au-delà de ce que GNU Parallel peut faire.

3. Ansible est sans agent

Pour remplir la colonne, ils ont écrit de trois manières différentes que cela ne nécessitait que ssh, qui, comme tout le monde le sait, est un démon et n'a rien à voir avec ces agents qui imprègnent la gestion de la configuration mondiale!

Le reste de la vidéo

Le reste de la vidéo présente les inventaires, qui sont des listes statiques de ressources (telles que des serveurs), et montre comment déployer Apache sur trois serveurs simultanément. Cela ne correspond vraiment pas à ma façon de travailler, où les ressources sont très dynamiques et peuvent être énumérées à l'aide d'outils en ligne de commande fournis par mon fournisseur de cloud et consommées par mes fonctions de shell à l'aide de l' |opérateur de canal . De plus, je ne déploie pas Apache sur trois serveurs simultanément, je construis plutôt une image d'instance principale que j'utilise ensuite pour démarrer 3 instances, qui sont des répliques exactes l'une de l'autre. La partie «orchestration» de l'argumentation n'a donc pas l'air très pertinente.

Documentation aléatoire étape 1: Intégration à EC2

EC2 est le service informatique d'Amazon, l'interaction avec celui-ci est prise en charge par un module Ansible . (D'autres fournisseurs d'informatique en nuage populaires sont également fournis):

# demo_setup.yml

- hosts: localhost
  connection: local
  gather_facts: False

  tasks:

    - name: Provision a set of instances
      ec2:
         key_name: my_key
         group: test
         instance_type: t2.micro
         image: "{{ ami_id }}"
         wait: true
         exact_count: 5
         count_tag:
            Name: Demo
         instance_tags:
            Name: Demo
      register: ec2

Le script shell correspondant serait essentiellement identique à YAML remplacé par JSON:

provision_a_set_of_instances()
{
  aws --output=text ec2 run-instances --image-id …   
}

ou la version JSON

provision_a_set_of_instances()
{
  aws --output=text ec2 run-instances --cli-input-json "$(provision_a_set_of_instances__json)"  
}

provision_a_set_of_instances__json()
{
  cat <<EOF
{
    "ImageId": … 
}
EOF
}

Les deux versions sont essentiellement identiques, l’essentiel de la charge utile est l’énumération des valeurs d’initialisation dans une structure YAML ou JSON.

Documentation aléatoire étape 2: Livraison continue et mises à niveau progressives

La plus grande partie de ce guide n'affiche aucune fonctionnalité vraiment intéressante: il introduit des variables (IIRC, les scripts shell ont aussi des variables) !, et un module Ansible gère mysql, de sorte que si au lieu de chercher après «comment créer un utilisateur mysql avec des privilèges sur XY ”et se termine par quelque chose comme

# Create Application DB User
mysql --host "${mysql_host}" --user "${mysql_user}" --password "${mysql_password}" "${mysql_table}" <<EOF
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';
EOF

vous recherchez "comment créer un utilisateur mysql avec des privilèges sur XY dans ansible " et me retrouver avec

- name: Create Application DB User
  mysql_user: name={{ dbuser }} password={{ upassword }}
              priv=*.*:ALL host='%' state=present

La différence n’est probablement toujours pas très significative. Sur cette page, nous découvrons également qu'Ansible possède un modèle de langage de méta-programmation.

{% for host in groups['monitoring'] %}
-A INPUT -p tcp -s {{ hostvars[host].ansible_default_ipv4.address }} --dport 5666 -j ACCEPT
{% endfor %}

Quand je vois cela, je me trouve vraiment dans ma zone de confort. Ce type de méta-programmation simple pour les langages déclaratifs correspond exactement au même paradigme théorique que les Makefiles BSD! Ce que j’ai programmé de manière intensive Cet extrait nous montre que la promesse de travailler avec le fichier YAML est brisée (je ne peux donc pas exécuter mes playbooks avec un analyseur syntaxique YAML, par exemple ). Cela nous montre également qu'Ansible doit discuter de l'art subtil de l'ordre d'évaluation: nous devons décider si les variables sont développées à la «partie déclarative» du langage ou à la méta-partie «impérative» du langage. Ici, la programmation shell est plus simple, il n’ya pas de méta-programmation, à l’exception du sourçage de scripts explicite eval ou externe. L’extrait de coque équivalent hypothétique serait

enumerate_group 'monitoring' | {
  while read host; do
    …
  done
}

Sa complexité par rapport à la variante Ansible est probablement tolérable: elle utilise simplement les constructions simples, régulières et ennuyeuses du langage.

Documentation aléatoire étape 3: Stratégies de test

Enfin, nous rencontrons ce qui s’avère être la première fonctionnalité réellement intéressante d’Ansible: «Les ressources Ansible sont des modèles d’état souhaité. En tant que tel, il ne devrait pas être nécessaire de vérifier que les services sont démarrés, que les packages sont installés, etc. Ansible est le système qui garantira que ces informations sont vraies de manière déclarative. Au lieu de cela, affirmez ces choses dans vos playbooks. »Cela commence à être un peu intéressant, mais:

  1. Mis à part une poignée de situations standard facilement implémentées par les modules disponibles, je devrai alimenter moi-même les bits implémentant le test, ce qui impliquera très probablement quelques commandes shell.

  2. La vérification de la conformité des installations peut ne pas être très pertinente dans le contexte où le modèle de serveur immuable est implémenté: où tous les systèmes en fonctionnement sont générés à partir d’une image maître (image d’instance ou image de menu fixe par exemple) et jamais mis à jour - ils sont remplacés par nouveau à la place.

Préoccupation non résolue: la maintenabilité

Le matériel d'introduction de Ansible ignore la question de la maintenabilité. En l'absence de système de type, les scripts shell ont la facilité de maintenance de JavaScript, Lisp ou Python: des refactorisations complètes ne peuvent être réalisées avec succès qu'à l'aide d'une suite de tests automatisés étendue, ou au moins de conceptions permettant des tests interactifs simples. Cela dit, si les scripts shell sont la lingua franca de la configuration et de la maintenance du système, presque tous les langages de programmation ont une interface avec le shell. Il est donc tout à fait possible de tirer parti de l’avantage en termes de facilité de maintenance des langages avancés, en les utilisant pour coller ensemble les divers bits de bits de configuration de shell. Pour OCaml, j’ai écrit Rashell cela fournit essentiellement une main de modèles d'interaction communs pour les sous-processus, ce qui rend la traduction des scripts de configuration pour OCaml essentiellement triviale.

Du côté d’Ansible, la structure très faible des cahiers et la présence d’une fonction de méta-programmation rendent la situation aussi mauvaise qu’elle en est pour les scripts shell, le point négatif étant qu’il n’est pas évident d’écrire des tests unitaires pour Ansible. , et l'argument de l'introduction ad-hoc d'un langage de niveau supérieur ne peut être imité.

Durée de vie des étapes de configuration

La documentation de Ansible attire l'attention sur la nécessité d'écrire des étapes de configuration idempotentes. Plus précisément, les étapes de configuration doivent être écrites afin que la séquence d’étapes aba puisse être simplifiée en ab , c’est-à-dire qu’il n’est pas nécessaire de répéter l’étape de configuration. C'est une condition plus forte que l'idempotency. Ansible autorisant les playbooks à utiliser des commandes de shell arbitraires, Ansible lui-même n'est pas en mesure de garantir le respect de cette condition plus stricte. Cela ne dépend que de la discipline du programmeur.


Cela ressemble à un manuel ... impressionnant!
Pierre.Vriens

4
Je ne pourrais pas être plus d'accord. Nous utilisons Ansible depuis plus d'un an maintenant et utilisons maintenant des conteneurs Docker, construits avec de bons vieux scripts bash. Définir l’état est également à mon avis de loin la caractéristique la plus intéressante, mais comme vous l’avez déjà mentionné, il y a tellement de services qui ne possèdent pas de module Ansible correspondant, de sorte que vous devez toujours revenir à des commandes bash de toute façon. Et oui, nous ne déployons également que des conteneurs immuables sur des serveurs. La définition de l'état n'est donc pas un avantage dans ce cas.
Andreas

1
Après avoir utilisé ansible à fond, je peux confirmer tous les arguments que j'ai déjà formulés. L’impuissance est possible mais non imposable (voir le module vmware_guest pour les mauvais citoyens), travailler avec leur système macro est une véritable gêne et il est incroyablement difficile d’effectuer même les traitements les plus élémentaires sur des données structurées. (le format du livre de lecture ne peut pas manger un mode de fichier Unix sans thérapie) et la seule vraie bonne chose est la charge de fonctions utiles écrites pour ansible. Donc, si Red Hat n'avait pas poussé ce produit, je ne pourrais pas comprendre l'adoption à grande échelle.
Michael Le Barbier Grünewald

1
@Andreas Je conviens que vous rencontrez toujours de nombreux cas dans lesquels vous devez recourir au shell ou à des modules de commande, ce qui ne signifie pas que votre jeu ansible ne peut pas être idempotent. Les modules de base eux-mêmes conservent leur idempotency en vérifiant simplement si l'action doit être effectuée. Vous pouvez faire la même chose avec le shell ou le module de commande en exécutant d’abord une tâche qui vérifie si quelque chose doit être fait et en enregistrant sa sortie, puis en conditionnant la seconde tâche en fonction du résultat de la première tâche.
Levi

1
@ MichaelLeBarbierGrünewald, je suis d’accord sur le fait que lorsque j’ai travaillé avec Ansible, c’était vraiment pénible de fonctionner et que son travail prend des semaines pour réunir un livret de jeu afin de se connecter à l’infrastructure de mon ancienne entreprise basée sur le cloud, fournir le linux distro, installer LAMP / LEMP ou autre. Une fois terminé, cela nous a fait gagner du temps, mais cela a pris environ un mois pour le rendre opérationnel. Aucun de nous n'était un scripteur de bash, donc ce n'était pas une alternative.
Daniel

22

En termes simples, même si Ansible présente certains avantages, l’utilisation d’outils connus (dans ce cas, les scripts shell) doit être compensée. Je ne pense pas qu'il y ait une réponse claire à cela.

Si l’équipe peut réaliser ce que Ansible propose avec shell:

  1. Gestion de configuration déclarative et idempotente
  2. Accès à des extraits réutilisables (c.-à-d. Des livres de lecture) pour des services populaires du secteur.
  3. Gestion fiable de l'exécution à distance, avec nouvelles tentatives, logique évolutive, etc.

alors ils pourraient probablement s'en tenir à ce qu'ils savent.

Après tout, vous pouvez implémenter des "gardes" dans BASH. Vous pouvez trouver de nombreux travaux BASH existants pour résoudre diverses tâches de configuration de serveur (essentiellement, tout fichier Docker existant contient 90% de code d’installation bash). Vous pouvez vous rapprocher de ce que Ansible / Salt / Chef-Zero vous offre, sans avoir à transférer toute votre solution existante vers ces outils.

C'est un acte d'équilibre entre les tendances des NIH (non inventés ici) et le rejet de bons scripts établis en faveur d'une solution plus robuste.

Une dernière considération à garder à l’esprit: comment votre technologie se compare-t-elle lorsque vous essayez de recruter plus de personnes dans l’équipe. Il est beaucoup plus facile de trouver des personnes qui ont une expérience Ansible que de trouver des personnes qui ont une expérience de votre outil de script de gestion de script développé à la maison. Ce n'est pas strictement une considération technique, plus culturelle. Voulez-vous être l'org étrange qui invente son propre Ansible, ou voulez-vous être l'org raisonnable qui trouve le bon outil pour le travail? Ces décisions ont un impact sur votre capacité à attirer des talents.


4
Aimé votre réponse; Je voudrais également mentionner que, si l'équipe bash opte pour l'idempotence, la gestion de l'exécution et la réutilisation, en écrivant essentiellement son propre cadre de gestion de la configuration, il en résulte un coût, et nous savons tous que cela peut être très désagréable pour des projets internes. .
ᴳᵁᴵᴰᴼ

Je souscris également à votre réponse, en particulier après avoir mis l'expérience disponible dans la balance. J'ai deux petits critiques: d'abord idempotency. Ceci est bien sûr un aspect important des systèmes de configuration, mais puisqu'il est possible d'utiliser toutes les commandes shell possibles dans les playbooks ansibles, le système peut au mieux inciter à utiliser idempotency. (Nous voulons en réalité quelque chose de plus puissant que idempotency aba = ab .) Deuxièmement, une gestion fiable de l'exécution à distance peut être totalement inutile dans certains cas importants, par exemple lors de la mise en œuvre du modèle de serveur immuable à l'aide d'images d'instance.
Michael Le Barbier Grünewald

13

La réponse ci-dessus en couvre une partie, mais manque l'un des éléments importants: la conception convergente. J'ai écrit quelques mots à ce sujet il y a quelque temps dans le contexte de Chef à l' adresse https://coderanger.net/thinking/, mais la version abrégée indique qu'un script bash est un ensemble d'instructions, tandis qu'un livre de lecture Ansible (ou la recette de Chef, Salt état, etc.) est une description de l'état souhaité. En documentant l'état souhaité plutôt que les étapes à suivre pour y parvenir, vous pouvez gérer beaucoup plus d'états de départ. C’était le cœur de la théorie de la promesse décrite dans CFEngine il y a longtemps, et une conception que nous (les outils de gestion de la configuration) copions depuis.

tl; dr Ansible code dit ce que vous voulez, Bash code dit comment faire une chose.


2
Pouvez-vous également ajouter des références à la "théorie des promesses", telles que des livres ou des articles, et à tout autre document précieux si quelqu'un veut en apprendre davantage?
Evgeny

1
C'est en fait ce à quoi j'ai fait allusion lorsque je disais que vous pouvez écrire du code bash idempotent (c'est-à-dire qu'il peut commencer à tout moment, être exécuté plusieurs fois et converger vers l'état souhaité). Mais votre réponse a été beaucoup plus claire.
Assaf Lavie

Ouais, l'idempotence est une propriété importante des systèmes convergents, mais les deux ne sont pas toujours directement liés :) portable.
coderanger


3

Une chose à noter est que vous aurez également moins de problèmes à gérer vos livres de lecture ansible sur des hôtes distants. Comme c'est la principale raison de courir ansible. Lorsque vous utilisez un script shell, vous devez toujours avoir un moyen de scripter le script sur l'hôte distant.


Ansible n’est-il pas juste un wrapper autour de ssh dans ce sens?
Evgeny

Essentiellement oui. Il fait ssh, copie les scripts python à distance et les exécute. Cela signifie, en fait, que si votre module ansible dépend d’une bibliothèque python, cette bibliothèque devrait être présente sur la machine distante, dans certaines circonstances.
Assaf Lavie

1
Et si vous gâchez la configuration ssh, vous êtes bloqué hors de votre machine, inconvénient habituel de push vs pull.
Tensibai

1

Nous sommes en 2019 et je viens de passer quelques jours à apprendre, et voici la vérité absolue: Ansible n'en vaut pas la peine.

ce n'est pas fini, il ne fonctionne pas sous Windows et la combinaison de la configuration YAML et de messages d'erreur trompeurs fera saigner vos yeux. Cela semble presque délibérément terrible et je le pense sérieusement. C'est clairement le produit d'un projet côté développeur redouté par les administrateurs système. Probablement un hipster.

Si vous n'avez besoin d'aucune de ses fonctionnalités au-delà du provisionnement, et que vous ne le faites que sur un seul système d'exploitation. Par pitié, écrivez un shell.script décent.

À l'heure actuelle, l'ensemble du projet me rappelle les premiers forums Linux où des noobs avaient été informés de la situation par RTFM et demandaient pourquoi quelqu'un ne pouvait pas écrire une interface graphique pour la configuration des paramètres graphiques. Tu ne comprends pas, n'est-ce pas? Vous devriez vous en tenir aux fenêtres ... peut-être que je vais me marier ... heureux VI-ing.

Utilisez Docker. De préférence à n'importe quoi. Docker est scandaleusement simple et puissant.

Mais que se passe-t-il si vous devez absolument prévoir des boîtes d'étain préexistantes? Quelles sont les vraies alternatives?

Eh bien ... il n'y en a pas encore. Mais je vous promettrai ceci, à moins que ansible ne s'améliore, il y en aura bientôt. Parce que peu importe la force avec laquelle les fanboys le poussent et pardonnent ses échecs… c'est un effort de 5 sur 10.

SCP met en place un script bash et évite les ennuis.


Tout d'abord, cela fonctionne sur Windows via Win_RM ou SSH. Deuxièmement, la syntaxe de yaml est très agréable et peut être générée par programme. Certaines erreurs peuvent induire en erreur n’est pas différente de celle de Java ou de Python qui vomit son courage lors d’une exception. Troisièmement, la notion de SCP uniquement d’un script sur un serveur ne s’applique pas dans les environnements de cloud hautement dynamiques. Quel serveur? Les serveurs pourraient changer tous les jours. Ansible permet de créer des plug-ins d’inventaire facilement configurables, qui permettent de grouper facilement les serveurs et de leur attribuer des variables. Je ne pense pas que Ansible n'en vaut pas la peine. Je pense que c'est exagéré pour votre environnement.
Levi

@ Levi oui. C'est entièrement ma faute si ansible ne tourne pas sous Windows, a une configuration qui n'a pas de schéma, et a une courbe d'apprentissage plus longue et des coûts de maintenance plus élevés que n'importe quelle méthode sur mesure permettant de réaliser la même tâche.
Richard

Pour les environnements en nuage, il existe d'autres approches pour les types d'entreprises à grande échelle qui pourraient justifier la courbe d'apprentissage. Je comprends ce que fait Ansible. Je ne vois tout simplement pas sa niche.
Richard

Le créneau est un cadre d'automatisation facile à utiliser pour plusieurs machines. Ce n'est pas aussi bien pour Windows que pour Linux. Ce n'est pas non plus idéal pour MSDOS et NetWare. Nous sommes en 2019, les serveurs Windows sont la petite niche inutile de nos jours.
dyasny
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.