Der Ansatz IaC (Infrastructure as Code) besteht nicht nur aus dem Code, der im Repository gespeichert ist, sondern auch aus den Personen und Prozessen, die diesen Code umgeben. Ist es möglich, Ansätze von der Softwareentwicklung bis zur Infrastrukturverwaltung und -beschreibung wiederzuverwenden? Es wäre eine gute Idee, diesen Gedanken im Hinterkopf zu behalten, während Sie den Artikel lesen.

Dies ist eine Abschrift von mir Aufführungen auf DevopsConf 2019.

Folien und Videos

Infrastruktur als Bash-Geschichte

Angenommen, Sie kommen zu einem neuen Projekt und man sagt Ihnen: „Das haben wir Infrastruktur als Code". In Wirklichkeit stellt sich heraus Infrastruktur als Bash-Geschichte oder zum Beispiel Dokumentation als Bash-Historie. Dies ist eine sehr reale Situation. Ein ähnlicher Fall wurde beispielsweise von Denis Lysenko in einer Rede beschrieben So ersetzen Sie die gesamte Infrastruktur und beginnen ruhig zu schlafen, erzählte er, wie sie aus der Bash-Geschichte eine kohärente Infrastruktur für das Projekt bekamen.

Mit einigem Wunsch können wir das sagen Infrastruktur als Bash-Geschichte das ist wie Code:

Reproduzierbarkeit: Sie können den Bash-Verlauf übernehmen, die Befehle von dort ausführen und erhalten möglicherweise nebenbei eine funktionierende Konfiguration als Ausgabe.
Versionierung: Sie wissen, wer reingekommen ist und was sie getan haben. Auch hier ist es keine Tatsache, dass Sie dadurch am Ausgang zu einer funktionierenden Konfiguration gelangen.
Geschichte: die Geschichte, wer was getan hat. Nur können Sie es nicht verwenden, wenn Sie den Server verlieren.

Was ist zu tun?

Infrastruktur als Code

Sogar ein so seltsamer Fall wie Infrastruktur als Bash-Geschichte man kann es an den Ohren ziehen Infrastruktur als Code, aber wenn wir etwas Komplizierteres als den guten alten LAMP-Server machen wollen, werden wir zu dem Schluss kommen, dass dieser Code irgendwie modifiziert, geändert, verbessert werden muss. Als nächstes möchten wir die Parallelen zwischen betrachten Infrastruktur als Code und Softwareentwicklung.

TROCKEN

Bei einem Speichersystem-Entwicklungsprojekt gab es eine Teilaufgabe SDS regelmäßig konfigurieren: Wir veröffentlichen eine neue Version – sie muss für weitere Tests eingeführt werden. Die Aufgabe ist denkbar einfach:

Melden Sie sich hier per SSH an und führen Sie den Befehl aus.
Kopieren Sie die Datei dorthin.
Korrigieren Sie die Konfiguration hier.
Starten Sie dort den Dienst
...
Gewinn!

Für die beschriebene Logik ist Bash mehr als ausreichend, insbesondere in den frühen Phasen des Projekts, wenn es gerade erst beginnt. Das Es ist nicht schlecht, dass Sie Bash verwenden, aber im Laufe der Zeit gibt es Anfragen, etwas Ähnliches, aber etwas anderes, bereitzustellen. Das erste, was mir in den Sinn kommt, ist Kopieren und Einfügen. Und jetzt haben wir bereits zwei sehr ähnliche Skripte, die fast dasselbe tun. Im Laufe der Zeit wuchs die Anzahl der Skripte und wir wurden mit der Tatsache konfrontiert, dass es eine bestimmte Geschäftslogik für die Bereitstellung einer Installation gibt, die zwischen verschiedenen Skripten synchronisiert werden muss. Das ist ziemlich kompliziert.

Es stellt sich heraus, dass es eine Praxis wie DRY (Do not Repeat Yourself) gibt. Die Idee besteht darin, vorhandenen Code wiederzuverwenden. Es klingt einfach, aber wir sind nicht sofort darauf gekommen. In unserem Fall war es eine banale Idee: Konfigurationen von Skripten zu trennen. Diese. Geschäftslogik, wie die Installation separat bereitgestellt wird, Konfigurationen separat.

SOLID für CFM

