Das Orchester des Performances

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

Ich bin Sergey, arbeite bei Yandex.Money im Team für Leistungsforschung. Ich möchte Ihnen den Anfang einer Geschichte über unseren Weg zur Nutzung von Orchestrierung erzählen – wie wir die Werkzeuge ausgewählt haben und was dabei zu berücksichtigen war. Alle Ereignisse in dem Artikel geschehen in Echtzeit, daher können Sie, liebe Leser, die Entwicklung der Situation fast live verfolgen.

Warum brauchen wir einen Dirigenten im Team?

Was ist ein Dirigent? Von frz. diriger – leiten, anweisen, führen – in der Musikwelt ist es eine Person, die das Einstudieren und Aufführen von Ensemblemusik leitet. In unserem Fall werden diese Aufgaben von Orchestrierungs- und Automatisierungssystemen übernommen.

Ihre Rolle unterscheidet sich nicht von der Rolle eines Dirigenten in der Musik – sie sind notwendig, um das Team zu unterstützen, zu leiten und sein Spiel zu organisieren.

In der Regel verfügt das Team über einen bestimmten Satz an Kapazitäten – nennen wir sie Server, auf denen sie ihre Projekte umsetzen.

Der Ansatz zur Beschaffung und Nutzung dieser Server ist vielfältig. Hier sind einige Beispiele:

• Das Team stellt eine Anfrage, beispielsweise an die Betriebsgruppe, um ihnen Ressourcen mit bestimmten Parametern bereitzustellen.
• Die Betriebsgruppe stellt ihnen die erforderliche Menge zur Verfügung – Cloud oder Bare Metal („nackte Hardware“) – und verpflichtet sich, diese gemäß SLA in gutem Zustand zu halten. Die Einrichtung erfolgt ebenfalls durch die Betriebsgruppe.
• Das Team erhält nur Cloud- oder Bare-Metal-Ressourcen von der Betriebsgruppe, die Einrichtung erfolgt selbst durch das Team.
• Das Team "erwirbt" die Ressourcen selbst und betreut/einrichtet diese vollständig eigenständig.

In unserem Team werden Server genutzt, die in Stand gehalten 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 Wartung zu tun hat – verschiedene Dienste zur Unterstützung des Release-Zyklus, zur Erstellung automatischer Berichte usw.

Eines Tages wurde es unpraktisch, all dies manuell zu verwalten, und wir dachten über die Automatisierung des gesamten Prozesses nach, angefangen bei der "Befüllung" der Server bis hin zur Entwicklung, Bereitstellung und dem Start unseres internen Dienstes.

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

Zunächst haben wir Ansible erlernt und begonnen, unsere Bare-Metal-Server zu "befüllen", um weniger abhängig von Systemadministratoren zu sein – alle profitieren davon, wir erwerben neue Fähigkeiten und entlasten die Administratoren von einem Teil der Arbeit, die sie auch ohne uns immer genug haben. Wir streben danach, uns außerhalb unserer Spezialisierung weiterzuentwickeln und die Autonomie des Teams so weit wie möglich zu fördern.

In der Firma ist die Arbeit mit Ansible bereits seit längerer Zeit eingerichtet und reglementiert, daher haben wir unsere Lösung problemlos in diesen Prozess integriert.

Derzeit besteht die Befüllung der Hosts aus drei Ansible-Rollen:

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

Kommen wir zu den Diensten, die wir im Team verwenden.

Für unsere Aufgaben nutzen wir gleichermaßen Kotlin und Python, und auch ein wenig Golang. Um die Entwicklung und Bereitstellung unserer Dienste zu vereinheitlichen, haben wir beschlossen, sie in Docker-Container zu verpacken. Das ermöglicht uns die Freiheit, die Programmiersprache zu wählen und reguliert gleichzeitig ein einheitliches Format für die Lieferung unserer Anwendungen.

Eine kleine Anmerkung zu IPv6 in Docker

Ein Teil der Dienste, mit denen wir interagieren, ist nur über IPv6 erreichbar, deshalb mussten wir herausfinden, wie man IPv6 für Container einrichtet.

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

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

Dabei muss der Anbieter ein IPv6-Subnetz bereitstellen, das Sie in fixed-cidr-v6 eintragen.
Wir haben jedoch eine andere Variante gewählt – IPv6 NAT, und das aus folgenden Gründen:

• Derzeit kann Docker nicht nur mit IPv6 verwendet werden. Das Vorhandensein einer global routierbaren Adresse in jedem Container bedeutet, dass alle Ports (auch nicht veröffentlichte) für alle zugänglich sind, es sei denn, eine zusätzliche Filterung erfolgt.
• Userland-Proxy zur Veröffentlichung von Ports,
• iptables nur für IPv4 IPv6 NAT ist.

Docker-Container docker-container, der selbst die Regeln in ip6tables verwaltet und sie beim Hinzufügen eines neuen Containers ändert.

Um diese Lösung korrekt zum Laufen zu bringen, waren einige weitere Manipulationen erforderlich. 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 beim Starten eines Containers mit NAT auf einem neuen Host folgenden Fehler erhielten:

