🥇Camunda BPM indítása Kubernetes-ben

Kubernetes-t használsz? Készen állsz átvinni a Camunda BPM példányaidat virtuális gépekről, vagy egyszerűen csak kipróbálnád futtatni őket Kubernetes-en? Nézzük meg néhány elterjedt konfigurációt és különböző elemeket, amelyeket az adott igényeidhez igazíthatsz.

Feltételezhetjük, hogy már korábban is használtad a Kubernetes-t. Ha nem, akkor miért ne néznél be a a kézikönyvet és indítanád el az első klaszteredet?

Authors

Alastair Firth (Alastair Firth) – a Camunda Cloud csapatának időbeli megbízhatósági mérnöke (Site Reliability Engineer);
Lars Lange (Lars Lange) – DevOps mérnök a Camundánál.

Röviden:

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

Rendben, valószínűleg ez nem működött, mivel a skaffold és a kustomize nincsenek telepítve. Nos, akkor folytasd az olvasást!

Mi az a Camunda BPM

A Camunda BPM egy nyílt forráskódú platform az üzleti folyamatok kezelésére és a döntések automatizálására, amely összeköti az üzleti felhasználókat és a szoftverfejlesztőket. Tökéletes a személyek, (mikro) szolgáltatások vagy akár botok koordinálására és összegyűjtésére! További információt a különböző használati lehetőségekről kaphatsz a linkre kattintva.

Miért használd a Kubernetes-t

A Kubernetes a de facto szabvány a modern alkalmazások Linux-alapú futtatásához. A rendszerhívások használatának köszönhetően a hardver szintű emuláció helyett, valamint a memóriakezelés és a feladatváltás képességeinek kihasználásával a betöltési és indítási idő minimalizálható. A legnagyobb előny azonban a szabványos API-interfész, amit a Kubernetes biztosít a szükséges infrastruktúra beállításához, amely minden alkalmazáshoz szükséges: tárolás, hálózat és megfigyelés. 2020 júniusában ünnepelte a 6. születésnapját, és valószínűleg a második legnagyobb nyílt forráskódú projekt (a Linux után). Az utóbbi időben aktívan stabilizálja a funkcióit a legutóbbi gyors iterációk után, mivel ez kritikus fontosságú a világszerte zajló termelési terhelések számára.

A Camunda BPM Engine könnyen csatlakoztatható más, ugyanabban a klaszterben futó alkalmazásokhoz, míg a Kubernetes kiváló skálázhatóságot biztosít, lehetővé téve az infrastruktúra költségeinek növelését csak akkor, amikor valóban szükséges (és könnyen csökkenthetőek, ha szükséges).

A monitoring quality is significantly enhanced by tools such as Prometheus, Grafana, Loki, Fluentd, and Elasticsearch, which allow centralized viewing of all cluster workloads. Today, we will explore how to implement a Prometheus exporter in a Java (JVM) virtual machine.

Célok

Let’s look at a few areas where we can configure the Camunda BPM Docker image (github), so that it interacts well with Kubernetes.

Logs and metrics;
Database connections;
Authentication;
Session management.

We will discuss several ways to achieve these goals and visually demonstrate the whole process.

Megjegyzés: Using an Enterprise version? Check out itt and update image links if necessary.

Workflow development

In this demonstration, we will use Skaffold to build Docker images using Google Cloud Build. It has good support for various tools (such as Kustomize and Helm), CI and build tools, as well as infrastructure providers. The skaffold.yaml.tmpl file includes settings for Google Cloud Build and GKE, providing a very simple way to launch enterprise-grade infrastructure.

make skaffold will upload the Dockerfile context to Cloud Build, create the image, and save it to GCR, followed by applying manifests to your cluster. This is what make skaffolddoes, but Skaffold has many other capabilities.

For yaml templates in Kubernetes, we use kustomize to manage yaml overlays without branching the entire manifest, allowing you to use git pull --rebase for further improvements. It is now in kubectl and works fairly well for such tasks.

