Ich möchte eine Geschichte darüber erzählen, wie die Anwendung in Openshift gestartet wurde. Auch im Verlauf des Spiels betrachten wir Dienstprogramme zum Verwalten der Anwendung in Openshift. Dies ist eine Abschrift der Leistung bei kubernetes SPB Meetup # 3 ..
Zweck
Normalerweise werden Clients auf separaten Servern bereitgestellt, aber hier kam die Aufgabe, die Möglichkeit zu testen, in OpenShift ausgeführt zu werden und den Rake zu sammeln.
Zuerst müssen Sie über unsere Anwendung sprechen. Ein Projekt mit einer reichen Geschichte. Wird in großen Organisationen verwendet und wahrscheinlich hat sich jeder von Ihnen indirekt überschnitten. Die Anwendung unterstützt viele Datenbanken, Integrationen usw. usw.
Voraussetzungen
Die Anwendung sollte in völlig anderen Umgebungen funktionieren. Daher ist unsere Installationsdokumentation sehr umfangreich. Aber wenn Sie auf Sie herabblicken, ist nichts kompliziert:
- Datenbankschema anwenden.
- Konfigurieren Sie den Anwendungsserver.
- Installieren Sie eine Lizenz.
- Passen Sie die Anwendung und die Integration mit externen Systemen an.
Aber die Welt ist grausam, wir hatten eine Reihe von Einschränkungen:
- Die Anwendung kann nur speziell auf Jenkins erstellt werden, der mit dem Signieren beschäftigt ist. Und nur dort.
- Der Openshift-Client hat keinen Zugriff auf die Entwicklungsumgebung.
- Aus einer Reihe von ideologischen Gründen war es nicht möglich, vorhandene Docker-Images für die Entwicklung wiederzuverwenden.
- Wir haben ansible Playbooks, um die Anwendung auf den Servern zu installieren und zu konfigurieren.
Ansible-Container-Demo
Ansible Container ist eine Open Source-Software, die die Montage, Bereitstellung und Prozesssteuerung von Containern automatisieren soll. Wie Sie vielleicht aus dem Namen erraten. Ansible wird zum Erstellen von Containern verwendet. Wir haben bereits Ansible-Rollen für die Installation und Bereitstellung von Anwendungen auf Servern geschrieben und beschlossen, das Rad nicht neu zu erfinden und wiederzuverwenden. Es wäre nicht nur das perfekte Werkzeug, sondern die schnelle Wiederverwendung vorhandener Rollen war ein entscheidender Faktor für die Demo.
Um eine Demo zu erstellen, haben wir im Großen und Ganzen die vorhandenen Rollen übernommen, die alles und jedes konfigurieren, und einen "monolithischen Container" erstellt. Es gab keine besonderen Probleme beim Sammeln des Behälters Openshift hat einige großartige Empfehlungen , aber ich werde separat erwähnen:
- Die Rollen mussten finalisiert werden. wir benutzen systemd.
- Aus Sicherheitsgründen ist es standardmäßig verboten, Syscall in OpenShift zu verwenden. Infolgedessen wird es Nuancen mit Chroot, Sudo geben. Hallo CVE-2019-5736 .
- Aus Sicherheitsgründen wird der Container unter einem Benutzer mit einer zufälligen ID gestartet. Dies ist ebenfalls ein benutzerdefiniertes Verhalten.
Die Hauptidee an diesem Punkt ist, dass wir eine Demo sooo schnell gemacht haben.
Demo mit mehreren Containern
Der Demo-Container hat seine Aufgabe erfüllt und wir haben ihn in separate Komponenten zerlegt:
- Unsere Bewerbung.
- Datenbank.
- Externe Dienste usw ...
Das erste, was Ihnen begegnet ist, wie man die Datenbank initialisiert. Es ist klar, dass wir Migrationen verwenden, aber wann und wie werden sie angewendet? Hier lohnt es sich, einen Link zu einem wunderbaren Artikel zu geben, der das Leben des Geräts POD: PODs beschreibt . Im Großen und Ganzen gibt es mehrere Ansätze:
- Verwenden Sie den Init-Container
- Verwenden Sie Orchestrierungssysteme, die bei Bedarf die Reihenfolge der Bereitstellung von Diensten und die Rollmigration bestimmen.
Wir haben uns entschlossen, dem Init-Container-Pfad zu folgen. Das heißt, Im POD unserer Anwendung wird vor dem Start unserer Anwendung ein Container gestartet, der Migrationen rollt. Aber wie konfiguriert man die Anwendung selbst und externe Integrationen?
Initialisieren Sie die Anwendung
Wie bereits erwähnt, kann und sollte unsere Anwendung in völlig unterschiedlichen Umgebungen mit unterschiedlichen Datenbanken und Integrationen arbeiten. Wieder ist die Frage, wie man alles einrichtet?
- Verwenden Sie Orchestrierungssysteme, die die Reihenfolge bestimmen, in der Dienste bereitgestellt werden, und wenden Sie die Konfiguration nach dem Start der Anwendung an.
- Übergeben Sie die Umgebungsvariablen an den zu konfigurierenden Container.
- Starthaken verwenden.
- Erstellen Sie einen separaten Container, der die Konfiguration enthält, und wenden Sie ihn auf die Anwendung an. Grob analoge Migration für die Datenbank.
Wir haben den letzten Ansatz gewählt, weil Damit können Sie die Konfiguration reproduzierbar und autark machen. Aus irgendeinem Grund haben wir diesen Container zunächst in einem separaten Replikationscontroller mit dem Faktor 1 erstellt.
Ok, lies die Dokumentation noch einmal.
Ein Pod (wie in einem Pod aus Walen oder Erbsen) ist eine Gruppe von einem oder mehreren Containern (z. B. Docker-Containern) mit gemeinsam genutztem Speicher / Netzwerk und einer Spezifikation für die Ausführung der Container.
POD ist eine Gruppe von Containern. Infolgedessen bestand unser U-Boot aus 3 Containern
- Init Container zum Initialisieren eines PostgreSQL.
- Container mit App.
- Container mit Anwendungskonfiguration.
Toolkit
Wir haben ein Diagramm erhalten, wie die bereitgestellte Anwendung aussieht. Jetzt ist es an der Zeit, die Werkzeuge in der Natur zu diskutieren. Es gibt vieles, was bereits fertig ist. Ich werde einige der folgenden Listen betrachten und subjektive Schlussfolgerungen ziehen.
OpenShift-Vorlagen
OpenShift-Vorlagen
Vorteile:
- Native und sie haben ausgezeichnete Dokumentation.
Nachteile:
- Eine weitere Template-Engine.
- Lange und schreckliche YAML-Dateien.
- Wenn Sie Abhängigkeiten zwischen Diensten und deren Startreihenfolge haben, ist dies schwierig.
Skripte und Vorlage
Vorteile:
- Sie können großartige Tools und die gesamte Leistung von OOP verwenden.
Nachteile:
- Krücken, die unterstützen. Und nicht nur für dich.
Terraform k8s Anbieter
Vorteile:
- Sie müssen sich keine Gedanken über die Priorität der Erstellung von Infrastrukturelementen machen.
- Sie können Infrastrukturcode als Module wiederverwenden.
- Sie können eine Anwendungsinitialisierungslogik hinzufügen.
Nachteile:
- Keine Unterstützung für Openshift, nur k8s.
- Manchmal veraltete Dock und Module.
- Eine weitere Tula in Ihrem Team.
Ansible-Container
Ansible-Container
Vorteile:
Nachteile:
- Riesige Bilder, weil gehe in einer Schicht.
- Sieht verlassen und nicht unterstützt aus. Wurde durch Ansible Bender ersetzt .
Ansible k8s Modul
Ansible + k8s Modul
Vorteile:
- Ein Playbook zur Beschreibung aller Projektinfrastrukturen in Openshift.
- Wiederverwendung von Code in Form von Rollen.
- Sie können eine Anwendungsinitialisierungslogik hinzufügen.
Nachteile:
- Keine Proxy-Unterstützung.
- Sie kümmern sich um die Entfernung. Wenn das Objekt nicht mehr benötigt wird, beschreiben Sie seine Entfernung.
- Sie selbst beschreiben die Reihenfolge der Erstellung von Infrastrukturelementen.
Ansible Playbook Bundle
Das Dienstprogramm Ansible Playbook Bundle (APB) bietet einen Ansatz: Packen Sie ansible Rollen für die Bereitstellung der Anwendung in k8s / openshift in einen Container und führen Sie sie in k8s / openshift aus.
Vorteile:
- Ich trage alles bei mir.
- Testbar und reproduzierbar.
- Integration in den Servicekatalog (benutzerfreundliche Weboberfläche zum Starten von Anwendungen).
Nachteile:
- Sie benötigen Administratorrechte.
- Die Dokumentation lässt manchmal zu wünschen übrig.
Ergebnis
Ich möchte nicht das letzte Mittel sein, aber ich werde meine Schlussfolgerungen teilen:
PS