Mit der Zeit wuchs das Projekt und natürliche Fortsetzung war die Entstehung von Ansible. Der Hauptgrund für sein Erscheinen ist, dass das Team über Fachwissen verfügt und dass Bash nicht für komplexe Logik ausgelegt ist. Ansible begann auch, komplexe Logik zu enthalten. Um zu verhindern, dass komplexe Logik zum Chaos wird, gibt es Prinzipien für die Organisation von Code in der Softwareentwicklung SOLIDE Auch Grigory Petrov stellte beispielsweise in dem Bericht „Warum braucht ein IT-Spezialist eine persönliche Marke“ die Frage, dass eine Person so gestaltet ist, dass es für sie einfacher ist, mit einigen sozialen Einheiten zusammenzuarbeiten, in der Softwareentwicklung mit diesen sind Objekte. Wenn wir diese beiden Ideen kombinieren und weiterentwickeln, werden wir feststellen, dass wir sie auch nutzen können SOLIDE um es einfacher zu machen, diese Logik in Zukunft beizubehalten und zu ändern.

Das Prinzip der Einzelverantwortung

Jede Klasse führt nur eine Aufgabe aus.

Es ist nicht nötig, Code zu vermischen und monolithische, göttliche Spaghetti-Monster zu erschaffen. Die Infrastruktur sollte aus einfachen Bausteinen bestehen. Es stellt sich heraus, dass, wenn Sie das Ansible-Playbook in kleine Teile aufteilen und Ansible-Rollen lesen, diese einfacher zu pflegen sind.

Das Offen-Geschlossen-Prinzip

Offen/geschlossen-Prinzip.

Offen für Erweiterung: bedeutet, dass das Verhalten einer Entität durch die Erstellung neuer Entitätstypen erweitert werden kann.
Änderungen vorbehalten: Aufgrund der Erweiterung des Verhaltens einer Entität sollten keine Änderungen am Code vorgenommen werden, der diese Entitäten verwendet.

Zunächst stellten wir die Testinfrastruktur auf virtuellen Maschinen bereit, aber aufgrund der Tatsache, dass die Geschäftslogik der Bereitstellung von der Implementierung getrennt war, fügten wir problemlos die Einführung auf Baremetall hinzu.

Das Liskov-Substitutionsprinzip

Das Substitutionsprinzip von Barbara Liskov. Objekte in einem Programm müssen durch Instanzen ihrer Untertypen ersetzbar sein, ohne die korrekte Ausführung des Programms zu verändern

Wenn man es allgemeiner betrachtet, handelt es sich nicht um ein Merkmal eines bestimmten Projekts, das dort angewendet werden kann SOLIDEDabei handelt es sich im Allgemeinen um CFM. Bei einem anderen Projekt ist es beispielsweise erforderlich, eine Box-Java-Anwendung auf verschiedenen Java-, Anwendungsservern, Datenbanken, Betriebssystemen usw. bereitzustellen. Anhand dieses Beispiels werde ich weitere Prinzipien betrachten SOLIDE

In unserem Fall besteht innerhalb des Infrastrukturteams eine Vereinbarung darüber, dass wir über eine ausführbare Java-Binärdatei verfügen, wenn wir die Rolle „imbjava“ oder „oraclejava“ installiert haben. Dies ist notwendig, weil Upstream-Rollen sind von diesem Verhalten abhängig; sie erwarten Java. Gleichzeitig können wir dadurch eine Java-Implementierung/-Version durch eine andere ersetzen, ohne die Anwendungsbereitstellungslogik zu ändern.

Das Problem hierbei liegt darin, dass dies in Ansible nicht umsetzbar ist, wodurch es zu einigen Absprachen im Team kommt.

Das Prinzip der Schnittstellentrennung

Prinzip der Schnittstellentrennung: „Viele kundenspezifische Schnittstellen sind besser als eine Allzweckschnittstelle.“

Anfangs haben wir versucht, die gesamte Variabilität der Anwendungsbereitstellung in einem Ansible-Playbook zusammenzufassen, aber es war schwierig zu unterstützen, und der Ansatz, wenn wir eine externe Schnittstelle spezifiziert haben (der Client erwartet Port 443), dann kann eine Infrastruktur aus einzelnen zusammengestellt werden Bausteine für eine bestimmte Implementierung.

Das Abhängigkeitsinversionsprinzip

Das Prinzip der Abhängigkeitsumkehr. Module auf höheren Ebenen sollten nicht von Modulen auf niedrigeren Ebenen abhängen. Beide Arten von Modulen müssen von Abstraktionen abhängen. Abstraktionen sollten nicht von Details abhängen. Details müssen von Abstraktionen abhängen.

Hier basiert das Beispiel auf einem Antimuster.

Einer der Kunden hatte eine private Cloud.
Wir haben virtuelle Maschinen in der Cloud bestellt.
Aufgrund der Beschaffenheit der Cloud war die Anwendungsbereitstellung jedoch davon abhängig, auf welchem Hypervisor sich die VM befand.

