Dieser Artikel ist der sechste in der Reihe "Wie man die Netzwerkinfrastruktur unter Kontrolle bringt". Die Inhalte aller Artikel dieser Reihe und die Links dazu finden Sie hier. .
Nachdem ich einige Themen hinter mir gelassen habe, habe ich beschlossen, ein neues Kapitel zu beginnen.
Zur Sicherheit komme ich später zurück. Hier möchte ich einen einfachen, aber effektiven Ansatz besprechen, der vielen von Nutzen sein könnte. Es ist vielmehr eine kurze Geschichte darüber, wie Automatisierung das Leben eines Ingenieurs verändern kann. Es geht um die Verwendung von Templates. Am Ende finden Sie eine Liste meiner Projekte, in denen Sie sehen können, wie alles hier Beschriebene funktioniert.
DevOps für Netzwerke
Die Erstellung von Konfigurationen mittels Skripten, die Nutzung von GIT zur Versionskontrolle der IT-Infrastruktur, die Remote-"Übertragung" – diese Ideen kommen einem sofort in den Sinn, wenn man über die technische Umsetzung des DevOps-Ansatzes nachdenkt. Die Vorteile sind offensichtlich. Leider gibt es jedoch auch Nachteile.
Als unsere Entwickler vor mehr als 5 Jahren mit diesen Vorschlägen zu uns, den Netzwerktechnikern, kamen, waren wir nicht begeistert.
Es ist zu erwähnen, dass wir ein recht buntes Netzwerk geerbt haben, bestehend aus Geräten von etwa 10 verschiedenen Herstellern. Einige Dinge ließen sich bequem über unsere bevorzugte CLI konfigurieren, während wir an anderen Stellen die GUI bevorzugten. Zudem hat uns die langjährige Arbeit mit „lebendiger“ Hardware an Echtzeit-Kontrollen gewöhnt. Ich persönlich fühle mich wohler, wenn ich Änderungen direkt über die CLI vornehme. So kann ich schnell erkennen, wenn etwas schiefgeht, und die Änderungen „zurückrollen“. All dies stand in einem gewissen Widerspruch zu ihren Ideen.
Es tauchen auch andere Fragen auf, zum Beispiel kann sich die Benutzeroberfläche von Version zu Version ändern. Das führt letztlich dazu, dass Ihr Skript möglicherweise eine falsche „Konfiguration“ erstellt. Es wäre nicht ratsam, die Produktion für Tests zu verwenden.
Oder wie stellt man fest, dass die Konfigurationsbefehle korrekt angewendet wurden, und was ist im Fehlerfall zu tun?
Ich möchte nicht sagen, dass all diese Fragen unlösbar sind. Wenn man ‚A‘ sagt, ist es wahrscheinlich klug, auch ‚B‘ zu sagen. Wenn Sie dieselben Prozesse zur Änderungssteuerung wie in der Entwicklung verwenden möchten, sollten Sie neben der Produktionsumgebung auch Entwicklungs- und Staging-Umgebungen haben. Dann wirkt dieser Ansatz vollständig. Aber was wird das kosten?
Es gibt jedoch eine Situation, in der die Nachteile nahezu ausgeglichen werden und nur Vorteile bleiben. Ich spreche von Projektarbeiten.
Projekt
In den letzten zwei Jahren habe ich an einem Projekt zum Aufbau eines Rechenzentrums für einen großen Anbieter gearbeitet. Ich bin in diesem Projekt für F5 und Palo Alto verantwortlich. Aus Sicht von Cisco handelt es sich um „3rd Party Equipment“.
Für mich gibt es in diesem Projekt zwei klar definierte Phasen.
Die erste Phase
Im ersten Jahr war ich unendlich beschäftigt, ich habe nachts und an Wochenenden gearbeitet. Ich konnte meinen Kopf nicht heben. Der Druck von Seiten des Managements und des Kunden war stark und kontinuierlich. In der ständigen Routine konnte ich nicht einmal versuchen, den Prozess zu optimieren. Es ging nicht nur, und schon gar nicht in erster Linie um die Konfiguration der Geräte, sondern um die Erstellung der Projektdokumentation.
Hier haben die ersten Tests begonnen, und ich war überrascht, wie viele kleine Fehler und Ungenauigkeiten gemacht wurden. Natürlich funktionierte alles, aber hier fehlte ein Buchstabe im Namen, dort fehlte eine Zeile im Befehl … Die Tests zogen sich hin, und ich befand mich in einem ständigen, täglichen Kampf mit Fehlern, Tests und Dokumentation.
Das ging ein Jahr lang so. Das Projekt, wie ich verstehe, war für alle nicht einfach, aber allmählich wurde der Kunde immer zufriedener, was es ermöglichte, zusätzliche Ingenieure einzustellen, die einen Teil der Routine übernehmen konnten.
Jetzt konnte man sich ein wenig umsehen.
Und das war der Beginn der zweiten Phase.
Zweite Phase
Ich beschloss, den Prozess zu automatisieren.
Was ich aus der damaligen Kommunikation mit den Entwicklern gelernt habe (und es ist zu sagen, dass wir ein starkes Team hatten), ist, dass das Textformat, obwohl es auf den ersten Blick wie etwas aus der Welt des DOS-Betriebssystems aussieht, viele wertvolle Eigenschaften hat.
So ist das Textformat beispielsweise nützlich, wenn Sie die Vorteile von GIT und all seinen Ablegern voll ausschöpfen möchten. Und das wollte ich.
Auf den ersten Blick könnte man einfach die Konfiguration oder eine Liste von Befehlen speichern, aber Änderungen dabei vorzunehmen ist ziemlich umständlich. Zudem gibt es eine weitere wichtige Aufgabe bei der Planung. Es muss eine Dokumentation vorhanden sein, die Ihr Design im Ganzen beschreibt (Low Level Design) sowie die spezifische Implementierung (Network Implementation Plan). In diesem Fall erscheint die Verwendung von Templates als sehr geeigneter Ansatz.
Beim Einsatz von YAML und Jinja2 fungiert die YAML-Datei mit den Konfigurationsparametern, wie IP-Adressen, BGP AS-Nummern usw., hervorragend als NIP, während die Jinja2-Templates die Syntax des entsprechenden Designs enthalten und somit im Wesentlichen eine Reflexion des LLD darstellen.
Das Erlernen der Sprachen YAML und Jinja2 dauerte zwei Tage. Um zu verstehen, wie es funktioniert, genügen einige gute Beispiele. Anschließend benötigte ich etwa zwei Wochen, um alle Templates zu erstellen, die unserem Design entsprechen: eine Woche für Palo Alto und eine weitere Woche für F5. Alles wurde auf dem firmeneigenen GitHub veröffentlicht.
Jetzt sah der Änderungsprozess folgendermaßen aus:
- Die YAML-Datei wurde geändert
- Die Konfigurationsdatei wurde mit Hilfe des Templates (Jinja2) erstellt
- wurde im Remote-Repository gespeichert
- Ich habe die erstellte Konfiguration auf die Hardware geladen
- Ich habe einen Fehler gesehen
- Ich habe die YAML-Datei oder die Jinja2-Vorlage geändert
- Die Konfigurationsdatei wurde mit Hilfe des Templates (Jinja2) erstellt
- …
Es ist klar, dass anfangs viel Zeit für Anpassungen benötigt wurde, aber nach ein oder zwei Wochen wurde das schon eher zur Seltenheit.
Eine gute Überprüfung und Möglichkeit zur Fehlerbehebung war der Wunsch des Kunden, die Namenskonvention zu ändern. Wer mit F5 gearbeitet hat, versteht die Brisanz der Situation. Für mich war das jedoch ziemlich einfach. Ich habe die Namen in der YAML-Datei geändert, die gesamte Konfiguration von der Hardware gelöscht, eine neue generiert und hochgeladen. Für alles, einschließlich der Fehlerkorrekturen, benötigte ich 4 Tage: jeweils zwei Tage für jede Technologie. Danach war ich bereit für die nächste Phase, nämlich die Erstellung von DEV- und Staging-Rechenzentren.
Dev und Staging
Das Staging spiegelt praktisch vollständig die Produktionsumgebung wider. Die Entwicklungsumgebung ist eine stark reduzierte und hauptsächlich auf virtueller Hardware basierende Kopie. Eine ideale Situation, um einen neuen Ansatz anzuwenden. Wenn ich die für den gesamten Prozess aufgewendete Zeit eliminiere, denke ich, dass die Arbeit nicht mehr als zwei Wochen in Anspruch genommen hat. Die meiste Zeit wurde durch das Warten auf die andere Seite und durch gemeinsame Problemlösungen beansprucht. Die Implementierung der Drittanbieter-Software verlief fast unbemerkt von Außenstehenden. Ich hatte sogar Zeit, um etwas zu lernen und ein paar Artikel auf Habré zu schreiben 🙂.
Fassen wir zusammen
Was bleibt also am Ende übrig?
- Alles, was ich zur Anpassung der Konfiguration benötige, ist die Änderung einer einfachen, klar strukturierten YAML-Datei mit den Konfigurationsparametern. Ich ändere niemals das Python-Skript und sehr selten (nur bei Fehlern) passe ich das Jinja2-Template an.
- Aus Sicht der Dokumentation ergibt sich eine nahezu ideale Situation. Sie ändern die Dokumentation (YAML-Dateien fungieren als NIP) und laden diese Konfiguration auf die Hardware hoch. Dadurch bleibt Ihre Dokumentation immer aktuell.
All dies führte dazu, dass
- die Fehlerquote praktisch auf 0 gesenkt wurde.
- 90 Prozent der Routineaufgaben entfielen.
- Die Implementierungsgeschwindigkeit hat sich erheblich erhöht.
BEZAHLEN, F5Y, ACY
Ich sagte, dass einige Beispiele ausreichen, um zu verstehen, wie es funktioniert.
Hier ist eine kurze (und natürlich angepasste) Version dessen, was während meiner Arbeit erstellt wurde.
= Bereitstellung Palo Alto von Yaml = Palo Alto von Yaml
= Bereitstellung F5 from Yaml = F5 from Yaml (kommt bald)
= Bereitstellung ACi von Yaml = F5 from Yaml
Ich werde ein paar Worte zu ACY hinzufügen (nicht zu verwechseln mit ACI).
Diejenigen, die mit ACI gearbeitet haben, wissen, dass dieses Wunder (und das ist im positiven Sinne gemeint) ganz sicher nicht von Netzwerktechnikern geschaffen wurde :). Vergessen Sie alles, was Sie über Netzwerke wussten — das wird Ihnen nicht helfen!
Ein wenig übertrieben, aber es vermittelt ungefähr das Gefühl, das ich seit 3 Jahren habe, wenn ich mit ACI arbeite.
In diesem Fall ist ACY nicht nur die Möglichkeit, den Änderungsprozess zu kontrollieren (was besonders wichtig im Fall von ACI ist, da dies die zentrale und kritische Komponente Ihres Rechenzentrums ist), sondern es bietet auch eine benutzerfreundliche Oberfläche zur Erstellung von Konfigurationen.
Ingenieure in diesem Projekt verwenden Excel zur Konfiguration von ACI anstelle von YAML, um die gleichen Ziele präzise zu erreichen. Die Verwendung von Excel hat natürlich Vorteile:
- Ihre USt-IdNr. in einer Datei
- schöne Tabellen, die den Kunden gut gefallen
- Sie können einige Excel-Tools verwenden.
Aber es gibt einen Nachteil, der meiner Meinung nach die Vorteile überwiegt. Es wird deutlich schwieriger, Änderungen zu kontrollieren und die Zusammenarbeit im Team abzustimmen.
ACY ist im Grunde die Anwendung der gleichen Ansätze, die ich für Dritte verwendet habe, um ACI zu konfigurieren.
Quelle: habr.com
