Vom Start-up zu Tausenden von Servern in Dutzenden von Rechenzentren. Wie wir Wachstum erzielten. Linux Infrastruktur

Wenn Ihre IT-Infrastruktur zu schnell wächst, stehen Sie früher oder später vor der Wahl: linear die Personalressourcen zur Unterstützung erhöhen oder mit der Automatisierung beginnen. Bis zu einem gewissen Punkt lebten wir im ersten Paradigma, und dann begann der lange Weg zu Infrastructure-as-Code.

Natürlich ist NSPK kein Startup, aber in den ersten Jahren seines Bestehens herrschte im Unternehmen eine solche Atmosphäre, und das waren sehr interessante Jahre. Ich heiße Kornjakow DmitriIch unterstütze die Infrastruktur seit über 10 Jahren. Linux mit hohen Anforderungen an die Barrierefreiheit. Ich bin im Januar 2016 dem NSPK-Team beigetreten und habe die Anfänge des Unternehmens leider nicht miterlebt, sondern bin zu einer Zeit großer Veränderungen dazugestoßen.

Unser Team liefert dem Unternehmen im Allgemeinen zwei Produkte. Das erste ist die Infrastruktur. E-Mail muss funktionieren, DNS muss zuverlässig arbeiten und Domänencontroller müssen die Verbindung zu Servern gewährleisten, die nicht ausfallen dürfen. Die IT-Landschaft des Unternehmens ist riesig! Es handelt sich um geschäftskritische Systeme, teilweise mit einer Verfügbarkeitsanforderung von 99,999 %. Das zweite Produkt sind die Server selbst, sowohl physische als auch virtuelle. Bestehende Server müssen überwacht und neue regelmäßig an Kunden in verschiedenen Abteilungen ausgeliefert werden. In diesem Artikel möchte ich mich darauf konzentrieren, wie wir die Infrastruktur entwickelt haben, die diesen Lebenszyklus unterstützt. Server.

Beginn einer Reise

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

All dies befand sich in drei Domänen, verteilt auf mehrere Rechenzentren. In einem Rechenzentrum gibt es Bürosysteme und Teststandorte, im Rest gibt es PROD.

Das Erstellen von Servern sah einmal so aus:

In der VM-Vorlage CentOS Minimal und das absolute Minimum, wie eine korrekte /etc/resolv.conf, der Rest kommt über Ansible.

CMDB – Excel.

Wenn der Server physisch ist, wurde das Betriebssystem mithilfe von Cobbler darauf installiert, anstatt die virtuelle Maschine zu kopieren. Die MAC-Adressen des Zielservers werden zur Cobbler-Konfiguration hinzugefügt, der Server erhält über DHCP eine IP-Adresse und dann das Betriebssystem hinzugefügt.

Zuerst haben wir sogar versucht, eine Art Konfigurationsmanagement in Cobbler durchzuführen. Im Laufe der Zeit führte dies jedoch zu Problemen bei der Portabilität von Konfigurationen sowohl auf andere Rechenzentren als auch beim Ansible-Code zur Vorbereitung von VMs.

Damals empfanden viele von uns Ansible als praktische Erweiterung von Bash und sparten nicht an Designs mit Shell und Sed. Insgesamt bashsible. Dies führte letztendlich dazu, dass es einfacher war, den Server zu löschen, das Playbook zu reparieren und erneut auszuführen, wenn das Playbook aus irgendeinem Grund nicht auf dem Server funktionierte. Es gab im Wesentlichen keine Versionierung von Skripten und keine Portabilität von Konfigurationen.

Wir wollten zum Beispiel einige Konfigurationen auf allen Servern ändern:

1. Wir ändern die Konfiguration auf bestehenden Servern im logischen Segment/Rechenzentrum. Manchmal nicht an einem Tag – Barrierefreiheitsauflagen und das Gesetz der großen Zahlen erlauben es nicht, alle Änderungen auf einmal anzuwenden. Und einige Änderungen sind möglicherweise destruktiv und erfordern einen Neustart – von Diensten bis hin zum Betriebssystem selbst.
2. Behebung in Ansible
3. Wir beheben es in Cobbler
4. Wiederholen Sie den Vorgang N-mal für jedes logische Segment/Rechenzentrum

Damit alle Änderungen reibungslos ablaufen konnten, mussten viele Faktoren berücksichtigt werden, und es kommt ständig zu Änderungen.

• Refactoring von Ansible-Code und Konfigurationsdateien
• Interne Best Practices ändern
• Änderungen basierend auf den Ergebnissen der Analyse von Vorfällen/Unfällen
• Sich ändernde Sicherheitsstandards, sowohl intern als auch extern. Beispielsweise wird PCI DSS jedes Jahr mit neuen Anforderungen aktualisiert

Infrastrukturwachstum und der Beginn der Reise

Die Zahl der Server/logischen Domänen/Rechenzentren wuchs und damit auch die Zahl der Fehler in Konfigurationen. Irgendwann kamen wir zu drei Richtungen, in die das Konfigurationsmanagement weiterentwickelt werden muss:

1. Automatisierung. Menschliche Fehler bei sich wiederholenden Vorgängen sollten so weit wie möglich vermieden werden.
2. Wiederholbarkeit. Es ist viel einfacher, die Infrastruktur zu verwalten, wenn sie vorhersehbar ist. Die Konfiguration der Server und Tools zu ihrer Vorbereitung sollte überall gleich sein. Dies ist auch für Produktteams wichtig – nach dem Test muss gewährleistet sein, dass die Anwendung in einer Produktionsumgebung landet, die ähnlich wie die Testumgebung konfiguriert ist.
3. Einfache und transparente Durchführung von Änderungen am Konfigurationsmanagement.

