Nutzen Sie Kubernetes? Sind Sie bereit, Ihre Camunda BPM-Instanzen von virtuellen Maschinen zu migrieren oder sie vielleicht einfach auf Kubernetes zu starten? Lassen Sie uns einige gängige Konfigurationen und einzelne Elemente betrachten, die an Ihre spezifischen Bedürfnisse angepasst werden können.
Es wird vorausgesetzt, dass Sie bereits Erfahrung mit Kubernetes haben. Wenn nicht, warum schauen Sie sich dann nicht den an und starten Sie Ihr erstes Cluster?
Autoren
- ist Site Reliability Engineer im Camunda Cloud-Team;
- ist DevOps-Ingenieur bei Camunda.
Kurz gesagt:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Nun, wahrscheinlich hat das nicht funktioniert, da Sie skaffold und kustomize nicht installiert haben. Lesen Sie dann weiter!
Was ist Camunda BPM
Camunda BPM ist eine Open-Source-Plattform zur Verwaltung von Geschäftsprozessen und Automatisierung von Entscheidungen, die Geschäftsanwender und Softwareentwickler zusammenbringt. Sie eignet sich hervorragend zur Koordinierung und Zusammenführung von Menschen, (Micro-)Diensten oder sogar Bots! Weitere Informationen über verschiedene Anwendungsmöglichkeiten finden Sie unter .
Warum Kubernetes verwenden
Kubernetes ist zum De-facto-Standard für den Betrieb moderner Anwendungen unter Linux geworden. Durch die Verwendung von Systemaufrufen anstelle der Emulation der Hardwareebene und den Kernfähigkeiten zur Verwaltung von Speicher und Kontextwechseln wird die Start- und Ladezeit auf ein Minimum reduziert. Der größte Vorteil liegt jedoch in der standardisierten API-Schnittstelle, die Kubernetes zur Anpassung der benötigten Infrastruktur für alle Anwendungen bietet: Speicher, Netzwerk und Monitoring. Im Juni 2020 feierte es sein 6-jähriges Bestehen und ist wahrscheinlich das zweitgrößte Open-Source-Projekt (nach Linux). In letzter Zeit stabilisiert es aktiv seine Funktionen nach einer schnellen Iteration in den letzten Jahren, da dies für Produktionslasten weltweit entscheidend wird.
Die Camunda BPM Engine kann sich problemlos mit anderen Anwendungen verbinden, die im selben Cluster ausgeführt werden, und Kubernetes bietet eine hervorragende Skalierbarkeit, die es ermöglicht, Infrastrukturkosten nur dann zu erhöhen, wenn es wirklich notwendig ist (und sie bei Bedarf leicht zu senken).
Die Qualität des Monitorings wird auch erheblich durch Werkzeuge wie Prometheus, Grafana, Loki, Fluentd und Elasticsearch verbessert, die es ermöglichen, alle Workloads des Clusters zentral zu überwachen. Heute werden wir betrachten, wie man einen Prometheus-Exporter in einer Java Virtual Machine (JVM) implementiert.
Ziele
Lassen Sie uns einige Bereiche betrachten, in denen wir das Docker-Image von Camunda BPM () so konfigurieren können, dass es gut mit Kubernetes zusammenarbeitet.
- Protokolle und Metriken;
- Datenbankverbindungen;
- Authentifizierung;
- Sitzungsmanagement.
Wir werden verschiedene Möglichkeiten zur Umsetzung dieser Ziele betrachten und den gesamten Prozess anschaulich demonstrieren.
Hinweis: Nutzen Sie die Enterprise-Version? Schauen Sie sich und aktualisieren Sie die Links zu den Images bei Bedarf an.
Entwicklung des Workflows
In dieser Demonstration verwenden wir Skaffold, um Docker-Images mit Google Cloud Build zu erstellen. Es bietet eine gute Unterstützung für verschiedene Tools (wie Kustomize und Helm), CI-Tools und Build-Tools sowie Infrastruktur-Anbieter. Die Datei skaffold.yaml.tmpl enthält Konfigurationen für Google Cloud Build und GKE, was einen sehr einfachen Ansatz zur Implementierung von Infrastruktur auf Unternehmensebene gewährleistet.
make skaffold lädt den Dockerfile-Kontext in Cloud Build hoch, erstellt das Image und speichert es in GCR, bevor es die Manifestdateien auf Ihren Cluster anwendet. Das ist es, was make skaffold, aber Skaffold hat viele andere Funktionen.
Für YAML-Templates in Kubernetes verwenden wir Kustomize, um YAML-Overlays zu verwalten, ohne das gesamte Manifest zu verzweigen, so dass Sie git pull --rebase für zukünftige Verbesserungen nutzen können. Momentan ist es in kubectl und funktioniert ziemlich gut für solche Dinge.
Wir verwenden auch envsubst, um den Hostnamen und die GCP-Projekt-ID in *.yaml.tmpl-Dateien zu füllen. Sie können sehen, wie das funktioniert in makefile oder einfach weitermachen.
Voraussetzungen
- Arbeitscluster
- – um eigene Docker-Images zu erstellen und einfach in GKE zu deployen
- Eine Kopie dieses Codes
- Envsubst
Workflow mit Manifests
Wenn Sie Kustomize oder Skaffold nicht verwenden möchten, können Sie sich die Manifeste in generated-manifest.yaml ansehen und diese an den Workflow Ihrer Wahl anpassen.
Protokolle und Metriken
Prometheus ist der Standard zur Sammlung von Metriken in Kubernetes. Es nimmt die gleiche Rolle ein wie AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics und andere. Es ist quelloffen und bietet eine leistungsstarke Abfragesprache. Die Visualisierung übernehmen wir mit Grafana – es kommt mit einer großen Anzahl an Dashboards, die sofort einsatzbereit sind. Diese sind miteinander verbunden und relativ einfach zu installieren mit .
Standardmäßig verwendet Prometheus ein Pull-Modell /metrics, und das Hinzufügen von Sidecar-Containern dafür ist üblich. Leider werden JMX-Metriken am besten innerhalb der JVM registriert, weshalb Sidecar-Container nicht so effektiv sind. Lassen Sie uns den Open-Source JMX-Exporter von Prometheus in die JVM einbinden, indem wir ihn in das Container-Image einfügen, das den Pfad bereitstellt /metrics auf einem anderen Port.
Fügen Sie den Prometheus jmx_exporter in den Container ein
-- 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 wird Tomcat überwachen und seine Metriken im Prometheus-Format unter der Adresse anzeigen :9404/metrics
Exporter-Konfiguration
Der aufmerksame Leser mag sich fragen, woher prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны kommt. Wir fügen Tomcat als in Kubernetes hinzu und montieren es dann als Volume.
Zunächst fügen wir die Konfigurationsdatei des Exporters in unser Verzeichnis platform/config/
plattform/config
└── prometheus-jmx.yaml
Dann fügen wir in kustomization.yaml.tmpl:
-- plattform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
art: Kustomisierung
[...]
configMapGenerator:
- name: config
dateien:
- config/prometheus-jmx.yaml
Das wird jedes Element files[] als Element der ConfigMap-Konfiguration hinzufügen. ConfigMapGenerators sind gut, weil sie die Daten in der Konfiguration hashieren und einen Neustart des Pods auslösen, wenn diese sich ändern. Sie reduzieren auch den Umfang der Konfiguration in der Bereitstellung, da Sie den gesamten "Ordner" von Konfigurationsdateien in einem VolumeMount montieren können.
Schließlich müssen wir die ConfigMap als Volume an den Pod montieren:
-- platform/deployment.yaml
apiVersion: apps/v1
Art: Bereitstellung
[...]
spezifikation:
Vorlage:
spezifikation:
[...]
Volumes:
- name: config
configMap:
Name: config
Standardmodus: 0744
Container:
- Name: camunda-bpm
VolumeMounts:
- Einhängepfad: /etc/config/
Name: config
[...]
Wunderbar. Wenn Prometheus nicht für eine vollständige Bereinigung konfiguriert ist, müssen Sie möglicherweise angeben, dass es die Pods bereinigt. Benutzer des Prometheus Operators können verwenden service-monitor.yaml um zu beginnen. Überprüfen Sie Service-monitor.yaml, und bevor Sie fortfahren.
Die Verbreitung dieser Vorlage auf andere Anwendungsfälle
Alle Dateien, die wir in ConfigMapGenerator hinzufügen, werden im neuen Verzeichnis verfügbar sein. /etc/config. Sie können diese Vorlage erweitern, um alle anderen benötigten Konfigurationsdateien zu mounten. Sie können sogar ein neues Startskript einbinden. Sie können verwenden zum Montieren einzelner Dateien. Für die Aktualisierung von XML-Dateien ziehen Sie in Betracht anstatt sed. Es ist bereits im Image enthalten.
Protokolle
Gute Nachrichten! Anwendungsprotokolle sind bereits über stdout verfügbar, zum Beispiel über Flags. Fluentd (standardmäßig in GKE installiert) leitet Ihre Protokolle an Elasticsearch, Loki oder Ihre Unternehmensprotokollplattform weiter. Wenn Sie jsonify für Protokolle verwenden möchten, können Sie dem obigen Template folgen, um zu installieren .
Datenbank
Standardmäßig wird das Image eine H2-Datenbank enthalten. Das passt uns nicht, und wir werden Google Cloud SQL mit Cloud SQL Proxy verwenden — das wird später für interne Aufgaben benötigt. Dies ist eine einfache und zuverlässige Option, wenn Sie keine eigenen Vorlieben hinsichtlich der Datenbankkonfiguration haben. AWS RDS bietet einen ähnlichen Service.
Unabhängig von der von Ihnen gewählten Datenbank, es sei denn, es handelt sich um H2, müssen Sie die entsprechenden Umgebungsvariablen in platform/deploy.yaml. So sieht es ungefähr aus:
-- platform/deployment.yaml
apiVersion: apps/v1
Art: Bereitstellung
[...]
spezifikation:
Vorlage:
spezifikation:
[...]
Container:
- 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
[...]
Hinweis: Sie können Kustomize verwenden, um in verschiedenen Umgebungen mit Overlays bereitzustellen: .
Hinweis: Verwendung valueFrom: secretKeyRef. Bitte nutzen Sie auch während der Entwicklung, um Ihre Geheimnisse sicher zu speichern.
Es ist wahrscheinlich, dass Sie bereits ein bevorzugtes Kubernetes-Secret-Management-System haben. Wenn nicht, hier sind einige Optionen: sie mit KMS Ihres Cloud-Anbieters zu verschlüsseln und dann über den CD-Pipeline in K8S als Secrets einzuführen — wird sehr gut mit Kustomize-Secrets funktionieren. Es gibt auch andere Tools, wie dotGPG — sie erfüllen ähnliche Funktionen: , .
Ingress
Es sei denn, Sie entscheiden sich für Port-Forwarding, benötigen Sie einen konfigurierten Ingress-Controller. Wenn Sie kein () verwenden, wissen Sie wahrscheinlich bereits, dass Sie die erforderlichen Annotationen in ingress-patch.yaml.tmpl oder platform/ingress.yaml. Wenn Sie ingress-nginx verwenden und die nginx ingress class mit einem darauf verweisenden Lastenausgleich und externem DNS oder einem Platzhalter-DNS-Eintrag sehen, ist alles bereit. Andernfalls konfigurieren Sie den Ingress-Controller und DNS oder überspringen Sie diese Schritte und lassen Sie die Verbindung direkt zum Pod.
TLS
Wenn Sie verwenden oder kube-lego und letsencrypt – die Zertifikate für den neuen Zugang werden automatisch erhalten. Andernfalls öffnen Sie ingress-patch.yaml.tmpl und konfigurieren Sie es nach Ihren Bedürfnissen.
Start!
Wenn Sie alles oben Genannte befolgt haben, sollte das Kommando make skaffold HOSTNAME= eine verfügbare Instanz in /camunda
starten. Wenn Sie den Zugang nicht über eine öffentliche URL bereitgestellt haben, können Sie ihn umleiten mit 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 etwas Zeit zur Überprüfung des Domainnamens. Danach können Sie die Protokolle mit verfügbaren Mitteln ü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
Autorisierung
Dies betrifft mehr die Konfiguration von Camunda BPM als Kubernetes, aber es ist wichtig zu beachten, dass die Authentifizierung im REST API standardmäßig deaktiviert ist. Sie können oder eine andere Methode verwenden, zum Beispiel . Sie können Configmaps und Volumes verwenden, um XML zu laden, oder xmlstarlet (siehe oben) verwenden, um bestehende Dateien im Image zu bearbeiten, sowie wget oder sie mit einem Init-Container und einem gemeinsamen Volume hochzuladen.
Sitzungsmanagement
Wie viele andere Anwendungen verarbeitet Camunda BPM Sitzungen in der JVM, daher können Sie, wenn Sie mehrere Replikate starten möchten, Sticky Sessions aktivieren (), die bestehen bleiben, bis die Replik verschwindet, oder setzen Sie das Max-Age-Attribut für Cookies. Als zuverlässigere Lösung können Sie einen Session Manager in Tomcat bereitstellen. Lars hat einen 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 '/^/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
Hinweis: xmlstarlet kann anstelle von sed verwendet werden
Wir haben vor Google Cloud Memorystore verwendet, mit (unterstützt Redis) für seinen Betrieb.
Skalierung
Wenn Sie bereits mit den Sessions vertraut sind, kann die erste (und oft letzte) Einschränkung für die Skalierung von Camunda BPM die Verbindung zur Datenbank sein. Teilweise Konfiguration ist bereits "" verfügbar. Außerdem deaktivieren wir initialSize in der Datei settings.xml. Fügen Sie hinzu und Sie können die Anzahl der Pods problemlos automatisch skalieren.
Anfragen und Einschränkungen
Im platform/deployment.yaml Sie werden sehen, dass wir das Ressourcenfeld fest codiert haben. Dies funktioniert gut mit HPA, kann jedoch zusätzliche Konfiguration erfordern. Dafür eignet sich der Kustomize-Patch. Siehe ingress-patch.yaml.tmpl und ./kustomization.yaml.tmpl
Ausgabe
So haben wir Camunda BPM auf Kubernetes mit Prometheus-Metriken, Protokollen, einer H2-Datenbank, TLS und Ingress eingerichtet. Wir haben JAR-Dateien und Konfigurationsdateien unter Verwendung von ConfigMaps und Dockerfile hinzugefügt. Wir haben über den Datenaustausch zwischen Volumes und Umgebungsvariablen aus Geheimnissen gesprochen. Darüber hinaus haben wir einen Überblick über die Konfiguration von Camunda für mehrere Replikate und authentifizierte APIs gegeben.
Links
github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes
│
├── generated-manifest.yaml <- Manifest zur Verwendung ohne Kustomize
├── Bilder
│ └── camunda-bpm
│ └── Dockerfile <- Overlay-Docker-Image
├── ingress-patch.yaml.tmpl <- standortspezifische Ingress-Konfiguration
├── kustomization.yaml.tmpl <- Hauptkustomisierung
├── Makefile <- Make-Ziele
├── namespace.yaml
├── Plattform
│ ├── Konfiguration
│ │ └── prometheus-jmx.yaml <- Prometheus-Exporter-Konfigurationsdatei
│ ├── deployment.yaml <- Hauptbereitstellung
│ ├── ingress.yaml
│ ├── kustomization.yaml <- "Basis"-Kustomisierung
│ ├── service-monitor.yaml <- Beispiel Prometheus-Operator-Konfiguration
│ └── service.yaml
└── skaffold.yaml.tmpl <- Skaffold-Direktiven
05.08.2020, Übersetzung Alastair Firth, Lars Lange
Quelle: habr.com
