🥇Von "Startup" zu Tausenden von Servern in einem Dutzend Rechenzentren. Wie wir dem Wachstum der Linux-Infrastruktur nachjagten

Wenn Ihre IT-Infrastruktur zu schnell wächst, stehen Sie irgendwann vor der Wahl – entweder die personellen Ressourcen zur Unterstützung linear erhöhen oder mit der Automatisierung beginnen. Bis zu einem bestimmten Punkt lebten wir im ersten Paradigma, und dann begann der lange Weg zu Infrastructure-as-Code.

Natürlich ist NSPK kein Startup, aber eine solche Atmosphäre herrschte in den ersten Jahren des Unternehmens, und es waren sehr interessante Jahre. Mein Name ist Dmitri Koryakov, seit über 10 Jahren unterstütze ich eine Linux-Infrastruktur mit hohen Verfügbarkeitsanforderungen. Ich bin im Januar 2016 zum NSPK-Team gestoßen und habe leider nicht den Anfang des Unternehmens miterlebt, kam aber in einer Phase großer Veränderungen.

Insgesamt kann man sagen, dass unser Team zwei Produkte für das Unternehmen liefert. Das erste ist die Infrastruktur. Die E-Mail muss funktionieren, DNS muss arbeiten und die Domänencontroller müssen Ihnen den Zugang zu den Servern ermöglichen, die nicht ausfallen dürfen. Die IT-Landschaft des Unternehmens ist riesig! Es sind business- und mission-critical Systeme, deren Verfügbarkeitsanforderungen teilweise bei 99,999 liegen. Das zweite Produkt sind die Server selbst, sowohl physische als auch virtuelle. Die bestehenden müssen überwacht werden, während neue regelmäßig an Kunden aus verschiedenen Abteilungen geliefert werden. In diesem Artikel möchte ich den Fokus darauf legen, wie wir die Infrastruktur entwickelt haben, die den Lebenszyklus verantwortet Server.

Der Beginn des Weges

Zu Beginn unseres Weges sah unser Technologie-Stack so aus:
Betriebssystem CentOS 7
Domänencontroller FreeIPA
Automatisierung – Ansible (+Tower), Cobbler

All dies war in 3 Domänen verteilt, die über mehrere Rechenzentren verteilt waren. In einem Rechenzentrum – Büro- und Testsysteme, in den anderen PROD.

Die Erstellung von Servern sah irgendwann so aus:

Im VM-Vorlage CentOS minimal und das notwendigste wie ein korrektes /etc/resolv.conf, der Rest kommt über Ansible.

CMDB – Excel.

Wenn der Server physisch ist, wurde statt der Kopie einer virtuellen Maschine das Betriebssystem mit Cobbler installiert – die MAC-Adressen des Zielservers werden zur Cobbler-Konfiguration hinzugefügt, der Server erhält über DHCP eine IP-Adresse, und dann wird das Betriebssystem installiert.

Zunächst haben wir sogar versucht, eine Art Konfigurationsmanagement in Cobbler zu implementieren. Mit der Zeit brachte das jedoch Probleme bei der Portabilität der Konfigurationen sowohl zu anderen Rechenzentren als auch zum Ansible-Code zur Vorbereitung von VMs.

Zu dieser Zeit betrachteten viele von uns Ansible als praktische Erweiterung von Bash und scheuten sich nicht, Konstruktionen mit Shell und sed zu verwenden. Im Grunde war es Bashsible. Dies führte letztendlich dazu, dass es einfacher war, einen Server zu löschen, das Playbook zu korrigieren und es erneut auszuführen, wenn das Playbook aus irgendeinem Grund nicht auf dem Server funktionierte. Es gab im Grunde kein Versionsmanagement für Skripte, auch nicht für die Portabilität von Konfigurationen.

Zum Beispiel wollten wir eine bestimmte Konfiguration auf allen Servern ändern:

Wir ändern die Konfiguration auf bestehenden Servern im logischen Segment/Rechenzentrum. Manchmal nicht an einem Tag – die Anforderungen an die Verfügbarkeit und das Gesetz der großen Zahlen lassen nicht zu, dass alle Änderungen auf einmal angewendet werden. Einige Änderungen sind zudem potenziell destruktiv und erfordern einen Neustart von etwas, sei es von Diensten bis hin zum Betriebssystem selbst.
Korrektur in Ansible
Korrektur in Cobbler
Wiederholen Sie N-mal für jedes logische Segment/Rechenzentrum

