Dieser Artikel ist der sechste in einer Reihe von Artikeln mit dem Titel „So nehmen Sie die Netzwerkinfrastruktur unter Ihre Kontrolle“. Den Inhalt aller Artikel der Reihe und Links finden Sie hier .
Nachdem ich einige Themen hinter mir gelassen hatte, beschloss ich, ein neues Kapitel zu beginnen.
Ich werde etwas später wieder in Sicherheit sein. Hier möchte ich einen einfachen, aber effektiven Ansatz diskutieren, der in der einen oder anderen Form sicher für viele nützlich sein kann. Es ist eher eine kurze Geschichte darüber, wie Automatisierung das Leben eines Ingenieurs verändern kann. Es wird um die Verwendung von Temlaten gehen. Am Ende finden Sie eine Liste meiner Projekte, in der Sie sehen können, wie alles hier beschriebene funktioniert.
DevOps für das Web
Erstellen einer Konfiguration mit einem Skript, Verwenden von GIT zur Steuerung von Änderungen in der IT-Infrastruktur, Remote "Fill" - diese Ideen stehen an erster Stelle, wenn Sie über die technische Implementierung des DevOps-Ansatzes nachdenken. Die Pluspunkte liegen auf der Hand. Aber es gibt leider auch Nachteile.
Als vor mehr als 5 Jahren unsere Entwickler zu uns kamen, zu Netzwerkern, waren wir mit diesen Angeboten nicht begeistert.
Ich muss sagen, dass wir ein ziemlich buntes Netzwerk geerbt haben, das aus der Ausrüstung von ungefähr 10 verschiedenen Anbietern besteht. Etwas war bequem über unsere Lieblings-CLI zu konfigurieren, aber irgendwo haben wir es vorgezogen, die GUI zu verwenden. Darüber hinaus wurde der Echtzeitsteuerung lange Arbeit an "Live" -Ausrüstungen beigebracht. Wenn ich zum Beispiel Änderungen vornehme, fühle ich mich viel wohler, wenn ich direkt über cli arbeite. So kann ich schnell erkennen, dass etwas schief gelaufen ist, und die Änderungen rückgängig machen. All dies stand im Widerspruch zu ihren Vorstellungen.
Andere Fragen stellen sich beispielsweise von Version zu Softwareversion. Die Benutzeroberfläche kann geringfügig variieren. Dies führt letztendlich dazu, dass Ihr Skript die falsche "Konfiguration" erstellt. Ich würde die Produktion nicht für einen Einbruch nutzen wollen.
Oder wie kann man verstehen, dass die Konfigurationsbefehle korrekt angewendet wurden und was im Fehlerfall zu tun ist?
Ich möchte nicht sagen, dass all diese Probleme unlösbar sind. Wenn Sie nur "A" sagen, ist es wahrscheinlich ratsam, "B" zu sagen. Wenn Sie dieselben Prozesse für die Änderungskontrolle wie in der Entwicklung verwenden möchten, müssen Sie neben der Produktion auch Entwicklungs- und Staging-Umgebungen haben. Dann scheint dieser Ansatz vollständig zu sein. Aber wie viel kostet es?
Aber es gibt eine Situation, in der die Nachteile fast ausgeglichen sind und nur die Vorteile übrig bleiben. Ich spreche von Designarbeit.
Projekt
In den letzten zwei Jahren habe ich an einem Projekt zum Aufbau eines Rechenzentrums für einen großen Anbieter teilgenommen. Ich bin für den F5 und Palo Alto in diesem Projekt verantwortlich. Aus Sicht von Cisco handelt es sich um die "Geräte von Drittanbietern".
Für mich persönlich gibt es zwei verschiedene Phasen in diesem Projekt.
Erste Stufe
Im ersten Jahr, in dem ich unendlich beschäftigt war, arbeitete ich nachts und am Wochenende. Ich konnte meinen Kopf nicht heben. Der Druck des Managements und des Kunden war stark und kontinuierlich. In einer ständigen Routine konnte ich nicht einmal versuchen, den Prozess zu optimieren. Es ging nicht nur und weniger um die Konfiguration der Ausrüstung als vielmehr um die Erstellung der Konstruktionsdokumentation.
Also begannen die ersten Tests und ich würde erstaunt sein, wie viele kleinere Fehler und Ungenauigkeiten gemacht wurden. Natürlich hat alles funktioniert, aber der Buchstabe im Namen fehlte, die Zeile im Team fehlte hier ... Die Tests wurden fortgesetzt und fortgesetzt, und ich war bereits in einem ständigen täglichen Kampf mit Fehlern, Tests und Dokumentation.
Das dauerte ein Jahr. Das Projekt war meines Wissens nicht für alle einfach, aber nach und nach wurde der Kunde immer zufriedener, und dies ermöglichte es, zusätzliche Ingenieure einzustellen, die in der Lage waren, einen Teil der Routine zu übernehmen.
Jetzt konnte man sich ein wenig umsehen.
Und das war der Beginn der zweiten Stufe.
Zweite Stufe
Ich habe beschlossen, den Prozess zu automatisieren.
Was ich aus der damaligen Kommunikation mit den Entwicklern verstanden habe (und wir müssen Tribut zollen, wir hatten ein starkes Team), 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 .
Ein Textformat ist beispielsweise hilfreich, wenn Sie GIT und alle seine Derivate optimal nutzen möchten. Ich wollte.
Nun, es scheint, dass Sie nur eine Konfiguration oder eine Liste von Befehlen speichern können, aber Änderungen vorzunehmen ist ziemlich unpraktisch. Darüber hinaus gibt es beim Entwerfen eine weitere wichtige Aufgabe. Sie müssen über eine Dokumentation verfügen, die Ihr Gesamtdesign (Low Level Design) und Ihre spezifische Implementierung (Netzwerkimplementierungsplan) beschreibt. In diesem Fall scheint die Verwendung von Vorlagen eine sehr geeignete Option zu sein.
Wenn Sie also YAML und Jinja2 verwenden, erfüllt eine YAML-Datei mit Konfigurationsparametern wie IP-Adressen, BGP-AS-Nummern ... die Rolle von NIP perfekt, während Jinja2-Vorlagen eine dem Design entsprechende Syntax enthalten, das heißt, sie spiegelt tatsächlich LLD wider.
Es dauerte zwei Tage, um die Sprachen YAML und Jinja2 zu lernen. Ein paar gute Beispiele reichen aus, um zu verstehen, wie dies funktioniert. Dann dauerte es ungefähr zwei Wochen, um alle Vorlagen zu erstellen, die zu unserem Design passen: eine Woche für Palo Alto und eine weitere Woche für F5. All dies wurde auf Corporate Githab veröffentlicht.
Nun war der Änderungsprozess wie folgt:
- yaml Datei geändert
- hat eine Konfigurationsdatei mit einer Vorlage erstellt (Jinja2)
- in einem Remote-Repository gespeichert
- hat die erstellte Konfiguration auf das Gerät hochgeladen
- sah einen Fehler
- geänderte YAML-Datei oder Jinja2-Vorlage
- hat eine Konfigurationsdatei mit einer Vorlage erstellt (Jinja2)
- ...
Es ist klar, dass zunächst viel Zeit für die Bearbeitung aufgewendet wurde, aber nach ein oder zwei Wochen war dies bereits eine Seltenheit.
Ein guter Test und die Möglichkeit, alles zu debuggen, war der Wunsch des Kunden, die Namenskonvention zu ändern. Wer mit F5 gearbeitet hat, versteht die Pikantheit der Situation. Aber für mich war es ziemlich einfach. Ich habe die Namen in der YAML-Datei geändert, die gesamte Konfiguration vom Gerät gelöscht, eine neue generiert und hochgeladen. Alles, unter Berücksichtigung von Fehlerkorrekturen, dauerte 4 Tage: 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.
Entwicklung und Inszenierung
Die Inszenierung wiederholt die Produktion tatsächlich vollständig. Dev ist eine stark reduzierte Kopie, die hauptsächlich auf virtueller Hardware basiert. Ideale Situation für einen neuen Ansatz. Wenn ich die Zeit, die ich verbracht habe, vom allgemeinen Prozess isoliere, hat die Arbeit, glaube ich, nicht länger als 2 Wochen gedauert. Die Hauptzeit ist die Wartezeit der anderen Seite und eine gemeinsame Suche nach Problemen. Die Implementierung des Dritten war für andere nahezu unsichtbar. Es war sogar Zeit, etwas zu unterrichten und ein paar Artikel über Habré zu schreiben :)
Zusammenfassend
Was habe ich also unter dem Strich?
- Zum Ändern der Konfiguration muss ich lediglich eine einfache, klar strukturierte YAML-Datei mit Konfigurationsparametern ändern. Ich ändere nie das Python-Skript und sehr selten (nur wenn es einen Fehler gibt) ändere ich Jinja2
- Aus dokumentarischer Sicht ergibt sich eine nahezu ideale Situation. Sie ändern die Dokumentation (YAML-Dateien fungieren als NIP) und laden diese Konfiguration auf das Gerät hoch. Somit ist Ihre Dokumentation immer auf dem neuesten Stand.
All dies führte dazu, dass
- Der Prozentsatz der Fehler verringerte sich auf fast 0
- Es dauerte 90 Prozent der Routine
- Die Implementierungsgeschwindigkeit hat erheblich zugenommen
ZAHLEN, F5Y, ACY
Ich sagte, ein paar Beispiele reichen aus, um zu verstehen, wie das funktioniert.
Hier ist eine kurze (und natürlich modifizierte) Version dessen, was im Verlauf meiner Arbeit erstellt wurde.
PAY = Einsatz
P alo
A lto von
Y aml = Palo Alto von Yaml
F5Y = Bereitstellung
F5 von
Y aml =
F5 von
Y aml (in Kürze)
ACY = Bereitstellung
AC i von
Y aml =
F5 von
Y aml
Ich werde ein paar Worte über ACY hinzufügen (nicht zu verwechseln mit ACI).
Diejenigen, die mit ACI gearbeitet haben, wissen, dass dieses Wunder (und auf gute Weise auch) nicht von Netzwerkern geschaffen wurde :). Vergessen Sie alles, was Sie über das Netzwerk wussten - es wird Ihnen nicht nützlich sein!
Es ist etwas übertrieben, vermittelt aber ungefähr das Gefühl, das ich seit 3 Jahren bei der Arbeit mit ACI ständig erlebe.
In diesem Fall bietet ACY nicht nur die Möglichkeit, einen Änderungskontrollprozess zu erstellen (was besonders bei ACI wichtig ist, da davon ausgegangen wird, dass dies der zentrale und kritischste Teil Ihres Rechenzentrums ist), sondern bietet Ihnen auch eine benutzerfreundliche Oberfläche zum Erstellen einer Konfiguration.
Die Ingenieure in diesem Projekt verwenden Excel, um ACI anstelle von YAML für genau denselben Zweck zu verwenden. Die Verwendung von Excel bietet natürlich einige Vorteile:
- Ihr Nip in einer Datei
- schöne Zeichen, die der Kunde gerne sieht
- Sie können einige Excel-Tools verwenden
Aber es gibt einen Nachteil, und meiner Meinung nach überwiegt er die Profis. Das Kontrollieren von Änderungen und das Koordinieren der Teamarbeit wird viel schwieriger.
ACY wendet tatsächlich dieselben Ansätze an, die ich für die Konfiguration von ACI durch Dritte verwendet habe.