2019/01/22 14:59:54 ausführen [/sbin/ip6tables -t filter -N DOCKER --wait]: Exit-Status 3: modprobe: Kann das Verzeichnis nicht ändern zu '/lib/modules': Datei oder Verzeichnis nicht gefunden
ip6tables v1.6.2: kann die ip6tables-Tabelle `filter` nicht initialisieren: Tabelle existiert nicht (müssen Sie insmod verwenden?)

Das Problem wurde behoben, nachdem wir die Initialisierung in die Ansible-Rolle mit dem Modifikationsmodul modprobe und dem Laden beim OS-Start mit lineinfile hinzugefügt hatten:

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

Übrigens gibt es auf Habr eine gute Artikel, die kurz und klar die Vor- und Nachteile der verschiedenen Methoden für die Arbeit mit ipv6 in Docker beschreibt.

Aber lassen Sie uns zu unserer eingangs gestellten Frage zurückkehren:
Warum ist ein Dirigent notwendig, selbst wenn das Orchester selbst spielen kann?

Jetzt wissen alle, wie man in unserem Team spielt:

• der Prozess des ‚Einspielens‘ von Servern wurde geschaffen,
• die Entwicklung und das Deployment von Diensten sind vereinheitlicht.

Es stellt sich die berechtigte Frage — wie können wir unsere Dienste in Docker-Containern effektiv und maximal automatisiert deployen, aktualisieren und überwachen?

Obwohl jeder Teilnehmer des Orchesters seine Stimme kennt, kann er sich irren und von der ursprünglichen Idee abweichen. Hier kommen wir zu dem Punkt, dass unser Orchester ohne Dirigenten nicht effektiv proben und harmonisch spielen kann. Der Dirigent ist verantwortlich für alle Parameter der Ausführung, dafür, dass alles in einem einheitlichen Tempo und Stimmung vereint ist.

Wie erhält man mit minimalen Investitionen einen guten Dirigenten?

Das Thema Orchestrierung ist auf dem Markt ziemlich gut entwickelt. Aber zuerst sprechen wir über die Hilfsmittel, die dem Dirigenten helfen können.

Consul — ein System, das zwei Hauptfunktionen bietet:

• Dienstentdeckung (service discovery),
• verteiltes Schlüssel-Wert-Speicher.

In unserem Orchester wird Consul für die Registrierung der Dienste und die Speicherung ihrer Konfigurationen zuständig sein. Es gibt zwei Varianten der Registrierung:

• Aktiv — das ist, wenn sich der Dienst selbst mit HTTP API registriert;
• Passiv — der Dienst muss manuell eingetragen werden.

Vault ist ein Repository, das die sichere Speicherung und Verwaltung von Geheimnissen – Passwörter, Zertifikate – standardisiert und vereinfacht.
Hier sind die Vorteile, die wir durch die Verwendung dieses Tools erhalten:

• Zentrales Repository zur Erstellung und Speicherung von Geheimnissen, Verwaltung ihres Lebenszyklus über eine HTTP-API.
• Transit Secrets Engine – Verschlüsselung und Entschlüsselung von Daten ohne deren Speicherung. Möglichkeit zur Übertragung von Daten in verschlüsselter Form über ungesicherte Kommunikationskanäle.
• Zugriffsrichtlinien, die einfach konfiguriert werden können.
• Zugriffsprotokollierung für Geheimnisse.
• Möglichkeit zur Erstellung einer eigenen CA (Zertifizierungsstelle) zur Verwaltung von selbstsignierten Zertifikaten innerhalb der eigenen Infrastruktur.

Angesichts aller unserer Anforderungen kamen zwei Optionen für die Rolle des Orchestrators in Betracht – Kubernetes und Nomad.

Kubernetes

Wie viele Artikel und Bücher bereits darüber geschrieben wurden (hier so eine, beispielsweise), wie viele Präsentationen gehalten wurden, möchte ich kurz zusammenfassen – es ist eine universelle Lösung, die nahezu alles kann. Der Preis dafür sind nicht immer einfache Einstellungen und die Verwaltung des Clusters unter Kubernetes.

Nomad

Tool von HashiCorp, einem Unternehmen, das für die oben genannten Produkte Consul und Vault bekannt ist.

Nomad erschien uns einfacher in der Installation und Konfiguration als Kubernetes. Eine einzelne Binärdatei funktioniert sowohl im Server- als auch im Clientmodus. Dabei deckt Nomad die gesamte Liste von Aufgaben ab, die wir möchten, dass es löst: Clusterverwaltung, schneller Scheduler, Unterstützung für mehrere Datenzentren. Außerdem erhalten wir durch die Verwendung von Consul und Vault eine engere Integration zur Orchestrierung unserer Dienste.

Was derzeit in Arbeit ist:

• Server für das Deployment von Consul vorbereitet,
• In Consul wird die Konfiguration des Nomad-Clusters eingetragen, mit der Nomad automatisch bereitgestellt werden soll,
• parallel werden wir Vault für die Speicherung von Geheimnissen installieren.

Die Frage an den Saal – sollte man für solche Aufgaben einen Orchestrator einsetzen oder funktioniert die Orchestrierung auch ohne ihn gut? Teilen Sie uns in den Kommentaren mit, was Sie darüber denken.

Abonnieren Sie unseren Blog und bleiben Sie in Kontakt – bald erzählen wir, was letztendlich herausgekommen ist und ob wir den Nomad-Cluster so eingerichtet haben, wie wir es wollten.

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