Ausführen von Camunda BPM auf Kubernetes

Ausführen von Camunda BPM auf Kubernetes

Verwenden Sie Kubernetes? Sind Sie bereit, Ihre Camunda BPM-Instanzen aus virtuellen Maschinen zu verschieben oder vielleicht einfach zu versuchen, sie auf Kubernetes auszuführen? Schauen wir uns einige gängige Konfigurationen und einzelne Elemente an, die an Ihre spezifischen Bedürfnisse angepasst werden können.

Es wird davon ausgegangen, dass Sie Kubernetes bereits verwendet haben. Wenn nicht, werfen Sie einen Blick darauf руководство und nicht Ihren ersten Cluster starten?

Autoren

  • Alastair Firth (Alastair Firth) – Senior Site Reliability Engineer im Camunda Cloud-Team;
  • Lars Lange (Lars Lange) – DevOps-Ingenieur bei Camunda.

Kurz gesagt, dann:

git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold

Okay, es hat wahrscheinlich nicht funktioniert, weil Sie weder Gerüst noch Kustomize installiert haben. Dann lesen Sie weiter!

Was ist Camunda BPM?

Camunda BPM ist eine Open-Source-Plattform für Geschäftsprozessmanagement und Entscheidungsautomatisierung, die Geschäftsanwender und Softwareentwickler verbindet. Es ist ideal für die Koordination und Verbindung von Menschen, (Mikro-)Diensten oder sogar Bots! Weitere Informationen zu den verschiedenen Anwendungsfällen finden Sie unter Link.

Warum Kubernetes verwenden?

Kubernetes ist zum De-facto-Standard für die Ausführung moderner Anwendungen unter Linux geworden. Durch die Verwendung von Systemaufrufen anstelle von Hardware-Emulation und die Fähigkeit des Kernels, Speicher und Aufgabenwechsel zu verwalten, werden die Startzeit und die Startzeit auf ein Minimum reduziert. Der größte Vorteil könnte jedoch aus der Standard-API resultieren, die Kubernetes zur Konfiguration der für alle Anwendungen erforderlichen Infrastruktur bereitstellt: Speicherung, Netzwerk und Überwachung. Im Juni 2020 wurde es 6 Jahre alt und ist vielleicht das zweitgrößte Open-Source-Projekt (nach Linux). Nach einer schnellen Iteration in den letzten Jahren hat es seine Funktionalität in jüngster Zeit aktiv stabilisiert, da es für Produktions-Workloads auf der ganzen Welt von entscheidender Bedeutung ist.

Camunda BPM Engine kann problemlos eine Verbindung zu anderen Anwendungen herstellen, die auf demselben Cluster ausgeführt werden, und Kubernetes bietet eine hervorragende Skalierbarkeit, sodass Sie die Infrastrukturkosten nur dann erhöhen, wenn es wirklich erforderlich ist (und diese bei Bedarf problemlos senken können).

Auch die Qualität der Überwachung wird mit Tools wie Prometheus, Grafana, Loki, Fluentd und Elasticsearch deutlich verbessert, sodass Sie alle Workloads in einem Cluster zentral einsehen können. Heute schauen wir uns an, wie man den Prometheus-Exporter in die Java Virtual Machine (JVM) implementiert.

Tore

Schauen wir uns einige Bereiche an, in denen wir das Camunda BPM Docker-Image anpassen können (github), damit es gut mit Kubernetes interagiert.

  1. Protokolle und Metriken;
  2. Datenbankverbindungen;
  3. Authentifizierung;
  4. Sitzungsverwaltung.

Wir werden verschiedene Wege zur Erreichung dieser Ziele betrachten und den gesamten Prozess anschaulich darstellen.

Beachten: Benutzen Sie die Enterprise-Version? Suchen hier und aktualisieren Sie Bildlinks nach Bedarf.

Workflow-Entwicklung

In dieser Demo verwenden wir Skaffold, um Docker-Images mit Google Cloud Build zu erstellen. Es bietet gute Unterstützung für verschiedene Tools (wie Kustomize und Helm), CI- und Build-Tools sowie Infrastrukturanbieter. Datei skaffold.yaml.tmpl Enthält Einstellungen für Google Cloud Build und GKE und bietet eine sehr einfache Möglichkeit, eine Infrastruktur in Produktionsqualität auszuführen.

make skaffold lädt den Dockerfile-Kontext in Cloud Build, erstellt das Image und speichert es in GCR und wendet dann die Manifeste auf Ihren Cluster an. Das ist es, was es tut make skaffold, aber Skaffold hat viele andere Funktionen.

