Das Jahr neigte sich dem Neuen Jahr zu. Die Kinder im ganzen Land hatten bereits Briefe an den Weihnachtsmann geschickt oder sich Geschenke gewünscht, und das Hauptorganisationsmittel – einer der großen Einzelhändler – bereitete sich auf das Verkaufsapotheose vor. Im Dezember steigt die Belastung für sein Rechenzentrum um ein Vielfaches. Daher entschied sich das Unternehmen, das Rechenzentrum zu modernisieren und mehrere Dutzend neue Server in Betrieb zu nehmen, anstelle von Geräten, deren Lebensdauer abgelaufen war. Damit endet die Einleitung vor den kreisenden Schneeflocken und beginnt ein Thriller.

Die Geräte kamen einige Monate vor dem Verkaufshoch auf die Plattform. Der Betriebservice weiß natürlich, wie und was an den Servern konfiguriert werden muss, um sie in die Produktionsumgebung zu bringen. Aber wir mussten das automatisieren und den menschlichen Faktor ausschließen. Außerdem ersetzten die Server vor der Migration ein Set von SAP-Systemen, die für das Unternehmen kritisch wichtig sind.

Die Inbetriebnahme der neuen Server war strikt an eine Frist gebunden. Und eine Verschiebung hätte sowohl die Auslieferung von einer Milliarde Geschenke als auch die Migration der Systeme gefährdet. Das Datum hätte nicht einmal das Team, zu dem der Weihnachtsmann und Santa Claus gehörten, ändern können – das Verschieben des SAP-Systems zur Lagerverwaltung kann nur einmal im Jahr erfolgen. Vom 31. Dezember bis zum 1. Januar legen riesige Lagerhäuser des Einzelhändlers, insgesamt so groß wie 20 Fußballfelder, ihre Arbeit für 15 Stunden nieder. Und dies ist der einzige Zeitfenster für die Migration des Systems. Wir hatten keinen Spielraum für Fehler bei der Einführung der Server.

Ich möchte gleich klarstellen: Meine Erzählung spiegelt die Werkzeuge und den Prozess des Konfigurationsmanagements wider, die unser Team anwendet.

Das Konfigurationsmanagementsystem besteht aus mehreren Ebenen. Die Schlüsselkomponente ist das CMS-System. Bei industrieller Nutzung würde das Fehlen einer der Ebenen unweigerlich zu unangenehmen Überraschungen führen.

Betriebssysteminstallation verwalten

Die erste Ebene ist das System zur Verwaltung der Installation von Betriebssystemen auf physischen und virtuellen Servern. Es erstellt grundlegende Betriebssystemkonfigurationen und beseitigt den menschlichen Faktor.

Mit diesem System erhielten wir standardisierte und für die weitere Automatisierung geeignete Instanzen von Servern mit Betriebssystem. Bei der „Bereitstellung“ erhielten sie eine minimale Anzahl lokaler Benutzer und öffentlicher SSH-Schlüssel sowie eine abgestimmte Betriebssystemkonfiguration. Wir konnten die Server garantiert über das CMS verwalten und waren sicher, dass es „unten“ auf Betriebssystemebene keine Überraschungen gab.

Die „maximale“ Aufgabe für das Installationsmanagementsystem besteht darin, Server automatisch vom BIOS-/Firmware-Level bis hin zum Betriebssystem zu konfigurieren. Vieles hängt hier von der Hardware und den Konfigurationsanforderungen ab. Für heterogene Hardware kann man REDFISH API. Wenn die gesamte Hardware von einem Anbieter stammt, ist es oft bequemer, fertige Verwaltungstools zu verwenden (zum Beispiel HP ILO Amplifier, DELL OpenManage usw.).

Für die Installation des Betriebssystems auf physischen Servern haben wir allen gut bekannten Cobbler verwendet, in dem eine Reihe abgestimmter Installationsprofile mit dem Betriebsteam definiert sind. Bei der Hinzufügung eines neuen Servers zur Infrastruktur verband der Ingenieur die MAC-Adresse des Servers mit dem erforderlichen Profil in Cobbler. Bei der ersten Netzwerkstart erhielt der Server eine temporäre Adresse und ein aktuelles Betriebssystem. Danach wurde er in die Ziel-VLAN/IP-Adresse umgeschaltet und die Arbeit dort fortgesetzt. Ja, das Ändern der VLAN benötigt Zeit und erfordert Koordination, aber es bietet zudem zusätzlichen Schutz vor einer versehentlichen Installation des Servers in der Produktionsumgebung.

