Verwenden Sie Kubernetes? Möchten Sie Ihre Camunda BPM-Instanzen von virtuellen Maschinen migrieren oder vielleicht einfach auf Kubernetes ausführen? Lassen Sie uns einige gängige Konfigurationen und Komponenten betrachten, die auf Ihre spezifischen Bedürfnisse angepasst werden können.
Es wird davon ausgegangen, dass Sie bereits Erfahrung mit Kubernetes haben. Wenn nicht, warum nicht einen Blick auf werfen und Ihren ersten Cluster starten?
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
Okay, das hat wahrscheinlich 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 für die Geschäftsprozessverwaltung und Entscheidungsautomatisierung, die Geschäftsbenutzer und Softwareentwickler zusammenbringt. Sie eignet sich hervorragend für die Koordination und Integration von Menschen, (Mikro-)Diensten oder sogar Bots! Erfahren Sie mehr über verschiedene Anwendungsmöglichkeiten unter .
Warum Kubernetes verwenden
Kubernetes ist der De-facto-Standard für den Einsatz moderner Anwendungen auf Linux. Durch den Einsatz von Systemaufrufen anstelle von Hardware-Emulation und die Möglichkeiten des Kernels zur Verwaltung von Speicher und Task-Switching werden Ladezeiten und Startzeiten auf ein Minimum reduziert. Der größte Vorteil liegt jedoch im standardisierten API-Interface, das Kubernetes zur Verfügung stellt, um die für alle Anwendungen erforderliche Infrastruktur wie Speicherung, Netzwerk und Monitoring zu konfigurieren. Im Juni 2020 feierte Kubernetes seinen sechsten Geburtstag und ist damit wahrscheinlich das zweitgrößte Open-Source-Projekt nach Linux. In letzter Zeit stabilisiert es aktiv seine Funktionen nach schnellen Iterationen in den letzten Jahren, da dies für Produktionslasten weltweit von entscheidender Bedeutung wird.
Die Camunda BPM Engine kann problemlos mit anderen Anwendungen, die im selben Cluster laufen, verbunden werden, während Kubernetes hervorragende Skalierbarkeit bietet, die es ermöglicht, die Infrastrukturkosten nur dann zu erhöhen, wenn dies wirklich erforderlich ist (und sie leicht zu reduzieren, wenn nötig).
Die Qualität des Monitorings wird auch erheblich verbessert durch Tools wie Prometheus, Grafana, Loki, Fluentd und Elasticsearch, die es ermöglichen, alle Workloads des Clusters zentral zu überwachen. Heute werden wir besprechen, wie man einen Prometheus-Exporter in eine Java Virtual Machine (JVM) integriert.
Ziele
Lassen Sie uns einige Bereiche betrachten, in denen wir das Docker-Image von Camunda BPM () so anpassen können, dass es gut mit Kubernetes interagiert.
- Protokolle und Metriken;
- Datenbankverbindungen;
- Authentifizierung;
- Sitzungsmanagement.
Wir werden mehrere Ansätze zur Umsetzung dieser Ziele betrachten und den gesamten Prozess anschaulich demonstrieren.
Hinweis: Verwenden Sie die Enterprise-Version? Sehen Sie sich an und aktualisieren Sie bei Bedarf die Links zu den Images.
Workflow-Entwicklung
In dieser Demonstration werden wir Skaffold verwenden, um Docker-Images mit Google Cloud Build zu erstellen. Es bietet eine gute Unterstützung für verschiedene Tools (wie Kustomize und Helm), CI- und Build-Tools sowie Infrastrukturprovider. Die Datei skaffold.yaml.tmpl enthält Einstellungen für Google Cloud Build und GKE, was einen sehr einfachen Weg bietet, Infrastruktur auf Unternehmensebene einzurichten.
make skaffold lädt den Dockerfile-Kontext in Cloud Build hoch, erstellt ein Image und speichert es in GCR, und wendet dann die Manifeste auf Ihrem Cluster an. Das ist es, was es macht make skaffold, aber Skaffold hat viele weitere Möglichkeiten.
Für YAML-Vorlagen in Kubernetes verwenden wir Kustomize, um YAML-Overlays zu verwalten, ohne das gesamte Manifest zu verzweigen, was Ihnen ermöglicht, git pull --rebase für weitere Verbesserungen. Momentan ist es in kubectl und funktioniert ziemlich gut für solche Dinge.
Außerdem verwenden wir envsubst, um den Hostnamen und die GCP-Projekt-ID in den Dateien * .yaml.tmpl auszufüllen. Sie können sehen, wie das funktioniert in makefile oder einfach weitermachen.
Voraussetzungen
- Arbeitscluster
- — um eigene Docker-Images zu erstellen und leicht in GKE bereitzustellen
- Eine Kopie dieses Codes
- Envsubst
Workflow mit Manifeste
Wenn Sie kustomize oder skaffold nicht verwenden möchten, können Sie die Manifeste in generated-manifest.yaml sehen und sie an den Workflow Ihrer Wahl anpassen.
Protokolle und Metriken
Prometheus ist der Standard zur Erfassung 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 Open Source und bietet eine leistungsstarke Abfragesprache. Die Visualisierung übernehmen wir mit Grafana — es wird mit einer Vielzahl von vorgefertigten Dashboards geliefert. Diese sind miteinander verbunden und relativ einfach in der Einrichtung. .
Standardmäßig verwendet Prometheus ein Pull-Modell. /metrics, und das Hinzufügen von Sidecar-Containern hierfür ist gängig. Leider werden JMX-Metriken am besten innerhalb der JVM erfasst, sodass Sidecar-Container nicht so effektiv sind. Lassen Sie uns einen Open-Source-Exporter von Prometheus zur JVM hinzufügen, indem wir ihn zum Container-Image hinzufügen, das einen Pfad bereitstellt /metrics auf einem anderen Port.
Fügen Sie den 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 unter :9404/metrics
die Konfiguration des Exporters ein.
Aufmerksame Leser könnten sich fragen, woher das kommt prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны . Wir fügen tomcat als in Kubernetes hinzu und mounten es dann als Volume.
Zunächst fügen wir die Konfigurationsdatei des Exporters in unser Verzeichnis platform/config/
plattform/konfiguration
└── prometheus-jmx.yaml
Dann fügen wir in kustomization.yaml.tmpl:
-- plattform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
Dateien:
- config/prometheus-jmx.yaml
Dies wird jedes Element files[] als Konfigurationselement in die ConfigMap hinzufügen. ConfigMapGenerators sind nützlich, da sie die Daten in der Konfiguration hashen und einen Pod neu starten, falls es Änderungen gibt. Sie reduzieren auch die Menge an Konfiguration im Deployment, da Sie den gesamten "Ordner" von Konfigurationsdateien in einem einzigen VolumeMount mounten können.
Schließlich müssen wir die ConfigMap als Volume an den Pod mounten:
-- plattform/deployment.yaml
apiVersion: apps/v1
art: Bereitstellung
[...]
spezifikation:
vorlage:
spezifikation:
[...]
volumen:
- name: config
configMap:
name: config
standardModus: 0744
container:
- name: camunda-bpm
volumeMounts:
- mountPfad: /etc/config/
name: config
[...]
Gut. Wenn Prometheus nicht für die vollständige Bereinigung konfiguriert ist, müssen Sie ihm möglicherweise sagen, dass er die Pods bereinigen soll. Benutzer des Prometheus Operators können service-monitor.yaml verwenden, um zu starten. Schauen Sie sich an 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 erforderlichen Konfigurationsdateien zu mounten. Sie können sogar ein neues Startskript mounten. Auch für das Mounten einzelner Dateien. Für die Aktualisierung von XML-Dateien ziehen Sie in Betracht, anstatt von sed zu verwenden. Es ist bereits im Image enthalten.
Protokolle
Gute Nachrichten! Die Anwendungsprotokolle sind bereits über stdout verfügbar, zum Beispiel durch kubectl logs. Fluentd (es ist standardmäßig in GKE installiert) leitet Ihre Protokolle an Elasticsearch, Loki oder Ihre Unternehmensprotokollplattform weiter. Wenn Sie jsonify für die Protokolle verwenden möchten, können Sie dem obigen Template für die Installation folgen. .
Datenbank
Standardmäßig wird das Image eine H2-Datenbank haben. 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 Präferenzen für die Datenbankkonfiguration haben. AWS RDS bietet einen ähnlichen Dienst.
Unabhängig von der von Ihnen gewählten Datenbank, solange es sich nicht um H2 handelt, müssen Sie die entsprechenden Umgebungsvariablen in platform/deploy.yaml. Das sieht ungefähr so aus:
-- plattform/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 Overlay zu deployen: .
Hinweis: Verwendung valueFrom: secretKeyRef. Bitte verwenden Sie sogar während der Entwicklung, um Ihre Geheimnisse sicher aufzubewahren.
Es ist sehr wahrscheinlich, dass Sie bereits ein bevorzugtes Kubernetes Secret Management System haben. Wenn nicht, hier einige Optionen: Verschlüsselung mit dem KMS Ihres Cloud-Anbieters und dann Bereitstellung als Secrets in K8S über eine CD-Pipeline — — wird sehr gut zusammen mit Kustomize Secrets funktionieren. Es gibt auch andere Tools wie dotGPG — diese bieten ähnliche Funktionen: , .
Ingress
Es sei denn, Sie entscheiden sich für die Portweiterleitung, benötigen Sie einen eingerichteten Ingress Controller. Wenn Sie nicht 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 eine nginx ingress-Klasse mit einem Load Balancer sehen, der auf ihn zeigt und auf externes DNS oder ein Platzhalter-DNS-Eintrag verweist, sind Sie bereit. Andernfalls konfigurieren Sie den Ingress-Controller und DNS oder überspringen Sie diese Schritte und lassen Sie eine direkte Verbindung zum Pod.
TLS
Wenn Sie verwenden oder kube-lego und letsencrypt – die Zertifikate für den neuen Ingress werden automatisch bereitgestellt. Andernfalls öffnen Sie ingress-patch.yaml.tmpl und passen Sie es an Ihre Bedürfnisse an.
Start!
Wenn Sie alles oben Genannte befolgt haben, sollte der Befehl make skaffold HOSTNAME= einen verfügbaren Instanz in /camunda
starten. Wenn Sie den Ingress nicht über eine öffentliche URL bereitgestellt haben, können Sie ihn mit localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 findet man localhost:8080/camunda
weiterleiten. Warten Sie ein paar Minuten, bis Tomcat vollständig einsatzbereit ist. Cert-manager benötigt einige Zeit, um den Domainnamen zu überprüfen. Danach können Sie die Protokolle mit verfügbaren Tools überwachen – zum Beispiel 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
Die nächsten Schritte
Autorisierung
Das bezieht sich mehr auf die Konfiguration von Camunda BPM als auf Kubernetes, aber es ist wichtig zu beachten, dass die Authentifizierung in der REST API standardmäßig deaktiviert ist. Sie können oder verwenden Sie eine andere Methode, wie zum Beispiel . Sie können Configmaps und Volumes verwenden, um XML zu laden, oder xmlstarlet (siehe oben) um bestehende Dateien im Image zu bearbeiten, sowie entweder wget nutzen oder diese mit einem Init-Container und einem gemeinsamen Volume hochladen.
Sitzungsmanagement
Wie viele andere Anwendungen verarbeitet Camunda BPM Sitzungen in der JVM, weshalb Sie, wenn Sie mehrere Replikate ausführen möchten, Sticky Sessions aktivieren können (), die bestehen bleiben, solange die Replik verschwindet, oder Sie können das Max-Age-Attribut für die Cookies festlegen. Eine zuverlässigeren Lösung wäre, im Tomcat einen Session Manager bereitzustellen. Lars hat dazu Informationen, aber etwa folgendes:
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: man kann xmlstarlet anstelle von sed verwenden
Wir haben vor Google Cloud Memorystore verwendet, mit (unterstützt Redis) für dessen Betrieb.
Skalierung
Wenn Sie bereits mit Sessions vertraut sind, könnte die erste (und oft letzte) Einschränkung für das Scaling von Camunda BPM die Verbindung zur Datenbank sein. Teilweise Konfiguration ist bereits "" verfügbar. Lassen Sie uns auch `intialSize` in der Datei `settings.xml` deaktivieren. Fügen Sie hinzu, und Sie können die Anzahl der Pods problemlos automatisch skalieren.
Anfragen und Einschränkungen
In platform/deployment.yaml Sie werden sehen, dass wir das Feld Ressourcen fest codiert haben. Das funktioniert gut mit HPA, kann aber zusätzliche Anpassungen erfordern. Hierfür ist ein Kustomize-Patch geeignet. Siehe ingress-patch.yaml.tmpl und ./kustomization.yaml.tmpl
Fazit
So haben wir Camunda BPM auf Kubernetes mit Prometheus-Metriken, Protokollen, einer H2-Datenbank, TLS und Ingress installiert. Wir haben JAR-Dateien und Konfigurationsdateien eingefügt, indem wir ConfigMaps und Dockerfile verwendet haben. Wir haben über den Datenaustausch mit Volumes und direkt in Umgebungsvariablen aus Secrets gesprochen. Darüber hinaus haben wir einen Überblick über die Konfiguration von Camunda für mehrere Replikate und eine authentifizierte API 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-Targets
├── namespace.yaml
├── Plattform
│ ├── Konfiguration
│ │ └── prometheus-jmx.yaml <- Konfigurationsdatei für Prometheus-Exporter
│ ├── deployment.yaml <- Hauptdeployment
│ ├── ingress.yaml
│ ├── kustomization.yaml <- "Basis" Kustomisierung
│ ├── service-monitor.yaml <- Beispielkonfiguration für Prometheus-Operator
│ └── service.yaml
└── skaffold.yaml.tmpl <- Skaffold-Direktiven
05.08.2020, Übersetzung Alastair Firth, Lars Lange
Quelle: habr.com
