Southbridge in Tscheljabinsk und Bitrix in Kubernetes

In Tscheljabinsk finden Meetups für Systemadministratoren von Sysadminka statt, und bei dem letzten habe ich einen Vortrag über unsere Lösung zur Ausführung von Anwendungen auf 1C-Bitrix in Kubernetes gehalten.

Bitrix, Kubernetes, Ceph – eine tolle Mischung?

Ich werde erzählen, wie wir aus all dem eine funktionierende Lösung zusammengebaut haben.

Los geht's!

Das Meetup fand am 18. April in Tscheljabinsk statt. Über unsere Meetups kann man lesen in Timepad und sich anschauen auf YouTube.

Wenn Sie zu uns kommen möchten, um einen Vortrag zu halten oder als Zuhörer – herzlich willkommen, schreiben Sie an vadim.isakanov@gmail.com und auf Telegram t.me/vadimisakanov.

Mein Vortrag

Folien

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

Ich werde über unsere Lösung im Format „für Einsteiger in Kubernetes“ berichten, wie es auf dem Meetup gemacht wurde. Aber ich gehe davon aus, dass Ihnen die Begriffe Bitrix, Docker, Kubernetes und Ceph zumindest auf dem Niveau von Wikipedia-Artikeln bekannt sind.

Was gibt es eigentlich schon über Bitrix in Kubernetes?

Im gesamten Internet gibt es sehr wenig Informationen über die Ausführung von Anwendungen auf Bitrix in Kubernetes.
Ich habe nur solche Materialien gefunden:

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

Ich empfehle, ihm zuzuhören.

Entwicklung einer eigenen Lösung vom Benutzer serkyron auf Habra.
Ich habe noch eine solche Lösung gefunden.

Und iiiih… das ist eigentlich alles.

Ich warne, die Qualität der Lösungen in den obigen Links haben wir nicht überprüft 🙂
Übrigens, bei der Vorbereitung unserer Lösung habe ich mit Alexander Serbul gesprochen, zu dieser Zeit gab es seinen Vortrag noch nicht, daher gibt es in meinen Folien einen Punkt "Bitrix nutzt kein Kubernetes".

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

Reicht das aus, um eine vollwertige Lösung für Bitrix in Kubernetes zu schaffen?
Nein. Es gibt viele Probleme, die gelöst werden müssen.

Was sind die Probleme mit Bitrix in Kubernetes?

Erstens – die fertigen Images aus Dockerhub sind nicht für Kubernetes geeignet.

Wenn wir eine mikroservicebasierte Architektur aufbauen wollen (was wir in Kubernetes normalerweise wollen), muss die Anwendung in Kubernetes in Container aufgeteilt werden, und wir müssen sicherstellen, dass jeder Container eine kleine Funktion ausführt (und das gut macht). Warum nur eine? Kurz gesagt – je einfacher, desto zuverlässiger.
Wenn Sie mehr Details 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 letztendlich unser eigenes Rad bauen und sogar die Images von Grund auf neu erstellen mussten.

Zweitens – der Code der Website wird aus dem Administrationsbereich bearbeitet.

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

Die Eigenschaften der Komponente im Admin-Bereich wurden geändert – der Code hat sich geändert.

Kubernetes kann standardmäßig nicht damit umgehen, 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, wird der Code in verschiedenen Pods unterschiedlich sein, die Website funktioniert unterschiedlich, unterschiedliche Benutzer sehen unterschiedliche Versionen der Website. So kann man nicht leben.

Drittens – es muss eine Lösung für das Deployment gefunden werden.

Wenn wir ein Monolithen und einen „klassischen“ Server haben, ist alles ganz einfach: wir setzen die neue Codebasis um, führen die Datenbankmigration durch und leiten den Traffic auf die neue Version des Codes um. Der Wechsel geschieht sofort.
Wenn unsere Website in Kubernetes läuft, in Mikrodienste aufgeteilt ist und viele Container mit Code hat – oh je. Wir müssen Container mit der neuen Codeversion bauen, sie anstelle der alten bereitstellen, die Datenbankmigration korrekt durchführen und idealerweise dies für die Besucher unmerklich machen. Zum Glück hilft uns Kubernetes dabei und unterstützt eine ganze Reihe von verschiedenen Deployment-Arten.

Viertens – es muss eine Lösung zur Speicherung von Statischen gefunden werden.

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 eine Ewigkeit zum Deployen benötigen.
Die schwersten Teile der Website müssen außerhalb der Container gespeichert werden, und die Frage, wie das richtig gemacht wird, stellt sich.

Was in unserer Lösung nicht vorhanden ist.

Der gesamte Bitrix-Code ist nicht auf Mikrofunktionen/Mikrodienste aufgeteilt (so dass die Registrierung separat, das Modul für den Online-Shop separat usw. ist). Die gesamte Codebasis speichern wir in jedem Container vollständig.