Für Yaml-Vorlagen in Kubernetes verwenden wir kustomize, um Yaml-Overlays zu verwalten, ohne das gesamte Manifest zu forken, sodass Sie es verwenden können git pull --rebase für weitere Verbesserungen. Jetzt ist es in kubectl und funktioniert für solche Dinge ganz gut.

Wir verwenden auch envsubst, um den Hostnamen und die GCP-Projekt-ID in die *.yaml.tmpl-Dateien einzutragen. Sie können sehen, wie es funktioniert makefile oder einfach weitermachen.

Voraussetzungen

  • Arbeitscluster Kubernetes
  • Anpassen
  • Gerüst – zum Erstellen eigener Docker-Images und zur einfachen Bereitstellung in GKE
  • Kopie dieses Codes
  • Envsubst

Workflow mit Manifesten

Wenn Sie Kustomize oder Skaffold nicht verwenden möchten, können Sie auf die Manifeste in verweisen generated-manifest.yaml und passen Sie sie an den Workflow Ihrer Wahl an.

Protokolle und Metriken

Prometheus ist zum Standard für die Erfassung von Metriken in Kubernetes geworden. Es besetzt die gleiche Nische wie AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics und andere. Es ist Open Source und verfügt über eine leistungsstarke Abfragesprache. Die Visualisierung vertrauen wir Grafana an – sie verfügt über eine große Anzahl an Dashboards, die sofort verfügbar sind. Sie sind miteinander verbunden und lassen sich relativ einfach installieren Prometheus-Operator.

Standardmäßig verwendet Prometheus das Extraktionsmodell <service>/metrics, und das Hinzufügen von Sidecar-Containern hierfür ist üblich. Leider werden JMX-Metriken am besten innerhalb der JVM protokolliert, sodass Sidecar-Container nicht so effizient sind. Lassen Sie uns verbinden jmx_exporter Open Source von Prometheus zur JVM hinzufügen, indem es dem Container-Image hinzugefügt wird, das den Pfad bereitstellt /metrics auf einem anderen Port.

Fügen Sie Prometheus jmx_exporter zum Container hinzu

-- images/camunda-bpm/Dockerfile
FROM camunda/camunda-bpm-platform:tomcat-7.11.0

## Add prometheus exporter
RUN wget https://repo1.maven.org/maven2/io/prometheus/jmx/
jmx_prometheus_javaagent/0.11.0/jmx_prometheus_javaagent-0.11.0.jar -P lib/
#9404 is the reserved prometheus-jmx port
ENV CATALINA_OPTS -javaagent:lib/
jmx_prometheus_javaagent-0.11.0.jar=9404:/etc/config/prometheus-jmx.yaml

Nun, das war einfach. Der Exporter überwacht Tomcat und zeigt seine Metriken im Prometheus-Format an <svc>:9404/metrics

Exporter-Setup

Der aufmerksame Leser fragt sich vielleicht, woher es kommt prometheus-jmx.yaml? Es gibt viele verschiedene Dinge, die in der JVM ausgeführt werden können, und Tomcat ist nur eines davon, sodass der Exporter einige zusätzliche Konfigurationen benötigt. Standardkonfigurationen für Tomcat, Wildfly, Kafka usw. sind verfügbar hier. Wir werden Tomcat als hinzufügen Konfigurationskarte in Kubernetes und mounten Sie es dann als Volume.

Zuerst fügen wir die Exporter-Konfigurationsdatei zu unserem Verzeichnis platform/config/ hinzu

platform/config
└── prometheus-jmx.yaml

Dann fügen wir hinzu ConfigMapGenerator в kustomization.yaml.tmpl:

-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...] configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml

Dadurch wird jedes Element hinzugefügt files[] als ConfigMap-Konfigurationselement. ConfigMapGeneratoren sind großartig, weil sie die Konfigurationsdaten hashen und einen Pod-Neustart erzwingen, wenn sie sich ändern. Sie reduzieren auch den Konfigurationsaufwand bei der Bereitstellung, da Sie einen ganzen „Ordner“ mit Konfigurationsdateien in einem VolumeMount bereitstellen können.

Schließlich müssen wir die ConfigMap als Volume im Pod mounten:

-- platform/deployment.yaml
apiVersion: apps/v1
kind: Deployment
[...] spec:
template:
spec:
[...] volumes:
- name: config
configMap:
name: config
defaultMode: 0744
containers:
- name: camunda-bpm
volumeMounts:
- mountPath: /etc/config/
name: config
[...]

Wunderbar. Wenn Prometheus nicht für eine vollständige Bereinigung konfiguriert ist, müssen Sie es möglicherweise anweisen, die Pods zu bereinigen. Prometheus-Operator-Benutzer können verwenden service-monitor.yaml um loszulegen. Erkunden Service-monitor.yaml, Betreiberdesign и ServiceMonitorSpec bevor du anfängst.

