Ansible est un système qui résout diverses tâches d'automatisation, y compris les projets de configuration, de sauvegarde et de déploiement. Il est agréable d'utiliser le système pour écrire des scripts d'automatisation d'un environnement simple à un grand projet. Dans les scripts, les playbooks jouent un rôle important et les playbooks structurés jouent des rôles.
Ansible n'est pas une pilule magique et n'aide que dans un premier temps. Lorsqu'un projet se développe, il devient difficile de maintenir un nombre accru de rôles. Le mécanisme de distribution continue des rôles aide à résoudre le problème.
À peu près à ce sujet, le décodage du rapport d'
Alexander Kharkevich à
DevOps Conf Russia . Dans le rapport: développement de rôles Ansible via CI, un mécanisme pour développer des rôles publics et des rôles publics avec des tests dans une infrastructure privée. Et il n'y a aucune conclusion dans le rapport.
À propos de l'orateur : Alexander Kharkevich (
kharkevich ) ingénieur système senior chez
EPAM Systems .
Commençons par un bref aperçu.
À propos d'Ansible
Ansible est un système de gestion de configuration. Il est écrit en Python, basé sur des modèles par Junja, et YAML est utilisé comme DSL. Géré via Ansible Tower - WebUI pour gérer et surveiller les performances du système.
Ansible est apparu en 2012, après 3 ans que Red Hat a acheté l'ensemble du projet, et deux ans plus tard, a présenté AWX - Project Open Source version d'Ansible Tower.
L'installation
Pour utiliser Ansible, vous devez faire deux choses simples.
Dans un premier temps, compilez un fichier d'inventaire en cas d'infrastructure statique.
La seconde consiste à écrire un Playbook qui amènera le système à l'état attendu.
Nous avons souvent un désir irrésistible d'écrire l'automatisation, qui peut être réutilisée à nouveau. L'automatisation est un bon désir, et les gars d'Ansible ont proposé un concept sympa - le rôle.
Rôle
Il s'agit d'une entité structurée qui amènera le système à son état attendu avec la possibilité de réutiliser l'automatisation.
Par exemple, nous pouvons écrire un rôle pour Oracle Java: prendre un Playbook, mettre un rôle et l'appliquer au système cible. La sortie obtiendra Java installé.
Comment nous avons imaginé travailler avec des rôles
Étant donné qu'Ansible a une chose aussi merveilleuse que les rôles, nous pensions que maintenant nous prendrions et écririons de très nombreux rôles pour toutes les occasions, nous amuserions et les réutiliserions pour réduire la quantité de travail.
Nous pensions que nous écririons des rôles beaux et intelligents ...
Mais la vie s'est avérée plus compliquée.
Il s'est avéré qu'en fait
Lorsque plus d'une personne travaille à écrire un rôle ou à l'améliorer, alors tout le monde écrit au même endroit et des surprises désagréables surviennent: le rôle se comporte différemment de ce que l'auteur avait initialement prévu.
C'est bien quand c'est appliqué à la fin, mais ça n'arrive pas toujours. Parfois, un rôle est exécuté avec succès, mais sur le système cible, cela n'affecte pas du tout comme souhaité à l'origine.
En conséquence, de terribles constructions surviennent, des tentatives de transfert de bash vers Ansible et de soumettre tout cela sous la sauce de gestion de configuration. Nous avons rencontré ce phénomène et étions tristes.
En réfléchissant, nous avons constaté que dans notre gestion de configuration, il existe une sorte de code, ce qui signifie que les pratiques qui s'appliquent à la gestion de code dans le cycle de vie de développement des systèmes sont également applicables dans Ansible.
- Recueillir les meilleures pratiques.
- Appliquer une analyse statique, des peluches.
- Pour tester.
- Pour overclocker, entrer dans la gestion des versions.
Nous avons décidé de mettre en œuvre la pratique à la maison et sommes immédiatement allés chercher des outils adaptés.
Les outils
Du point de vue des systèmes de contrôle de version et de l'intégration continue, il existe des dizaines de solutions disponibles et un zoo de test ramifié.
Du point de vue de la gestion des versions dans Ansible, il n'y a pas tellement de solutions: étiqueter dans Git, ou étiqueter dans Git et télécharger sur Galaxy.
Il existe de nombreuses approches pour tester les outils, chacune utilisant ce qu'elle aime. Solutions populaires utilisant KitchenCI, InSpec, Serverspec.
Notre âme n'a pas menti pour prendre Ansible écrit en Python, et y mélanger des outils du monde Ruby. Par conséquent, après avoir jeté tout ce qui n'est pas natif du monde Python, nous avons obtenu l'image suivante.
Nous utilisons:
- Pour la gestion de la configuration - GitHub et GitLab. GitLab regarde directement sur GitHub. Pourquoi cela, je le dirai plus tard.
- Pour CI, nous avons pris Travis pour la partie publique et GitLab Runner pour la partie privée.
- Test de molécule.
- Lancez-vous dans GitHub et ajoutez-le à Ansible Galaxy.
Notre cycle de développement avec ces outils est devenu plus amusant.
Molécule
Cet outil permet de tester pleinement le rôle ansible. Pour ce faire, il a tout:
- Intégration avec YAML lint et Ansible lint pour vérifier la conformité des rôles avec nos exigences.
- Infrastructure de test pour l'exécution de tests fonctionnels.
- Molecule drivers est l'endroit où Molecule déploie notre banc de test. Tout est pris en charge: Azure, Delegated, Docker, EC2, GCE, LXC, LXD, Openstack, Vagrant.
- Il y a encore une chose utile et simple - la délégation. Cela signifie que Molecule n'est pas responsable du déploiement du banc de test et que le développeur doit écrire un Playbook pour élever le banc de test. Si vous avez un cloud super privé, déléguez la création et la suppression de machines de test, et Molecule elle-même ajoutera tout à l'intérieur.
Matrice de test
Considérez la matrice de test par étapes. Il y a 11 étapes au total, mais je serai bref.
No. 1. Lint
Ils exécutent les peluches YAML et les peluches Ansible et trouvent quelque chose.
Dans l'exemple ci-dessus, lint jure que le shell ne doit pas être simplement appelé dans Ansible, mais doit être fixé, lié à quelque chose.
No. 2. Détruisez
La molécule se débarrasse de tout ce qui reste après les tests précédents.
Il y a des moments où une course est passée, un terrain d'entraînement s'est ouvert et les tests sont terminés. Le stand doit être nettoyé à la fin, mais un cas de force majeure est intervenu et il n'y a pas eu de nettoyage. Dans de telles situations, Molecule s'enfuit, détruit et nettoie l'environnement des résidus.
No. 3. Dépendance
Nous prenons le fichier requirements.yml et ajoutons les dépendances de notre rôle à d'autres rôles. Par exemple, une référence au fait que le rôle ne décollera pas sans Java installé sur le système:
--- - src: lean_delivery.java version: 1.4
Molecule comprend cela et exécutera le script:
- Goes Galaxy ou Git
- reconnaît que les dépendances doivent être traitées;
- Va à nouveau sur Galaxy;
- téléchargements;
- va se développer.
N ° 4. Syntaxe
La prochaine étape est la vérification de la syntaxe. mais pas votre rôle, mais le Playbook de test que vous ajoutez à Molecule. Il y a aussi des erreurs de syntaxe dans cette étape.
La diapositive montre que le rôle ansible est appelé «kibana», et dans le Playbook de test, il est appelé ansible-role-kibana. Le système dit: "Tout irait bien et vous pouvez le créer ici, mais je ne le ferai pas parce que les noms ne correspondent pas!"
No. 5. Créer
À ce stade, nous indiquons le pilote avec lequel le site de test est déployé. Pointez Google - cela augmentera les machines de test dans Google Cloud.
Nous pouvons écrire dans le fichier molécule.yml ce que nous voulons. Voyons à quoi cela ressemble sur un exemple pour Docker.
- Je spécifie les images de docker à tirer vers le haut.
- J'indique comment les regrouper pour former un fichier d'inventaire.
Je veux avoir deux images de docker: une pour RHEL-like, la seconde pour Debian-like, pour être sûr que pendant le test, tout ira bien avec RHEL et Debian.
No. 6. Préparez
Il s'agit d'une étape de préparation de l'environnement d'exécution des tests.
Il semble que tout a augmenté, mais vous devez parfois effectuer des réglages supplémentaires. Dans le cas de tests à l'intérieur d'un Docker sur Debian ou Ubuntu, vous devez installer un deuxième Python, ce qui arrive souvent.
No. 7. Converge
L'étape de la première grande exécution du rôle à l'intérieur de l'instance, pour s'assurer qu'il atteint la fin, est exécutée et Ansible confirme que tout va bien.
- Molécule fait référence à Ansible.
- Ansible déployé sur un site de test.
- Ça marche.
- Tout va bien!
No. 8. Idempotence
Le test d'idempotence est simple et ressemble à ceci.
- La première fois que le rôle s'exécute à l'étape précédente.
- Ansible indique combien de modifications ont été apportées.
- Relance le même rôle.
- Vérifie que le système a été ramené à l'état attendu, mais il n'y a aucun changement lors de la deuxième location.
En conséquence, nous comprenons que notre rôle n'agit pas de manière destructrice.
Cette étape a causé de la douleur aux gars avec qui je travaille. Ils ont essayé de contourner pour vaincre le test d'idempotence. La molécule peut contrôler les étapes qu'elle traverse, et la première chose qu'ils ont faite a été de désactiver le contrôle d'idempotence.
Nous avons pris des pannes d'électricité et nous avons battus pour cela, mais les ingénieurs sont intelligents et sont allés plus loin. Les développeurs ont décidé de dire que cette étape dans Ansible ne change rien.
Bien qu'en fait, une sorte d'équipe apparaisse ici. Ansible prendra directement et
va écraser le fichier, mais en même temps, tout semble idempotent.
Lorsque cette astuce a également été détectée, l'image a commencé à ressembler à ceci.
Bon - le script s'exécutait sous le nom par défaut, et il est idempotent.
No. 9. Side_effect
À l'étape suivante, les effets secondaires sont superposés. Cela n'est pas nécessaire, mais c'est pratique lorsque vous testez des rôles de diffusion complexes qui dépendent les uns des autres.
Par exemple, soulevez la pile ELK, puis Elasticsearch dans un cluster. À l'étape side_effect, ajoutez des données de test et supprimez quelques nœuds du cluster. Le site de test est prêt pour les tests fonctionnels qui ont lieu à l'étape suivante.
Numéro 10. Vérifier
Test de l'infrastructure.
Ci-dessus est un exemple de test très simple. Nous vérifions que le package Docker Community Edition est installé si Ubuntu est installé, il a la bonne version et le service est en cours d'exécution.
A ce stade du lancement des tests fonctionnels, tout peut être très compliqué.
Le meilleur exemple serait probablement, dans le cas de la pile ELK, si nous faisons une demande dans une demande Elasticsearch pour certaines données de test, et puisque nous connaissons les données de test, il nous répondra. Nous ne vérifierons pas que tous les composants installés sont assemblés, mais nous verrons qu'Elasticsearch est opérationnel, et donne exactement ce dont vous avez besoin lors de la recherche.
Lorsque les tests fonctionnels s'exécutent, cela semble beau, monte et descend tout au long de l'inventaire, et le système nous dit que tout va bien pour nous. Encore une fois, les tests s'exécuteront si nous les écrivons.
No. 11. Détruisez
Nous avons effectué des tests, il y a un rapport de test sous une forme quelconque, et maintenant nous enlevons toutes les ordures derrière nous.
Automatisation
La molécule est un excellent outil. Maintenant, la chose la plus simple reste - de lui connecter un système d'intégration continue afin de profiter du test automatique de nos rôles, ce que nous avons fait.
Comme ailleurs, il existe plusieurs fonctionnalités.
Certains des rôles que nous écrivons pour automatiser quelque chose sont bons, mais nous ne pouvons pas tester le système à l'aide de Travis, car les rôles déploient des produits que nous ne pouvons pas partager pour des raisons de licence.
Par exemple, vous disposez d'un déploiement automatisé d'une base de données Oracle. Si vous mettez la base de l'installateur dans un dossier, les avocats de l'entreprise viendront à vous et jureront grandement. Pour que tout le monde vive en paix et ne jure pas, nous avons décidé de faire ce qui suit.
- GitLab, dans l'une de ses dernières versions, a appris à faire du CI pour les référentiels tiers.
- Le rôle réside dans le GitHub public, le même GitLab.com public y est connecté, dans lequel nous avons indiqué: «Cher GitLab, récupère-nous le CI pour le référentiel externe».
- Les coureurs privés sont boulonnés à GitLab, dans un périmètre fermé, et ils ont déjà accès au binaire, qu'ils peuvent déployer.
En fait, le rôle est public, les données aussi, et nous ne trompons personne - nous exécutons de vrais tests avec de vrais outils.
Jetons un coup d'œil aux étapes de ce à quoi il ressemble à Travis.
Travis
Les étapes:
- À la première étape, la 8e ligne, nous disons à Travis que nous ne voulons pas seulement le lancer, mais aussi utiliser le service Docker pour que Docker soit disponible à l'intérieur de Travis.
- Ensuite, la 10ème ligne, nous prenons nos règles de charpie. Nous utilisons non seulement les règles par défaut des peluches Ansible, mais nous écrivons également les nôtres.
- Sur la ligne 15, nous appelons d'abord lint pour gagner du temps lors de l'exécution de la matrice de test. Si quelque chose n'est pas écrit selon les règles et que les peluches ne le trouvent pas, il revient au début et laisse un rapport. Un développeur qui valide, répare sa validation ou annule les modifications. Une fois réparé, laissez-le venir, et nous continuerons le test.
CI public
CI public semble élémentaire.
De GitHub, une flèche à Travis, à l'intérieur de laquelle vivent Molecule et Docker.
CI privé
Pour la partie privée de GitLab, tout est pareil.
Dans le périmètre privé, nous courons un coureur, et l'image semble plus amusante.
Le code passe de GitHub à GitLab, quelque part où un runner privé s'exécute, qui peut extraire des services externes, par exemple, exécuter quelque chose sur Amazon.
Une petite digression. Le démarrage et le déploiement d'un environnement de test sur Amazon ne veulent pas être portés, car vous avez besoin de clés. Trouver des mécanismes pour les rendre publics, mais en même temps ne pas devenir la prochaine plate-forme de démarrage pour l'exploitation minière - c'est une tâche non triviale. Par conséquent, nous ne l'avons pas résolu, mais avons pris le coureur en privé afin de ne pas exploiter les bitcoins Amazon.
Même ici, nous étions un peu paresseux et avons fait ce qui suit. Chez EPAM, nous avons notre propre cloud privé et il est hybride. Cela signifie que de nombreux clouds publics sont accessibles depuis le cloud interne, comme les régions. Vous ne pouvez pas écrire mille tests, mais jouer avec les régions et dire: «Maintenant, testez selon ce scénario de test pour AWS, EPAM Cloud, région Azure».
Galaxie Ansible
Nous sommes arrivés à la finale, notre rôle est vert, beau, nous le publierons dans Galaxy.
C'est une opération simple:
- L'appel de webhook qui se trouve à Travis.
- Dans ce cas, Travis se déclenchera, CI s'exécutera à nouveau.
- Appelez le webhook.
- La nouvelle version se développera avec succès dans Galaxy.
Il y a une fonctionnalité - si vous ne marquez pas un rôle, ne marquez pas, ne lui attribuez pas de version, alors dans Galaxy, il sera toujours sans version. Dès qu'un autre développeur souhaite l'installer lui-même via l'installation Ansible Galaxy, il supprime le rôle qui se trouve dans la branche principale, ou dans une autre branche par défaut. Par défaut, la branche n'est pas toujours stable, ce qui n'est pas pratique.
Si vous publiez quelque chose sur Galaxy, n'oubliez pas de le taguer, juste pour qu'il y ait des versions, et tout était cool.
Patterns
Je partage une petite astuce: afin de ne pas copier-coller à chaque fois lors de l'écriture d'un nouveau rôle, nous avons décidé de créer des modèles et un référentiel séparé dans lequel nous plaçons le modèle afin d'écrire rapidement des rôles à partir de zéro.
Le modèle a des paramètres par défaut pour Ansible lint et GitHub issue_template. Tout est dans le domaine public, donc issue_template dans une belle forme était aussi beau pour nous d'émettre des demandes de pull ou des rapports de bugs. Nous ajoutons des modèles pour Gitignore, Gitlab-ci et une licence au même référentiel.
Par défaut, nous publions sous la licence Apache 2.0. Si vous souhaitez venir chez nous et réutiliser les modèles, vous pouvez tout emporter, créer un référentiel fermé et ne rien expliquer à personne. Merci Apache.
Nous avons plusieurs options de test pour que vous puissiez rapidement démarrer et tout démarrer.
Résumé
Il n'y aura aucune conclusion, mais des liens vers
mon GitHub , mon
profil Galaxy ,
GitHub Lean Delivery et
Ansible Galaxy . En utilisant les liens, vous pouvez voir comment tout fonctionne. Tous les exemples sont disponibles gratuitement.
La prochaine conférence DevOps se tiendra en mai.
En attendant l'événement, abonnez-vous à la chaîne YouTube et à la newsletter . La chaîne sera réapprovisionnée avec les enregistrements des meilleurs rapports, et dans la liste de diffusion, il y aura des sélections de documents utiles, des transcriptions et des nouvelles DevOps.
Abonnez-vous, ce sera intéressant :)