Comment tester le provisioning et la configuration dans l'installation Ansible?

33

Nous essayons de renforcer la résilience de notre configuration Ansible, qui traite du provisionnement et de la configuration.

Je comprends quelques méthodes de test du côté de la configuration, mais je me demande comment le mieux mettre en œuvre des tests du côté du provisioning, et s’il existe des outils pouvant aider à ce type de mise en oeuvre.

Actuellement, une grande partie de nos tests sont effectués en série dans le livre de jeu, ce qui est logique pour des choses telles que "le service est disponible; la vip est-elle disponible? Cette tâche async est-elle terminée?" configuration au niveau de la couche application et mise en service (telle que la configuration de la machine virtuelle). Je suis conscient que Ansible n'est pas le meilleur outil pour travailler avec la dérive de configuration, mais je suis curieux de connaître votre propre opinion.

Si vous avez quelque chose à automatiser complètement le processus encore mieux. (Nous avons quelques scripts laids qui font un compte rendu quotidien).

Remarque : à l'heure actuelle, il existe quelques conditions dans lesquelles une réapprovisionnement peut avoir lieu (par exemple, une reconstruction à partir d'une sauvegarde, un problème critique des systèmes), mais en général, il effectue une boucle sur certaines des tâches de configuration standard et n'y pense plus.

Naphta
la source
2
serverspec.org
Matt Schuchard Le
Ansible ne fonctionne-t-il qu'une fois lors du provisionnement? Si non, quelle est sa fréquence d'exécution? J'essaie juste de comprendre le problème avant de proposer une solution.
Woodland Hunter
Bonjour @Naphta Si l'une des réponses a résolu votre question, veuillez l' accepter en cliquant sur la coche. Cela indique à la communauté plus large que vous avez trouvé une solution et donne une certaine réputation à la fois au répondeur et à vous-même. Il n'y a aucune obligation de le faire.
Richard Slater
I'm aware Ansible isn't the best tool for working with configuration drift S'il vous plaît, expliquez.
030

Réponses:

19

Quelques options là-bas ..

Outils de test: triés par étoiles de github

  • Serverspec - Ruby, l’outil le plus populaire sur le marché, construit à partir de la commande rspec de ruby
  • Goss - YAML, simple, <10Mo binaire autonome, extrêmement rapide, peut générer des tests à partir de l'état du système
  • Inspec - Ruby, considérez-le comme une spécification de serveur améliorée, presque identique, faite par les chefs. Construit pour être plus facile à étendre que serverpec
  • Testinfra - Python, a la particularité de pouvoir utiliser l'inventaire / vars d'Ansible

Différences majeures entre eux:

En fin de compte, je suggérerais de passer une journée à expérimenter avec chacun d’entre eux pour les sentir avant de décider par vous-même.

  • À l'exception de Goss, tous les frameworks peuvent fonctionner sur une machine distante (par exemple sur ssh). Goss ne fonctionne que localement ou en docker w / dgoss.
  • Tous les frameworks peuvent être exécutés localement sur un serveur, mais nécessitent l'installation ou l'intégration de Python ou de Ruby. Inspec fournit un ensemble autonome <150 Mo avec une version intégrée de ruby. Goss est un seul binaire <10 Mo sans aucune dépendance externe.
  • Goss prend en charge de manière intégrée la sortie nagios / sensu, ce qui facilite l’intégration aux outils de surveillance.
  • Les tests de Goss ont tendance à être plus simples, mais moins flexibles car basés sur YAML. D'autres frameworks vous permettent d'exploiter toute la puissance du langage sous-jacent Python / Ruby pour écrire des tests ou étendre les fonctionnalités de l'outil. (simplicité vs flexibilité)
  • Goss vous permet de générer des tests à partir de l'état actuel du système
  • À ma connaissance, Testinfra est le seul à prendre en charge les stocks et variables variables
  • Inspec est soutenu par le chef

Test continu / de divergence:

  • Chef Compliance - collabore avec inspec pour tester en permanence vos serveurs, produit payant
  • Goss - Peut être facilement accroché à Nagios ou à Sensu. En outre, prend en charge l'exposition des tests de serveur en tant que point d'extrémité http.