Diese. Die Anwendungsbereitstellungslogik auf hoher Ebene floss mit Abhängigkeiten zu niedrigeren Ebenen des Hypervisors, was zu Problemen bei der Wiederverwendung dieser Logik führte. Nicht so.

Interaktion

Bei Infrastructure as Code geht es nicht nur um Code, sondern auch um die Beziehung zwischen Code und Menschen, um Interaktionen zwischen Infrastrukturentwicklern.

Busfaktor

Nehmen wir an, dass Vasya an Ihrem Projekt beteiligt ist. Vasya weiß alles über Ihre Infrastruktur. Was passiert, wenn Vasya plötzlich verschwindet? Das ist eine sehr reale Situation, denn er könnte von einem Bus angefahren werden. Manchmal passiert es. Wenn dies passiert und das Wissen über den Code, seinen Aufbau, seine Funktionsweise, sein Erscheinungsbild und seine Passwörter nicht im Team verteilt ist, kann es zu unangenehmen Situationen kommen. Um diese Risiken zu minimieren und Wissen im Team zu verteilen, können Sie verschiedene Ansätze nutzen

Paarentwicklung

Es ist nicht wie als Witz, dass die Administratoren Bier tranken, Passwörter änderten und ein Analogon der Paarprogrammierung verwendeten. Diese. Zwei Ingenieure setzen sich an einen Computer, eine Tastatur und beginnen gemeinsam mit der Einrichtung Ihrer Infrastruktur: Einrichten eines Servers, Schreiben einer Ansible-Rolle usw. Klingt nett, hat aber bei uns nicht funktioniert. Aber Sonderfälle dieser Praxis funktionierten. Ein neuer Mitarbeiter ist angekommen, sein Mentor übernimmt gemeinsam mit ihm eine echte Aufgabe, arbeitet und vermittelt Wissen.

Ein weiterer Sonderfall ist ein Störfallanruf. Während eines Problems versammelt sich eine Gruppe von Verantwortlichen und Beteiligten, es wird ein Leiter ernannt, der seinen Bildschirm teilt und den Gedankengang äußert. Andere Teilnehmer folgen den Gedanken des Leiters, spionieren Tricks von der Konsole aus, überprüfen, ob sie keine Zeile im Protokoll übersehen haben, und erfahren Neues über das System. Dieser Ansatz hat in den meisten Fällen funktioniert.

Code-Überprüfung

Subjektiv war es effektiver, Wissen über die Infrastruktur und deren Funktionsweise mittels Code-Review zu verbreiten:

Die Infrastruktur wird durch Code im Repository beschrieben.
Änderungen erfolgen in einem separaten Zweig.
Während einer Zusammenführungsanforderung können Sie das Delta der Änderungen in der Infrastruktur sehen.

Der Clou dabei war, dass die Gutachter einzeln nach einem Zeitplan ausgewählt wurden, d. h. Mit einiger Wahrscheinlichkeit werden Sie in ein neues Stück Infrastruktur aufsteigen.

Codestil

Im Laufe der Zeit kam es bei Rezensionen zu Streitereien, weil... Die Rezensenten hatten ihren eigenen Stil und die Rotation der Rezensenten stapelte sie mit unterschiedlichen Stilen: 2 Leerzeichen oder 4, CamelCase oder Snake_Case. Dies konnte nicht sofort umgesetzt werden.

Die erste Idee war, die Verwendung von Linter zu empfehlen, denn schließlich ist jeder Ingenieur und jeder ist schlau. Aber verschiedene Editoren und Betriebssysteme sind nicht praktisch
Daraus entwickelte sich ein Bot, der bei jedem problematischen Commit in Slack schrieb und die Linter-Ausgabe anhängte. Aber in den meisten Fällen gab es Wichtigeres zu tun und der Code blieb unfixiert.

Green Build Master

Die Zeit vergeht und wir sind zu dem Schluss gekommen, dass Commits, die bestimmte Tests nicht bestehen, nicht in den Master aufgenommen werden können. Voila! Wir haben den Green Build Master erfunden, der schon lange in der Softwareentwicklung praktiziert wird:

Die Entwicklung erfolgt in einem separaten Zweig.
In diesem Thread werden Tests ausgeführt.
Wenn die Tests fehlschlagen, gelangt der Code nicht in den Master.

Diese Entscheidung zu treffen war sehr schmerzhaft, weil... sorgte für viele Kontroversen, aber es hat sich gelohnt, denn... Bei den Rezensionen begannen Fusionsanfragen ohne Stilunterschiede einzugehen, und im Laufe der Zeit begann die Zahl der Problembereiche abzunehmen.

IaC-Tests

