🥇Spuštění Camunda BPM v Kubernetes

Používáte Kubernetes? Chcete přesunout své instance Camunda BPM z virtuálních strojů, nebo možná jen vyzkoušet jejich spuštění na Kubernetes? Pojďme se podívat na některé běžné konfigurace a jednotlivé prvky, které lze přizpůsobit vašim konkrétním potřebám.

Předpokládá se, že už jste Kubernetes dříve používali. Pokud ne, proč se nepodívat na průvodce a nespustit svůj první cluster?

Autoři

Alastair Firth je senior site reliability engineer v týmu Camunda Cloud;
Lars Lange je DevOps inženýr v Camunda.

Abych to shrnul:

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

Dobře, pravděpodobně to nefungovalo, protože nemáte nainstalované skaffold a kustomize. Takže čtěte dál!

Co je Camunda BPM

Camunda BPM je platforma s otevřeným zdrojovým kódem pro správu podnikových procesů a automatizaci rozhodování, která spojuje obchodní uživatele a vývojáře softwaru. Je ideální pro koordinaci a spojování lidí, (mikro) služeb nebo dokonce botů! Více o různých možnostech použití se dočtete na odkazu.

Proč používat Kubernetes

Kubernetes se stal de facto standardem pro provoz moderních aplikací v Linuxu. Díky používání systémových volání místo emulace hardwarového úrovně a možnostem jádra řídit paměť a přepínání úloh, je doba načítání a doba spuštění minimalizována. Největší výhodou však může být standardní API, které Kubernetes poskytuje pro konfiguraci potřebné infrastruktury pro všechny aplikace: úložiště, síť a monitoring. V červnu 2020 oslavil své 6. narozeniny a je to pravděpodobně druhý největší projekt s otevřeným zdrojovým kódem (po Linuxu). V poslední době se aktivně stabilizuje jeho funkčnost po rychlé iteraci posledních několika let, jelikož to je kriticky důležité pro produkční zátěže po celém světě.

Camunda BPM Engine se snadno připojuje k dalším aplikacím běžícím ve stejném clusteru, zatímco Kubernetes zajišťuje vynikající škálovatelnost, což umožňuje zvyšovat náklady na infrastrukturu pouze tehdy, když je to skutečně nutné (a snadno je snižovat podle potřeby).

Kvalita monitorování se také výrazně zlepšuje pomocí nástrojů jako Prometheus, Grafana, Loki, Fluentd a Elasticsearch, které umožňují centralizované zobrazení všech pracovních zátěží clusteru. Dnes se podíváme, jak implementovat exportéra Prometheus do virtuálního stroje Java (JVM).

Cíle

Podívejme se na několik oblastí, ve kterých můžeme nastavit Docker obraz Camunda BPM (github), aby dobře spolupracoval s Kubernetes.

Žurnály a metriky;
Připojení k databázi;
Autentizace;
Správa relací.

Prozkoumáme několik způsobů, jak těchto cílů dosáhnout a názorně ukážeme celý proces.

Poznámka: Používáte verzi Enterprise? Podívejte se zde a aktualizujte odkazy na obrazy, pokud je to nutné.

Vývoj pracovního postupu

V této ukázce budeme používat Skaffold k vytváření Docker obrazů pomocí Google Cloud Build. Má dobrou podporu různých nástrojů (jako Kustomize a Helm), CI a nástrojů pro sestavování, stejně jako dodavatelů infrastruktury. Konfigurační soubor skaffold.yaml.tmpl obsahuje nastavení pro Google Cloud Build a GKE, což zajišťuje velmi jednoduchý způsob spuštění infrastruktury průmyslové úrovně.

make skaffold nahradí kontext Dockerfile do Cloud Build, vytvoří obraz a uloží ho do GCR a poté aplikuje manifesty na váš cluster. To je to, co dělá make skaffold, ale Skaffold má mnoho dalších možností.

Pro šablony yaml v Kubernetes používáme kustomize pro správu overlay yaml bez rozvětvení celého manifestu, což vám umožňuje používat git pull --rebase pro další zlepšení. Nyní je to v kubectl a docela dobře to funguje pro takové věci.

Také používáme envsubst k vyplnění názvu hostitele a ID projektu GCP v souborech *.yaml.tmpl. Můžete se podívat, jak to funguje v makefile nebo jednoduše pokračujte dále.

Požadavky

Pracovní cluster Kubernetes
Kustomize
Skaffold — pro vytváření vlastních docker obrazů a snadné nasazení do GKE
Kopie tohoto kódu
Envsubst

Pracovní postup s pomocí manifestů

