{"id":34742,"date":"2019-10-31T22:00:10","date_gmt":"2019-10-31T19:00:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty\/"},"modified":"2019-10-31T22:00:10","modified_gmt":"2019-10-31T19:00:10","slug":"kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","title":{"rendered":"Wie Sie die Netzwerk-Infrastruktur unter Kontrolle bringen. Kapitel vier. Automatisierung. Vorlagen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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. hier<\/a><\/noindex><\/i>.<\/p>\n

Nachdem ich einige Themen hinter mir gelassen habe, habe ich beschlossen, ein neues Kapitel zu beginnen.<\/p>\n

Zur Sicherheit komme ich sp\u00e4ter zur\u00fcck. Hier m\u00f6chte ich einen einfachen, aber effektiven Ansatz besprechen, der vielen von Nutzen sein k\u00f6nnte. Es ist vielmehr eine kurze Geschichte dar\u00fcber, wie Automatisierung das Leben eines Ingenieurs ver\u00e4ndern kann. Es geht um die Verwendung von Templates. Am Ende finden Sie eine Liste meiner Projekte, in denen Sie sehen k\u00f6nnen, wie alles hier Beschriebene funktioniert.<\/p>\n

DevOps f\u00fcr Netzwerke<\/h2>\n

\nDie Erstellung von Konfigurationen mittels Skripten, die Nutzung von GIT zur Versionskontrolle der IT-Infrastruktur, die Remote-\"\u00dcbertragung\" \u2013 diese Ideen kommen einem sofort in den Sinn, wenn man \u00fcber die technische Umsetzung des DevOps-Ansatzes nachdenkt. Die Vorteile sind offensichtlich. Leider gibt es jedoch auch Nachteile.<\/p>\n

Als unsere Entwickler vor mehr als 5 Jahren mit diesen Vorschl\u00e4gen zu uns, den Netzwerktechnikern, kamen, waren wir nicht begeistert.
\n<\/a><\/noindex>
\nEs ist zu erw\u00e4hnen, dass wir ein recht buntes Netzwerk geerbt haben, bestehend aus Ger\u00e4ten von etwa 10 verschiedenen Herstellern. Einige Dinge lie\u00dfen sich bequem \u00fcber unsere bevorzugte CLI konfigurieren, w\u00e4hrend wir an anderen Stellen die GUI bevorzugten. Zudem hat uns die langj\u00e4hrige Arbeit mit \u201elebendiger\u201c Hardware an Echtzeit-Kontrollen gew\u00f6hnt. Ich pers\u00f6nlich f\u00fchle mich wohler, wenn ich \u00c4nderungen direkt \u00fcber die CLI vornehme. So kann ich schnell erkennen, wenn etwas schiefgeht, und die \u00c4nderungen \u201ezur\u00fcckrollen\u201c. All dies stand in einem gewissen Widerspruch zu ihren Ideen.<\/p>\n

Es tauchen auch andere Fragen auf, zum Beispiel kann sich die Benutzeroberfl\u00e4che von Version zu Version \u00e4ndern. Das f\u00fchrt letztlich dazu, dass Ihr Skript m\u00f6glicherweise eine falsche \u201eKonfiguration\u201c erstellt. Es w\u00e4re nicht ratsam, die Produktion f\u00fcr Tests zu verwenden. <\/p>\n

Oder wie stellt man fest, dass die Konfigurationsbefehle korrekt angewendet wurden, und was ist im Fehlerfall zu tun?<\/p>\n

Ich m\u00f6chte nicht sagen, dass all diese Fragen unl\u00f6sbar sind. Wenn man \u201aA\u2018 sagt, ist es wahrscheinlich klug, auch \u201aB\u2018 zu sagen. Wenn Sie dieselben Prozesse zur \u00c4nderungssteuerung wie in der Entwicklung verwenden m\u00f6chten, sollten Sie neben der Produktionsumgebung auch Entwicklungs- und Staging-Umgebungen haben. Dann wirkt dieser Ansatz vollst\u00e4ndig. Aber was wird das kosten?<\/p>\n

Es gibt jedoch eine Situation, in der die Nachteile nahezu ausgeglichen werden und nur Vorteile bleiben. Ich spreche von Projektarbeiten.<\/p>\n

Projekt<\/h2>\n

\nIn den letzten zwei Jahren habe ich an einem Projekt zum Aufbau eines Rechenzentrums f\u00fcr einen gro\u00dfen Anbieter gearbeitet. Ich bin in diesem Projekt f\u00fcr F5 und Palo Alto verantwortlich. Aus Sicht von Cisco handelt es sich um \u201e3rd Party Equipment\u201c.<\/p>\n

F\u00fcr mich gibt es in diesem Projekt zwei klar definierte Phasen. <\/p>\n

Die erste Phase<\/h3>\n

\nIm ersten Jahr war ich unendlich besch\u00e4ftigt, 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\u00e4ndigen 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\u00e4te, sondern um die Erstellung der Projektdokumentation. <\/p>\n

Hier haben die ersten Tests begonnen, und ich war \u00fcberrascht, wie viele kleine Fehler und Ungenauigkeiten gemacht wurden. Nat\u00fcrlich funktionierte alles, aber hier fehlte ein Buchstabe im Namen, dort fehlte eine Zeile im Befehl \u2026 Die Tests zogen sich hin, und ich befand mich in einem st\u00e4ndigen, t\u00e4glichen Kampf mit Fehlern, Tests und Dokumentation. <\/p>\n

Das ging ein Jahr lang so. Das Projekt, wie ich verstehe, war f\u00fcr alle nicht einfach, aber allm\u00e4hlich wurde der Kunde immer zufriedener, was es erm\u00f6glichte, zus\u00e4tzliche Ingenieure einzustellen, die einen Teil der Routine \u00fcbernehmen konnten.<\/p>\n

Jetzt konnte man sich ein wenig umsehen.
\nUnd das war der Beginn der zweiten Phase. <\/p>\n

Zweite Phase<\/h3>\n

\nIch beschloss, den Prozess zu automatisieren.<\/p>\n

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.
\nSo ist das Textformat beispielsweise n\u00fctzlich, wenn Sie die Vorteile von GIT und all seinen Ablegern voll aussch\u00f6pfen m\u00f6chten. Und das wollte ich. <\/p>\n

Auf den ersten Blick k\u00f6nnte man einfach die Konfiguration oder eine Liste von Befehlen speichern, aber \u00c4nderungen dabei vorzunehmen ist ziemlich umst\u00e4ndlich. 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.<\/p>\n

Beim Einsatz von YAML und Jinja2 fungiert die YAML-Datei mit den Konfigurationsparametern, wie IP-Adressen, BGP AS-Nummern usw., hervorragend als NIP, w\u00e4hrend die Jinja2-Templates die Syntax des entsprechenden Designs enthalten und somit im Wesentlichen eine Reflexion des LLD darstellen. <\/p>\n

Das Erlernen der Sprachen YAML und Jinja2 dauerte zwei Tage. Um zu verstehen, wie es funktioniert, gen\u00fcgen einige gute Beispiele. Anschlie\u00dfend ben\u00f6tigte ich etwa zwei Wochen, um alle Templates zu erstellen, die unserem Design entsprechen: eine Woche f\u00fcr Palo Alto und eine weitere Woche f\u00fcr F5. Alles wurde auf dem firmeneigenen GitHub ver\u00f6ffentlicht.<\/p>\n

Jetzt sah der \u00c4nderungsprozess folgenderma\u00dfen aus:<\/p>\n