Um sicherzustellen, dass alle Änderungen reibungslos verlaufen, mussten viele Faktoren berücksichtigt werden, und Änderungen sind ständig im Gange.

Refactoring des Ansible-Codes, der Konfigurationsdateien
Änderung interner Best Practices
Änderungen aufgrund der Analyse von Vorfällen/Störungen
Änderung der Sicherheitsstandards, sowohl intern als auch extern. Beispielsweise werden die Anforderungen des PCI DSS jedes Jahr um neue Anforderungen ergänzt.

Wachstum der Infrastruktur und Beginn des Weges

Anzahl der Server/logischen Domänen/Rechenzentren wuchs, ebenso die Anzahl der Fehler in den Konfigurationen. Irgendwann kamen wir auf drei Richtungen, in die das Configuration Management entwickelt werden musste:

Automatisierung. Wo immer möglich, sollte der menschliche Faktor in wiederkehrenden Operationen vermieden werden.
Wiederholbarkeit. Es ist viel einfacher, Infrastruktur zu verwalten, wenn sie vorhersehbar ist. Die Konfiguration der Server und der Werkzeuge zu ihrer Vorbereitung sollte überall identisch sein. Dies ist auch für die Produktteams wichtig – die Anwendung sollte garantiert nach dem Testen in die Produktionsumgebung gelangen, die ähnlich wie die Testumgebung konfiguriert ist.
Einfachheit und Transparenz bei der Umsetzung von Änderungen im Configuration Management.

Es bleibt, ein paar Werkzeuge hinzuzufügen.

Als Code-Repository haben wir GitLab CE gewählt, nicht zuletzt wegen der integrierten CI/CD-Module.

Das Geheimnis-Repository – Hashicorp Vault, auch wegen seiner ausgezeichneten API.

Die Testkonfigurationen und Ansible-Rollen – Molecule+Testinfra. Die Tests laufen viel schneller, wenn Sie Ansible mit Mitogen verbinden. Parallel dazu haben wir begonnen, unsere eigene CMDB und einen Orchestrator für automatische Deployments (auf dem Bild über Cobbler) zu schreiben, aber das ist eine ganz andere Geschichte, über die mein Kollege und Hauptentwickler dieser Systeme in Zukunft berichten wird.

Unsere Auswahl:

Molecule + Testinfra
Ansible + Tower + AWX
Welt der Server + DITNET (Eigene Entwicklung)
Cobbler
Gitlab + GitLab Runner
Hashicorp Vault

Übrigens zu den Ansible-Rollen. Zunächst gab es nur eine, nach mehreren Refactorings sind es 17 geworden. Ich empfehle dringend, das Monolithische in idempotente Rollen zu unterteilen, die man dann separat ausführen kann; zusätzlich können Tags hinzugefügt werden. Wir haben die Rollen nach Funktionalität unterteilt – Netzwerk, Logging, Pakete, Hardware, Molecule usw. Insgesamt haben wir uns an die folgende Strategie gehalten. Ich behaupte nicht, dass dies die einzige Wahrheit ist, aber es hat bei uns funktioniert.

Das Kopieren von Servern aus dem 'Golden Image' – ein Übel!Zu den Hauptnachteilen – Sie wissen genau nicht, in welchem Zustand sich die Images jetzt befinden und dass alle Änderungen in alle Images für alle Virtualisierungsfarmen kommen werden.
Verwenden Sie Standardkonfigurationsdateien nur im Minimum und einigen Sie sich mit anderen Abteilungen darauf, dass Sie für die wichtigsten Systemdateien verantwortlich sind., zum Beispiel:
1. Halten Sie /etc/sysctl.conf leer, die Einstellungen sollten nur in /etc/sysctl.d/ liegen. Ihr Standard in eine Datei, das Custom für die Anwendung in eine andere.
2. Verwenden Sie Override-Dateien zur Bearbeitung von systemd-Einheiten.
Template alle Konfigurationen und legen Sie sie ganz bei, wenn möglich, keine sed und ähnliche Befehle in den Playbooks.
Refaktorisierung des Codes des Konfigurationsmanagementsystems:
1. Teilen Sie Aufgaben in logische Einheiten auf und schreiben Sie das Monolith in Rollen um.
2. Verwenden Sie Linter! Ansible-lint, yaml-lint usw.
3. Ändern Sie den Ansatz! Kein Bashsible. Der Systemzustand muss beschrieben werden.
Zu allen Ansible-Rollen müssen Tests in Molecule geschrieben werden und einmal täglich Berichte generiert werden.
In unserem Fall wurden nach der Vorbereitung von Tests (von denen es mehr als 100 gab) etwa 70000 Fehler gefunden. Die Behebung hat mehrere Monate gedauert.