Ausweitung dieses Musters auf andere Anwendungsfälle

Alle Dateien, die wir zu ConfigMapGenerator hinzufügen, sind im neuen Verzeichnis verfügbar /etc/config. Sie können diese Vorlage erweitern, um alle anderen benötigten Konfigurationsdateien bereitzustellen. Sie können sogar ein neues Startskript bereitstellen. Sie können verwenden Unterpfad um einzelne Dateien zu mounten. Um XML-Dateien zu aktualisieren, sollten Sie die Verwendung in Betracht ziehen xmlstarlet statt sed. Es ist bereits im Bild enthalten.

Zeitschriften

Großartige Neuigkeiten! Anwendungsprotokolle sind bereits auf stdout verfügbar, beispielsweise mit kubectl logs. Fluentd (standardmäßig in GKE installiert) leitet Ihre Protokolle an Elasticsearch, Loki oder Ihre Unternehmensprotokollierungsplattform weiter. Wenn Sie jsonify für Protokolle verwenden möchten, können Sie zur Installation der obigen Vorlage folgen Wieder anmelden.

Datenbank

Standardmäßig verfügt das Bild über eine H2-Datenbank. Dies ist für uns nicht geeignet und wir werden Google Cloud SQL mit Cloud SQL Proxy verwenden – dies wird später zur Lösung interner Probleme benötigt. Dies ist eine einfache und zuverlässige Option, wenn Sie beim Einrichten der Datenbank keine eigenen Vorlieben haben. AWS RDS bietet einen ähnlichen Service.

Unabhängig von der von Ihnen gewählten Datenbank müssen Sie die entsprechenden Umgebungsvariablen festlegen, es sei denn, es handelt sich um H2 platform/deploy.yaml. Es sieht ungefähr so ​​aus:

-- platform/deployment.yaml
apiVersion: apps/v1
kind: Deployment
[...] spec:
template:
spec:
[...] containers:
- name: camunda-bpm
env:
- name: DB_DRIVER
value: org.postgresql.Driver
- name: DB_URL
value: jdbc:postgresql://postgres-proxy.db:5432/process-engine
- name: DB_USERNAME
valueFrom:
secretKeyRef:
name: cambpm-db-credentials
key: db_username
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: cambpm-db-credentials
key: db_password
[...]

Beachten: Sie können Kustomize verwenden, um mithilfe eines Overlays in verschiedenen Umgebungen bereitzustellen: Beispiel.

Beachten: Verwendung valueFrom: secretKeyRef. Benutzen Sie bitte diese Kubernetes-Funktion auch während der Entwicklung, um Ihre Geheimnisse zu schützen.

Wahrscheinlich verfügen Sie bereits über ein bevorzugtes System zur Verwaltung von Kubernetes-Geheimnissen. Wenn nicht, gibt es hier einige Optionen: Verschlüsseln Sie sie mit dem KMS Ihres Cloud-Anbieters und fügen Sie sie dann als Geheimnisse über die CD-Pipeline in K8S ein Mozilla-SOPS - Funktioniert sehr gut in Kombination mit Kustomize Secrets. Es gibt andere Tools wie dotGPG, die ähnliche Funktionen ausführen: HashiCorp-Tresor, Passen Sie Secret Value Plugins an.

Eintritt

Sofern Sie sich nicht für die lokale Portweiterleitung entscheiden, benötigen Sie einen konfigurierten Ingress Controller. Wenn Sie es nicht verwenden Ingress-Nginx (Helmkarte), dann wissen Sie höchstwahrscheinlich bereits, dass Sie die erforderlichen Anmerkungen installieren müssen ingress-patch.yaml.tmpl oder platform/ingress.yaml. Wenn Sie ingress-nginx verwenden und eine Nginx-Ingress-Klasse mit einem darauf verweisenden Load Balancer und einem externen DNS- oder Wildcard-DNS-Eintrag sehen, können Sie loslegen. Andernfalls konfigurieren Sie den Ingress Controller und DNS oder überspringen Sie diese Schritte und behalten Sie die direkte Verbindung zum Pod bei.

TLS

Wenn Sie verwenden Zertifizierungsmanager oder kube-lego undletsencrypt – Zertifikate für die neue Anmeldung werden automatisch abgerufen. Ansonsten öffnen ingress-patch.yaml.tmpl und passen Sie es an Ihre Bedürfnisse an.

Start!

Wenn Sie alles oben Geschriebene befolgt haben, dann der Befehl make skaffold HOSTNAME=<you.example.com> sollte eine verfügbare Instanz in starten <hostname>/camunda