We also use envsubst to populate the host name and GCP project ID in * .yaml.tmpl files. You can see how it works in makefile or simply move on.

Prerequisites

Working cluster Kubernetes
Kustomize
Skaffold — to build your own Docker images and easily deploy them in GKE.
A copy of this code
Envsubst

Workflow with manifests

If you don't want to use kustomize or skaffold, you can refer to the manifests in generated-manifest.yaml and adapt them to a workflow of your choice.

Logs and metrics

A Prometheus a Kubernetesben a metrikák gyűjtésének szabványává vált. Hasonló szerepet tölt be, mint az AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics és mások. Nyílt forráskódú és egy erőteljes kérdezési nyelvvel rendelkezik. A vizualizációt a Grafana-ra bízunk — amely nagy mennyiségű kész dashboarddal érkezik. Ezek összekapcsolódnak egymással, és viszonylag egyszerűen telepíthetők. prometheus-operator.

Alapértelmezés szerint a Prometheus a lehívási modellt használja. /metrics, és a sidecar konténerek hozzáadása erre általános gyakorlat. Sajnos a JMX metrikák legjobban a JVM-en belül regisztrálhatók, ezért a sidecar konténerek nem olyan hatékonyak. Csatlakoztassuk a jmx_exporter nyílt forráskódú Prometheus-t a JVM-hez, úgy, hogy hozzáadjuk a konténer képéhez, amely biztosítja az utat /metrics másik porton.

Adja hozzá a Prometheus jmx_exporter-t a konténerhez.

-- 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

Nos, ez könnyű volt. Az exporter figyelemmel kíséri a tomcat-ot és a Prometheus formátumban megjeleníti a metrikákat a következő címen: :9404/metrics

Az exporter konfigurálása

A figyelmes olvasó esetleg megkérdezheti, honnan származik a prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны itt. A tomcat-ot hozzáadjuk a ConfigMap Kubernetesben, majd mountoljuk mint egy kötetet.

Először is, hozzáadjuk az exporter konfigurációs fájlját a platform/config/ könyvtárunkhoz.

platform/config └── prometheus-jmx.yaml

Ezután hozzáadjuk ConfigMapGenerator be. kustomization.yaml.tmpl:

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

Ez minden egyes elemet hozzáad a files[] configurációs ConfigMap elemként. A ConfigMapGenerátorok előnye, hogy hash-elik az adatokat a konfigurációban, és újraindítják a pod-ot, ha az megváltozik. Ezenkívül csökkentik a Deployment konfigurációjának mennyiségét, mivel egyetlen VolumeMount-on belül mountolhatja az összes konfigurációs fájl 'mappát'.

Végül, mountolnunk kell a ConfigMap-et mint kötetet a podhoz:

-- 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 [...]

Tökéletes. Ha a Prometheus nincs beállítva teljes tisztításra, lehet, hogy meg kell mondania neki, hogy tisztítsa meg a podokat. A Prometheus Operator felhasználói használhatják a service-monitor.yaml az indításhoz. Tanulmányozza a Service-monitor.yaml, operátor tervezését és ServiceMonitorSpec mielőtt hozzáfogna.

Ezen sablon elterjesztése más használati esetekre

Minden fájl, amelyet hozzáadunk a ConfigMapGenerator-hez, elérhető lesz az új könyvtárban. /etc/config. Bővítse ki ezt a sablont bármilyen egyéb szükséges konfigurációs fájl csatolásához. Még új indító scriptet is csatolhat. Használhatja subPath különböző fájlok csatolásához. XML fájlok frissítéséhez érdemes megfontolni a xmlstarlet használatát a sed helyett. Ez a kép már tartalmazza.

Naplók

Remek hír! Az alkalmazásnaplók már elérhetők a stdout-on keresztül, például a A kubectl logs. A Fluentd (alapértelmezetten telepítve van a GKE-ben) átirányítja a naplóit az Elasticsearch-ra, Loki-ra vagy a vállalati naplóplatformjára. Ha szeretné a naplókat jsonify formátumban használni, kövesse a fenti sablon telepítési útmutatóját. logback.