Unsere Implementierung

So, die Ansible-Rollen waren bereit, templatisiert und von Linter überprüft. Und sogar die Gits sind überall angehoben. Aber die Frage der zuverlässigen Bereitstellung von Code in verschiedene Segmente blieb offen. Wir haben beschlossen, mithilfe von Skripten zu synchronisieren. Es sieht so aus:

Nachdem die Änderung eingetroffen ist, wird CI gestartet, ein Testserver erstellt, Rollen angewendet und mit Molecule getestet. Wenn alles in Ordnung ist, geht der Code in den Produktionsbranch. Aber wir wenden den neuen Code nicht automatisch auf bestehende Server an. Das ist eine Art Stopper, der für die hohe Verfügbarkeit unserer Systeme notwendig ist. Und wenn die Infrastruktur riesig wird, kommt ein weiteres Gesetz ins Spiel – selbst wenn Sie sicher sind, dass die Änderung harmlos ist, kann sie zu unglücklichen Folgen führen.

Es gibt viele Möglichkeiten zur Erstellung von Servern. Letztendlich haben wir uns für benutzerdefinierte Skripte in Python entschieden. Und für CI Ansible:

- name: create1.yml - Erstelle eine VM aus einer Vorlage
  vmware_guest:
    hostname: "{{datacenter}}".domain.ru
    username: "{{ username_vc }}"
    password: "{{ password_vc }}"
    validate_certs: no
    cluster: "{{cluster}}"
    datacenter: "{{datacenter}}"
    name: "{{ name }}"
    state: poweredon
    folder: "\/{{folder}}"
    template: "{{template}}"
    customization:
      hostname: "{{ name }}"
      domain: domain.ru
      dns_servers:
        - "{{ ipa1_dns }}"
        - "{{ ipa2_dns }}"
    networks:
      - name: "{{ network }}"
        type: static
        ip: "{{ip}}"
        netmask: "{{netmask}}"
        gateway: "{{gateway}}"
        wake_on_lan: True
        start_connected: True
        allow_guest_control: True
    wait_for_ip_address: yes
    disk:
      - size_gb: 1
        type: thin
        datastore: "{{datastore}}"
      - size_gb: 20
        type: thin
        datastore: "{{datastore}}"

Das haben wir erreicht, das System lebt und entwickelt sich weiter.

17 Ansible-Rollen zur Serverkonfiguration. Jede Rolle dient der Lösung einer spezifischen logischen Aufgabe (Protokollierung, Auditing, Benutzerauthentifizierung, Monitoring usw.).
Testen der Rollen. Molecule + TestInfra.
Eigene Entwicklung: CMDB + Orchestrator.
Die Servererstellungszeit beträgt etwa 30 Minuten, ist automatisiert und hängt kaum von der Aufgabenwarteschlange ab.
Gleicher Zustand/Namen der Infrastruktur in allen Segmenten – Playbooks, Repositories, Virtualisierungselemente.
Tägliche Überprüfung des Serverzustands mit Erstellung von Berichten über Abweichungen vom Standard.

Ich hoffe, meine Erzählung ist für diejenigen nützlich, die am Anfang stehen. Welchen Automatisierungs-Stack verwenden Sie?

Quelle: habr.com

Von einem „Startup“ zu tausenden Servern in einem Dutzend Rechenzentren. Wie wir das Wachstum der Linux-Infrastruktur vorangetrieben haben