Dieser Artikel ist der sechste in der Reihe von Artikeln „Wie man die Netzwerk-Infrastruktur unter Kontrolle bringt“. Den Inhalt aller Artikel der Reihe und die Links dazu finden Sie .
Nachdem ich einige Themen hinter mir gelassen habe, habe ich beschlossen, dennoch ein neues Kapitel zu beginnen.
Zur Sicherheit komme ich etwas später zurück. Hier möchte ich einen einfachen, aber effektiven Ansatz besprechen, der, davon bin ich überzeugt, vielen in irgendeiner Form nützlich sein kann. Es ist eher 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, wo Sie sehen können, wie alles hier beschriebene funktioniert.
DevOps für Netzwerke
Die Erstellung von Konfigurationen mit Skripten, die Verwendung von GIT zur Versionskontrolle der IT-Infrastruktur, das Remote-„Deployment“ – diese Ideen kommen einem zuerst in den Sinn, wenn man über die technische Umsetzung des DevOps-Ansatzes nachdenkt. Die Vorteile sind offensichtlich. Aber es gibt leider auch Nachteile.
Als unsere Entwickler vor über 5 Jahren mit diesen Vorschlägen zu uns Netzwerktechnikern kamen, waren wir nicht begeistert.
Es ist zu sagen, dass wir ein recht buntes Netzwerk geerbt haben, das aus Geräten von etwa 10 verschiedenen Anbietern besteht. Einige ließen sich bequem über unsere bevorzugte CLI konfigurieren, während wir bei anderen lieber die GUI verwendeten. Außerdem hat die lange Arbeit mit der „Live“-Hardware uns an die Echtzeitkontrolle gewöhnt. Ich beispielsweise fühle mich bei Änderungen viel wohler, wenn ich direkt über die CLI arbeite. So kann ich schnell sehen, wenn etwas schief geht und die Änderungen „rückgängig machen“. Das stand ein wenig im Widerspruch zu ihren Ideen.
Es ergeben sich auch andere Fragen, zum Beispiel kann sich die Benutzeroberfläche von Version zu Version der Software leicht ändern. Dies wird letztendlich dazu führen, dass Ihr Skript eine falsche „Konfiguration“ erstellt. Es wäre nicht ideal, die Produktionsumgebung für „Tests“ zu verwenden.
Oder wie erkennt man, 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. Nur zu sagen „A“, ist wahrscheinlich klug, auch „B“ zu sagen und, wenn Sie dieselben Prozesse zur Versionskontrolle wie in der Entwicklung verwenden möchten, benötigen Sie neben der Produktionsumgebung auch Entwicklungs- und Staging-Umgebungen. Dann scheint dieser Ansatz vollständig zu sein. Aber wie viel wird das kosten?
Es gibt jedoch eine Situation, in der die Nachteile praktisch ausgeglichen werden und nur die Vorteile bleiben. Ich spreche von Projektarbeiten.
Projekt
In den letzten zwei Jahren war ich an einem Projekt zum Aufbau eines Rechenzentrums für einen großen Anbieter beteiligt. Ich bin in diesem Projekt verantwortlich für F5 und Palo Alto. Aus der Sicht von Cisco handelt es sich um „3rd party equipment“.
Für mich gibt es zwei deutlich ausgeprägte Phasen in diesem Projekt.
Erste Phase
Im ersten Jahr war ich unendlich beschäftigt, ich arbeitete nachts und an den Wochenenden. Ich konnte meinen Kopf nicht heben. Der Druck von Management und Kunde war stark und kontinuierlich. In der ständigen Routine konnte ich nicht einmal versuchen, den Prozess zu optimieren. Es ging nicht nur um die Konfiguration der Hardware, sondern auch um die Erstellung der Projektdokumentation.
Dann begannen die ersten Tests, 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 war ständig in einem täglichen Kampf mit Fehlern, Tests und Dokumentation.
Das dauerte ein Jahr lang. Das Projekt war, soweit ich verstehe, für alle nicht einfach, aber allmählich wurde der Kunde immer zufriedener, und das gab die Möglichkeit, zusätzliche Ingenieure einzustellen, die einen Teil der Routine übernehmen konnten.
Jetzt konnte ich mich etwas 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 (und man muss sagen, wir hatten ein starkes Team) verstanden habe, ist, dass das Textformat, obwohl es auf den ersten Blick etwas aus der Welt des DOS-Betriebssystems zu sein scheint, eine Reihe wertvoller Eigenschaften hat.
So ist beispielsweise das Textformat nützlich, wenn Sie die Vorteile von GIT und seinen Derivaten voll ausschöpfen möchten. Und das wollte ich.
Nun, es schien, als könnte man einfach die Konfiguration oder die Liste der Befehle speichern, aber Änderungen dabei vorzunehmen ist ziemlich umständlich. Außerdem gibt es bei der Planung noch eine weitere wichtige Aufgabe. Sie sollten eine Dokumentation haben, die Ihr Design insgesamt beschreibt (Low Level Design) und die spezifische Implementierung (Network Implementation Plan). Und in diesem Fall scheint die Verwendung von Vorlagen eine sehr geeignete Lösung zu sein.
So, beim Einsatz von YAML und Jinja2 erfüllt die YAML-Datei mit Konfigurationsparametern wie IP-Adressen, BGP AS-Nummern,… hervorragend die Rolle von NIP, während die Jinja2-Templates die dem Design entsprechende Syntax enthalten, das heißt, sie sind im Wesentlichen ein Spiegelbild von LLD.
Das Studium der Sprachen YAML und Jinja2 dauerte zwei Tage. Um zu verstehen, wie es funktioniert, genügen einige gute Beispiele. Anschließend dauerte es 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. Das gesamte Ergebnis wurde auf unserem Unternehmens-GitHub abgelegt.
Jetzt sah der Änderungsprozess folgendermaßen aus:
- Änderung der YAML-Datei
- Erstellung der Konfigurationsdatei mithilfe des Templates (Jinja2)
- Speichern im entfernten Repository
- Hochladen der erstellten Konfiguration auf die Hardware
- Fehler gesehen
- Änderung der YAML-Datei oder des Jinja2-Templates
- Erstellung der Konfigurationsdatei mithilfe des Templates (Jinja2)
- …
Es ist klar, dass anfangs viel Zeit mit Anpassungen verbracht wurde, aber nach einer Woche oder zwei wurde es eher zur Seltenheit.
Eine gute Überprüfung und Möglichkeit, alles zu debuggen, war der Wunsch des Kunden, die Namenskonvention zu ändern. Wer mit F5 gearbeitet hat, versteht die Brisanz der Situation. Aber für mich war alles ziemlich einfach. Ich änderte die Namen in der YAML-Datei, löschte die gesamte Konfiguration von der Hardware, generierte eine neue und lud sie hoch. Für alles, unter Berücksichtigung der Bugfix-Anpassungen, benötigte ich 4 Tage: jeweils zwei Tage für jede Technologie. Danach war ich bereit für den nächsten Schritt, nämlich die Erstellung von DEV- und Staging-Rechenzentren.
Dev und Staging
Staging spiegelt praktisch vollständig die Produktion wider. Dev ist eine stark reduzierte Version, die hauptsächlich auf virtueller Hardware basiert. Eine ideale Situation für den Einsatz des neuen Ansatzes. Wenn ich die Zeit, die ich dafür aufgewendet habe, vom gesamten Prozess abziehe, denke ich, dass die Arbeiten nicht mehr als 2 Wochen in Anspruch genommen haben. Die meiste Zeit war die Wartezeit auf die andere Seite und das gemeinsame Suchen nach Problemen. Die Implementierung von 3rd Party verlief kaum bemerkbar für die Umgebung. Es blieb sogar Zeit, etwas zu lernen und ein paar Artikel auf Habré zu schreiben 🙂
Fassen wir zusammen
Also, was bleibt mir in der Quintessenz?
- Alles, was ich für die Änderung der Konfiguration benötige, ist eine einfache, klar strukturierte YAML-Datei mit den Konfigurationsparametern zu ändern. Ich ändere niemals das Python-Skript und nur sehr selten (nur wenn es einen Fehler gibt) ändere ich das Jinja2-Template.
- Aus Sicht der Dokumentation ergibt sich eine fast ideale Situation. Sie ändern die Dokumentation (YAML-Dateien fungieren als NIP) und laden diese Konfiguration auf die Geräte hoch. So bleibt Ihre Dokumentation immer aktuell.
All dies führte dazu, dass
- der Fehleranteil auf nahezu 0 gesenkt wurde.
- 90 Prozent der Routinearbeiten entfallen.
- Die Implementierungsgeschwindigkeit hat sich vervielfacht.
PAY, F5Y, ACY
Ich habe gesagt, dass ein paar Beispiele ausreichen, um zu verstehen, wie es funktioniert.
Hier ist eine kurze (und natürlich modifizierte) Version dessen, was im Verlauf 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 im positiven Sinne) definitiv nicht von Netzwerktechnikern geschaffen wurde :). Vergessen Sie alles, was Sie über Netzwerke wussten — es wird Ihnen nicht helfen!
Etwas übertrieben, aber es vermittelt ungefähr das Gefühl, das ich seit 3 Jahren ständig beim Arbeiten mit ACI habe.
In diesem Fall ist ACY nicht nur die Möglichkeit, einen Änderungsüberwachungsprozess aufzubauen (was besonders wichtig ist, wenn es um ACI geht, da es sich um den zentralen und kritischsten Teil Ihres Rechenzentrums handelt), sondern es bietet Ihnen auch eine benutzerfreundliche Schnittstelle zur Erstellung der Konfiguration.
Die Ingenieure in diesem Projekt verwenden Excel anstelle von YAML zur präzisen Erreichung der gleichen Ziele zur Konfiguration von ACI. Die Verwendung von Excel hat natürlich ihre Vorteile:
- Ihr NIP in einer Datei
- schöne Tabellen, die für den Kunden ansprechend sind
- Sie können einige Excel-Tools nutzen
Aber es gibt einen Nachteil, der meiner Meinung nach die Vorteile überwiegt. Es wird viel komplizierter, Änderungen zu kontrollieren und die Teamarbeit abzustimmen.
ACY ist tatsächlich die Anwendung der gleichen Ansätze, die ich für Dritthersteller verwendet habe, zur Konfiguration von ACI.
Quelle: habr.com