Virtuelle Server haben wir auf der Grundlage von Vorlagen erstellt, die mit HashiCorp Packer vorbereitet wurden. Der Grund war der gleiche: um mögliche menschliche Fehler bei der Installation des Betriebssystems zu verhindern. Im Gegensatz zu physischen Servern ermöglicht Packer jedoch, kein PXE, Netzwerkboote und VLAN-Wechsel zu verwenden. Dies erleichterte und vereinfachte die Erstellung virtueller Server.

Abb. 1. Verwaltung der Installation von Betriebssystemen.

Geheimnisverwaltung

Jedes Konfigurationsmanagementsystem enthält Daten, die vor normalen Benutzern verborgen werden müssen, aber zur Vorbereitung von Systemen erforderlich sind. Dazu gehören Passwörter lokaler Benutzer und Dienstkonten, Schlüssel für Zertifikate, verschiedene API-Token usw. Diese werden im Allgemeinen als „Geheimnisse“ bezeichnet.

Wenn von Anfang an nicht festgelegt wird, wo und wie diese Geheimnisse gespeichert werden, sind je nach Strenge der Informationssicherheitsanforderungen solche Speicherarten wahrscheinlich:

direkt im Management-Code der Konfiguration oder in Dateien im Repository;
in spezialisierten Tools für das Konfigurationsmanagement (zum Beispiel Ansible Vault);
in CI/CD-Systemen (Jenkins/TeamCity/GitLab/usw.) oder in Systemen des Konfigurationsmanagements (Ansible Tower/Ansible AWX);
außerdem können Geheimnisse im „Manuellen Modus“ übergeben werden. Zum Beispiel werden sie an einem vereinbarten Ort abgelegt und dann von den Systemen des Konfigurationsmanagements verwendet;
verschiedene Kombinationen der oben beschriebenen Methoden.

Jede Methode hat ihre eigenen Nachteile. Der Hauptnachteil besteht darin, dass es an Zugriffspolitiken für Geheimnisse mangelt: Es ist nicht möglich oder schwierig festzustellen, wer welche Geheimnisse nutzen kann. Ein weiterer Nachteil ist das Fehlen einer Zugriffsauditierung und eines vollständigen Lebenszyklus. Wie schnell kann man zum Beispiel einen öffentlichen Schlüssel ersetzen, der im Code und in mehreren zusammenhängenden Systemen vermerkt ist?

Wir haben ein zentrales Geheimnisspeicher-System namens HashiCorp Vault verwendet. Das hat uns ermöglicht:

Geheimnisse sicher zu speichern. Sie sind verschlüsselt, und selbst wenn jemand Zugriff auf die Datenbank des Vault-Speichers erhält (zum Beispiel durch Wiederherstellung aus einem Backup), kann er die dort speicherten Geheimnisse nicht lesen;
Zugriffspolitiken für Geheimnisse zu organisieren. Nutzern und Anwendungen stehen nur die ihnen „zugewiesenen“ Geheimnisse zur Verfügung;
Zugriffsaudits für Geheimnisse durchzuführen. Alle Aktionen mit Geheimnissen werden im Audit-Log von Vault aufgezeichnet;
einen vollständigen „Lebenszyklus“ für den Umgang mit Geheimnissen zu organisieren. Man kann sie erstellen, widerrufen, Fristen festlegen usw.
sich leicht mit anderen Systemen zu integrieren, die Zugriff auf Geheimnisse benötigen;
und auch Durchgängige Verschlüsselung, Einmalpasswörter für das Betriebssystem und die Datenbanken, Zertifikate autorisierter Stellen usw. anzuwenden.

Kommen wir nun zu dem zentralen System für Authentifizierung und Autorisierung. Man hätte auch darauf verzichten können, aber die Verwaltung von Nutzern in vielen Begleitsystemen wäre zu kompliziert. Wir haben die Authentifizierung und Autorisierung über einen LDAP-Dienst eingerichtet. Andernfalls müsste man im gleichen Vault kontinuierlich Authentifizierungstokens für Nutzer generieren und verwalten. Die Entfernung und Hinzufügung von Nutzern würde sich in einen Quest verwandeln: "Habe ich überall diesen Benutzer erstellt/entfernt?"

Wir fügen unserer Systemarchitektur eine weitere Ebene hinzu: das Management von Geheimnissen und zentrale Authentifizierung/Autorisierung:

Abbildung 2. Management von Geheimnissen.

Konfigurationsmanagement

Wir sind zum Kern angekommen — zum CMS-System. In unserem Fall handelt es sich um die Kombination von Ansible und Red Hat Ansible AWX.

Anstelle von Ansible können auch Chef, Puppet, SaltStack in Betracht gezogen werden. Wir haben uns aus mehreren Gründen für Ansible entschieden.