Pokud nechcete používat kustomize nebo skaffold, můžete se obrátit na manifesty v generated-manifest.yaml a přizpůsobit je pracovním postupem podle vašeho výběru.

Žurnály a metriky

Prometheus se stal standardem pro sběr metrik v Kubernetes. Zaujímá stejnou pozici jako AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics a další. Má otevřený zdrojový kód a mocný dotazovací jazyk. Vizualizaci necháme na Grafana — poskytuje velké množství panelů pro monitorování, které jsou k dispozici ihned po instalaci. Tyto panely jsou vzájemně propojené a relativně jednoduše se instalují s prometheus-operator.

Ve výchozím nastavení Prometheus používá model extrakce /metrics, a přidání sidecar kontejnerů pro to je běžnou praxí. Bohužel, metriky JMX jsou nejlépe dostupné uvnitř JVM, takže sidecar kontejnery nejsou tak efektivní. Připojme jmx_exporter otevřený zdrojový kód Prometheus k JVM tím, že ho přidáme do obrazu kontejneru, který poskytne cestu /metrics na jiném portu.

Přidejte Prometheus jmx_exporter do kontejneru

-- images/camunda-bpm/Dockerfile Z 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

No, bylo to snadné. Exportér bude monitorovat tomcat a zobrazí jeho metriky ve formátu Prometheus na adrese :9404/metrics

Nastavení exportéra

Pozorný čtenář si může položit otázku, odkud se vzal prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны zde. Přidáme tomcat jako ConfigMap v Kubernetes a poté jej přimontujeme jako svazek.

Nejprve přidáme konfigurační soubor exportéra do našeho adresáře platform/config/

platforma/konstrukce └── prometheus-jmx.yaml

Poté přidáme ConfigMapGenerator v kustomization.yaml.tmpl:

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

To přidá každou položku files[] jako položku konfigurace ConfigMap. ConfigMapGenerators jsou dobré v tom, že hashují data v konfiguraci a iniciují restart podu, pokud se změní. Také snižují objem konfigurace v nasazení, protože můžete přimontovat celou "složku" konfiguračních souborů v jedné VolumeMount.

Nakonec musíme přimontovat ConfigMap jako svazek k podu:

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

Skvělé. Pokud není Prometheus nastaven na úplné vyčištění, možná budete muset říct, aby byl vyčištěn pod. Uživatelé Prometheus Operator mohou použít service-monitor.yaml pro zahájení práce. Prozkoumejte Service-monitor.yaml, design operátora a ServiceMonitorSpec předtím, než začnete.

Šíření této šablony na další možnosti použití

Všechny soubory, které přidáme do ConfigMapGenerator, budou dostupné v novém adresáři /etc/configMůžete rozšířit tuto šablonu pro montáž jakýchkoli dalších potřebných konfiguračních souborů. Můžete dokonce namontovat nový spouštěcí skript. Můžete použít subPath pro montáž jednotlivých souborů. Pro aktualizaci xml souborů zvažte použití xmlstarlet místo sed. Ten je již zahrnut v obraze.

Žurnály

Skvělé zprávy! Žurnály aplikací jsou již dostupné na stdout, například pomocí kubectl logs. Fluentd (je předinstalován v GKE) přesměruje vaše žurnály do Elasticsearch, Loki nebo na vaši firemní platformu pro žurnály. Pokud chcete použít jsonify pro žurnály, můžete se řídit výše uvedenou šablonou pro instalaci logback.

Databáze

Ve výchozím stavu bude obraz mít databázi H2. To nám nevyhovuje, a budeme používat Google Cloud SQL s Cloud SQL Proxy — to bude potřeba později pro řešení interních úkolů. Je to jednoduchá a spolehlivá varianta, pokud nemáte vlastní preference v nastavení databáze. AWS RDS poskytuje obdobnou službu.

Bez ohledu na to, kterou databázi vyberete, pokud to není H2, budete muset nastavit odpovídající proměnné prostředí v platform/deploy.yaml. Vypadá to přibližně takto:

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

Poznámka: Můžete použít Kustomize pro nasazení v různých prostředích pomocí overlay: příklad.

Poznámka: použití valueFrom: secretKeyRef. Prosím, používejte tuto funkci Kubernetes i během vývoje, abyste udrželi své tajemství v bezpečí.

Je velmi pravděpodobné, že již máte preferovaný systém správy tajemství Kubernetes. Pokud ne, zde je několik možností: šifrování pomocí KMS vašeho cloudového poskytovatele a poté jejich zavedení do K8S jako tajemství prostřednictvím CD pipeline — MozillaSOPS — bude velmi dobře fungovat v kombinaci s tajemstvími Kustomize. Existují i další nástroje, jako dotGPG — ty plní podobné funkce: HashiCorp Vault, Kustomize Secret Value Plugins.