Die Datenbank speichern wir auch nicht in Kubernetes (ich habe zwar Lösungen mit einer Datenbank in Kubernetes für Entwicklerumgebungen implementiert, aber nicht für die Produktionsumgebung).

Die 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 im Admin-Bereich zu bearbeiten, muss zuerst der Knopf „Ich möchte den Code bearbeiten“ gedrückt werden.

Wir haben die Probleme gelöst, wir sind uns der Notwendigkeit der Implementierung von Mikrodiensten bewusst, das Ziel ist klar – ein funktionierendes System für Anwendungen auf Bitrix in Kubernetes zu erhalten, wobei sowohl die Möglichkeiten von Bitrix als auch die Vorteile von Kubernetes erhalten bleiben. Wir beginnen mit der Implementierung.

Architektur

Viele "Worker"-Pods mit Webserver (Worker).
Ein Pod mit Cron-Jobs (unbedingt nur einer).
Ein Upgrade-Pod für die Bearbeitung des Website-Codes aus dem Admin-Panel (ebenfalls unbedingt nur einer).

Wir klären die Fragen:

• Wo speichern wir die Sitzungen?
• Wo speichern wir den Cache?
• Wo speichern wir die Statischen Dateien? Wir können doch nicht Gigabytes an Statischen Dateien in einer Vielzahl von Containern lagern?
• Wie wird die Datenbank funktionieren?

Docker-Image

Wir beginnen mit dem Aufbau des Docker-Images.

Die ideale Lösung – wir haben ein universelles Image, auf dessen Basis wir sowohl Worker-Pods als auch Pods mit Cron-Jobs und Upgrade-Pods erhalten.

Wir haben genau so ein Image erstellt..

Es enthält nginx, apache/php-fpm (bei der Erstellung auswählbar), msmtp zum Versand von E-Mails und cron.

Bei der Erstellung des Images wird der vollständige Code der Website in das Verzeichnis /app kopiert (mit Ausnahme der Teile, die wir in einen separaten Shared Storage auslagern).

Mikrodienste, Services

Worker-Pods:

• Container mit nginx + Container apache/php-fpm + msmtp
• msmtp konnte nicht in einen separaten Mikrodienst ausgelagert werden, Bitrix beschwert sich, dass es die E-Mails nicht direkt senden kann.
• In jedem Container befindet sich der vollständige Codebasis.
• Verbot von Änderungen am Code in Containern.

Cron-Pod:

• Container mit apache, php, cron
• Im Paket befindet sich die vollständige Codebasis.
• Verbot von Änderungen am Code in Containern.

Upgrade-Pod:

• Container mit nginx + Container apache/php-fpm + msmtp
• Kein Verbot von Änderungen am Code in Containern.

Sitzungsspeicher

Cache-Speicher für Bitrix

Wichtig: Die Passwörter für die Verbindung zu allem, von der Datenbank bis zur E-Mail, speichern wir in Kubernetes-Secrets. Wir erhalten den Bonus, dass die Passwörter nur denjenigen sichtbar sind, denen wir Zugriff auf die Secrets gewähren, und nicht allen, die Zugang zur Codebasis des Projekts haben.

Speicher für Statik

Wir können alles verwenden: Ceph, NFS (aber NFS empfehlen wir nicht für die Produktion), Netzwerkspeicher von ‚Cloud‘-Anbietern usw.

Der Speicher muss in den Containern im Verzeichnis /upload/ der Website und in anderen Verzeichnissen mit Statischen Dateien eingebunden werden.

Datenbank

Zur Vereinfachung empfehlen wir, die Datenbank außerhalb von Kubernetes zu platzieren. Die Datenbank in Kubernetes ist eine separate, komplexe Aufgabe, sie macht das Schema erheblich komplizierter.

Sitzungsspeicher

Wir verwenden Memcached 🙂

Er kümmert sich gut um die Speicherung von Sitzungen, wird clusterfähig und wird „nativ“ als session.save_path in PHP unterstützt. Ein solches System wurde bereits in der klassischen monolithischen Architektur mehrfach erprobt, als wir Cluster mit einer Vielzahl von Webservern aufgebaut haben. Für das Deployment verwenden wir Helm.

$ helm install stable/memcached --name session

php.ini — hier sind im Image die Einstellungen für die Speicherung von Sitzungen in Memcached definiert

Wir haben Umgebungsvariablen verwendet, um Daten über die Hosts mit Memcached zu übertragen https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
Dies ermöglicht es, denselben Code in den Umgebungen dev, stage, test, prod zu verwenden (die Hostnamen von Memcached werden sich unterscheiden, daher müssen wir jedem Umfeld einen einzigartigen Hostnamen für die Sitzungen übergeben).
Cache-Speicher von Bitrix

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

Wir nutzen ebenfalls Memcached.
Diese Lösung wird von Bitrix selbst empfohlen.

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php — hier wird in Bitrix definiert, wo wir den Cache speichern

