Ansatz . Das ist verständlich. Denn nur sie ermöglichten die vollständige Konfiguration eines virtuellen Rechenzentrums: Keine physischen Server, keine Racks, keine Netzwerkkomponenten, die gesamte Infrastruktur kann durch Skripte und Konfigurationsdateien beschrieben werden. (Infrastructure as Code) besteht nicht nur aus dem Code, der im Repository gespeichert ist, sondern auch aus den Menschen und Prozessen, die diesen Code umgeben. Kann man Ansätze aus der Softwareentwicklung für das Management und die Beschreibung von Infrastruktur wiederverwenden? Es wäre nicht verkehrt, diese Idee im Hinterkopf zu behalten, während Sie den Artikel lesen.

Das ist die Entschlüsselung meines Vortrags auf DevopsConf 2019-05-28.

Präsentationen und Videos

Englische Version
Russische Version
Trockenlauf 2019-04-24 SpbLUG
Video(RU) von DevopsConf 2019-05-28
Video(RU) von DINS DevOps EVENING 2019-06-20
Folien

Infrastruktur als Bash-Verlauf

Angenommen, Sie kommen zu einem neuen Projekt, und Ihnen wird gesagt: „Bei uns Infrastructure as Code“. In Wirklichkeit stellt sich heraus, Infrastruktur als Bash-Verlauf oder zum Beispiel Dokumentation als Bash-Verlauf. Das ist eine durchaus reale Situation; zum Beispiel hat Denis Lysenko einen ähnlichen Fall in seinem Vortrag Wie man die gesamte Infrastruktur ersetzt und anfängt, ruhig zu schlafen, er erzählte, wie sie aus dem Bash-Verlauf eine strukturierte Infrastruktur im Projekt erhielten.

Mit ein wenig Willen könnte man sagen, dass Infrastruktur als Bash-Verlauf es wie Code ist:

Reproduzierbarkeit: Sie können den Bash-Verlauf nehmen, die Befehle dort ausführen; möglicherweise erhalten Sie übrigens eine funktionierende Konfiguration als Ergebnis.
Versionskontrolle: Sie wissen, wer eingeloggt war und was er gemacht hat; wiederum ist es nicht garantiert, dass dies Sie zu einer funktionierenden Konfiguration als Ergebnis führt.
Historie: Die Geschichte darüber, wer was gemacht hat. Allerdings können Sie sie nicht nutzen, wenn Sie den Server verlieren.

Was ist zu tun?

Infrastructure as Code

Selbst ein so seltsamer Fall wie Infrastruktur als Bash-Verlauf lässt sich an den Haaren herbeiziehen Infrastructure as Code, aber wenn wir etwas Komplexeres als einen guten alten LAMP-Server machen wollen, kommen wir zu dem Punkt, dass dieser Code irgendwie modifiziert, verändert und weiterentwickelt werden muss. Im Folgenden werden wir Parallelen zwischen Infrastructure as Code und der Softwareentwicklung betrachten.

D.R.Y.

In einem Projekt zur Entwicklung von SAN gab es eine Teilaufgabe, regelmäßig SDS zu konfigurieren: Wir veröffentlichen ein neues Release – es muss ausgerollt werden, um weitere Tests durchzuführen. Die Aufgabe ist ganz einfach:

Sie gehen hier per SSH rein und führen den Befehl aus.
Dahin kopieren Sie die Datei.
Hier passen Sie die Konfiguration an.
Dort starten Sie den Dienst.
…
PROFIT!

Für die beschriebene Logik reicht Bash mehr als aus, insbesondere in den frühen Phasen des Projekts, wenn es gerade startet. Es ist nicht schlecht, dass Sie Bash verwenden., aber im Laufe der Zeit entstehen Anfragen, etwas Ähnliches, aber leicht abgewandelt, zu entwickeln. Das Erste, was mir in den Sinn kommt: Copy-Paste. Und so haben wir bereits zwei sehr ähnliche Skripte, die fast dasselbe tun. Im Laufe der Zeit hat sich die Anzahl der Skripte erhöht, und wir sind mit einer gewissen Geschäftslogik für die Bereitstellung von Installationen konfrontiert, die zwischen verschiedenen Skripten synchronisiert werden muss, was ziemlich kompliziert ist.

Es stellt sich heraus, dass es eine Praxis namens D.R.Y. (Do not Repeat Yourself) gibt. Die Idee besteht darin, bestehenden Code wiederzuverwenden. Das klingt einfach, aber wir sind nicht sofort zu dieser Erkenntnis gelangt. In unserem Fall war es eine banale Idee: Konfigurationen von Skripten zu trennen. Das heißt, die Geschäftslogik für die Bereitstellung der Installation separat und die Konfigurationen separat.

