🥇Performance Orchester

Es wäre wohl nicht falsch zu sagen, dass die besten Menschen
Freude durch Leiden finden.
Ludwig van Beethoven

Ich bin Sergey und arbeite bei Yandex.Money im Team für Leistung Forschung. Ich möchte Ihnen den Beginn einer Geschichte erzählen, wie wir zur Orchestrierung gekommen sind – wie wir die Werkzeuge ausgewählt haben und was wir dabei berücksichtigt haben. All die Ereignisse im Artikel geschehen in Echtzeit, sodass Sie, liebe Leser, die Situation praktisch live verfolgen können.

Warum brauchen wir einen Maestro im Team?

Wer ist also ein Maestro? Vom französischen diriger – leiten, führen, dirigieren – ist im Musikbereich eine Person, die das Einstudieren und Aufführen von Ensemblemusik leitet. In unserem Fall nehmen Orchestrierungs- und Automatisierungssysteme diese Rolle ein.

Ihre Rolle unterscheidet sich nicht von der eines Maestros in der Musik – sie helfen dem Team, es zu leiten und zu organisieren.

In der Regel verfügt das Team über eine bestimmte Reihe von Ressourcen – nennen wir sie Server, auf denen sie ihre Projekte realisieren.

Der Ansatz zur Beschaffung und Nutzung dieser Server ist unterschiedlich. Hier sind einige Beispiele:

Das Team stellt eine Anfrage, beispielsweise an die Betriebsgruppe, um Ressourcen mit bestimmten Parametern bereitzustellen.
Die Betriebsgruppe stellt die erforderliche Menge an Cloud- oder Bare-Metal-Ressourcen bereit und verpflichtet sich, diese gemäß SLA in einem ordnungsgemäßen Zustand zu halten. Die Konfiguration erfolgt ebenfalls durch die Betriebsgruppe.
Das Team erhält lediglich Cloud- oder Bare-Metal-Ressourcen von der Betriebsgruppe; die Konfiguration erfolgt eigenständig.
Das Team „beschafft“ die Ressourcen selbst und verwaltet/konfiguriert diese vollständig unabhängig.

In unserem Team verwenden wir Server, die gewartet werden müssen – Betriebssysteme aktualisieren, neue Pakete installieren usw.

Wir haben sie in zwei Haupttypen unterteilt:

Tankgruppe,
Servicegruppe.

Die Tankgruppe besteht aus Hosts mit Yandex.Tank.

Die Servicegruppe umfasst alles, was mit der Wartung zu tun hat – verschiedene Dienstleistungen zur Unterstützung des Release-Zyklus, zur Generierung automatischer Berichte usw.

Zu einem bestimmten Zeitpunkt wurde die manuelle Verwaltung all dieser Aufgaben unpraktisch, und wir begannen über die Automatisierung des gesamten Prozesses nachzudenken, beginnend mit der Bereitstellung von Servern bis hin zur Entwicklung, Veröffentlichung und dem Start unseres internen Dienstes.

Warum ist ein Dirigent notwendig, auch wenn das Orchester selbst spielen kann?

Zunächst haben wir uns mit Ansible vertraut gemacht und begannen, unsere Bare-Metal-Server zu konfigurieren, um weniger abhängig von Systemadministratoren zu sein – davon profitieren alle: Wir erwerben neue Fähigkeiten und entlasten die Administratoren von einem Teil der Arbeit, die sie ohnehin schon genug haben. Wir streben nach Weiterentwicklung über unsere Spezialisierung hinaus und nach einer gewissen Autonomie des Teams, soweit es möglich ist.

Im Unternehmen sind die Arbeitsabläufe mit Ansible bereits seit geraumer Zeit etabliert und geregelt, daher konnten wir unsere Lösung problemlos in diesen Prozess integrieren.

Aktuell setzt sich die Bereitstellung von Hosts aus drei Ansible-Rollen zusammen:

Die erste Rolle installiert das Betriebssystem.
Die zweite Rolle wendet grundlegende Einstellungen für den Host an, zum Beispiel die LDAP-Authentifizierung.
Und die dritte Rolle installiert Yandex.Tank in einem Docker-Container und die dazugehörigen Abhängigkeiten.