Neben der Stilprüfung können Sie auch andere Dinge nutzen, um beispielsweise zu überprüfen, ob Ihre Infrastruktur tatsächlich bereitgestellt werden kann. Oder stellen Sie sicher, dass Änderungen in der Infrastruktur nicht zu Geldverlusten führen. Warum könnte das nötig sein? Die Frage ist komplex und philosophisch, es ist besser, sie mit der Geschichte zu beantworten, dass es irgendwie einen Autoscaler auf Powershell gab, der die Randbedingungen nicht überprüfte => es wurden mehr VMs erstellt als nötig => der Kunde gab mehr Geld aus als geplant. Das ist nicht sehr erfreulich, aber es wäre durchaus möglich, diesen Fehler in einem früheren Stadium zu erkennen.

Man könnte sich fragen, warum man komplexe Infrastrukturen noch komplexer machen sollte? Bei Infrastrukturtests geht es, genau wie bei Code, nicht um Vereinfachung, sondern darum, zu wissen, wie Ihre Infrastruktur funktionieren soll.

IaC-Testpyramide

IaC-Tests: Statische Analyse

Wenn Sie die gesamte Infrastruktur auf einmal bereitstellen und überprüfen, ob sie funktioniert, stellen Sie möglicherweise fest, dass dies viel Zeit in Anspruch nimmt. Daher muss die Basis etwas sein, das schnell funktioniert, es gibt viel davon und es deckt viele primitive Orte ab.

Bash ist schwierig

Schauen wir uns ein triviales Beispiel an. Wählen Sie alle Dateien im aktuellen Verzeichnis aus und kopieren Sie sie an einen anderen Speicherort. Das erste, was mir in den Sinn kommt:

for i in * ; do 
    cp $i /some/path/$i.bak
done

Was passiert, wenn der Dateiname ein Leerzeichen enthält? Nun gut, wir sind schlau, wir wissen, wie man Anführungszeichen verwendet:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

Gut gemacht? Nein! Was ist, wenn im Verzeichnis nichts vorhanden ist, d. h. Globbing wird nicht funktionieren.

find . -type f -exec mv -v {} dst/{}.bak ;

Nun gut gemacht? Nein ... Ich habe vergessen, was im Dateinamen stehen kann n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

Statische Analysewerkzeuge

Das Problem aus dem vorherigen Schritt könnte auftreten, wenn wir die Anführungszeichen vergessen haben. Dafür gibt es in der Natur viele Abhilfemaßnahmen Shellcheck, im Allgemeinen gibt es viele davon, und höchstwahrscheinlich finden Sie unter Ihrer IDE einen Linter für Ihren Stack.

Sprache
Werkzeug

bash
Shellcheck

Ruby
RuboCop

python
Pylint

ansible
Ansible Lint

IaC-Tests: Unit-Tests

Wie wir im vorherigen Beispiel gesehen haben, sind Linters nicht allmächtig und können nicht alle Problembereiche aufzeigen. Darüber hinaus können wir uns analog zum Testen in der Softwareentwicklung an Unit-Tests erinnern. Was mir sofort in den Sinn kommt, ist shunit, junit, rspez, Frage. Aber was tun mit Ansible, Chef, Saltstack und anderen wie ihnen?

Ganz am Anfang haben wir darüber gesprochen SOLIDE und dass unsere Infrastruktur aus kleinen Bausteinen bestehen sollte. Ihre Zeit ist gekommen.

Die Infrastruktur ist in kleine Bausteine unterteilt, beispielsweise Ansible-Rollen.
Es wird eine Art Umgebung bereitgestellt, sei es Docker oder eine VM.
Wir wenden unsere Ansible-Rolle auf diese Testumgebung an.
Wir überprüfen, ob alles wie erwartet funktioniert hat (wir führen Tests durch).
Wir entscheiden, ob es ok ist oder nicht.

IaC-Tests: Unit-Test-Tools

Frage: Was sind CFM-Tests? Sie können das Skript einfach ausführen oder auf vorgefertigte Lösungen zurückgreifen:

CFM
Werkzeug

Ansible
Testinfra

KüchenchefIn
Inspizieren

KüchenchefIn
Serverspez

Salzhaufen
Goss

Beispiel für Testinfra, Überprüfung dieser Benutzer test1, test2 existieren und sind in einer Gruppe sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

Was auszusuchen? Die Frage ist komplex und mehrdeutig. Hier ist ein Beispiel für Änderungen in Projekten auf Github für 2018-2019:

IaC-Test-Frameworks

