Ich möchte meine Geschichte über die Migration einer Anwendung zu Openshift teilen. Infolgedessen werde ich auch einige der beliebtesten Lösungen und Tools für die Verwaltung Ihrer Anwendung in Openshift vergleichen. Es ist die Transkription meiner Präsentation beim kubernetes SPB Meetup # 3 .
Lassen Sie uns zu Openshift bereitstellen
Was sollen wir tun?
Lassen Sie uns zunächst über unsere Anwendung sprechen. Es handelt sich um eine sofort einsatzbereite Unternehmenslösung, die verschiedene Datenbanken, Anwendungsserver und Integrationsschnittstellen mit Systemen von Drittanbietern unterstützt. Normalerweise wurden unsere Clients auf dedizierten Servern installiert, wir waren jedoch mit dem Problem konfrontiert. Wir mussten die Anwendung in Openshift optimieren.
Voraussetzungen
Die Anwendung ist das Produkt mit einer langen Geschichte, es sollte sofort in völlig anderen Umgebungen funktionieren. Infolgedessen finden Sie in unseren Installationshandbüchern viele Seiten. Das Schema der obersten Ebene ist jedoch kinderleicht. Sie sollten nur Folgendes tun:
- DB-Schema anwenden.
- Bereiten Sie die Anwendungsserverkonfiguration vor.
- Installieren Sie Ihre Lizenz.
- Initialisieren Sie die Anwendung.
Leider ist die Welt grausam, es gab einige wichtige Voraussetzungen.
- Aus Sicherheitsgründen konnten wir die Anwendung nur auf einem speziellen Jenkins-Slave erstellen
- Es gab keinen Zugriff von der Openshift-Installation des Clients auf die Docker-Registrierung der privaten Entwickler.
- Wir konnten vorhandene Docker-Images nicht wiederverwenden, da sie nur zum Entwickeln und Testen von Anforderungen erstellt wurden.
- Es gab ansible Playbooks für die Anwendungsbereitstellung auf VMs.
Ansible-Container-Demo
Ansible Container ist ein Open Source-Projekt, das die Automatisierung des gesamten Prozesses zum Erstellen, Bereitstellen und Verwalten von Containern ermöglichen soll. Das Beste ist, dass dieselbe einfache, leistungsstarke und agentenlose Ansible-Automatisierungssprache verwendet wird, die Sie bereits verwenden, um sicherzustellen, dass Sie den gesamten Anwendungslebenszyklus automatisieren können.
Wir hatten bereits einige Ansible-Rollen für die Installation der Anwendung auf VMs geschrieben und sie daher mit ansible-container wiederverwendet. Ansible Container ist ein Toolset zum Erstellen von Containern. Ich bin mir nicht sicher, ob es wirklich ein gutes Toolset ist, aber es erlaubt:
- Erstellen Sie Container auf die gleiche Weise, wie wir unsere Server bereitstellen.
- Beenden Sie die Verkettung von Shell-Befehlen in Dockerfiles.
Es gab kein großes Problem mit Ansible-Container, da OpenShift das Erstellen von Bildrichtlinien fantastisch ist. Ich möchte jedoch Folgendes bemerken:
- Wir haben unsere Ansible-Rollen geändert, weil
Docker + systemd = pain . - Aus Sicherheitsgründen gibt es in Openshift standardmäßig keine Möglichkeit, chroot, sudo zu verwenden. Lesen Sie einfach CVE-2019-5736 .
- Aus Sicherheitsgründen generiert Openshift standardmäßig auch eine zufällige UID für jeden Container. Mit anderen Worten, openshift ignoriert die USER-Option aus einer Docker-Datei.
Der Hauptpunkt ist, dass ansible-container uns geholfen hat, aufgrund der Wiederverwendung sehr schnell eine Demo zu erstellen.
Demo mit mehreren Containern
Der erste Demo-Container wurde über einen Ansible-Container erstellt. Es war gut genug für die Demo, aber wir haben uns entschieden, es nicht zu verwenden. Wir teilen den Monolithbehälter in verschiedene Teile auf:
- Wir haben den ursprünglichen Openshift PostgreSQL-Container ohne Änderungen verwendet.
- Wir haben den zustandslosen Container der Anwendung erstellt.
Es war jedoch nicht klar, die Datenbank zu initialisieren? Wir haben einen großartigen Artikel über das Leben von PODs in Kubernetes gefunden. Daher haben wir uns entschieden, den Init-Container für die Datenbankinitialisierung zu verwenden.
Initialisieren Sie die Anwendung
Wie bereits erwähnt, sollte die Anwendung in völlig unterschiedlichen Umgebungen sofort einsatzbereit sein, unterschiedliche Anwendungsserver / -datenbanken und Integrationsschnittstellen mit Systemen von Drittanbietern unterstützen.
Es gibt viele Möglichkeiten, die Anwendung zu initialisieren:
- Übergeben Sie die Konfiguration über Umgebungsvariablen. Dies bedeutet, dass Sie alle unsere Dokumentationen / Kenntnisse zum Initialisieren der Anwendung für jeden Anwendungsfall in jeden Container einfügen. Es klingt nicht gut.
- Verwenden Sie den Starthaken. Dies entspricht in etwa dem ersten.
- Während der Bereitstellung für Openshift initialisieren.
- Verwenden Sie für jeden Anwendungsfall einen externen Container mit individueller Konfiguration.
Wir haben den letzten ausgewählt und einen zusätzlichen Replikationscontroller zum Initialisieren der Anwendung erstellt. Wirklich?
Wir haben die Dokumentation noch einmal gelesen.
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 der Container. Aus diesem Grund haben wir beschlossen, 3 Container in einem Anwendungs-POD auszuführen
- Init-Container für eine PostgreSQL-Initialisierung.
- Der Anwendungscontainer.
- Anwendungsinitialisierungscontainer.
Dieser Ansatz ermöglicht es, unsere Konfiguration als Code zu speichern. Es gibt zwei interessante Ergebnisse: Die Anwendungskonfiguration ist testbar und reproduzierbar.
Es gibt bereits viele für die Verwaltung von OpenShift.
Während der Migration habe ich einige davon getestet. Ich möchte meine Ergebnisse teilen.
OpenShift-Vorlagen
OpenShift-Vorlagen
Vorteile:
- Einheimisch Es hat eine großartige Dokumentation.
Nachteile:
- Noch eine YAML-Vorlage.
- Protokollieren Sie eine schreckliche YAML-Datei.
- Sie kümmern sich um Dienstabhängigkeiten.
Skripte und Vorlage
Vorteile:
Nachteile:
Terraform k8s Anbieter
Vorteile:
- Es ist mir egal, wie man Ordnung schafft.
- Code als Module wiederverwenden.
- Sie können eine Initialisierungslogik hinzufügen.
Nachteile:
- Keine OpenShift-Unterstützung, nur k8s.
- Manchmal veraltet.
- Noch ein Werkzeug.
Ansible-Container
Ansible-Container
Vorteile:
Nachteile:
- Riesige Bilder aufgrund einer einzigen Ebene.
- Sieht verlassen und veraltet aus.
Ansible Container wurde durch Ansible Bender ersetzt .
Ansible k8s Modul
Ansible + k8s Modul
Vorteile:
- Ein einziges Spielbuch für alle.
- Verwenden Sie Code erneut als Rollen.
- Sie können eine Initialisierungslogik hinzufügen.
Nachteile:
- Keine Proxy-Unterstützung.
- Sie kümmern sich um das Entfernen. Wenn Sie etwas entfernen möchten, müssen Sie es deklarieren.
- Es ist Ihnen wichtig, Ordnung zu schaffen. Sie sollten die Anwendung vor der Initialisierung bereitstellen.
Ansible Playbook Bundle
Ein Ansible Playbook Bundle (APB) ist eine einfache Anwendungsdefinition (Meta-Container). Sie werden zum Definieren und Bereitstellen komplexer Gruppen von Anwendungen, Bereitstellungskonfigurationen, Bereitstellungen und Diensten für einen OpenShift Origin-Cluster verwendet, auf dem Ansible Service Broker ausgeführt wird. APBs bieten mehr Leistung und einfache Konfiguration, indem sie die Leistung von Ansible nutzen. APBs haben die folgenden Funktionen:
Die Hauptidee ist, dass Sie alles Notwendige in einen Container packen und den Container in Openshift ausführen. Ansible Playbook Bundle
Vorteile:
- Bündelt alles.
- Testbar und reproduzierbar.
- Servicekatalog-Integration.
Nachteile:
- Sie benötigen Administratorrechte.
- Die Dokumentation ist manchmal veraltet.
Ergebnis
Einerseits möchte ich nicht die letzte Instanz sein, andererseits möchte ich meinen Standpunkt teilen. Es gibt keine Silberkugel.
PS