Adatbázis

Alapértelmezés szerint a kép H2 adatbázist használ. Ez számunkra nem megfelelő, és a Google Cloud SQL-t Cloud SQL Proxy-val fogjuk használni - ez szükséges lesz a belső feladatokhoz. Ez egy egyszerű és megbízható lehetőség, ha nincsenek saját preferenciái az adatbázis beállításához. Az AWS RDS hasonló szolgáltatást kínál.

Függetlenül attól, hogy melyik adatbázist választja, hacsak nem H2, meg kell adnia a megfelelő környezeti változókat a platform/deploy.yaml. Ez körülbelül így néz ki:

-- platform\/deployment.yaml apiVersion: apps/v1 kind: Deployment [...] spec: template: spec: [...] containers: - name: camunda-bpm környezet: - név: DB_DRIVER érték: org.postgresql.Driver - név: DB_URL érték: jdbc:postgresql://postgres-proxy.db:5432/process-engine - név: DB_USERNAME értékForrás: titkosKulcsHivatkozás: név: cambpm-db-credentials kulcs: db_username - név: DB_PASSWORD értékForrás: titkosKulcsHivatkozás: név: cambpm-db-credentials kulcs: db_password [...]

Megjegyzés: Használhatja a Kustomize-ot különböző környezetekbe való telepítéshez overlay segítségével: példám.

Megjegyzés: használat valueFrom: secretKeyRef. Kérjük, használja ezt a Kubernetes funkciót még a fejlesztés során is, hogy biztonságban tartsa titkait.

Valószínűleg már van egy preferált Kubernetes titkos kezelő rendszere. Ha nincs, itt van néhány lehetőség: a titkai KMS-en keresztüli titkosítása a felhőszolgáltatójával, majd ezek integrálása K8S-be mint titkok a CD folyamaton keresztül - MozillaSOPS nagyon jól működik a Kustomize titkosítjaival együtt. Vannak más eszközök is, mint a dotGPG - ezek hasonló funkciókat látnak el: HashiCorp Vault, Kustomize Titkosérték Pluginok.

Ingress

Ha egy lokális port átirányítást nem kíván használni, akkor beállított Ingress Controller szükséges. Ha nem használja ingress-nginx (Helm chart) akkor valószínűleg már tudja, hogy szükséges beállítania a megfelelő annotációkat a ingress-patch.yaml.tmpl vagy platform/ingress.yaml. Ha az ingress-nginx-t használod, és látod, hogy az nginx ingress osztály a hozzá tartozó terheléselosztóval és egy külső DNS-rekorddal vagy helyettesítő DNS-rekorddal van beállítva, akkor minden kész. Ellenkező esetben állítsd be az Ingress Controller-t és a DNS-t, vagy hagyd ki ezeket a lépéseket, és tartsd meg a közvetlen kapcsolatot a poddal.

TLS

Ha használja cert-manager vagy kube-lego és letsencrypt – az új belépési tanúsítványok automatikusan meg lesznek szerezve. Ellenkező esetben nyisd meg ingress-patch.yaml.tmpl és állítsd be az igényeid szerint.

Indítás!

Ha mindent pontosan a fentiek szerint követtél, akkor a parancs make skaffold HOSTNAME=<<te.pelda.com> el kell indítania egy elérhető példányt a <hostname>/camunda

Ha nem állítottad be a belépést nyilvános URL-címen, akkor átirányíthatod az alábbiakkal localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 Gyorsan emlékezzünk vissza, hogyan működik a moduláris aritmetika. Az óra már egy ismert koncepció. Az órák használata localhost:8080/camunda

Várj néhány percet, amíg tomcat teljesen felkészül. A cert-managernek egy kis időre van szüksége a domain név ellenőrzéséhez. Ezután a logok követésére használhatod az elérhető eszközöket, például egy olyan eszközt, mint a kubetail, vagy egyszerűen a kubectl-t:

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

