Southbridge in Tscheljabinsk und Bitrix in Kubernetes

In Tscheljabinsk finden die Sysadmin-Meetups von Sysadminka statt, und bei der letzten Veranstaltung habe ich über unsere Lösung für die Implementierung von 1C-Bitrix-Anwendungen in Kubernetes gesprochen.

Bitrix, Kubernetes, Ceph – eine perfekte Kombination?

Ich erkläre Ihnen, wie wir aus all dem eine funktionierende Lösung entwickelt haben.

Los geht's!

Das Meetup fand am 18. April in Tscheljabinsk statt. Informationen über unsere Meetups können Sie nachlesen unter Timepad und anschauen auf YouTube.

Wenn Sie uns einen Vortrag halten oder als Zuhörer teilnehmen möchten – herzlich willkommen, schreiben Sie an vadim.isakanov@gmail.com oder über Telegram t.me/vadimisakanov.

Mein Vortrag

Folien

Lösung „Bitrix in Kubernetes, Version Southbridge 1.0“

Ich werde Ihnen unsere Lösung im Format „für Einsteiger in Kubernetes“ vorstellen, wie es beim Meetup gezeigt wurde. Ich gehe davon aus, dass Ihnen die Begriffe Bitrix, Docker, Kubernetes und Ceph zumindest auf Wikipedia-Ebene bekannt sind.

Was gibt es bereits an Informationen über Bitrix in Kubernetes?

Im Internet gibt es sehr wenig Informationen zur Nutzung von Bitrix-Anwendungen in Kubernetes.
Ich habe nur folgende Materialien gefunden:

Der Vortrag von Alexander Serbul, 1C-Bitrix, und Anton Tuzlukov von Qsoft:

Ich empfehle, ihn anzuhören.

Entwicklung einer eigenen Lösung vom Nutzer serkyron auf Habré.
Ich habe noch eine solche Lösung gefunden.

Und… das ist eigentlich alles.

Ich weise darauf hin, dass wir die Qualität der Arbeiten zu den oben genannten Lösungen nicht überprüft haben 🙂
Übrigens, während der Vorbereitung unserer Lösung habe ich mit Alexander Serbul kommuniziert; zu diesem Zeitpunkt gab es seinen Vortrag noch nicht, weshalb in meinen Folien steht: „Bitrix verwendet kein Kubernetes“.

Aber es gibt bereits viele fertige Docker-Images für Bitrix, die in Docker funktionieren: https://hub.docker.com/search?q=bitrix&type=image

Reicht das für die Erstellung einer vollständigen Lösung für Bitrix in Kubernetes aus?
Nein. Es gibt eine Vielzahl von Problemen, die gelöst werden müssen.

Was sind die Probleme mit Bitrix in Kubernetes?

Das erste — die fertigen Images aus Dockerhub sind nicht für Kubernetes geeignet.

Wenn wir eine Mikroservice-Architektur aufbauen wollen (was wir in Kubernetes normalerweise wollen), muss die Anwendung in Kubernetes in Container aufgeteilt werden, und es muss sichergestellt werden, dass jeder Container eine kleine Funktion erfüllt (und das gut macht). Warum nur eine? Kurz gesagt: Je einfacher, desto zuverlässiger.
Wenn Sie mehr erfahren möchten — schauen Sie sich bitte diesen Artikel und das Video an: https://habr.com/ru/company/southbridge/blog/426637/

Docker-Images in Dockerhub sind hauptsächlich nach dem Prinzip „alles in einem“ erstellt, weshalb wir tatsächlich unser eigenes Rad erfinden mussten und sogar die Images von Grund auf neu erstellen mussten.

Das zweite — der Code der Website wird über das Admin-Panel bearbeitet.

Ein neuer Abschnitt auf der Website wurde erstellt – der Code wurde aktualisiert (ein Verzeichnis mit dem Namen des neuen Abschnitts wurde hinzugefügt).

Die Eigenschaften der Komponente im Administrationsbereich wurden geändert – der Code hat sich geändert.

Kubernetes kann standardmäßig nicht damit arbeiten, Container müssen unveränderlich (Stateless) sein.