S.O.L.I.D. für CFM

Im Laufe der Zeit wuchs das Projekt und eine natürliche Fortsetzung war das Auftreten von Ansible. Der Hauptgrund für sein Auftreten war die vorhandene Expertise im Team und dass Bash nicht für komplexe Logik geeignet ist. Ansible enthält ebenfalls eine komplexe Logik. Damit diese komplexe Logik nicht ins Chaos umschlägt, existieren in der Softwareentwicklung Prinzipien zur Organisation von Code. S.O.L.I.D. Gleichzeitig hat Grigori Petrow in seinem Vortrag „Warum braucht ein IT-Spezialist eine persönliche Marke?“ angesprochen, dass Menschen so gestrickt sind, dass es ihnen leichter fällt, mit sozialen Entitäten zu operieren, in der Softwareentwicklung sind das Objekte. Wenn man diese beiden Ideen zusammenführt und weiterentwickelt, könnte man feststellen, dass auch in der Beschreibung der Infrastruktur S.O.L.I.D. es einfacher wäre, diese Logik in Zukunft zu unterstützen und zu modifizieren.

Das Prinzip der Einzelverantwortung

Jede Klasse führt nur eine Aufgabe aus.

Man sollte den Code nicht mischen und keine monolithischen, göttlichen Nudelmonster schaffen. Die Infrastruktur sollte aus einfachen Bausteinen bestehen. Es stellt sich heraus, dass wenn man ein Ansible-Playbook in kleine Stücke zerlegt, sprich in Ansible-Rollen, sie einfacher zu warten sind.

Das Prinzip der offenen und geschlossenen

Das Prinzip der Offenheit/Schließung.

Offen für Erweiterungen: bedeutet, dass das Verhalten einer Entität erweitert werden kann, indem neue Entitätstypen erstellt werden.
Geschlossen für Änderungen: als Ergebnis der Erweiterung des Verhaltens einer Entität sollten keine Änderungen im Code vorgenommen werden, der diese Entitäten verwendet.

Ursprünglich haben wir die Testinfrastruktur auf virtuellen Maschinen eingerichtet, aber da die Geschäftslogik der Bereitstellung getrennt von der Implementierung war, haben wir problemlos die Bereitstellung auf Bare Metal hinzugefügt.

Das Liskov'sche Substitutionsprinzip

Das Liskov'sche Substitutionsprinzip. Objekte in einem Programm sollten durch Instanzen ihrer Subtypen ersetzt werden können, ohne die Korrektheit des Programms zu beeinträchtigen.

Wenn man breiter schaut, dann ist das keine Besonderheit eines bestimmten Projekts, dass man dort etwas anwenden kann. S.O.L.I.D., es geht insgesamt um CFM, zum Beispiel muss in einem anderen Projekt eine fertige Java-Anwendung über verschiedene Java, Anwendungsserver, Datenbanken, Betriebssysteme usw. bereitgestellt werden. An diesem Beispiel werde ich die weiteren Prinzipien betrachten. S.O.L.I.D.

In unserem Fall gibt es im Rahmen des Infrastruktur-Teams eine Vereinbarung, dass, wenn wir die Rolle imbjava oder oraclejava installiert haben, wir eine ausführbare Binärdatei von Java haben. Dies ist notwendig, da obere Rollen von diesem Verhalten abhängen und sie die Anwesenheit von Java erwarten. Gleichzeitig erlaubt es uns, eine Implementierung/Version von Java durch eine andere zu ersetzen, ohne dabei die Logik der Bereitstellung der Anwendung zu ändern.

Das Problem liegt darin, dass man dies in Ansible nicht umsetzen kann, was zur Folge hat, dass im Team gewisse Vereinbarungen entstehen.

Das Prinzip der Schnittstellentrennung

Das Prinzip der Schnittstellentrennung "Viele Schnittstellen, die speziell für Kunden ausgelegt sind, sind besser als eine allgemeine Schnittstelle.

Ursprünglich haben wir versucht, alle Variationen der Bereitstellung der Anwendung in einem Ansible-Playbook zu bündeln, aber das war schwierig zu warten. Mit dem Ansatz, dass wir eine spezifizierte Schnittstelle nach außen haben (der Kunde erwartet Port 443), können wir die Infrastruktur für eine bestimmte Implementierung aus einzelnen Bausteinen komponieren.