Következő lépések

Engedélyezés

Ez inkább a Camunda BPM beállításához kapcsolódik, mint a Kuberneteshez, de fontos megjegyezni, hogy alapértelmezés szerint a REST API hitelesítés ki van kapcsolva. Engedélyezheted az alapvető hitelesítést, vagy használhatsz más módszert, például JWT. Használhatsz configmapeket és köteteket az xml betöltésére, vagy xmlstarlet-tel (lásd fent) módosíthatod a meglévő fájlokat a képen, illetve használhatsz wget-et, vagy letöltheted őket init konténerrel és közös kötet használatával.

Munkamenetek kezelése

Mint sok más alkalmazás, a Camunda BPM is a JVM-ben kezeli a munkameneteket, ezért ha több replikát szeretnél futtatni, engedélyezheted a sticky sessions-t (például az ingress-nginx-hez,), amelyek addig léteznek, amíg a replikát nem törlik, vagy beállíthatod a Max-Age attribútumot a sütikhez. Megbízhatóbb megoldásként Session Manager-t is telepíthetsz a Tomcat-be. Larsnak van külön cikke erről a témáról, de valami ilyesmi: sed -i '/^<\/Context>/i

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/ &&

<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="redis://redis-proxy.db:22121"
sticky="false"
sessionBackupAsync="false"
storageKeyPrefix="context"
lockingMode="auto"
: xmlstarlet-t is használható a sed helyett
/>' conf/context.xml

MegjegyzésHasználjuk a

twemproxy-t a Google Cloud Memorystore előtt, a memcached-session-manager (támogatja a Redis-t) futtatásához. (поддерживает Redis) для его запуска.

Skálázhatóság

Ha már tisztában van a session-ökkel, akkor az első (és gyakran az utolsó) korlát, amely a Camunda BPM skálázásával kapcsolatban felmerülhet, az adatbázis kapcsolata lehet. A részleges beállítás már „dobozból” elérhető. Ezenkívül kapcsoljuk ki az initialSize-t a settings.xml fájlban. Adjon hozzá HorizontalPodAutoscaler (HPA) és könnyen automatikusan skálázhatja a podok számát.

Kérések és korlátozások

A platform/deployment.yaml látni fogja, hogy a források mezőt keményen kódoltuk. Ez jól működik a HPA-val, de további beállításra lehet szükség. Ehhez használja a kustomize patch-et. Lásd a ingress-patch.yaml.tmpl és ./kustomization.yaml.tmpl

Következtetés

Így telepítettük a Camunda BPM-et Kubernetesre Prometheus metrikákkal, naplókkal, H2 adatbázissal, TLS-sel és Ingress-szel. Hozzáadtuk a jar fájlokat és a konfigurációs fájlokat ConfigMap-ek használatával, valamint Dockerfile-lal. Beszélgettünk az adatok cseréjéről a kötetek között és közvetlenül környezeti változókként titkokból. Ezen kívül áttekintettük a Camunda konfigurálását több replikációra és az azonosított API-ra.

Hivatkozások

github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes │ ├── generated-manifest.yaml <- manifest az önálló használathoz kustomize nélkül ├── képek │ └── camunda-bpm │ └── Dockerfile <- overlay docker kép ├── ingress-patch.yaml.tmpl <- helyspecifikus ingress konfiguráció ├── kustomization.yaml.tmpl <- fő Kustomization ├── Makefile <- make célok ├── namespace.yaml ├── platform │ ├── config │ │ └── prometheus-jmx.yaml <- prometheus exporter konfigurációs fájl │ ├── deployment.yaml <- fő telepítés │ ├── ingress.yaml │ ├── kustomization.yaml <- "base" kustomization │ ├── service-monitor.yaml <- példa prometheus-operator konfiguráció │ └── service.yaml └── skaffold.yaml.tmpl <- skaffold direktívák