Kommen wir zu den Diensten, die wir innerhalb des Teams verwenden.

Für unsere Projekte nutzen wir gleichermaßen Kotlin und Python sowie ein wenig Golang. Um die Entwicklung und Bereitstellung unserer Services zu vereinheitlichen, haben wir uns entschieden, sie in Docker-Container zu verpacken. Das bietet die Freiheit, die Programmiersprache zu wählen und regelt gleichzeitig ein einheitliches Format für die Bereitstellung unserer Anwendungen.

Eine kurze Anmerkung zu IPv6 in Docker

Einige der Services, mit denen wir interagieren, sind nur über IPv6 verfügbar, daher mussten wir herausfinden, wie man IPv6 für Container einrichtet.

Laut der offiziellen Dokumentation zu IPv6 auf der Docker-Website wird IPv6 aktiviert, indem Parameter zu daemon.json hinzugefügt werden:

{
  "ipv6": true,
  "fixed-cidr-v6": "2001:db8:1::/64"
}

Der Provider muss dabei ein IPv6-Subnetz bereitstellen, das Sie in fixed-cidr-v6 eintragen.
Wir haben uns jedoch für eine andere Lösung entschieden — IPv6 NAT, und das aus folgenden Gründen:

Aktuell kann Docker nicht nur mit IPv6 verwendet werden. Wenn jeder Container eine global routierbare Adresse hat, sind alle Ports (auch unpublizierte) für alle zugänglich, es sei denn, es gibt eine zusätzliche Filterung.
Userland-Proxy zum Veröffentlichen von Ports,
iptables nur für IPv4 IPv6 NAT bedeutet.

Docker-Container Docker-Container, der die Regeln in ip6tables selbst verwaltet und diese beim Hinzufügen eines neuen Containers anpasst.

Damit diese Lösung korrekt funktioniert, mussten noch einige weitere Manipulationen vorgenommen werden. Es ist unbedingt notwendig, ip6table_nat im System zu initialisieren. Das Vorhandensein des Moduls im System garantiert nicht, dass es beim Start geladen wird. Wir sind auf dieses Problem gestoßen, als wir folgende Fehlermeldung beim Starten eines Containers mit NAT auf einem neuen Host erhielten:

2019/01/22 14:59:54 running [/sbin/ip6tables -t filter -N DOCKER --wait]: exit status 3: modprobe: Verzeichnis '/lib/modules' kann nicht geändert werden: Datei oder Verzeichnis nicht gefunden
ip6tables v1.6.2: kann ip6tables-Tabelle `filter` nicht initialisieren: Tabelle existiert nicht (müssen Sie insmod verwenden?)

Das Problem wurde gelöst, indem wir in die Ansible-Rolle die Initialisierung über das Modul modprobe hinzugefügt und beim Systemstart mit lineinfile geladen haben:

- name: ip6table_nat-Modul hinzufügen
 modprobe:
   name: ip6table_nat
   state: present
- name: ip6table_nat im Boot hinzufügen
 lineinfile:
   path: /etc/modules
   line: 'ip6table_nat'

Übrigens gibt es auf Habr einen guten Artikel, Artikel, der kurz und prägnant die Vor- und Nachteile der verschiedenen Methoden zur Arbeit mit IPv6 in Docker beschreibt.

Aber zurück zu unserer eingangs gestellten Frage:
Warum ist ein Dirigent notwendig, auch wenn das Orchester selbst spielen kann?

Jetzt wissen alle, wie man in unserem Team spielt:

der Prozess des „Aufsetzens“ von Servern wurde erstellt,
Die Entwicklung und das Deployment von Services sind vereinheitlicht.

Hier stellt sich die berechtigte Frage: Wie können wir unsere Services in Docker-Containern effektiv und maximal automatisiert bereitstellen, aktualisieren und überwachen?

