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?

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.

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.

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.

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.

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.