Auch hier verwenden wir Umgebungsvariablen.

Cron-Jobs

Es gibt verschiedene Ansätze zur Ausführung von Cron-Jobs in Kubernetes.

• einen separaten Deployment mit einem Pod zur Ausführung von Cron-Jobs
• Cronjob zur Ausführung der Cron-Jobs (wenn es sich um eine Web-App handelt — mit wget https://$host$cronjobname, oder kubectl exec in einen der Worker Pods, usw.)
• usw.

Man kann über die beste Lösung diskutieren, aber in diesem Fall haben wir die Option "separates Deployment mit Pods für Cronjobs" gewählt.

So wurde es gemacht:

• Cron-Jobs fügen wir über ConfigMap oder über die Datei config/addcron hinzu
• Wir starten einen Container in einem einzigen Exemplar, der dem Worker-Pod identisch ist + erlauben die Ausführung von Cron-Jobs in ihm
• Es wird dieselbe Codebasis verwendet, sodass der Aufbau des Containers einfach ist

Was wir Gutes erhalten:

• Wir haben funktionierende Cron-Jobs in einer Umgebung, die der Umgebung der Entwickler (Docker) entspricht
• Cronjobs müssen nicht für Kubernetes "neu geschrieben" werden, sie funktionieren in der gleichen Art und Weise und im gleichen Codebasiss wie zuvor.
• Cron-Jobs können von allen Teammitgliedern mit Commit-Rechten im Produktionszweig hinzugefügt werden, nicht nur von Administratoren

Modul Southbridge K8SDeploy und Bearbeitung des Codes aus dem Administrationspanel

Wir haben doch über das Upgrade des Pods gesprochen?
Wie leitet man den Verkehr dorthin?
Hurra, wir haben dafür ein Modul in PHP geschrieben 🙂 Das ist ein kleines klassisches Modul für Bitrix. Es ist noch nicht öffentlich zugänglich, aber wir planen, es freizugeben.
Das Modul wird wie ein gewöhnliches Modul in Bitrix installiert:

Und so sieht es aus:

Es ermöglicht das Setzen eines Cookies, das den Administrator der Website identifiziert und Kubernetes erlaubt, den Traffic auf das Upgrade-Pod zu lenken.

Sobald die Änderungen abgeschlossen sind, muss man `git push` drücken, die Änderungen im Code werden an git gesendet, danach erstellt das System das Image mit der neuen Version des Codes und "rollt" es im Cluster aus, wobei die alten Pods ersetzt werden.

Ja, etwas improvisiert, aber so bewahren wir die Microservice-Architektur und nehmen den Benutzern von Bitrix die Möglichkeit, den Code über das Admin-Panel zu ändern, nicht weg. Schließlich ist das eine Option, die Aufgabe der Codeanpassung kann auch anders gelöst werden.

Helm-Chart

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

Er führt die Erstellung von Worker-, Upgrade- und Cron-Pods durch, konfiguriert Ingress, Services und überträgt Variablen aus Kubernetes Secrets in die Pods.

Wir speichern den Code in Gitlab, und das Helm-Build wird ebenfalls aus Gitlab gestartet.

Kurz gesagt, so sieht es 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 während des Deployments etwas schiefgeht. Es ist angenehm, wenn nicht du in Panik bist, den Code per FTP zu "fixen, weil die Produktion gefallen ist", sondern Kubernetes dies automatisch ohne Downtime erledigt.

Bereitstellung

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

Phasen:

• build (neues Docker-Image erstellen)
• test (testen)
• clean up (Testumgebung löschen)
• push (es in das Docker-Registry senden)
• deploy (Anwendung über Helm in Kubernetes bereitstellen).

Hurra, es ist fertig, wir implementieren!
Oder wir stellen Fragen, wenn welche vorhanden sind.

Also, was haben wir gemacht

Aus technischer Sicht:

• wir haben Bitrix containerisiert;
• "wir haben Bitrix in Container zerlegt, von denen jeder minimale Funktionen ausführt;
• wir haben einen zustandslosen Zustand der Container erreicht;
• wir haben das Problem mit dem Update von Bitrix in Kubernetes gelöst;
• alle Funktionen von Bitrix funktionieren weiterhin (fast alle);
• wir haben das Deployment in Kubernetes und den Rollback zwischen Versionen erfolgreich durchgeführt.

Aus geschäftlicher Sicht:

• Ausfallsicherheit;
• Kubernetes-Tools (einfache Integration mit Gitlab CI, nahtloses Deployment usw.);
• Passwörter in Secrets (sind nur für diejenigen sichtbar, denen der Zugriff auf die Passwörter direkt gewährt wurde);
• Es ist bequem, zusätzliche Umgebungen (für Entwicklung, Tests usw.) innerhalb einer einheitlichen Infrastruktur zu erstellen.

Quelle: habr.com