Wenn Sie Ihren Login nicht auf eine öffentliche URL eingestellt haben, können Sie ihn mit umleiten localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 auf localhost:8080/camunda

Warten Sie einige Minuten, bis Tomcat vollständig bereit ist. Der Cert-Manager benötigt einige Zeit, um den Domänennamen zu überprüfen. Sie können die Protokolle dann mit verfügbaren Tools überwachen, beispielsweise mit einem Tool wie kubetail, oder einfach mit kubectl:

kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f

Nächste Schritte

Genehmigung

Dies ist für die Konfiguration von Camunda BPM relevanter als für Kubernetes, es ist jedoch wichtig zu beachten, dass die Authentifizierung in der REST-API standardmäßig deaktiviert ist. Du kannst Aktivieren Sie die Basisauthentifizierung oder verwenden Sie eine andere Methode wie JWT. Sie können configmaps und volumes verwenden, um XML zu laden, oder xmlstarlet (siehe oben), um vorhandene Dateien im Image zu bearbeiten, und entweder wget verwenden oder sie mithilfe eines Init-Containers und eines freigegebenen Volumes laden.

Sitzungsverwaltung

Wie viele andere Anwendungen verwaltet Camunda BPM Sitzungen in der JVM. Wenn Sie also mehrere Replikate ausführen möchten, können Sie Sticky Sessions aktivieren (zum Beispiel für ingress-nginx), die bestehen bleibt, bis das Replikat verschwindet, oder legen Sie das Max-Age-Attribut für Cookies fest. Für eine robustere Lösung können Sie Session Manager in Tomcat bereitstellen. Lars hat separater Beitrag zu diesem Thema, aber so etwas wie:

wget http://repo1.maven.org/maven2/de/javakaffee/msm/memcached-session-manager/
2.3.2/memcached-session-manager-2.3.2.jar -P lib/ &&
wget http://repo1.maven.org/maven2/de/javakaffee/msm/memcached-session-manager-tc9/
2.3.2/memcached-session-manager-tc9-2.3.2.jar -P lib/ &&

sed -i '/^</Context>/i
<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="redis://redis-proxy.db:22121"
sticky="false"
sessionBackupAsync="false"
storageKeyPrefix="context"
lockingMode="auto"
/>' conf/context.xml

Beachten: Sie können xmlstarlet anstelle von sed verwenden

Wir verwendeten twemproxy vor Google Cloud Memorystore, mit memcached-session-manager (unterstützt Redis), um es auszuführen.

Skalierung

Wenn Sie sich bereits mit Sitzungen auskennen, kann die erste (und oft letzte) Einschränkung bei der Skalierung von Camunda BPM die Verbindung zur Datenbank sein. Teilweise Anpassung ist bereits verfügbar.aus der Schachtel" Lassen Sie uns auch intialSize in der Datei „settings.xml“ deaktivieren. Hinzufügen Horizontaler Pod-Autoscaler (HPA) und Sie können die Anzahl der Pods ganz einfach automatisch skalieren.

Wünsche und Einschränkungen

В platform/deployment.yaml Sie werden sehen, dass wir das Ressourcenfeld fest codiert haben. Dies funktioniert gut mit HPA, erfordert jedoch möglicherweise eine zusätzliche Konfiguration. Hierfür eignet sich der Kustomize-Patch. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl

Abschluss

Deshalb haben wir Camunda BPM auf Kubernetes mit Prometheus-Metriken, Protokollen, H2-Datenbank, TLS und Ingress installiert. Wir haben JAR-Dateien und Konfigurationsdateien mithilfe von ConfigMaps und Dockerfile hinzugefügt. Wir haben über den Datenaustausch zwischen Secrets und Volumes und direkt mit Umgebungsvariablen gesprochen. Darüber hinaus haben wir einen Überblick über die Einrichtung von Camunda für mehrere Replikate und eine authentifizierte API gegeben.

Referenzen

github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes

├── generated-manifest.yaml <- manifest for use without kustomize
├── images
│ └── camunda-bpm
│ └── Dockerfile <- overlay docker image
├── ingress-patch.yaml.tmpl <- site-specific ingress configuration
├── kustomization.yaml.tmpl <- main Kustomization
├── Makefile <- make targets
├── namespace.yaml
├── platform
│ ├── config
│ │ └── prometheus-jmx.yaml <- prometheus exporter config file
│ ├── deployment.yaml <- main deployment
│ ├── ingress.yaml
│ ├── kustomization.yaml <- "base" kustomization
│ ├── service-monitor.yaml <- example prometheus-operator config
│ └── service.yaml
└── skaffold.yaml.tmpl <- skaffold directives

05.08.2020, Übersetzung Artikel Alastair Firth, Lars Lange

Source: habr.com

Kommentar hinzufügen