Das Jahr neigte sich dem Ende zu. Die Kinder im ganzen Land hatten bereits Briefe an den Weihnachtsmann geschickt oder sich Geschenke gewünscht, und der Hauptakteur – einer der großen Einzelhändler – bereitete sich auf den Höhepunkt des Verkaufs vor. Im Dezember steigt die Last auf sein Rechenzentrum um ein Vielfaches. Daher beschloss das Unternehmen, das Rechenzentrum zu modernisieren und mehrere Dutzend neue Server in Betrieb zu nehmen, um die veraltete Hardware zu ersetzen. An dieser Stelle endet das Märchen vor dem Hintergrund von fallenden Schneeflocken, und ein Thriller beginnt.
Die Ausrüstung kam mehrere Monate vor dem Verkaufspeak auf die Fläche. Der Betrieb wusste natürlich, wie man die Server konfiguriert, um sie in die Produktionsumgebung zu integrieren. Doch wir mussten dies automatisieren und den menschlichen Faktor ausschließen. Zudem ersetzten die Server vor der Migration eine Reihe von SAP-Systemen, die für das Unternehmen von entscheidender Bedeutung waren.
Die Einführung der neuen Server war strikt an eine Frist gebunden. Eine Verschiebung hätte sowohl die Auslieferung von einer Milliarde Geschenken als auch die Migration der Systeme gefährdet. Einen Termin zu ändern, wäre selbst für ein Team wie das des Weihnachtsmanns oder Santa Claus nicht möglich gewesen – das Verschieben des SAP-Systems zur Lagerverwaltung kann nur einmal im Jahr erfolgen. Vom 31. Dezember bis zum 1. Januar stellen die riesigen Lager des Einzelhändlers, die insgesamt der Größe von 20 Fußballfeldern entsprechen, für 15 Stunden ihren Betrieb ein. Und das ist das einzige Zeitfenster für den Systemumzug. Wir hatten keinen Spielraum für Fehler beim Einsatz der Server.
Ich erläutere gleich: Meine Erzählung spiegelt die Werkzeuge und den Prozess des Konfigurationsmanagements wider, die unser Team anwendet.
Das Konfigurationsmanagement-System besteht aus mehreren Ebenen. Die zentrale Komponente ist das CMS-System. Bei einem industriellen Einsatz 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 die grundlegenden Konfigurationen des Betriebssystems und verhindert den Einfluss menschlicher Fehler.
Mit diesem System erhielten wir standardisierte und für die weitere Automatisierung geeignete Serverinstanzen mit einem Betriebssystem. Bei der "Verteilung" wurden minimale lokale Benutzer und öffentliche SSH-Schlüssel eingerichtet sowie eine einheitliche Betriebssystemkonfiguration angewendet. Wir konnten die Server über die CMS sicher verwalten und waren uns sicher, dass es auf Betriebssystemebene keine Überraschungen gab.
Die "Maximalaufgabe" für das Installationsmanagementsystem besteht darin, Server automatisch von der BIOS-/Firmware-Ebene bis zum Betriebssystem einzurichten. Vieles hängt hier von der Hardware und den Konfigurationsaufgaben ab. Für heterogene Hardware könnte man . Wenn die gesamte Hardware von einem Anbieter stammt, ist es oft bequemer, fertige Verwaltungsmittel zu verwenden (zum Beispiel HP ILO Amplifier, DELL OpenManage usw.).
Für die Installation von Betriebssystemen auf physischen Servern haben wir den allen gut bekannten Cobbler verwendet, der eine Reihe von mit dem Betriebsteam abgestimmten Installationsprofilen enthält. Bei der Hinzufügung eines neuen Servers zur Infrastruktur koppelte 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 frisches Betriebssystem. Danach wurde er in das Ziel-VLAN/IP-Adressierung übertragen und die Arbeit dort fortgesetzt. Ja, die VLAN-Änderung kostet Zeit und erfordert Abstimmungen, aber sie bietet zusätzlichen Schutz vor einer versehentlichen Installation des Servers in der Produktionsumgebung.
Virtuelle Server haben wir auf Basis von mit HashiCorp Packer vorbereiteten Vorlagen erstellt. Der Grund war der gleiche: mögliche menschliche Fehler bei der Installation des Betriebssystems zu vermeiden. Im Gegensatz zu physischen Servern ermöglicht es Packer jedoch, keine PXE, Netzwerkstart und VLAN-Änderungen zu verwenden. Das erleichterte und vereinfachte die Erstellung virtueller Server.
Abb. 1. Verwaltung der Installation von Betriebssystemen.
Verwaltung von Geheimnissen
Jedes Konfigurationsmanagementsystem enthält Daten, die vor regulären Benutzern verborgen bleiben sollten, aber zur Systemvorbereitung erforderlich sind. Dazu gehören Passwörter lokaler Benutzer und Servicedatenkonten, Zertifikatsschlüssel, verschiedene API-Tokens usw. Diese werden normalerweise als „Secrets“ bezeichnet.
Wenn von Anfang an nicht festgelegt wird, wo und wie diese Secrets gespeichert werden sollen, können je nach Strenge der Anforderungen an die Informationssicherheit folgende Speicherarten auftreten:
- direkt im Code des Konfigurationsmanagements oder in Dateien im Repository;
- in spezialisierten Konfigurationsmanagement-Tools (zum Beispiel Ansible Vault);
- in CI/CD-Systemen (Jenkins/TeamCity/GitLab usw.) oder in Konfigurationsmanagementsystemen (Ansible Tower/Ansible AWX);
- auch können Secrets manuell übergeben werden. Beispielsweise werden sie an einem vereinbarten Ort bereitgestellt und dann von den Konfigurationsmanagementsystemen verwendet;
- verschiedene Kombinationen der oben beschriebenen Methoden.
Jede Methode hat ihre eigenen Nachteile. Der Hauptnachteil ist das Fehlen von Zugriffspolitiken für Secrets: Es ist nicht möglich oder schwierig festzustellen, wer bestimmte Secrets verwenden kann. Ein weiterer Nachteil ist das Fehlen von Zugriffs-Audits und einem vollständigen Lebenszyklus. Wie schnell kann man beispielsweise einen öffentlichen Schlüssel ersetzen, der im Code und in mehreren angrenzenden Systemen vermerkt ist?
Wir haben ein zentrales Secret-Storage mit HashiCorp Vault verwendet. Dadurch konnten wir:
- Secrets sicher speichern. Diese sind verschlüsselt, und selbst wenn jemand Zugriff auf die Datenbank des Vault-Storage erhält (zum Beispiel durch Wiederherstellung aus einem Backup), kann er die dort gespeicherten Secrets nicht lesen;
- Zugriffspolitiken für Secrets organisieren. Nutzern und Anwendungen stehen nur die ihnen "zugewiesenen" Secrets zur Verfügung;
- Zugriffs-Audits für Secrets durchführen. Alle Aktionen mit Secrets werden im Audit-Protokoll von Vault aufgezeichnet;
- einen vollständigen "Lebenszyklus" für den Umgang mit Secrets organisieren. Diese können erstellt, widerrufen, mit Ablaufdaten versehen usw. werden.
- sich leicht mit anderen Systemen integrieren, die Zugriff auf Secrets benötigen;
- und auch durchgehende Verschlüsselung, Einmalpasswörter für OS und DB, Zertifikate von autorisierten Stellen usw. anzuwenden.
Jetzt wechseln wir zum zentralen Authentifizierungs- und Autorisierungssystem. Man hätte es auch ohne auskommen können, aber die Verwaltung von Benutzern in vielen unterstützenden Systemen ist zu komplex. Wir haben die Authentifizierung und Autorisierung über den LDAP-Dienst eingerichtet. Andernfalls müsste man im gleichen Vault ständig Authentifizierungstoken für die Benutzer ausstellen und verwalten. Das Hinzufügen und Entfernen von Benutzern hätte sich dann in eine Quest verwandelt: 'Habe ich überall dieses Benutzerkonto erstellt/getilgt?'
Wir fügen unserer Systemarchitektur eine weitere Ebene hinzu: das Management von Secrets sowie die zentrale Authentifizierung/Autorisierung:
Abb. 2. Management von Secrets.
Konfigurationsmanagement
Wir sind nun beim Kern angekommen – beim CMS-System. In unserem Fall ist es die Kombination aus Ansible und Red Hat Ansible AWX.
Statt Ansible könnten auch Chef, Puppet oder SaltStack zum Einsatz kommen. Wir haben uns aus mehreren Gründen für Ansible entschieden.
- Erstens zeichnet es sich durch Vielseitigkeit aus. Die Sammlung fertiger Module zur Verwaltung . Sollte etwas fehlen, kann man auf GitHub und Galaxy suchen.
- Zweitens müssen keine Agenten auf der verwalteten Hardware installiert und gewartet werden, um nachzuweisen, dass sie die Leistung nicht beeinträchtigen und das Fehlen von "Backdoors" zu bestätigen.
- Drittens hat Ansible eine niedrige Einstiegshürde. Ein versierter Ingenieur kann am ersten Arbeitstag mit dem Produkt ein funktionierendes Playbook schreiben.
Doch Ansible allein genügte uns nicht in einer produktiven Umgebung. Andernfalls würden viele Probleme mit Zugriffsbeschränkungen und der Überprüfung der Administratorenaktionen entstehen. Wie kann der Zugriff geregelt werden? Es war notwendig, dass jede Abteilung ihre "eigenen" Server (d.h. die Ansible Playbooks) verwaltet. Wie kann der Start bestimmter Ansible Playbooks nur für ausgewählte Mitarbeiter genehmigt werden? Oder wie kann verfolgt werden, wer ein Playbook gestartet hat, ohne zahlreiche lokale Benutzerkonten auf den Servern und Geräten, die von Ansible verwaltet werden, anzulegen?
Die meisten dieser Fragen werden von Red Hat beantwortet, , oder seinem Open-Source-Upstream-Projekt . Deshalb haben wir uns für diesen Weg für den Kunden entschieden.
Und noch ein weiterer Punkt zu unserem CMS-System. Das Ansible Playbook muss in einem Code-Repository-Management-System gespeichert werden. Bei uns ist das .
Die Konfigurationen werden von einer Kombination aus Ansible/Ansible AWX/GitLab verwaltet (siehe Abb. 3). Selbstverständlich sind AWX/GitLab in ein einheitliches Authentifizierungssystem integriert, und das Ansible-Playbook ist mit HashiCorp Vault verbunden. Die Konfigurationen gelangen nur über Ansible AWX in die Produktionsumgebung, wo alle "Spielregeln" festgelegt sind: Wer was konfigurieren kann, wo der Konfigurationscode für CMS herkommt usw.
Abb. 3. Konfigurationsmanagement.
Testmanagement
Unsere Konfiguration wird in Form von Code dargestellt. Daher müssen wir nach denselben Regeln spielen wie Softwareentwickler. Wir mussten die Prozesse der Entwicklung, kontinuierlichen Tests, Lieferung und Anwendung des Konfigurationscodes auf Produktionsservern organisieren.
Wenn dies nicht sofort geschieht, würden die geschriebenen Rollen für die Konfiguration entweder nicht mehr unterstützt und geändert oder würden den Produktionsbetrieb einstellen. Das Heilmittel gegen diesen Schmerz ist bekannt und hat sich in diesem Projekt bewährt:
- jede Rolle ist durch modulare Tests abgedeckt;
- Tests werden automatisch bei jeder Änderung im Konfigurationscode ausgeführt;
- Änderungen im Konfigurationsmanagement-Code gelangen nur in die Produktionsumgebung, nachdem alle Tests und das Code-Review erfolgreich abgeschlossen sind.
Die Entwicklung von Code und das Konfigurationsmanagement sind inzwischen ruhiger und vorhersehbarer. Für die Organisation des kontinuierlichen Testens haben wir das Werkzeug GitLab CI/CD verwendet, und als Test-Framework haben wir .
Bei jeder Änderung im Konfigurationsmanagement-Code löst GitLab CI/CD Molecule aus:
- dies prü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 durch (die Granularität liegt hier auf der Ebene der Ansible-Rolle, siehe Abb. 4).
Die Konfigurationen in die Produktionsumgebung haben wir mit Ansible AWX bereitgestellt. Die für den Betrieb verantwortlichen Ingenieure haben Änderungen in der Konfiguration über zuvor definierte Vorlagen angewendet. AWX hat bei jeder Anwendung eigenständig die neueste Version des Codes von dem Master-Branch in GitLab „angefordert“. So haben wir ausgeschlossen, dass unverifizierter oder veralteter Code in der Produktionsumgebung verwendet wird. Selbstverständlich gelangte der Code in den Master-Branch nur nach Prüfung, Durchsicht und Genehmigung.
Abb. 4. Automatisiertes Testen von Rollen in GitLab CI/CD.
Es gibt ein weiteres Problem im Zusammenhang mit dem Betrieb von Produktionssystemen. In der Praxis ist es sehr schwierig, Änderungen in der Konfiguration nur über den CMS-Code vorzunehmen. Es treten unvorhergesehene Situationen auf, in denen der Ingenieur die Konfiguration „hier und jetzt“ ändern muss, ohne auf die Korrektur des Codes, Tests, Genehmigungen usw. zu warten.
Infolgedessen entstehen durch manuelle Änderungen Abweichungen in der Konfiguration auf identischer Hardware (zum Beispiel unterschiedliche sysctl-Einstellungen an den Knoten eines HA-Clusters). Oder die tatsächliche Konfiguration auf der Hardware weicht von der im CMS-Code festgelegten Konfiguration ab.
Daher überprüfen wir zusätzlich zur kontinuierlichen Testung die Produktionsumgebungen auf Konfigurationsabweichungen. Wir haben die einfachste Variante gewählt: den Code der CMS-Konfiguration im „Dry Run“-Modus auszuführen, d.h. ohne Änderungen zu implementieren, dafür aber mit Benachrichtigung über alle Abweichungen zwischen der geplanten und der tatsächlichen Konfiguration. Dies haben wir durch regelmäßige Ausführung aller Ansible-Playbooks mit der Option „—check“ auf den Produktionsservern realisiert. Für die Ausführung und Aktualität der Playbooks ist wie immer Ansible AWX verantwortlich (siehe Abb. 5):
Abb. 5. Überprüfungen auf Konfigurationsabweichungen in Ansible AWX.
Nach den Überprüfungen sendet AWX einen Bericht über die Abweichungen an die Administratoren. Diese untersuchen die problematische Konfiguration und beheben sie dann über die angepassten Playbooks. So halten wir die Konfiguration in der Produktionsumgebung aufrecht und das CMS bleibt stets aktuell und synchronisiert. Dies befreit uns von unangenehmen „Wundern“, wenn der CMS-Code auf „Live“-Servern angewendet wird.
Jetzt haben wir eine wichtige Testebene, die aus Ansible AWX/GitLab/Molecule besteht (Abb. 6).
Abb. 6. Testmanagement.
Schwierig? Das kann ich nicht leugnen. Aber ein solches Konfigurationsmanagementsystem ist eine umfassende Antwort auf viele Fragen zur Automatisierung der Serverkonfiguration. Jetzt hat der Einzelhändler eine klar definierte Konfiguration für Standardserver. Das CMS wird, im Gegensatz zu einem Ingenieur, die erforderlichen Einstellungen nicht vergessen, Benutzer erstellen und die Dutzenden oder sogar Hunderte erforderlichen Anpassungen durchführen.
In der Server- und Umgebungsconfiguration gibt es heute keine "geheimen Kenntnisse" mehr. Alle notwendigen Besonderheiten sind im Playbook dokumentiert. Kein Platz mehr für Kreativität und vage Anweisungen: „setze es wie ein normales Oracle auf, aber dort müssen ein paar sysctl-Einstellungen vorgenommen und Benutzer mit den erforderlichen UIDs hinzugefügt werden. Frag die Kollegen aus dem Betrieb, die wissen Bescheid.».
Die Möglichkeit, Abweichungen in den Konfigurationen zu erkennen und diese im Voraus zu beheben, sorgt für Ruhe. Ohne ein Konfigurationsmanagementsystem sieht das normalerweise anders aus. Probleme häufen sich, bis sie eines Tages in der Produktion "explodieren". Dann wird eine Nachbesprechung durchgeführt, die Konfigurationen werden überprüft und angepasst. Und der Zyklus beginnt von neuem.
Und natürlich haben wir den Start der Serverinbetriebnahme von mehreren Tagen auf Stunden beschleunigt.
An Silvester Nacht, als die Kinder fröhlich ihre Geschenke auspackten und die Erwachsenen Wünsche unter dem Glockenläuten formulierten, migrierten unsere Ingenieure das SAP-System auf neue Server. Selbst der Weihnachtsmann würde sagen, dass die besten Wunder gut vorbereitet sind.
P.S. Unser Team stößt häufig auf die Herausforderung, dass Kunden die Aufgaben des Konfigurationsmanagements so einfach wie möglich lösen möchten. Ideal wäre es, das Ganze wie durch Zauberei mit einem einzigen Werkzeug zu erledigen. Aber im echten Leben ist es komplexer (ja, wieder keine Silberkugeln geliefert): Es müssen ganze Prozesse mit den für das Team des Kunden geeigneten Werkzeugen erstellt werden.
Autor: Sergey Artemov, Abteilungsarchitekt «Informatiksysteme Jet»
Quelle: habr.com