Obwohl jedes Mitglied des Orchesters seine Stimme kennt, kann es dennoch abgelenkt werden und vom ursprünglichen Konzept abweichen. Hier kommt die Erkenntnis ins Spiel, dass unser Orchester ohne einen Dirigenten nicht effektiv proben und harmonisch spielen wird. Der Dirigent ist verantwortlich für alle Ausführungsparameter und sorgt dafür, dass alles im gleichen Tempo und mit der richtigen Stimmung zusammengeführt wird.

Wie kann man mit minimalen Investitionen einen guten Dirigenten erhalten?

Das Thema Orchestrierung ist auf dem Markt bereits gut etabliert. Zunächst wollen wir jedoch über die Hilfsmittel sprechen, die dem Dirigenten helfen können.

Consul — ein System, das zwei Hauptfunktionen bereitstellt:

Service Discovery,
verteiltes Schlüssel-Wert-Speicher.

In unserem Orchester wird Consul für die Registrierung der Services und die Speicherung ihrer Konfigurationen verantwortlich sein. Es gibt zwei Optionen für die Registrierung:

Aktiv, was bedeutet, dass der Service sich selbst unter Verwendung der HTTP-API registriert;
Passiv – der Service muss manuell konfiguriert werden.

Vault ist ein Speicher, der die sichere Lagerung und Verwaltung von Geheimnissen – Passwörtern, Zertifikaten – standardisiert und vereinheitlicht.
Hier sind die Vorteile, die wir durch die Verwendung dieses Tools erhalten:

Ein zentrales System zur Erstellung und Speicherung von Geheimnissen sowie zur Verwaltung ihres Lebenszyklus über HTTP API.
Transit Secrets Engine – Verschlüsselung und Entschlüsselung von Daten, ohne sie zu speichern. Möglichkeit, Daten in verschlüsselter Form über ungesicherte Kommunikationskanäle zu übertragen.
Zugriffsrichtlinien, die bequem konfiguriert werden können.
Audit des Zugriffs auf Geheimnisse.
Die Möglichkeit, eine eigene CA (Zertifizierungsstelle) zu erstellen, um selbstsignierte Zertifikate innerhalb Ihrer Infrastruktur zu verwalten.

Unter Berücksichtigung all unserer Anforderungen kamen zwei Optionen als Orchestratoren in Frage – Kubernetes und Nomad.

Kubernetes

Wie viele Artikel und Bücher bereits darüber geschrieben wurden (hier ist ein Beispiel), ich werde es kurz halten – es ist ein universeller Kombiner, der praktisch alles kann. Der Preis dafür sind nicht immer einfache Einstellungen und die Wartung eines Clusters auf Kubernetes.

Nomad

Ein Tool von HashiCorp, einem Unternehmen, das für die oben erwähnten Produkte consul und vault bekannt ist.

Nomad hat sich für uns als einfacher in der Installation und Konfiguration erwiesen als Kubernetes. Eine Binärdatei funktioniert sowohl im Server- als auch im Client-Modus. Dabei übernimmt Nomad alle Aufgaben, die wir ihm übertragen möchten: Clusterverwaltung, ein schneller Scheduler und Unterstützung für mehrere Rechenzentren. Zudem erhalten wir durch die Verwendung von Consul und Vault eine engere Integration zur Orchestrierung unserer Dienste.

Momentan in Arbeit:

Wir haben die Server für die Bereitstellung von Consul vorbereitet,
die Clusterkonfiguration für Nomad wird in Consul eingefügt, damit Nomad automatisch bereitgestellt werden kann,
gleichzeitig installieren wir Vault zur Speicherung von Geheimnissen.

Die Frage an die Community – sollten wir für solche Aufgaben einen Dirigenten einführen oder läuft die Orchestrierung auch ohne gut? Erzählen Sie uns in den Kommentaren, was Sie darüber denken.

Abonnieren Sie unseren Blog und bleiben Sie in Verbindung – bald erzählen wir, was letztendlich herausgekommen ist und ob wir den Nomad-Cluster wie gewünscht konfiguriert haben.

Besuchen Sie unseren gemütlichen Telegram-Chat,wo Sie immer um Rat fragen, Kollegen helfen und einfach über Leistungstests und mehr plaudern können.

Quelle: habr.com