Ingress

Pokud se nerozhodnete použít přesměrování místního portu, budete potřebovat nastavený Ingress Controller. Pokud nepoužíváte ingress-nginx (Helm chart) pravděpodobně už víte, že budete muset nastavit potřebné anotace v ingress-patch.yaml.tmpl nebo platform/ingress.yaml. Pokud používáte ingress-nginx a vidíte třídu nginx ingress s vyrovnávačem zatížení, který na něj odkazuje, a externím DNS nebo záznamem pro podmínkové DNS, všechno je hotovo. Jinak nastavte Ingress Controller a DNS, nebo přeskočte tyto kroky a nechte přímé připojení k podu.

TLS

Pokud používáte cert-manager nebo kube-lego a letsencrypt — certifikáty pro nový vstup budou získány automaticky. Jinak otevřete ingress-patch.yaml.tmpl a nastavte ho podle svých potřeb.

Spuštění!

Pokud jste se drželi všech výše uvedených pokynů, tým make skaffold HOSTNAME= by měl spustit dostupný instance na /camunda

Pokud jste nenastavili vstup přes veřejnou URL adresu, můžete ho přesměrovat z localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 na localhost:8080/camunda

Počkejte několik minut, než bude tomcat plně připraven. Cert-manager potřebuje nějaký čas na ověření doménového jména. Po tom můžete sledovat protokoly pomocí dostupných nástrojů — například nástroje jako kubetail, nebo jednoduše pomocí kubectl:

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

Další kroky

Autentizace

To se více týká nastavení Camunda BPM než Kubernetes, ale je důležité poznamenat, že ve výchozím nastavení je v REST API autentifikace vypnuta. Můžete povolit základní autentifikaci nebo použít jinou metodu, například JWT. Můžete použít configmaps a svazky k načtení xml, nebo xmlstarlet (viz výše) k úpravě existujících souborů v obraze, a také buď použít wget, nebo je načíst pomocí init kontejneru a sdíleného svazku.

Správa relací

Stejně jako mnoho jiných aplikací, Camunda BPM zpracovává relace v JVM, takže pokud chcete spustit více replik, můžete povolit sticky sessions (například pro ingress-nginx), které budou existovat, dokud replikace nezmizí, nebo nastavit atribut Max-Age pro soubory cookie. Jako spolehlivější řešení můžete nasadit Session Manager v Tomcat. Lars má samostatný příspěvek na to téma, ale něco jako:

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

Poznámka: můžete použít xmlstarlet místo sed

Použili jsme twemproxy před Google Cloud Memorystore, s memcached-session-manager (podporuje Redis) pro jeho provoz.

Škálování

Pokud už jste se seznámili se relacemi, prvním (a často posledním) omezením pro škálování Camunda BPM může být připojení k databázi. Částečná konfigurace je k dispozici již „z krabice“. Také zakážeme intialSize v souboru settings.xml. Přidejte HorizontalPodAutoscaler (HPA) a budete moci snadno automaticky škálovat počet podů.

Požadavky a limity

V platform/deployment.yaml uvidíte, že jsme pevně zakódovali pole zdrojů. To dobře funguje s HPA, ale může být potřeba další konfigurace. K tomu se hodí patch kustomize. Viz ingress-patch.yaml.tmpl a ./kustomization.yaml.tmpl

Výstup

Tak jsme nainstalovali Camunda BPM na Kubernetes s metrikami Prometheus, logy, databází H2, TLS a Ingress. Přidali jsme soubory jar a konfigurační soubory pomocí ConfigMaps a Dockerfile. Hovořili jsme o výměně dat s objemy a přímo do proměnných prostředí ze sekretů. Kromě toho jsme poskytli přehled nastavení Camunda pro více replik a autentizovaného API.

Odkazy

github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes │ ├── generated-manifest.yaml <- manifest pro použití bez kustomize ├── obrázky │ └── camunda-bpm │ └── Dockerfile <- překryvný docker image ├── ingress-patch.yaml.tmpl <- specifická konfigurace přístupu pro web ├── kustomization.yaml.tmpl <- hlavní Kustomization ├── Makefile <- cíle pro make ├── namespace.yaml ├── platforma │ ├── config │ │ └── prometheus-jmx.yaml <- konfigurační soubor pro Prometheus exporter │ ├── deployment.yaml <- hlavní nasazení │ ├── ingress.yaml │ ├── kustomization.yaml <- "základní" kustomization │ ├── service-monitor.yaml <- příklad konfigurace prometheus-operator │ └── service.yaml └── skaffold.yaml.tmpl <- direktivy pro skaffold