Erstens, die Vielseitigkeit. Die Menge an bereits verfügbaren Modulen zur Verwaltung beeindruckt.. Und wenn etwas fehlt, kann man auf GitHub und Galaxy nachsehen.
Zweitens müssen keine Agenten auf der verwalteten Hardware installiert und gewartet werden, man muss nicht beweisen, dass sie die Last nicht stören, und bestätigen, dass es keine "Backdoors" gibt.
Drittens hat Ansible eine niedrige Einstiegshürde. Ein fähiger Ingenieur kann am ersten Tag der Arbeit mit dem Produkt ein funktionierendes Playbook schreiben.

Doch allein Ansible war uns in einer Produktionsumgebung nicht genug. Andernfalls hätten wir viele Probleme mit der Zugangsbeschränkung und der Überwachung von Administratorenaktionen gehabt. Wie kann der Zugang eingeschränkt werden? Es war nötig, dass jede Abteilung ihren "eigenen" Satz von Servern verwaltet (sprich — Ansible-Playbook ausführt). Wie kann man bestimmten Mitarbeitern die Ausführung bestimmter Ansible-Playbooks erlauben? Oder wie verfolgt man, wer ein Playbook ausgeführt hat, ohne zahlreiche lokale Benutzerkonten auf den Servern und der mit Ansible verwalteten Hardware einzurichten?

Die meisten solcher Fragen werden von Red Hat Ansible Tower, oder seinem Open-Source-Upstream-Projekt Ansible AWX. Daher haben wir es unserem Kunden bevorzugt.

Und noch eine Nuance zum Portrait unseres CMS-Systems. Ansible-Playbooks müssen in Code-Repository-Verwaltungssystemen gespeichert werden. In unserem Fall ist das GitLab CE..

Somit verwaltet die Kombination aus Ansible/Ansible AWX/GitLab die Konfigurationen (siehe Abb. 3). Natürlich sind AWX/GitLab mit einem einheitlichen Authentifizierungssystem integriert, und das Ansible-Playbook ist mit HashiCorp Vault verbunden. Konfigurationen gelangen nur über Ansible AWX in die Produktionsumgebung, wo alle "Spielregeln" festgelegt sind: wer was konfigurieren kann, woher der Code für die Konfigurationsverwaltung des CMS kommt usw.

Abb. 3. Konfigurationsmanagement.

Testmanagement

Unsere Konfiguration wird in Form von Code dargestellt. Daher sind wir gezwungen, nach den gleichen Regeln zu spielen wie die Softwareentwickler. Wir mussten die Prozesse für Entwicklung, kontinuierliche Tests, Bereitstellung und Anwendung des Konfigurationscodes auf Produktionsservern organisieren.

Wenn dies nicht sofort erledigt wird, würden die geschriebenen Rollen für die Konfiguration entweder nicht mehr unterstützt und geändert oder könnten nicht mehr in der Produktion gestartet werden. Das Heilmittel gegen dieses Problem ist bekannt und hat sich in diesem Projekt bewährt:

jede Rolle ist mit Modultests abgedeckt;
Tests werden automatisch bei jeder Änderung im Code, der die Konfigurationen steuert, ausgeführt;
Änderungen im Code zur Verwaltung von Konfigurationen gelangen nur nach erfolgreichem Bestehen aller Tests und des Code-Reviews in die Produktionsumgebung.

Die Entwicklung des Codes und die Verwaltung der Konfigurationen wurden ruhiger und vorhersehbarer. Für die Organisation kontinuierlicher Tests haben wir die GitLab CI/CD-Tools genutzt und als Framework für die Organisation der Tests Ansible Molecule.

Bei jeder Änderung im Code zur Verwaltung der Konfigurationen ruft GitLab CI/CD Molecule auf:

es überprüft die Syntax des Codes,
startet einen Docker-Container,
wendet den geänderten Code im erstellten Container an,
prüft die Rolle auf Idempotenz und führt Tests für diesen Code aus (die Granularität liegt hier auf der Ebene der Ansible-Rolle, siehe Abb. 4).

Wir haben die Konfigurationen in die Produktionsumgebung mit Hilfe von Ansible AWX ausgeführt. Die für den Betrieb verantwortlichen Ingenieure wendeten die Änderungen an der Konfiguration über vordefinierte Vorlagen an. AWX forderte bei jedem Antrag selbstständig die neueste Version des Codes vom Master-Branch in GitLab an. So schlossen wir die Verwendung von ungetestetem oder veraltetem Code in der Produktionsumgebung aus. Natürlich gelangte der Code in den Master-Branch nur nach Tests, Überprüfung und Abstimmung.

Abb. 4. Automatisierte Tests von Rollen in GitLab CI/CD.