Grund: Jeder Container (Pod) im Cluster verarbeitet nur einen Teil des Traffics. Wenn der Code nur in einem Container (Pod) geändert wird, ist der Code in verschiedenen Pods unterschiedlich, die Website funktioniert unterschiedlich, und verschiedene Benutzer sehen unterschiedliche Versionen der Website. So kann man nicht arbeiten.

Das Dritte – wir müssen das Deployment-Problem lösen.

Wenn wir ein Monolith sind und einen „klassischen“ Server haben, ist alles ganz einfach: Wir setzen die neue Codebasis auf, führen die Datenbankmigration durch und schalten den Traffic auf die neue Version des Codes um. Der Umschaltung erfolgt sofort.
Wenn wir eine Website in Kubernetes haben, die in Mikrodienste aufgeteilt ist und viele Container mit Code hat – oh je. Wir müssen Container mit der neuen Version des Codes erstellen, sie statt der alten ausrollen, die Datenbankmigration korrekt durchführen und idealerweise dies unbemerkt für die Besucher tun. Glücklicherweise unterstützt uns Kubernetes dabei mit verschiedenen Arten des Deployments.

Der vierte Punkt – wir müssen das Problem mit der Speicherung von statischen Inhalten angehen.

Wenn Ihre Website "nur" 10 Gigabyte groß ist und Sie sie vollständig in Containern bereitstellen, erhalten Sie Container mit einem Gewicht von 10 Gigabyte, die ewig deployt werden.
Die schwersten Teile der Website müssen außerhalb der Container gespeichert werden, und es stellt sich die Frage, wie man das richtig macht.

Was in unserer Lösung nicht enthalten ist.

Der gesamte Bitrix-Code ist nicht in Mikrofunktionen/Mikroservices aufgeteilt (z. B. Registrierung separat, Online-Shop-Modul separat usw.). Den gesamten Code-Basis speichern wir in jedem Container vollständig.

Die Datenbank wird ebenfalls nicht in Kubernetes gespeichert (ich habe zwar Lösungen mit einer Datenbank in Kubernetes für Entwicklerumgebungen umgesetzt, aber nicht für die Produktion).

Administratoren der Website werden dennoch bemerken, dass die Website in Kubernetes läuft. Die Funktion „Systemprüfung“ funktioniert nicht korrekt, um den Code der Website aus dem Admin-Panel zu bearbeiten, muss zuerst die Schaltfläche „Ich möchte den Code bearbeiten“ gedrückt werden.

Wir haben die Probleme gelöst, die Notwendigkeit von Microservices erkannt, und das Ziel ist klar – ein funktionierendes System für die Ausführung von Anwendungen auf Bitrix in Kubernetes zu schaffen, dabei sowohl die Möglichkeiten von Bitrix als auch die Vorteile von Kubernetes zu erhalten. Wir beginnen mit der Umsetzung.

Architektur von

Viele „Arbeits“-Pods mit einem Webserver (Worker).
Ein Pod mit Cron-Tasks (unbedingt nur einer).
Ein Upgrade-Pod für die Bearbeitung des Website-Codes aus dem Admin-Panel (auch hier unbedingt nur einer).

Wir klären die Fragen:

• Wo sollen die Sitzungen gespeichert werden?
• Wo soll der Cache gespeichert werden?
• Wo soll die statische Datei gespeichert werden, sollen wir wirklich Gigabytes an Statik in zahlreichen Containern ablegen?
• Wie wird die Datenbank funktionieren?

Docker-Image

Wir beginnen mit dem Aufbau des Docker-Images.

Die ideale Lösung – wir haben ein universelles Image, darauf basierend erhalten wir sowohl Worker-Pods, als auch Pods mit Cron-Tasks und Upgrade-Pods.

Genau so ein Image haben wir erstellt..

Es enthält Nginx, Apache/PHP-FPM (wählbar beim Aufbau), msmtp zum Versenden von E-Mails und Cron.

Beim Aufbau des Images wird die vollständige Codebasis der Website in das Verzeichnis /app kopiert (außer den Teilen, die wir in einen separaten Shared Storage auslagern).

Microservices, Services

Worker-Pods:

• Container mit Nginx + Container Apache/PHP-FPM + msmtp
• msmtp konnte nicht in einen separaten Microservice ausgelagert werden, Bitrix beschwert sich, dass es keine E-Mails direkt senden kann.
• In jedem Container ist der vollständige Code vorhanden.
• Änderungen am Code in Containern sind nicht erlaubt.

Cron läuft unter:

• Container mit Apache, PHP, Cron.
• Im Lieferumfang enthalten ist der vollständige Code.
• Änderungen am Code in Containern sind verboten.

Upgrade erfolgt unter:

• Container mit Nginx + Container Apache/PHP-FPM + msmtp.
• Es gibt keine Einschränkungen für Änderungen am Code in den Containern.

Sessionspeicher.

Cache-Speicher für Bitrix.

Außerdem wichtig: Die Passwörter für den Zugriff auf alles, von der Datenbank bis zur E-Mail, speichern wir in Kubernetes-Secrets. Der Vorteil ist, dass Passwörter nur von denjenigen eingesehen werden können, denen wir Zugang zu den Secrets gewähren, nicht von allen, die Zugang zum Code des Projekts haben.

Speicher für statische Dateien.

Es kann alles Mögliche verwendet werden: Ceph, NFS (aber NFS empfehlen wir nicht für die Produktion), Netzwerkspeicher von "Cloud"-Anbietern usw.

Der Speicher muss in den Containern mit dem Verzeichnis /upload/ der Website und anderen Verzeichnissen für statische Dateien verbunden werden.

Datenbank

Zur Vereinfachung empfehlen wir, die Datenbank außerhalb von Kubernetes auszulagern. Eine Datenbank in Kubernetes ist eine komplexe Aufgabe, die das Schema erheblich komplizierter macht.

Sessionspeicher.

Wir verwenden memcached 🙂

Es bewältigt die Speicherung von Sessions gut, kann clusterartig arbeiten und wird "nativ" als session.save_path in PHP unterstützt. Solch ein System wurde schon vielfach in klassischen monolithischen Architekturen eingesetzt, als wir Cluster mit einer großen Anzahl von Webservern aufgebaut haben. Für das Deployment verwenden wir Helm.

$ helm install stable/memcached --name session

php.ini – hier sind die Einstellungen für die Speicherung von Sessions in Memcached im Image festgelegt.

Wir verwendeten Umgebungsvariablen, um Informationen über die Hosts mit Memcached zu übermitteln. https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
Dadurch können wir denselben Code in den Umgebungen dev, stage, test, prod verwenden (die Namen der Memcached-Hosts werden unterschiedlich sein, daher müssen wir für jede Umgebung die eindeutigen Hostnamen für die Sessions übergeben).
Cache-Speicher Bitrix

Wir benötigen einen fehlertoleranten Speicher, in den alle Pods schreiben und aus dem sie lesen können.

Außerdem verwenden wir Memcached.
Diese Lösung wird von Bitrix selbst empfohlen.

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php – hier wird in Bitrix festgelegt, wo der Cache gespeichert ist.

Wir verwenden ebenfalls Umgebungsvariablen.

Cronjobs

Es gibt verschiedene Ansätze zur Ausführung von Cronjobs in Kubernetes.

