Es näherte sich dem neuen Jahr. Kinder im ganzen Land hatten bereits Briefe an den Weihnachtsmann geschickt oder sich selbst Geschenke gemacht, und ihr Hauptausführender, einer der großen Einzelhändler, bereitete sich auf die Apotheose des Verkaufs vor. Im Dezember erhöht sich die Belastung seines Rechenzentrums um ein Vielfaches. Daher entschloss sich das Unternehmen, das Rechenzentrum zu modernisieren und mehrere Dutzend neue Server anstelle von Geräten in Betrieb zu nehmen, die das Ende ihrer Lebensdauer erreicht hatten. Damit endet die Geschichte vor dem Hintergrund wirbelnder Schneeflocken und der Thriller beginnt.
Die Ausrüstung traf mehrere Monate vor dem Höhepunkt der Verkäufe am Standort ein. Der Betriebsdienst weiß natürlich, wie und was auf den Servern konfiguriert werden muss, um sie in die Produktionsumgebung zu bringen. Aber wir mussten dies automatisieren und den menschlichen Faktor eliminieren. Darüber hinaus wurden vor der Migration einer Reihe unternehmenskritischer SAP-Systeme die Server ausgetauscht.
Die Inbetriebnahme neuer Server war streng an eine Frist gebunden. Und der Umzug bedeutete, dass sowohl der Versand einer Milliarde Geschenke als auch die Migration von Systemen gefährdet waren. Auch ein Team bestehend aus Väterchen Frost und Weihnachtsmann konnte den Termin nicht ändern – die Umstellung des SAP-Systems zur Lagerverwaltung ist nur einmal im Jahr möglich. Vom 31. Dezember bis 1. Januar legen die riesigen Lagerhallen des Einzelhändlers, insgesamt so groß wie 20 Fußballfelder, für 15 Stunden ihre Arbeit nieder. Und dies ist der einzige Zeitraum, in dem das System bewegt werden kann. Bei der Einführung von Servern durften wir uns keine Fehler erlauben.
Um es klar zu sagen: Meine Geschichte spiegelt die Tools und den Konfigurationsmanagementprozess wider, die unser Team verwendet.
Der Konfigurationsmanagementkomplex besteht aus mehreren Ebenen. Die Schlüsselkomponente ist das CMS-System. Im industriellen Betrieb würde das Fehlen einer der Ebenen unweigerlich zu unangenehmen Wundern führen.
Verwaltung der Betriebssysteminstallation
Die erste Ebene ist ein System zur Verwaltung der Installation von Betriebssystemen auf physischen und virtuellen Servern. Es erstellt grundlegende Betriebssystemkonfigurationen und eliminiert den menschlichen Faktor.
Mit diesem System erhielten wir Standardserverinstanzen mit einem für die weitere Automatisierung geeigneten Betriebssystem. Während des „Eingießens“ erhielten sie einen Mindestsatz an lokalen Benutzern und öffentlichen SSH-Schlüsseln sowie eine konsistente Betriebssystemkonfiguration. Wir konnten die Verwaltung der Server über das CMS garantieren und waren sicher, dass es „unten“ auf der Betriebssystemebene keine Überraschungen gab.
Die „maximale“ Aufgabe des Installationsmanagementsystems besteht darin, Server automatisch von der BIOS-/Firmware-Ebene bis zum Betriebssystem zu konfigurieren. Hier hängt viel von der Ausstattung und den Rüstarbeiten ab. Bei heterogener Ausstattung können Sie darüber nachdenken . Wenn die gesamte Hardware von einem Anbieter stammt, ist es oft bequemer, vorgefertigte Verwaltungstools zu verwenden (z. B. HP ILO Amplifier, DELL OpenManage usw.).
Um das Betriebssystem auf physischen Servern zu installieren, verwendeten wir den bekannten Cobbler, der eine Reihe von Installationsprofilen definiert, die mit dem Betriebsdienst vereinbart wurden. Beim Hinzufügen eines neuen Servers zur Infrastruktur verknüpfte der Techniker die MAC-Adresse des Servers mit dem erforderlichen Profil in Cobbler. Beim ersten Booten über das Netzwerk erhielt der Server eine temporäre Adresse und ein neues Betriebssystem. Anschließend wurde es auf das Ziel-VLAN/IP-Adressierung übertragen und dort weitergearbeitet. Ja, der Wechsel des VLAN erfordert Zeit und Koordination, bietet aber zusätzlichen Schutz vor einer versehentlichen Installation des Servers in einer Produktionsumgebung.
Wir haben virtuelle Server basierend auf Vorlagen erstellt, die mit HashiСorp Packer erstellt wurden. Der Grund war derselbe: mögliche menschliche Fehler bei der Installation des Betriebssystems zu verhindern. Aber im Gegensatz zu physischen Servern macht Packer PXE, Netzwerk-Booten und VLAN-Änderungen überflüssig. Dadurch ist es immer einfacher geworden, virtuelle Server zu erstellen.
Reis. 1. Verwaltung der Installation von Betriebssystemen.
Geheimnisse verwalten
Jedes Konfigurationsmanagementsystem enthält Daten, die normalen Benutzern verborgen bleiben sollten, aber zur Vorbereitung von Systemen benötigt werden. Dabei handelt es sich um Passwörter für lokale Benutzer und Dienstkonten, Zertifikatsschlüssel, verschiedene API-Token usw. Sie werden üblicherweise als „Geheimnisse“ bezeichnet.
Wenn Sie nicht von Anfang an festlegen, wo und wie diese Geheimnisse gespeichert werden sollen, kommen je nach Strenge der Informationssicherheitsanforderungen wahrscheinlich folgende Speichermethoden in Frage:
- direkt im Konfigurationssteuercode oder in Dateien im Repository;
- in speziellen Konfigurationsmanagement-Tools (z. B. Ansible Vault);
- in CI/CD-Systemen (Jenkins/TeamCity/GitLab/etc.) oder in Konfigurationsmanagementsystemen (Ansible Tower/Ansible AWX);
- Geheimnisse können auch „manuell“ übertragen werden. Sie werden beispielsweise an einem bestimmten Ort ausgelegt und dann von Konfigurationsmanagementsystemen verwendet.
- verschiedene Kombinationen der oben genannten.
Jede Methode hat ihre eigenen Nachteile. Der Hauptgrund ist das Fehlen von Richtlinien für den Zugang zu Geheimnissen: Es ist unmöglich oder schwierig zu bestimmen, wer bestimmte Geheimnisse nutzen darf. Ein weiterer Nachteil ist das Fehlen einer Zugriffsprüfung und eines vollständigen Lebenszyklus. Wie kann man beispielsweise einen öffentlichen Schlüssel, der im Code und in einer Reihe verwandter Systeme geschrieben ist, schnell ersetzen?
Wir haben den zentralisierten Geheimspeicher HashiCorp Vault verwendet. Dies ermöglichte uns:
- Bewahre Geheimnisse sicher auf. Sie sind verschlüsselt, und selbst wenn jemand Zugriff auf die Vault-Datenbank erhält (z. B. durch Wiederherstellung aus einem Backup), kann er die dort gespeicherten Geheimnisse nicht lesen.
- Organisieren Sie Richtlinien für den Zugriff auf Geheimnisse. Nur die ihnen „zugewiesenen“ Geheimnisse stehen Benutzern und Anwendungen zur Verfügung;
- Überprüfen Sie den Zugriff auf Geheimnisse. Alle Aktionen mit Geheimnissen werden im Vault-Überwachungsprotokoll aufgezeichnet.
- Organisieren Sie einen vollständigen „Lebenszyklus“ der Arbeit mit Geheimnissen. Sie können erstellt, widerrufen, ein Ablaufdatum festgelegt werden usw.
- einfache Integration in andere Systeme, die Zugriff auf Geheimnisse benötigen;
- und verwenden Sie auch End-to-End-Verschlüsselung, Einmalkennwörter für das Betriebssystem und die Datenbank, Zertifikate autorisierter Zentren usw.
Kommen wir nun zum zentralen Authentifizierungs- und Autorisierungssystem. Man könnte darauf verzichten, aber die Verwaltung der Benutzer ist in vielen verwandten Systemen zu wenig trivial. Wir haben die Authentifizierung und Autorisierung über den LDAP-Dienst konfiguriert. Andernfalls müsste Vault kontinuierlich Authentifizierungstoken für Benutzer ausstellen und verfolgen. Und das Löschen und Hinzufügen von Benutzern würde zu einer Frage werden: „Habe ich dieses Benutzerkonto überall erstellt/gelöscht?“
Wir fügen unserem System eine weitere Ebene hinzu: Geheimnisverwaltung und zentrale Authentifizierung/Autorisierung:
Reis. 2. Geheimnisverwaltung.
Konfigurationsmanagement
Wir sind beim Kern angelangt – dem CMS-System. In unserem Fall handelt es sich um eine Kombination aus Ansible und Red Hat Ansible AWX.
Anstelle von Ansible können Chef, Puppet, SaltStack verwendet werden. Wir haben uns aufgrund mehrerer Kriterien für Ansible entschieden.
- Erstens ist es Vielseitigkeit. Eine Reihe vorgefertigter Module zur Steuerung . Und wenn Sie nicht genug davon haben, können Sie auf GitHub und Galaxy suchen.
- Zweitens besteht keine Notwendigkeit, Agenten auf verwalteten Geräten zu installieren und zu unterstützen, nachzuweisen, dass sie die Auslastung nicht beeinträchtigen, und das Fehlen von „Lesezeichen“ zu bestätigen.
- Drittens weist Ansible eine niedrige Eintrittsbarriere auf. Ein kompetenter Ingenieur wird buchstäblich am ersten Tag der Arbeit mit dem Produkt ein funktionierendes Playbook schreiben.
Aber Ansible allein in einer Produktionsumgebung reichte uns nicht. Andernfalls würde es zu vielen Problemen bei der Zugriffsbeschränkung und der Überwachung der Aktionen von Administratoren kommen. Wie kann der Zugriff eingeschränkt werden? Schließlich musste jede Abteilung „ihre“ Servergruppe verwalten (sprich: das Ansible-Playbook ausführen). Wie kann man nur bestimmten Mitarbeitern erlauben, bestimmte Ansible-Playbooks auszuführen? Oder wie kann man nachverfolgen, wer das Playbook gestartet hat, ohne viel lokales Wissen über Server und Geräte aufzubauen, auf denen Ansible läuft?
Der Löwenanteil dieser Probleme wird von Red Hat gelöst oder sein Open-Source-Upstream-Projekt . Deshalb haben wir es für den Kunden bevorzugt.
Und noch eine kleine Bemerkung zum Porträt unseres CMS-Systems. Das Ansible-Playbook sollte in Code-Repository-Verwaltungssystemen gespeichert werden. Wir haben es .
Die Konfigurationen selbst werden also von einer Kombination aus Ansible/Ansible AWX/GitLab verwaltet (siehe Abb. 3). Natürlich ist AWX/GitLab in ein einziges Authentifizierungssystem integriert, und das Ansible-Playbook ist in HashiCorp Vault integriert. Konfigurationen gelangen nur über Ansible AWX in die Produktionsumgebung, in dem alle „Spielregeln“ festgelegt sind: Wer kann was konfigurieren, wo erhält man den Konfigurationsverwaltungscode für das CMS usw.
Reis. 3. Konfigurationsmanagement.
Testmanagement
Unsere Konfiguration wird in Codeform dargestellt. Daher sind wir gezwungen, nach denselben Regeln zu handeln wie Softwareentwickler. Wir mussten die Prozesse der Entwicklung, des kontinuierlichen Testens, der Bereitstellung und der Anwendung von Konfigurationscode auf Produktionsservern organisieren.
Wenn dies nicht sofort geschieht, werden die für die Konfiguration geschriebenen Rollen entweder nicht mehr unterstützt und geändert oder sie werden nicht mehr in der Produktion eingeführt. Die Heilung dieser Schmerzen ist bekannt und hat sich in diesem Projekt bewährt:
- jede Rolle wird durch Unit-Tests abgedeckt;
- Tests werden automatisch ausgeführt, wenn sich der Code ändert, der die Konfigurationen verwaltet.
- Änderungen im Konfigurationsverwaltungscode werden erst nach erfolgreichem Bestehen aller Tests und Codeüberprüfungen in die Produktionsumgebung freigegeben.
Codeentwicklung und Konfigurationsmanagement sind ruhiger und vorhersehbarer geworden. Um kontinuierliche Tests zu organisieren, haben wir das GitLab CI/CD-Toolkit verwendet und übernommen .
Immer wenn sich der Konfigurationsverwaltungscode ändert, ruft GitLab CI/CD Molecule auf:
- es überprüft die Codesyntax,
- hebt den Docker-Container an,
- wendet den geänderten Code auf den erstellten Container an,
- prüft die Rolle auf Idempotenz und führt Tests für diesen Code durch (die Granularität liegt hier auf der Ebene der Ansible-Rolle, siehe Abb. 4).
Wir haben Konfigurationen mit Ansible AWX an die Produktionsumgebung geliefert. Betriebsingenieure führten Konfigurationsänderungen über vordefinierte Vorlagen durch. AWX forderte bei jeder Verwendung selbstständig die neueste Version des Codes vom GitLab-Masterzweig an. Auf diese Weise haben wir die Verwendung von ungetestetem oder veraltetem Code in der Produktionsumgebung ausgeschlossen. Natürlich gelangte der Code erst nach Tests, Überprüfung und Genehmigung in den Master-Zweig.
Reis. 4. Automatisches Testen von Rollen in GitLab CI/CD.
Es gibt auch ein Problem im Zusammenhang mit dem Betrieb von Produktionssystemen. Im wirklichen Leben ist es sehr schwierig, Konfigurationsänderungen allein über den CMS-Code vorzunehmen. Notfallsituationen entstehen, wenn ein Ingenieur die Konfiguration „hier und jetzt“ ändern muss, ohne auf Codebearbeitung, Tests, Genehmigung usw. warten zu müssen.
Infolgedessen treten aufgrund manueller Änderungen Diskrepanzen in der Konfiguration auf demselben Gerätetyp auf (z. B. sind die Sysctl-Einstellungen auf HA-Clusterknoten unterschiedlich konfiguriert). Oder die tatsächliche Konfiguration des Geräts weicht von der im CMS-Code angegebenen ab.
Daher überprüfen wir zusätzlich zu den kontinuierlichen Tests die Produktionsumgebungen auf Konfigurationsabweichungen. Wir haben uns für die einfachste Option entschieden: den CMS-Konfigurationscode im „Probelauf“-Modus auszuführen, also ohne Änderungen vorzunehmen, aber mit Benachrichtigung über alle Abweichungen zwischen der geplanten und tatsächlichen Konfiguration. Wir haben dies implementiert, indem wir regelmäßig alle Ansible-Playbooks mit der Option „—check“ auf Produktionsservern ausgeführt haben. Wie immer ist Ansible AWX für den Start und die Aktualisierung des Playbooks verantwortlich (siehe Abb. 5):
Reis. 5. Prüft auf Konfigurationsdiskrepanzen in Ansible AWX.
Nach der Prüfung sendet AWX einen Abweichungsbericht an die Administratoren. Sie untersuchen die problematische Konfiguration und beheben sie dann durch angepasste Playbooks. So pflegen wir die Konfiguration in der Produktionsumgebung und das CMS ist immer aktuell und synchronisiert. Dies verhindert unangenehme „Wunder“, wenn CMS-Code auf „Produktions“-Servern verwendet wird.
Wir haben jetzt eine wichtige Testebene bestehend aus Ansible AWX/GitLab/Molecule (Abbildung 6).
Reis. 6. Testmanagement.
Schwierig? Ich argumentiere nicht. Aber ein solcher Komplex des Konfigurationsmanagements ist zu einer umfassenden Antwort auf viele Fragen im Zusammenhang mit der Automatisierung der Serverkonfiguration geworden. Heutzutage haben die Standardserver eines Einzelhändlers immer eine streng definierte Konfiguration. Im Gegensatz zu einem Ingenieur vergisst ein CMS nicht, die erforderlichen Einstellungen hinzuzufügen, Benutzer zu erstellen und Dutzende oder Hunderte erforderlicher Einstellungen vorzunehmen.
Es gibt heute kein „Geheimwissen“ über die Einstellungen von Servern und Umgebungen. Alle notwendigen Funktionen sind im Playbook enthalten. Schluss mit Kreativität und vagen Anweisungen: „Installieren Sie es wie normales Oracle, aber Sie müssen einige Sysctl-Einstellungen angeben und Benutzer mit der erforderlichen UID hinzufügen. Fragen Sie die Leute im Einsatz, sie wissen Bescheid".
Die Möglichkeit, Konfigurationsdiskrepanzen zu erkennen und diese proaktiv zu korrigieren, sorgt für Sicherheit. Ohne ein Konfigurationsmanagementsystem sieht das meist anders aus. Probleme häufen sich, bis sie eines Tages in Produktion gehen. Anschließend wird ein Debriefing durchgeführt, Konfigurationen überprüft und korrigiert. Und der Zyklus wiederholt sich erneut
Und natürlich haben wir die Inbetriebnahme der Server von mehreren Tagen auf Stunden beschleunigt.
Nun, am Silvesterabend selbst, als die Kinder voller Freude Geschenke auspackten und die Erwachsenen unter dem Glockenschlag Wünsche äußerten, migrierten unsere Ingenieure das SAP-System auf neue Server. Sogar der Weihnachtsmann wird sagen, dass die besten Wunder diejenigen sind, die gut vorbereitet sind.
PS: Unser Team stößt oft auf die Tatsache, dass Kunden Konfigurationsmanagementprobleme so einfach wie möglich lösen möchten. Im Idealfall wie von Zauberhand – mit einem Werkzeug. Aber im Leben ist alles komplizierter (ja, es wurden keine Wundermittel geliefert): Man muss einen gesamten Prozess mit Tools erstellen, die für das Team des Kunden praktisch sind.
Autor: Sergey Artemov, Abteilungsarchitekt „Jet-Infosysteme“
Source: habr.com