Es stellt sich die Frage: Wie kann man alles zusammenfügen und starten? Kann nimm es und mach es selbst wenn genügend Ingenieure vorhanden sind. Oder Sie nehmen vorgefertigte Lösungen, von denen es allerdings nicht sehr viele gibt:

CFM
Werkzeug

Ansible
Molekül

KüchenchefIn
Testküche

Terraform
Terratest

Beispiel für Änderungen in Projekten auf Github für 2018-2019:

Molekül vs. Testküche

Zunächst wir Habe es mit testkitchen versucht:

Erstellen Sie parallel eine VM.
Ansible-Rollen anwenden.
Inspektion durchführen.

Bei 25-35 Rollen hat es 40-70 Minuten gedauert, was sehr lang war.

Der nächste Schritt war der Übergang zu jenkins/docker/ansible/molecule. Idiologisch ist alles gleich

Lint-Playbooks.
Ordne die Rollen an.
Container starten
Ansible-Rollen anwenden.
Führen Sie testinfra aus.
Überprüfen Sie die Idempotenz.

Das Linting für 40 Rollen und Tests für ein Dutzend begann etwa 15 Minuten zu dauern.

Was zu wählen ist, hängt von vielen Faktoren ab, wie zum Beispiel dem verwendeten Stack, der Expertise im Team usw. Hier entscheidet jeder selbst, wie er die Unit-Testing-Frage abschließt

IaC-Tests: Integrationstests

Der nächste Schritt in der Infrastrukturtestpyramide werden Integrationstests sein. Sie ähneln Unit-Tests:

Die Infrastruktur ist in kleine Bausteine unterteilt, beispielsweise Ansible-Rollen.
Es wird eine Art Umgebung bereitgestellt, sei es Docker oder eine VM.
Für diese Testumgebung gelten Satz von Ansible-Rollen.
Wir überprüfen, ob alles wie erwartet funktioniert hat (wir führen Tests durch).
Wir entscheiden, ob es ok ist oder nicht.

Grob gesagt überprüfen wir nicht wie bei Unit-Tests die Leistung eines einzelnen Elements des Systems, sondern wie der Server als Ganzes konfiguriert ist.

IaC-Tests: End-to-End-Tests

An der Spitze der Pyramide werden wir von End-to-End-Tests begrüßt. Diese. Wir überprüfen nicht die Leistung eines separaten Servers, eines separaten Skripts oder eines separaten Bausteins unserer Infrastruktur. Wir überprüfen, ob viele Server miteinander verbunden sind und unsere Infrastruktur so funktioniert, wie wir es erwarten. Leider habe ich noch nie fertige Boxlösungen gesehen, wahrscheinlich weil... Die Infrastruktur ist oft einzigartig und es ist schwierig, Vorlagen zu erstellen und einen Rahmen für Tests zu erstellen. Dadurch schafft jeder seine eigenen Lösungen. Es gibt eine Nachfrage, aber keine Antwort. Deshalb erzähle ich Ihnen, was es gibt, um andere zu vernünftigen Gedanken zu bewegen oder mir die Nase darüber zu reiben, dass alles schon lange vor uns erfunden wurde.

Ein Projekt mit einer reichen Geschichte. Es wird in großen Organisationen eingesetzt und wahrscheinlich ist jeder von Ihnen indirekt damit in Berührung gekommen. Die Anwendung unterstützt viele Datenbanken, Integrationen usw. Zu wissen, wie die Infrastruktur aussehen könnte, ist eine Menge Docker-Compose-Dateien, und zu wissen, welche Tests in welcher Umgebung ausgeführt werden sollen, ist Jenkins.

Dieses Schema funktionierte ziemlich lange, bis es in den Rahmen fiel Forschung Wir haben nicht versucht, dies auf Openshift zu übertragen. Die Container bleiben die gleichen, aber die Startumgebung hat sich geändert (hallo nochmal DRY).

Die Forschungsidee ging weiter und in OpenShift fanden sie so etwas wie APB (Ansible Playbook Bundle), mit dem Sie Wissen über die Bereitstellung von Infrastruktur in einen Container packen können. Diese. Es gibt einen wiederholbaren, überprüfbaren Wissensstand darüber, wie die Infrastruktur bereitgestellt werden soll.

Das klang alles gut, bis wir auf eine heterogene Infrastruktur stießen: Wir brauchten Windows für Tests. Daher ist das Wissen darüber, was, wo, wie bereitgestellt und getestet werden soll, in Jenkins enthalten.

Zusammenfassung

Infrastruktur als Code ist

Code im Repository.
Menschliche Interaktion.
Infrastrukturtests.

Links

Source: habr.com

Was ich aus dem Testen von 200 Zeilen Infrastrukturcode gelernt habe