• ein separater Deployment mit Pod für die Ausführung von Cronjobs
• Cronjob zur Ausführung von Cronjobs (wenn es sich um eine Web-App handelt – mit wget https://$host$cronjobname, oder kubectl exec in einen der Worker-Pods, usw.)
• etc.

Es lässt sich darüber streiten, was die beste Lösung ist, aber wir haben uns in diesem Fall für die Option «separates Deployment mit Pods für Cronjobs» entschieden.

So wird es gemacht:

• Wir fügen die Cronjobs über ConfigMap oder über die Datei config/addcron hinzu.
• Wir starten den Container einmal, der identisch zum Worker-Pod ist + erlauben die Ausführung der Cronjobs darin.
• Es wird die gleiche Codebasis verwendet, was die Containererstellung vereinfacht.

Was haben wir davon:

• Wir haben funktionierende Cronjobs in einer Umgebung, die identisch mit der der Entwickler (Docker) ist.
• Die Cronjobs müssen nicht «neu geschrieben» werden für Kubernetes, sie funktionieren in der gleichen Form und mit der gleichen Codebasis wie zuvor.
• Alle Teammitglieder mit Commit-Rechten im Produktionsbranch können Cronjobs hinzufügen, nicht nur die Administratoren.

Das Southbridge K8SDeploy-Modul und das Bearbeiten von Code aus dem Admin-Panel.

Wir haben doch über das Upgrade der Pods gesprochen?
Wie leiten wir den Traffic dorthin?
Hurra, wir haben dafür ein PHP-Modul geschrieben 🙂 Es ist ein kleines klassisches Modul für Bitrix. Es ist noch nicht öffentlich verfügbar, aber wir planen, es zu veröffentlichen.
Das Modul wird wie ein reguläres Modul in Bitrix installiert:

Und sieht so aus:

Es ermöglicht die Festlegung eines Cookies, das den Administrator der Website identifiziert und Kubernetes ermöglicht, den Traffic auf das Upgrade-Deployment zu leiten.

Sobald die Änderungen abgeschlossen sind, müssen Sie git push drücken; der Code wird an git gesendet, dann erstellt das System ein Image mit der neuen Version des Codes und verteilt es im Cluster, wobei die alten Pods ersetzt werden.

Ja, etwas umständlich, aber dabei bewahren wir die Microservices-Architektur und nehmen den Bitrix-Nutzern nicht die Möglichkeit, den Code aus dem Admin-Bereich zu bearbeiten. Schließlich ist es eine Option; man kann die Codeänderung auch anders angehen.

Helm Chart

Für den Aufbau von Anwendungen in Kubernetes verwenden wir in der Regel den Paketmanager Helm.
Für unsere Bitrix-Lösung in Kubernetes hat Sergey Bondarev, unser leitender Systemadministrator, ein spezielles Helm Chart geschrieben.

Es erstellt Pods für Worker, Upgrade und Cron, konfiguriert Ingresses, Services und überträgt Variablen aus Kubernetes Secrets in die Pods.

Wir speichern den Code in GitLab und starten auch den Helm-Bau aus GitLab.

Kurz gesagt, das sieht so aus:

$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=production

Helm ermöglicht auch einen nahtlosen Rollback, falls bei der Bereitstellung etwas schiefgeht. Es ist beruhigend zu wissen, dass nicht Sie in Panik den Code per FTP „fixen“, weil die Produktion ausgefallen ist, sondern Kubernetes das automatisch und ohne Ausfallzeiten erledigt.

Deployment

Ja, wir sind Fans von Gitlab & Gitlab CI, wir nutzen es 🙂
Beim Commit in Gitlab wird ein Pipeline im Projekt-Repository gestartet, die die Bereitstellung einer neuen Version der Umgebung durchführt.

Phasen:

• build (wir erstellen ein neues Docker-Image)
• test (wir führen Tests durch)
• clean up (wir löschen die Testumgebung)
• push (wir senden es an das Docker-Registry)
• deploy (wir deployen die Anwendung in Kubernetes über Helm).

Hurra, alles bereit, wir setzen es um!
Oder wir stellen Fragen, wenn es welche gibt.

Also, was haben wir gemacht

Aus technischer Sicht:

• Wir haben Bitrix dockerisiert;
• Wir haben Bitrix in Container unterteilt, von denen jeder minimale Funktionen ausführt;
• Wir haben den stateless Zustand der Container erreicht;
• Wir haben das Problem mit der Aktualisierung von Bitrix in Kubernetes gelöst;
• Alle Funktionen von Bitrix funktionieren weiterhin (fast alle);
• Wir haben das Deployment in Kubernetes und Rollbacks zwischen Versionen erfolgreich umgesetzt.

Aus geschäftlicher Sicht:

• Fehlertoleranz;
• Kubernetes-Tools (einfache Integration mit Gitlab CI, nahtloses Deployment usw.);
• Passwörter in Geheimnissen (nur für Benutzer sichtbar, denen der Zugriff auf die Passwörter direkt gewährt wurde);
• Zusätzliche Umgebungen (für Entwicklung, Tests usw.) bequem innerhalb einer einheitlichen Infrastruktur erstellen.

Quelle: habr.com