Dieser Artikel ist der sechste in der Reihe „So übernehmen Sie die Kontrolle über Ihre Netzwerkinfrastruktur“. 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 komme etwas später noch einmal auf den Sicherheitsdienst zurück. 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. Dies ist eher eine Kurzgeschichte darüber, wie Automatisierung das Leben eines Ingenieurs verändern kann. Wir werden über die Verwendung von Vorlagen sprechen. Am Ende gibt es eine Liste meiner Projekte, in der Sie sehen können, wie alles, was hier beschrieben wird, funktioniert.
DevOps für das Netzwerk
Eine Konfiguration per Skript erstellen, GIT zur Steuerung von Änderungen an der IT-Infrastruktur nutzen, Remote-„Upload“ – diese Ideen stehen an erster Stelle, wenn man über die technische Umsetzung des DevOps-Ansatzes nachdenkt. Die Vorteile liegen auf der Hand. Aber leider gibt es auch Nachteile.
Als vor mehr als 5 Jahren unsere Entwickler mit diesen Vorschlägen zu uns, den Netzwerkern, kamen, waren wir nicht begeistert.
Ich muss sagen, dass wir ein ziemlich buntes Netzwerk geerbt haben, das aus Geräten von etwa 10 verschiedenen Anbietern besteht. Einige Dinge ließen sich bequem über unsere Lieblings-CLI konfigurieren, andere zogen wir jedoch vor, die GUI zu verwenden. Darüber hinaus haben wir durch die lange Arbeit an „lebenden“ Geräten die Echtzeitsteuerung gelernt. Wenn ich beispielsweise Änderungen vornehme, fühle ich mich viel wohler, wenn ich direkt über die CLI arbeite. Auf diese Weise kann ich schnell erkennen, dass etwas schief gelaufen ist, und die Änderungen rückgängig machen. All dies stand in gewissem Widerspruch zu ihren Vorstellungen.
Es stellen sich auch andere Fragen, beispielsweise kann sich die Benutzeroberfläche von Version zu Version der Software geringfügig ändern. Dies führt letztendlich dazu, dass Ihr Skript die falsche „Konfiguration“ erstellt. Ich möchte die Produktion nicht zum „Einfahren“ nutzen.
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 Probleme unlösbar sind. Wenn Sie nur „A“ sagen, macht es wahrscheinlich Sinn, auch „B“ zu sagen, und wenn Sie für die Änderungskontrolle dieselben Prozesse wie in der Entwicklung verwenden möchten, müssen Sie zusätzlich zur Produktion über Entwicklungs- und Staging-Umgebungen verfügen. Dann sieht dieser Ansatz vollständig aus. Aber wie viel wird es kosten?
Aber es gibt eine Situation, in der die Nachteile praktisch ausgeglichen werden und nur die Vorteile übrig bleiben. Ich spreche von Designarbeit.
Projekt
Seit zwei Jahren beteilige ich mich an einem Projekt zum Aufbau eines Rechenzentrums für einen großen Anbieter. Ich bin in diesem Projekt für F5 und Palo Alto verantwortlich. Aus Sicht von Cisco handelt es sich hierbei um „3rd-Party-Equipment“.
Für mich persönlich gibt es in diesem Projekt zwei unterschiedliche Phasen.
Die erste Stufe
Im ersten Jahr war ich endlos beschäftigt, ich arbeitete nachts und am Wochenende. Ich konnte meinen Kopf nicht heben. Der Druck seitens des Managements und des Kunden war stark und kontinuierlich. In einer ständigen Routine konnte ich nicht einmal versuchen, den Prozess zu optimieren. Dabei ging es nicht nur um die Konfiguration der Ausrüstung, sondern vielmehr um die Erstellung der Konstruktionsdokumentation.
Die ersten Tests haben begonnen und ich wäre erstaunt, wie viele kleine Fehler und Ungenauigkeiten gemacht wurden. Natürlich hat alles funktioniert, aber es fehlte ein Buchstabe im Namen, eine fehlende Zeile im Befehl ... Die Tests gingen immer weiter und ich befand mich bereits in einem ständigen, täglichen Kampf mit Fehlern, Tests und Dokumentationen .
Das ging ein Jahr lang so. Soweit ich weiß, war das Projekt nicht für alle einfach, aber nach und nach wurde der Kunde immer zufriedener, und dies ermöglichte die Einstellung zusätzlicher Ingenieure, die einen Teil der Routine selbst übernehmen konnten.
Jetzt konnten wir uns ein wenig umsehen.
Und das war der Beginn der zweiten Etappe.
Die zweite Stufe
Ich habe beschlossen, den Prozess zu automatisieren.
Was ich aus meiner damaligen Kommunikation mit den Entwicklern verstanden habe (und das müssen wir würdigen, wir hatten ein starkes Team), ist, dass das Textformat, obwohl es auf den ersten Blick wie etwas aus der Welt des DOS-Betriebssystems aussieht, eine Nummer hat von wertvollen Immobilien.
So ist das Textformat beispielsweise nützlich, wenn Sie GIT und alle seine Derivate optimal nutzen möchten. Und ich wollte.
Nun, es scheint, dass man einfach eine Konfiguration oder eine Liste von Befehlen speichern kann, aber Änderungen vorzunehmen ist ziemlich umständlich. Darüber hinaus gibt es beim Design noch eine weitere wichtige Aufgabe. Sie sollten über eine Dokumentation verfügen, die Ihren Entwurf als Ganzes (Low-Level-Design) und die spezifische Implementierung (Netzwerkimplementierungsplan) beschreibt. Und 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 usw. perfekt die Rolle von NIP, während Jinja2-Vorlagen eine Syntax enthalten, die dem Design entspricht, d. h. im Wesentlichen eine Reflexion von LLD.
Das Erlernen von YAML und Jinja2 dauerte zwei Tage. Ein paar gute Beispiele reichen aus, um zu verstehen, wie das funktioniert. Dann dauerte es etwa zwei Wochen, alle Vorlagen zu erstellen, die zu unserem Design passten: eine Woche für Palo Alto und eine weitere Woche für F5. All dies wurde auf Corporate Githab veröffentlicht.
Nun sah der Änderungsprozess so aus:
- hat die YAML-Datei geändert
- eine Konfigurationsdatei mit einer Vorlage erstellt (Jinja2)
- in einem Remote-Repository gespeichert
- hat die erstellte Konfiguration auf das Gerät hochgeladen
- Ich habe einen Fehler gesehen
- die YAML-Datei oder die Jinja2-Vorlage geändert
- eine Konfigurationsdatei mit einer Vorlage erstellt (Jinja2)
- ...
Es ist klar, dass anfangs viel Zeit für Bearbeitungen aufgewendet wurde, aber nach ein oder zwei Wochen wurde dies eher eine Seltenheit.
Ein guter Test und eine Gelegenheit, alles zu debuggen, war der Wunsch des Kunden, die Namenskonvention zu ändern. Diejenigen, die mit F5 gearbeitet haben, verstehen die Pikantheit der Situation. Aber für mich war alles ganz 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, einschließlich Fehlerbehebungen, dauerte vier Tage: zwei Tage für jede Technologie. Danach war ich bereit für den nächsten Schritt, nämlich die Schaffung von DEV- und Staging-Rechenzentren.
Entwicklung und Staging
Die Inszenierung bildet die Produktion tatsächlich vollständig nach. Dev ist eine stark abgespeckte Kopie, die hauptsächlich auf virtueller Hardware basiert. Eine ideale Situation für einen neuen Ansatz. Wenn ich die Zeit, die ich aufgewendet habe, vom Gesamtprozess isolierte, schätze ich, dass die Arbeit nicht länger als zwei Wochen gedauert hat. Die Hauptzeit besteht darin, auf die andere Seite zu warten und gemeinsam nach Problemen zu suchen. Die Implementierung von Drittanbietern blieb von anderen nahezu unbemerkt. Es gab sogar Zeit, etwas zu lernen und ein paar Artikel über Habré zu schreiben :)
Zusammengefasst
Was habe ich also unterm Strich?
- Um die Konfiguration zu ändern, muss ich lediglich eine einfache, klar strukturierte YAML-Datei mit Konfigurationsparametern ändern. Ich ändere nie das Python-Skript und sehr selten (nur wenn ein Fehler vorliegt) ändere ich das Jinja2-Heatlate
- Aus dokumentarischer Sicht ist dies eine nahezu ideale Situation. Sie ändern die Dokumentation (YAML-Dateien dienen als NIP) und laden diese Konfiguration auf das Gerät hoch. So ist Ihre Dokumentation immer auf dem neuesten Stand
All dies führte dazu, dass
- die Fehlerquote ist auf nahezu 0 gesunken
- 90 Prozent der Routine sind weg
- Die Geschwindigkeit der Umsetzung hat sich deutlich erhöht
PAY, F5Y, ACY
Ich sagte, dass ein paar Beispiele ausreichen, um zu verstehen, wie es funktioniert.
Hier ist eine kurze (und natürlich modifizierte) Version dessen, was während meiner Arbeit entstanden ist.
= Bereitstellung Palo Alto von Yaml = Palo Alto von Yaml
= Bereitstellung F5 für Yaml = F5 für Yaml (bald verfügbar)
= Bereitstellung ACich von Yaml = F5 für Yaml
Ich füge noch ein paar Worte zu ACY hinzu (nicht zu verwechseln mit ACI).
Diejenigen, die mit ACI gearbeitet haben, wissen, dass dieses Wunder (und im positiven Sinne) definitiv nicht von Netzwerkern geschaffen wurde :). Vergessen Sie alles, was Sie über das Netzwerk wussten – es wird Ihnen nichts nützen!
Es ist ein wenig übertrieben, aber es vermittelt ungefähr das Gefühl, das ich in den letzten drei Jahren bei der Arbeit mit ACI ständig verspüre.
Und in diesem Fall bietet ACY nicht nur die Möglichkeit, einen Änderungskontrollprozess aufzubauen (was im Fall von ACI besonders wichtig ist, da es der zentrale und kritischste Teil Ihres Rechenzentrums sein soll), sondern bietet Ihnen auch die Möglichkeit eine benutzerfreundliche Oberfläche zum Erstellen von Konfigurationen.
Die Ingenieure dieses Projekts verwenden Excel, um ACI anstelle von YAML für genau die gleichen Zwecke zu konfigurieren. Die Verwendung von Excel bietet natürlich Vorteile:
- Ihr NIP in einer Datei
- schöne Schilder, die für den Kunden angenehm anzusehen sind
- Sie können einige Excel-Tools verwenden
Aber es gibt einen Minuspunkt, der meiner Meinung nach die Vorteile überwiegt. Die Kontrolle von Veränderungen und die Koordinierung der Teamarbeit werden deutlich schwieriger.
ACY ist eigentlich eine Anwendung derselben Ansätze, die ich für den Drittanbieter zur Konfiguration von ACI verwendet habe.
Source: habr.com