Ansible ist ein System, das verschiedene Automatisierungsaufgaben löst, einschließlich Konfigurations-, Sicherungs- und Bereitstellungsprojekte. Es ist angenehm, das System zum Schreiben von Automatisierungsskripten aus einer einfachen Umgebung in ein großes Projekt zu verwenden. In Skripten spielen Spielbücher eine wichtige Rolle und strukturierte Spielbücher eine Rolle.
Ansible ist keine magische Pille und hilft zunächst nur. Wenn ein Projekt wächst, wird es schwierig, eine erweiterte Anzahl von Rollen beizubehalten. Der kontinuierliche Übermittlungsmechanismus für Rollen hilft, das Problem zu lösen.
Genau dazu die Entschlüsselung des Berichts von
Alexander Kharkevich bei
DevOps Conf Russia . Im Bericht: Entwicklung von Ansible-Rollen durch CI, ein Mechanismus zur Entwicklung öffentlicher Rollen und öffentlicher Rollen mit Testläufen in einer privaten Infrastruktur. Und der Bericht enthält keine Schlussfolgerung.
Über den Sprecher : Alexander Kharkevich (
kharkevich ), leitender
Systemingenieur bei
EPAM Systems .
Beginnen wir mit einem kurzen Überblick.
Über Ansible
Ansible ist ein Konfigurationsmanagementsystem. Es ist in Python geschrieben, von Junja als Vorlage, und YAML wird als DSL verwendet. Verwaltet über Ansible Tower - WebUI zur Verwaltung und Überwachung der Systemleistung.
Ansible erschien 2012, nachdem Red Hat 3 Jahre lang das gesamte Projekt gekauft hatte, und zwei Jahre später führte AWX - Project Open Source Version von Ansible Tower ein.
Installation
Um Ansible verwenden zu können, müssen Sie zwei einfache Dinge tun.
Kompilieren Sie in der ersten Phase eine Inventardatei für den Fall einer statischen Infrastruktur.
Die zweite besteht darin, ein Playbook zu schreiben, das das System in den erwarteten Zustand versetzt.
Oft haben wir den unwiderstehlichen Wunsch, Automatisierung zu schreiben, die wieder verwendet werden kann. Automatisierung ist ein guter Wunsch, und die Jungs von Ansible haben sich ein cooles Konzept ausgedacht - die Rolle.
Rolle
Dies ist eine strukturierte Einheit, die das System in den erwarteten Zustand versetzt und die Automatisierung wiederverwenden kann.
Zum Beispiel können wir eine Rolle für Oracle Java schreiben: Nehmen Sie ein Playbook, legen Sie eine Rolle ab und wenden Sie sie auf das Zielsystem an. Die Ausgabe wird Java installiert.
Wie wir uns vorgestellt haben, mit Rollen zu arbeiten
Da Ansible so wunderbare Rollen hat, dachten wir, wir würden jetzt viele, viele Rollen für alle Gelegenheiten übernehmen und schreiben, herumalbern und wiederverwenden, um den Arbeitsaufwand zu reduzieren.
Wir dachten, wir würden schöne und kluge Rollen schreiben ...
Das Leben erwies sich jedoch als komplizierter.
Wie sich herausstellte, eigentlich
Wenn mehr als eine Person daran arbeitet, eine Rolle zu schreiben oder zu verbessern, schreibt jeder an einem Ort und es entstehen unangenehme Überraschungen: Die Rolle verhält sich anders als ursprünglich vom Autor beabsichtigt.
Es ist gut, wenn es bis zum Ende angewendet wird, aber das passiert nicht immer. Manchmal wird eine Rolle erfolgreich ausgeführt, aber auf dem Zielsystem wirkt sich dies überhaupt nicht wie ursprünglich gewünscht aus.
Infolgedessen entstehen schreckliche Konstruktionen, Versuche, Bash an Ansible zu übertragen und all dies unter der Konfigurationsverwaltungssauce einzureichen. Wir sind auf dieses Phänomen gestoßen und waren traurig.
Wir haben festgestellt, dass es in unserem Konfigurationsmanagement eine Art Code gibt, was bedeutet, dass die Praktiken, die für das Code-Management im Systementwicklungs-Lebenszyklus gelten, auch in Ansible anwendbar sind.
- Sammeln Sie Best Practices.
- Statische Analyse anwenden, Flusen.
- Zum Testen.
- Übertakten, um in das Release-Management zu gelangen.
Wir beschlossen, die Praxis zu Hause umzusetzen und suchten sofort nach geeigneten Werkzeugen.
Die Werkzeuge
Unter dem Gesichtspunkt der Versionskontrollsysteme und der kontinuierlichen Integration stehen Dutzende von Lösungen und ein verzweigter Testzoo zur Verfügung.
Aus Sicht des Release-Managements in Ansible gibt es nicht so viele Lösungen: in Git taggen oder in Git taggen und auf Galaxy hochladen.
Es gibt viele Ansätze zum Testen von Tools, die jeweils das verwenden, was ihnen gefällt. Beliebte Lösungen mit KitchenCI, InSpec, Serverspec.
Unsere Seele hat nicht gelogen, Ansible in Python geschrieben zu nehmen und Werkzeuge aus der Ruby-Welt zu mischen. Nachdem wir also alles weggeworfen haben, was nicht in der Python-Welt heimisch ist, haben wir das folgende Bild erhalten.
Wir verwenden:
- Für das Konfigurationsmanagement - GitHub und GitLab. GitLab schaut direkt auf GitHub. Warum das so ist, werde ich später erzählen.
- Für CI haben wir Travis für den öffentlichen Teil und GitLab Runner für den privaten Teil genommen.
- Molekül testen.
- Starten Sie GitHub und fügen Sie es zu Ansible Galaxy hinzu.
Unser Entwicklungszyklus mit diesen Tools hat mehr Spaß gemacht.
Molekül
Mit diesem Tool können Sie die Ansible-Rolle vollständig testen. Dazu hat er alles:
- Integration mit YAML Lint und Ansible Lint, um die Rollen auf Übereinstimmung mit unseren Anforderungen zu überprüfen.
- Testinfrastruktur zum Ausführen von Funktionstests.
- In Molecule-Treibern setzt Molecule unseren Prüfstand ein. Alles wird unterstützt: Azure, Delegiert, Docker, EC2, GCE, LXC, LXD, Openstack, Vagrant.
- Es gibt noch eine nützliche und einfache Sache - die Delegation. Dies bedeutet, dass Molecule nicht für die Bereitstellung des Prüfstands verantwortlich ist und der Entwickler ein Playbook schreiben muss, um den Prüfstand anzuheben. Wenn Sie über eine superprivate Cloud verfügen, delegieren Sie die Erstellung und Entfernung von Testmaschinen, und Molecule selbst fügt alles hinzu.
Testmatrix
Betrachten Sie die Testmatrix in Schritten. Insgesamt gibt es 11 Schritte, aber ich werde mich kurz fassen.
Nr. 1. Fussel
Sie lassen YAML-Flusen und Ansible-Flusen laufen und finden etwas.
Im obigen Beispiel schwört Lint, dass die Shell nicht nur in Ansible aufgerufen, sondern fixiert und an etwas gebunden werden sollte.
Nr. 2. Zerstören
Das Molekül entfernt alles, was nach früheren Tests übrig bleibt.
Es gibt Zeiten, in denen ein Lauf vergangen ist, sich ein Trainingsgelände entfaltet hat und die Tests abgeschlossen sind. Der Ständer sollte am Ende gereinigt werden, aber höhere Gewalt griff ein und es gab keine Reinigung. In solchen Situationen läuft Molecule weg, zerstört und reinigt die Umgebung von Rückständen.
Nr. 3. Abhängigkeit
Wir nehmen die Datei require.yml und fügen die Abhängigkeiten unserer Rolle von anderen Rollen hinzu. Ein Hinweis auf die Tatsache, dass die Rolle ohne Java, das auf dem System installiert ist, nicht gestartet werden kann:
--- - src: lean_delivery.java version: 1.4
Molecule versteht dies und führt das Skript aus:
- Geht Galaxy oder Git
- Wird erkennen, dass es notwendig ist, Abhängigkeiten zu lösen;
- Geht wieder zu Galaxy;
- Downloads;
- wird erweitert.
Nr. 4. Syntax
Der nächste Schritt ist die Syntaxprüfung. aber nicht deine Rolle, sondern das Test-Playbook, das du zu Molecule hinzufügst. Auch in diesem Schritt treten Syntaxfehler auf.
Die Folie zeigt, dass die Ansible-Rolle "Kibana" heißt, und im Test-Playbook heißt sie "Ansible-Rolle-Kibana". Das System sagt: "Alles wäre in Ordnung und Sie können es hier erstellen, aber ich werde es nicht tun, weil die Namen nicht übereinstimmen!"
Nr. 5. Erstellen
In dieser Phase geben wir den Treiber an, mit dem die Testwebsite bereitgestellt wird. Punkt Google - es werden Testmaschinen in Google Cloud ausgelöst.
Wir können in die Datei molecular.yml schreiben, was wir wollen. Mal sehen, wie es an einem Beispiel für Docker aussieht.
- Ich spezifiziere Docker-Bilder zum Aufrufen.
- Ich gebe an, wie sie gruppiert werden sollen, damit eine Inventardatei erstellt wird.
Ich möchte zwei Docker-Images haben: eines für RHEL-like, das zweite für Debian-like, um sicherzugehen, dass während des Testlaufs sowohl mit RHEL als auch mit Debian alles in Ordnung ist.
Nr. 6. Vorbereiten
Dies ist ein vorbereitender Vorbereitungsschritt für die Testausführungsumgebung.
Es scheint, dass alles gestiegen ist, aber manchmal müssen Sie einige zusätzliche Einstellungen vornehmen. Beim Testen in einem erhöhten Docker in Debian oder Ubuntu müssen Sie einen zweiten Python installieren, was häufig vorkommt.
Nr. 7. Konvergieren
Die Phase des ersten großen Durchlaufs der Rolle innerhalb der Instanz, um sicherzustellen, dass sie das Ende erreicht, wird ausgeführt, und Ansible bestätigt, dass alles in Ordnung ist.
- Molekül bezieht sich auf Ansible.
- Ansible auf einer Test-Site bereitgestellt.
- Es läuft.
- Alles ist gut!
Nr. 8. Idempotenz
Der Idempotenztest ist einfach und sieht so aus.
- Das erste Mal, wenn die Rolle den vorherigen Schritt durchläuft.
- Ansible meldet, wie viele Änderungen vorgenommen wurden.
- Startet dieselbe Rolle neu.
- Überprüft, ob das System in den erwarteten Zustand versetzt wurde, aber bei der zweiten Vermietung gibt es keine Änderungen.
Infolgedessen verstehen wir, dass unsere Rolle nicht destruktiv wirkt.
Diese Phase verursachte den Jungs, mit denen ich arbeite, Schmerzen. Sie versuchten, das Problem zu umgehen, um den Idempotenztest zu bestehen. Das Molekül kann die Phasen steuern, die es durchläuft, und als erstes haben sie die Idempotenzprüfung ausgeschaltet.
Wir haben Stromausfälle gefangen und uns dafür geschlagen, aber die Ingenieure sind schlau und gingen tiefer. Die Entwickler haben beschlossen zu sagen, dass dieser Schritt in Ansible nichts ändert.
Obwohl tatsächlich eine Art Team hier erscheinen wird. Ansible wird direkt nehmen und
überschreibt die Datei, aber gleichzeitig sieht alles idempotent aus.
Als dieser Trick auch gefangen wurde, sah das Bild so aus.
Gut - das Skript wurde unter dem Standardnamen ausgeführt und ist idempotent.
Nr. 9. Nebeneffekt
In der nächsten Phase werden Nebenwirkungen überlagert. Dies ist nicht erforderlich, aber praktisch, wenn Sie komplexe, voneinander abhängige Verteilungsrollen testen.
Heben Sie beispielsweise den ELK-Stapel und dann Elasticsearch in einem Cluster an. Fügen Sie in der Phase side_effect Testdaten hinzu und entfernen Sie einige Knoten aus dem Cluster. Die Teststelle ist bereit für die Funktionstests, die im nächsten Schritt stattfinden.
Nummer 10. Überprüfen
Testen der Infrastruktur.
Oben ist ein Beispiel für einen sehr einfachen Test. Wir überprüfen, ob das Docker Community Edition-Paket installiert ist, wenn Ubuntu installiert ist, die richtige Version hat und der Dienst ausgeführt wird.
In dieser Phase des Starts von Funktionstests kann alles sehr kompliziert sein.
Das wahrscheinlich beste Beispiel wäre im Fall eines ELK-Stapels, wenn wir in einer Elasticsearch-Anfrage eine Anforderung für einige Testdaten stellen, und da wir die Testdaten kennen, wird sie uns antworten. Wir werden nicht überprüfen, ob alle installierten Komponenten zusammengebaut sind, aber wir werden feststellen, dass Elasticsearch aktiv ist und genau das bietet, was Sie für die Suche benötigen.
Wenn Funktionstests ausgeführt werden, scheint es schön zu sein, läuft im gesamten Inventar auf und ab und das System informiert uns, dass bei uns alles in Ordnung ist. Wieder werden die Tests ausgeführt, wenn wir sie schreiben.
Nr. 11. Zerstören
Wir haben Tests durchgeführt, es gibt einen Testbericht in irgendeiner Form, und jetzt entfernen wir den gesamten Müll hinter uns.
Automatisierung
Molekül ist ein großartiges Werkzeug. Jetzt bleibt das Einfachste - ein kontinuierliches Integrationssystem daran anzuschließen, um das automatische Testen unserer Rollen zu genießen, was wir getan haben.
Wie überall gibt es mehrere Funktionen.
Einige der Rollen, die wir schreiben, um etwas zu automatisieren, sind gut, aber wir können das System nicht mit Travis testen, da die Rollen Produkte bereitstellen, die wir aus Lizenzgründen nicht gemeinsam nutzen können.
Sie haben beispielsweise eine automatisierte Bereitstellung einer Oracle-Datenbank. Wenn Sie die Installationsbasis in eine Datei einfügen, kommen die Anwälte des Unternehmens zu Ihnen und schwören sehr. Damit alle in Frieden leben und nicht schwören, haben wir uns entschlossen, Folgendes zu tun.
- GitLab hat in einer seiner neuesten Versionen gelernt, wie CI für Repositorys von Drittanbietern ausgeführt wird.
- Die Rolle liegt im öffentlichen GitHub, mit dem auch öffentliches GitLab.com verbunden ist, in dem wir angegeben haben: "Lieber GitLab, sammeln Sie uns das CI für das externe Repository".
- Private Läufer sind in einem geschlossenen Umkreis mit GitLab verschraubt und haben bereits Zugriff auf Binärdateien, die sie bereitstellen können.
Tatsächlich liegt die Rolle öffentlich, die Daten auch, und wir täuschen niemanden - wir führen echte Tests mit echten Werkzeugen durch.
Werfen wir einen Blick auf die Schritte, wie es in Travis aussieht.
Travis
Die Schritte:
- Im ersten Schritt, der 8. Zeile, teilen wir Travis mit, dass wir ihn nicht nur starten, sondern auch den Docker-Dienst verwenden möchten, damit Docker in Travis verfügbar ist.
- Als nächstes, in der 10. Zeile, nehmen wir unsere Flusenregeln. Wir verwenden nicht nur die Standardregeln für Ansible-Flusen, sondern schreiben auch unsere eigenen.
- In Zeile 15 rufen wir zuerst lint auf, um Zeit beim Ausführen der Testmatrix zu sparen. Wenn etwas nicht gemäß den Regeln geschrieben ist und Lint es nicht findet, geht es zum Anfang und hinterlässt einen Bericht. Ein Entwickler, der Festschreibungen festschreibt, repariert oder Änderungen verwirft. Wenn es repariert ist, lassen Sie es kommen, und wir werden den Test fortsetzen.
Öffentliches CI
Öffentliches CI sieht elementar aus.
Von GitHub ein Pfeil zu Travis, in dem Molecule und Docker leben.
Privates CI
Für den privaten Teil von GitLab ist alles gleich.
Im privaten Bereich führen wir einen Läufer aus, und das Bild sieht lustiger aus.
Der Code gelangt von GitHub zu GitLab, wo ein privater Runner ausgeführt wird, der externe Dienste abrufen kann, z. B. etwas bei Amazon.
Ein kleiner Exkurs. Das Starten und Bereitstellen einer Testumgebung bei Amazon möchte nicht portiert werden, da Sie Schlüssel benötigen. Mechanismen zu entwickeln, um sie der Öffentlichkeit zugänglich zu machen, aber gleichzeitig nicht die nächste Startup-Plattform für den Bergbau zu werden - das ist keine triviale Aufgabe. Daher haben wir es nicht gelöst, sondern Läufer privat genommen, um Amazon-Bitcoins nicht abzubauen.
Auch hier waren wir etwas faul und haben folgendes gemacht. Wir bei EPAM haben unsere eigene private Cloud und sie ist hybride. Dies bedeutet, dass viele öffentliche Clouds wie Regionen von der inneren Cloud aus zugänglich sind. Sie können nicht tausend Tests schreiben, sondern mit den Regionen herumspielen und sagen: "Testen Sie jetzt gemäß diesem Testszenario für die Region AWS, EPAM Cloud, Azure."
Ansible Galaxie
Wir sind zum Finale gekommen, unsere Rolle ist grün, schön, wir werden sie in Galaxy veröffentlichen.
Dies ist eine einfache Operation:
- Der Webhook-Anruf in Travis.
- In diesem Fall wird Travis ausgelöst und CI wird erneut ausgeführt.
- Rufen Sie den Webhook an.
- Die neue Version wird in Galaxy erfolgreich wachsen.
Es gibt eine Funktion: Wenn Sie eine Rolle nicht markieren, nicht markieren, ihr keine Version zuweisen, ist sie in Galaxy immer ohne Version. Sobald ein anderer Entwickler es selbst über die Installation von Ansible Galaxy installieren möchte, wird er die Rolle entfernen, die im Hauptzweig oder standardmäßig in einem anderen Zweig liegt. Standardmäßig ist die Verzweigung nicht immer stabil, was unpraktisch ist.
Wenn Sie etwas auf Galaxy veröffentlichen, vergessen Sie nicht, es zu markieren, damit es Versionen gibt und alles cool war.
Muster
Ich teile einen kleinen Trick: Um beim Schreiben einer neuen Rolle nicht jedes Mal zu kopieren und einzufügen, haben wir beschlossen, Vorlagen und ein separates Repository zu erstellen, in das wir die Vorlage einfügen, um Rollen schnell von Grund auf neu zu schreiben.
Die Vorlage verfügt über Standardeinstellungen für Ansible Lint und GitHub issue_template. Alles ist gemeinfrei, daher war issue_template in einer schönen Form auch schön für uns, Pull-Request- oder Fehlerberichte zu erstellen. Wir fügen dem gleichen Repository Vorlagen für Gitignore, Gitlab-ci und eine Lizenz hinzu.
Standardmäßig veröffentlichen wir unter der Apache 2.0-Lizenz. Wenn Sie zu uns kommen und die Vorlagen wiederverwenden möchten, können Sie alles wegnehmen, ein geschlossenes Repository erstellen und niemandem etwas erklären. Danke Apache.
Wir haben verschiedene Testoptionen, damit Sie schnell alles starten und starten können.
Zusammenfassung
Es wird keine Schlussfolgerung geben, stattdessen gibt es Links zu
meinem GitHub , meinem
Galaxy-Profil ,
GitHub Lean Delivery und
Ansible Galaxy . Über die Links können Sie sehen, wie alles funktioniert. Alle Beispiele sind frei verfügbar.
Die nächste DevOps-Konferenz findet im Mai statt.
Abonnieren Sie den YouTube-Kanal und den Newsletter, während wir auf die Veranstaltung warten. Der Kanal wird mit Aufzeichnungen der besten Berichte aufgefüllt, und in der Mailingliste finden Sie eine Auswahl nützlicher Materialien, Transkripte und DevOps-Nachrichten.
Abonnieren, es wird interessant sein :)