Es müssen noch ein paar Tools hinzugefügt werden.

Wir haben GitLab CE als unser Code-Repository ausgewählt, nicht zuletzt wegen seiner integrierten CI/CD-Module.

Tresor der Geheimnisse – Hashicorp Vault, inkl. für die tolle API.

Testkonfigurationen und ansible Rollen – Molecule+Testinfra. Tests gehen viel schneller, wenn Sie eine Verbindung zu Ansible Mitogen herstellen. Gleichzeitig haben wir begonnen, unsere eigene CMDB und unseren eigenen Orchestrator für die automatische Bereitstellung zu schreiben (im Bild oben Cobbler), aber das ist eine ganz andere Geschichte, die mein Kollege und Hauptentwickler dieser Systeme in Zukunft erzählen wird.

Unsere Wahl:

Molekül + Testinfra
Ansible + Tower + AWX
World of Servers + DITNET (Eigenentwicklung)
Cobbler
Gitlab + GitLab-Läufer
Hashicorp-Tresor

Übrigens zu ansiblen Rollen. Zuerst gab es nur eine, aber nach mehreren Umgestaltungen waren es 17. Ich empfehle dringend, den Monolithen in idempotente Rollen aufzuteilen, die dann separat gestartet werden können; zusätzlich können Sie Tags hinzufügen. Wir haben die Rollen nach Funktionalität aufgeteilt – Netzwerk, Protokollierung, Pakete, Hardware, Molekül usw. Im Allgemeinen folgten wir der unten aufgeführten Strategie. Ich behaupte nicht, dass dies die einzige Wahrheit ist, aber es hat bei uns funktioniert.

• Server vom „goldenen Image“ zu kopieren ist böse!Der Hauptnachteil besteht darin, dass Sie nicht genau wissen, in welchem ​​Zustand sich die Bilder gerade befinden, und dass alle Änderungen für alle Bilder in allen Virtualisierungsfarmen gelten.
• Verwenden Sie auf ein Minimum Standardkonfigurationsdateien und vereinbaren Sie mit anderen Abteilungen, dass Sie für die Hauptsystemdateien verantwortlich sindzum Beispiel:
  1. Lassen Sie /etc/sysctl.conf leer, die Einstellungen sollten sich nur in /etc/sysctl.d/ befinden. Ihr Standardwert in einer Datei, benutzerdefiniert für die Anwendung in einer anderen.
  2. Verwenden Sie Override-Dateien, um Systemd-Einheiten zu bearbeiten.
• Erstellen Sie Vorlagen für alle Konfigurationen und beziehen Sie sie vollständig ein; wenn möglich, kein Sed oder dessen Analoga in Playbooks
• Refactoring des Codes des Konfigurationsmanagementsystems:
  1. Teilen Sie Aufgaben in logische Einheiten auf und schreiben Sie den Monolithen in Rollen um
  2. Verwenden Sie Linters! Ansible-lint, yaml-lint usw
  3. Ändern Sie Ihren Ansatz! Kein Bashable. Es ist notwendig, den Zustand des Systems zu beschreiben
• Für alle Ansible-Rollen müssen Sie einmal täglich Tests in Molekülen schreiben und Berichte erstellen.
• In unserem Fall wurden nach der Vorbereitung der Tests (von denen es mehr als 100 gibt) etwa 70000 Fehler gefunden. Es dauerte mehrere Monate, das Problem zu beheben.

Unsere Umsetzung

Die Ansible-Rollen waren also fertig, wurden mit Vorlagen erstellt und von Linters überprüft. Und sogar Idioten werden überall großgezogen. Die Frage der zuverlässigen Codebereitstellung an verschiedene Segmente blieb jedoch offen. Wir haben uns für die Synchronisierung mit Skripten entschieden. Sieht so aus:

Nachdem die Änderung eintrifft, wird CI gestartet, ein Testserver erstellt, Rollen ausgerollt und vom Molekül getestet. Wenn alles in Ordnung ist, geht der Code an den prod-Zweig. Wir wenden jedoch keinen neuen Code auf vorhandene Server in der Maschine an. Dabei handelt es sich um eine Art Stopper, der für eine hohe Verfügbarkeit unserer Systeme notwendig ist. Und wenn die Infrastruktur riesig wird, kommt das Gesetz der großen Zahlen ins Spiel – selbst wenn man sicher ist, dass die Veränderung harmlos ist, kann sie schlimme Folgen haben.

Es gibt auch viele Möglichkeiten, Server zu erstellen. Am Ende haben wir uns für benutzerdefinierte Python-Skripte entschieden. Und für CI ansible:

- name: create1.yml - Create a VM from a template
  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 ist es, was wir erreicht haben, das System lebt und entwickelt sich weiter.

• 17 Ansible-Rollen zum Einrichten des Servers. Jede der Rollen ist darauf ausgelegt, eine separate logische Aufgabe zu lösen (Protokollierung, Auditierung, Benutzerautorisierung, Überwachung usw.).
• Rollentest. Molekül + TestInfra.
• Eigene Entwicklung: CMDB + Orchestrator.
• Die Servererstellungszeit beträgt ca. 30 Minuten, ist automatisiert und praktisch unabhängig von der Aufgabenwarteschlange.
• Der gleiche Zustand/die gleiche Benennung der Infrastruktur in allen Segmenten – Playbooks, Repositories, Virtualisierungselemente.
• Tägliche Überprüfung des Serverstatus mit Erstellung von Berichten über Abweichungen vom Standard.

Ich hoffe, dass meine Geschichte denjenigen nützlich sein wird, die am Anfang ihrer Reise stehen. Welchen Automatisierungsstack verwenden Sie?

Source: habr.com