Tester les faisceaux pour le développement:

  • kitchen - L'outil de test de harnais, lance l'instance, exécute le code de gestion de configuration, exécute la suite de tests. Fabriqué par les gars du chef
  • Molécule - Similaire à la cuisine d'essai, mais écrit spécifiquement pour ansible

Full Disclosure: je suis l'auteur de goss

UPDATE: InSpec 4.x ou une version ultérieure utilise une licence commerciale / open source mixte - voir les commentaires.

Ahmed Elsabbahy
la source
4
Je comprends que vous soyez un peu partial, mais inspec n’a pas besoin de Compliance pour fonctionner périodiquement. Et il n’ya pas de dépendances à gérer, toutes les bibliothèques et le framework (ruby) nécessaires sont regroupés dans le paquet qui peut être installé localement sur chaque nœud. Lorsqu’il est exécuté via ssh / winrm, Inspec se met en place. Vous indiquez une commande exclusivement externe qui n’est pas vraie. De nombreux tests sont effectués avec un code ruby ​​interne. (Je pense que cela vaut la peine d'être noté)
Tensibai
J'ai mis à jour la réponse pour corriger la commande externe et le ruby ​​intégré pour inspec. Pouvez-vous clarifier ou envoyez-moi un lien expliquant comment inspec peut être utilisé seul pour détecter / signaler la dérive?
Ahmed Elsabbahy
Eh bien, la partie rapport sera sous votre main, il est en effet objectif de conformité de faire une déclaration. Mais vous pouvez exécuter inspec dans une crontab et vous fier au courrier crontab lorsqu'un test échoue pour vous alerter (par exemple).
Tensibai
Dans l’ensemble, pour le montage, cela sonne comme une bonne exposition de votre outil et des autres. Je crains que cela ne devienne vite obsolète, mais +1 quand même pour la liste et les pointeurs.
Tensibai
Ah, oui… tous les outils peuvent être utilisés de cette façon. J'essayais de fournir des outils (ou des intégrations avec des outils) qui fournissent de meilleurs rapports. À ma connaissance, il existe une conformité, ou un habillage des outils qui les rend nagios / sensu / amical. Ex: slideshare.net/m_richardson/… Des excuses si cela avait été biaisé au départ, ce n’était pas censé l’être.
Ahmed Elsabbahy
13

Les deux outils que j'ai vus pour cela sont InSpec et ServerSpec . Serverspec est un outil basé sur Ruby qui repose sur RSpec . InSpec est inspiré de RSpec et ServerSpec.

J'ai utilisé ServerSpec. C'est cool, mais peut-être pas 100% stable. J'ai eu des problèmes pour tester des versions spécifiques du logiciel sur Ubuntu.

J'ai lu la documentation InSpec mais je n'ai pas approfondi mes connaissances. Il fait essentiellement la même chose que Serverspec.

À en juger par les commits Github, il semble que le travail sur ServerSpec ait quelque peu diminué, alors qu'InSpec est en train de monter en puissance.

UPDATE: InSpec 4.x ou une version ultérieure utilise une licence commerciale / open source mixte - voir les commentaires.

Dave Swersky
la source
1
"J'ai eu des problèmes pour tester des versions spécifiques du logiciel sur Ubuntu." J'ai résolu ce problème après avoir remarqué une question à ce sujet sur un SO: stackoverflow.com/questions/42417864/…
Matt Schuchard le
Pour clarifier un peu, InSpec émule RSpec mais ne le construit pas.
coderanger
1
@ MattSchuchard Merci pour cette référence!
Dave Swersky
bien « pas stable à 100% » pour un outil de test ne semble pas bon
ᴳᵁᴵᴰᴼ
InSpec est très bon en tant qu'outil de test et permet de ne rien installer sur le serveur, alors que ServerSpec ne peut le faire qu'avec un peu de travail supplémentaire. Cependant, il faudrait un peu de travail pour qu'InSpec utilise un inventaire Ansible - probablement plus facile si l'inventaire est au format YAML (Ansible 2.4+).
RichVel
10

Lors de l'utilisation d'outils de gestion de la configuration, tels que Ansible, l'outil lui-même serait responsable de la prévention des dérives de configuration. Une fois que vous avez utilisé Ansible pour définir une certaine configuration, son exécution répétitive garantira que votre configuration est celle que vous avez définie. Cela nécessite également que votre code Ansible soit écrit de manière idempotente.

Compte tenu de ce qui précède, il est possible de tester le provisionnement en exécutant vos playbooks Ansible en boucle à partir d’un serveur. Par exemple, un travail cron, ou Jenkins, peut exécuter les playbooks toutes les 30 minutes et rendre compte de tout échec. Ne pas avoir d'échec signifie que votre configuration est sous contrôle, avoir des échecs signifie qu'il est difficile de placer les serveurs dans l' état souhaité .

Dans le cas où vous ne pouvez pas faire confiance à votre code pour qu'il soit écrit en tant qu'idempotent et que vous ne pouvez donc pas exécuter de manière répétitive Ansible dans une boucle à partir d'un serveur automatique, il existe une solution de contournement. Vous pouvez faire la même chose que ci-dessus (exécuter Ansible dans une boucle) mais utiliser son mode de fonctionnement à sec . Chaque fois que Ansible signale que des modifications sont nécessaires, le travail Jenkins (ou le travail cron) peut vous informer que votre configuration provisionnée a été modifiée et que les serveurs ne sont pas dans l' état souhaité .

Pour que votre code Ansible remplisse réellement ce que vous pensez qu'il devrait être, les solutions mentionnées par Dave Swersky s'appliquent. Les deux Inspec et Serverspec sont des outils qui permettent de vérifier dans une autre façon que vos Playbooks ne fait ce que vous voulez dire. Un bon moyen d’exécuter ce type d’outils dans des environnements de test (même dans des conteneurs Docker) consiste à utiliser kitchen.ci, qui gère tout le lien entre les divers outils de test des unités infra et l’exécution de vos playbooks / modules / livres de cuisine.

Kitchen.ci a été utilisé à l'origine pour tester les livres de cuisine Chef, mais des plug-ins existent également pour Ansible et d'autres outils CM.

Evgeny
la source
5

Test Kitchen dispose d'un plugin d'approvisionnement de cuisine ansible pour tester le code Ansible. Cela n’est pas aussi profond que l’intégration de Chef, mais cela fonctionne dans la plupart des cas. Il y a aussi le projet plus récent Molecule qui est un système de test Ansible dédié.

coderanger
la source
0

Vous pouvez suivre les divergences / dérives de configuration / infrastructure avec Outthentic . Il est facile de créer une suite de tests pour "corriger" l'état souhaité et l'exécuter à chaque fois que vous devez suivre les modifications non souhaitées.

Alexey Melezhik
la source
1
Bienvenue sur DevOps.se Alexey. Bien que votre outil puisse aider l'utilisateur dans ce cas, pour que ceci soit une réponse ici, il devrait y en avoir un peu plus pour indiquer en quoi cela est pertinent pour la question. Sinon, cela ressemble à une publicité avec lien uniquement.
poussins
Salut! Bien sûr, juste donné plus de détails.
Alexey Melezhik
De mon point de vue, cela ne fait rien de plus que ce que Rundeck peut faire et dépasse le cadre de cette question. Surtout que la réponse n'explique pas comment elle peut résoudre l'audit d'un millier de serveurs et être alertée d'une dérive ou présenter un rapport lisible par l'homme pour un auditeur en donnant une sortie analysable. D'après ce que je viens de lire, il ne fait pas plus qu'inspec (par exemple) et donne une sortie moins utilisable à grande échelle tout en nécessitant beaucoup d'outils externes pour faire le travail et donc moins portable.
Tensibai
"comment résoudre l'audit de milliers de serveurs" - je n'ai rien trouvé sur des milliers de serveurs dans la question
Alexey Melezhik
"et soyez alerté d'une dérive ou présentez un rapport lisible par un homme pour un auditeur en lui donnant une sortie analysable." ni j'ai trouvé cela dans la question. L'alerte évidente à la dérive est le fait que les tests commencent à échouer ...
Alexey Melezhik