Das Prinzip der Abhängigkeitsumkehr

Das Prinzip der Abhängigkeitsumkehr. Module höherer Ebenen sollten nicht von Modulen niedrigerer Ebenen abhängen. Beide Modularten sollten von Abstraktionen abhängen. Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen.

Hier wird das Beispiel auf einem Antipattern basieren.

Einer der Kunden hatte eine private Cloud.
Innerhalb der Cloud haben wir virtuelle Maschinen bestellt.
Aber aufgrund der Besonderheiten der Cloud war die Bereitstellung der Anwendung daran gebunden, auf welchem Hypervisor die VM gelandet ist.

Das heißt, die hochrangige Logik der Bereitstellung der Anwendung und deren Abhängigkeiten verliefen auf die darunterliegenden Ebenen des Hypervisors, und das bedeutete Probleme bei der Wiederverwendung dieser Logik. Mach das nicht.

Interaktion

Infrastruktur als Code bedeutet nicht nur Code, sondern auch die Beziehungen zwischen Code und Mensch, die Interaktionen zwischen Infrastrukturentwicklern.

Bus-Faktor

Angenommen, Sie haben einen Vasja in Ihrem Projekt. Vasja weiß alles über Ihre Infrastruktur, was passiert, wenn Vasja plötzlich verschwindet? Das ist eine durchaus reale Situation, denn er könnte von einem Bus überfahren werden. Manchmal passiert so etwas. Wenn dies geschieht und das Wissen über den Code, dessen Struktur, wie er funktioniert, und über Anmeldedaten nicht im Team verteilt ist, könnten unangenehme Situationen auftreten. Um diese Risiken zu minimieren und das Wissen innerhalb des Teams zu verteilen, können verschiedene Ansätze verwendet werden.

Pair Devopsing

Das ist nicht wie in einem Witz, dass Administratoren Bier trinken, Passwörter ändern, und das Pendant zum Pair Programming. Das heißt, zwei Ingenieure setzen sich an einen Computer, eine Tastatur, und beginnen gemeinsam Ihre Infrastruktur zu konfigurieren: Server einrichten, Ansible-Rolle schreiben, usw. Klingt schön, aber bei uns hat es nicht funktioniert. Aber es gab einige spezifische Fälle dieser Praxis, die funktionierten. Ein neuer Mitarbeiter kam, sein Mentor nahm mit ihm eine echte Aufgabe in Angriff, arbeitete und vermittelte das Wissen.

Ein anderer spezifischer Fall ist der Incident Call. Während eines Problems versammelt sich eine Gruppe von Bereitschaftsdiensten und Beteiligten, ein Moderator wird bestimmt, der seinen Bildschirm teilt und seinen Gedankengang erklärt. Die anderen Teilnehmer folgen dem Gedanken des Moderators, schauen sich Tricks aus der Konsole an, überprüfen, ob eine Zeile im Protokoll übersehen wurde, und lernen Neues über das System. Dieser Ansatz hat eher funktioniert als nicht.

Code-Review

Subjektiv geschah die effektivere Verbreitung von Wissen über die Infrastruktur und deren Funktionsweise durch Code-Reviews:

Die Infrastruktur ist im Code im Repository beschrieben.
Änderungen erfolgen in einem separaten Branch.
Beim Mergen einer Anfrage kann man die Änderungs-Differenz in der Infrastruktur sehen.

Das Besondere hier war, dass die Prüfer nach einem festen Plan ausgewählt wurden, sodass mit einer gewissen Wahrscheinlichkeit man in einen neuen Bereich der Infrastruktur eintauchen konnte.

Code-Stil

Im Laufe der Zeit traten während des Reviews Konflikte auf, da die Reviewer ihren eigenen Stil hatten und die Rotation der Reviewer sie mit unterschiedlichen Stilen konfrontierte: 2 Leerzeichen oder 4, camelCase oder snake_case. Es dauerte eine Weile, bis wir das umsetzen konnten.

Die erste Idee war, zu empfehlen, einen Linter zu verwenden, schließlich sind es alles Ingenieure, alle klug. Aber verschiedene Editoren und Betriebssysteme machen das unpraktisch.
Das entwickelte sich zu einem Bot, der bei jedem problematischen Commit in Slack schrieb und die Ausgabe des Linters beifügte. Aber in den meisten Fällen gab es wichtigere Dinge zu erledigen, und der Code blieb unberührt.

Green Build Master