Es gibt noch ein Problem im Zusammenhang mit dem Betrieb von Produktionssystemen. In der Praxis ist es sehr schwierig, Änderungen an der Konfiguration nur über den CMS-Code vorzunehmen. Es ergeben sich unvorhergesehene Situationen, in denen ein Ingenieur die Konfiguration "hier und jetzt" ändern muss, ohne auf die Korrektur des Codes, Tests, Abstimmungen usw. zu warten.

Infolgedessen entstehen durch manuelle Änderungen Abweichungen in der Konfiguration auf identischer Hardware (zum Beispiel haben die Knoten eines HA-Clusters unterschiedliche Konfigurationen der sysctl-Einstellungen). Oder die tatsächliche Konfiguration auf der Hardware weicht von der ab, die im CMS-Code festgelegt ist.

Deshalb überprüfen wir neben kontinuierlichen Tests auch die Produktionsumgebungen auf Konfigurationsabweichungen. Wir haben die einfachste Option gewählt: den Code der CMS-Konfiguration im ‚Dry Run‘-Modus auszuführen, das heißt ohne Änderungen anzuwenden, aber mit Benachrichtigung über alle Abweichungen zwischen der geplanten und der tatsächlichen Konfiguration. Dies haben wir durch regelmäßige Ausführungen aller Ansible-Playbooks mit der Option ‚—check‘ auf den Produktionsservern realisiert. Wie immer ist Ansible AWX für die Ausführung und Aktualität der Playbooks verantwortlich (vgl. Abb. 5):

Abb. 5. Überprüfungen auf Konfigurationsabweichungen in Ansible AWX.

Nach den Prüfungen sendet AWX einen Bericht über die Abweichungen an die Administratoren. Diese analysieren die problematische Konfiguration und beheben sie dann über korrigierte Playbooks. So halten wir die Konfiguration in der Produktionsumgebung aufrecht, und das CMS befindet sich immer in einem aktuellen und synchronisierten Zustand. Das befreit von unangenehmen ‚Wundern‘, wenn der CMS-Code auf ‚Produktions‘-Servern angewendet wird.

Jetzt haben wir eine wichtige Testebene, die aus Ansible AWX/GitLab/Molecule besteht (Abb. 6).

Abb. 6. Testmanagement.

Schwierig? Ich kann nicht widersprechen. Aber ein solches Komplexmanagementsystem für Konfigurationen ist eine umfassende Antwort auf viele Fragen, die mit der Automatisierung der Serverkonfiguration zusammenhängen. Jetzt hat der Einzelhändler immer eine klar definierte Konfiguration für Standardserver. Das CMS wird, im Gegensatz zu einem Ingenieur, die notwendigen Einstellungen nicht vergessen, Benutzer erstellen und Dutzende oder Hunderte von erforderlichen Anpassungen vornehmen.

In den Einstellungen der Server und Umgebungen gibt es heute kein ‚geheimes Wissen‘ mehr. Alle erforderlichen Besonderheiten sind in den Playbooks zusammengefasst. Kein Platz mehr für Kreativität und nebulöse Anweisungen: „setze wie bei einem normalen Oracle, aber da müssen ein paar sysctl-Einstellungen vorgenommen werden und Benutzer mit der entsprechenden UID hinzugefügt werden. Frag die Leute aus dem Betrieb, sie wissen Bescheid.».

Die Möglichkeit, Konfigurationsabweichungen zu erkennen und sie im Voraus zu beheben, bringt Ruhe. Ohne ein Konfigurationsmanagementsystem sieht das normalerweise anders aus. Probleme sammeln sich an, bis sie eines Tages in der Produktion ‚explodieren‘. Danach wird eine Ursachenanalyse durchgeführt, die Konfigurationen werden überprüft und korrigiert. Und der Zyklus beginnt von neuem.

Und natürlich haben wir die Inbetriebnahme der Server von mehreren Tagen auf Stunden beschleunigt.

In der Silvesternacht, als die Kinder voller Freude Geschenke auspackten und die Erwachsenen ihre Wünsche beim Glockenläuten äußerten, haben unsere Ingenieure das SAP-System auf neue Server migriert. Selbst der Weihnachtsmann würde sagen, dass die besten Wunder gut vorbereitet sind.

P.S. Unser Team hat oft mit der Herausforderung zu kämpfen, dass Auftraggeber die Aufgabe der Konfigurationsverwaltung so einfach wie möglich lösen möchten. Ideal wäre es, wenn es wie durch Zauberhand mit einem einzigen Tool geschehen könnte. Aber im Leben ist alles komplizierter (ja, wieder keine silbernen Kugeln geliefert): Es bleibt nicht aus, einen ganzen Prozess mit den für das Team des Auftraggebers geeigneten Werkzeugen zu schaffen.

Autor: Sergey Artemov, Architekt der Abteilung DevOps-Lösungen „Inforsysteme Jet“

Quelle: habr.com