Die Zeit vergeht, und wir kamen zu der Erkenntnis, dass man keine Commits in den Master zulassen kann, die bestimmte Tests nicht bestehen. Voilà! Wir haben den Green Build Master erfunden, der in der Softwareentwicklung bereits lange praktiziert wird:

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

Die Annahme dieser Entscheidung war ziemlich schmerzhaft, da sie viele Diskussionen auslöste, aber es hat sich gelohnt, denn beim Review kamen die Merge-Anfragen ohne Stilkonflikte, und im Laufe der Zeit verringerte sich die Anzahl der problematischen Stellen.

IaC Testing

Neben der Stilprüfung kann man auch andere Dinge nutzen, z.B. überprüfen, ob Ihre Infrastruktur tatsächlich bereitgestellt werden kann. Oder überprüfen, ob Änderungen an der Infrastruktur zu finanziellen Einbußen führen. Warum könnte das wichtig sein? Es ist eine komplexe und philosophische Frage, die man besser mit einer Anekdote beantwortet: Irgendwann gab es einen Auto-Scaler in PowerShell, der Grenzbedingungen nicht überprüfte => es wurden mehr VMs erstellt als nötig => der Kunde gab mehr Geld aus, als geplant. Das ist kaum erfreulich, aber diesen Fehler hätte man frühzeitig erkennen können.

Man könnte fragen, warum man die komplexe Infrastruktur noch komplexer machen sollte? Tests für die Infrastruktur, genau wie für den Code, dienen nicht der Vereinfachung, sondern dem Verständnis, wie Ihre Infrastruktur funktionieren sollte.

IaC Testing Pyramid

IaC Testing: Statische Analyse

Wenn man die gesamte Infrastruktur sofort bereitstellt und überprüft, ob sie funktioniert, kann es sein, dass das eine Menge Zeit in Anspruch nimmt und viele Ressourcen benötigt. Daher sollte etwas Grundlegendes, Schnelles und Effizientes im Vordergrund stehen, das zahlreiche primitive Fälle abdeckt.

Bash ist knifflig

Lassen Sie uns ein banales Beispiel betrachten. Wählen Sie alle Dateien im aktuellen Verzeichnis aus und kopieren Sie sie an einen anderen Ort. Das Erste, was einem in den Sinn kommt:

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

Was ist, wenn im Dateinamen ein Leerzeichen vorhanden ist? Na ja, wir sind ja clever und 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. das Globing nicht funktioniert hat.

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

Sind wir jetzt gut gemacht? Nö… Wir haben vergessen, dass im Dateinamen sein kann n.

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

Statische Analysetools

Das Problem aus dem vorherigen Schritt hätte erkannt werden können, als wir die Anführungszeichen vergessen haben, dafür gibt es viele Mittel. Shellcheck, es gibt viele davon, und wahrscheinlich können Sie einen Linter für Ihren Stack unter Ihrer IDE finden.

Sprache
Werkzeug

bash
Shellcheck

Ruby
RuboCop

python
Pylint

ansible
Ansible Lint

IaC Testing: Unit Tests

Wie wir aus dem vorherigen Beispiel gesehen haben, sind Linter nicht allmächtig und können nicht auf alle problematischen Stellen hinweisen. Analog zum Testen in der Softwareentwicklung können wir uns an Unit-Tests erinnern. Hier kommen sofort shunit, junit, rspec, pytest. Aber was ist mit Ansible, Chef, Saltstack und dengleichen?

Am Anfang haben wir über S.O.L.I.D. und dass unsere Infrastruktur aus kleinen Bausteinen bestehen sollte. Jetzt ist ihre Zeit gekommen.

Die Infrastruktur wird in kleine Bausteine unterteilt, zum Beispiel Ansible-Rollen.
Ein gewisses Umfeld wird eingerichtet, sei es Docker oder VM.
Auf dieses Testumfeld wenden wir unsere Ansible-Rolle an.
Wir überprüfen, ob alles wie erwartet funktioniert hat (wir führen die Tests durch).
Wir entscheiden, ob es in Ordnung ist oder nicht.

IaC Testing: Unit Testing tools

Die Frage, was Tests für CFM sind? Man kann einfach ein Skript ausführen oder fertige Lösungen dafür verwenden:

CFM
Werkzeug

Ansible
Testinfra

Chef
Inspec

Chef
Serverspec

saltstack
Goss

Beispiel für testinfra, prüfen wir, ob die Benutzer test1, test2 existieren und in der 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 wählen? Die Frage ist kompliziert und nicht eindeutig, hier ist ein Beispiel für Änderungen in Projekten auf GitHub aus den Jahren 2018-2019:

IaC Testing frameworks

Wie bringt man das alles zusammen und startet es? Man kann einfach alles selbst machen wenn genügend Ingenieure vorhanden sind. Oder man kann fertige Lösungen verwenden, auch wenn es nicht viele davon gibt:

CFM
Werkzeug

Ansible
Molecule

Chef
Test Kitchen

Terraform
Terratest

Beispiel für Änderungen in Projekten auf GitHub aus den Jahren 2018-2019:

Molecule vs. Testkitchen

Ursprünglich haben wir versucht, testkitchen zu verwenden:

Eine VM parallel erstellen.
Ansible-Rollen anwenden.
Inspec ausführen.

Für 25-35 Rollen dauerte dies 40-70 Minuten, was lang war.

Der nächste Schritt war der Übergang zu Jenkins / Docker / Ansible / Molecule. Ideologisch ist alles dasselbe.

Playbooks linten.
Rollen linten.
Container starten.
Ansible-Rollen anwenden.
Testinfra ausführen.
Die Idempotenz überprüfen.

Linting für 40 Rollen und Tests für ein Dutzend dauerten etwa 15 Minuten.

Was zu wählen ist, hängt von vielen Faktoren ab, wie dem verwendeten Stack, der Expertise im Team usw. Hier entscheidet jeder selbst, wie er das Thema Unit-Tests angeht.

IaC-Tests: Integrationstests.

Auf der nächsten Stufe der Testpyramide erscheinen Integrationstests. Sie ähneln Unit-Tests:

Die Infrastruktur wird in kleine Bausteine zerlegt, zum Beispiel Ansible-Rollen.
Ein gewisses Umfeld wird eingerichtet, sei es Docker oder VM.
Dieses Testumfeld wird angewendet. eine Vielzahl Ansible-Rollen.
Wir überprüfen, ob alles wie erwartet funktioniert (führen die Tests durch).
Wir entscheiden, ob es in Ordnung ist oder nicht.

Groß gesagt, wir überprüfen nicht die Funktionsfähigkeit eines einzelnen Elements des Systems wie bei Unit-Tests, sondern überprüfen, wie der Server insgesamt konfiguriert ist.

IaC-Tests: End-to-End-Tests.

An der Spitze der Pyramide erwarten uns End-to-End-Tests. Das heißt, wir überprüfen nicht die Funktionsfähigkeit eines einzelnen Servers, eines einzelnen Skripts, eines einzelnen Bausteins unserer Infrastruktur. Wir prüfen, ob eine Vielzahl von Servern, die zusammengefasst sind, unsere Infrastruktur wie erwartet funktioniert. Leider habe ich keine fertigen Lösungen gesehen, vielleicht weil die Infrastruktur oft einzigartig ist und es schwierig ist, ein Framework für deren Tests zu erstellen. Daher schaffen alle ihre eigenen Lösungen. Die Nachfrage ist vorhanden, aber es gibt keine Antwort. Deshalb werde ich erklären, was es gibt, um andere zu gesunden Gedanken anzuregen oder mich darauf hinzuweisen, dass alles längst erfunden wurde.

Ein Projekt mit reicher Geschichte. Es wird in großen Organisationen verwendet und wahrscheinlich hat jeder von Ihnen indirekt damit zu tun gehabt. Die Anwendung unterstützt zahlreiche Datenbanken, Integrationen usw. Das Wissen darüber, wie die Infrastruktur aussehen kann, umfasst viele docker-compose-Dateien, und das Wissen darüber, welche Tests in welcher Umgebung ausgeführt werden, ist Jenkins.

Dieses Schema hat lange Zeit funktioniert, bis wir versucht haben, es nach Openshift zu migrieren. Forschung Die Container blieben gleich, aber die Ausführungsumgebung hat sich geändert (Hallo D.R.Y. wieder).

Der Gedanke der Forschung ging weiter, und in OpenShift fand sich eine Sache namens APB (Ansible Playbook Bundle), die es ermöglicht, Wissen darüber, wie man die Infrastruktur bereitstellt, in einem Container zu verpacken. Das bedeutet, es gibt einen reproduzierbaren, testbaren Wissensstand, wie man die Infrastruktur bereitstellt.

Das alles klang gut, bis wir auf eine heterogene Infrastruktur stießen: Für Tests benötigten wir Windows. Letztendlich sitzt das Wissen darüber, was, wo und wie bereitgestellt und getestet werden soll, in Jenkins.