🥇Spusťte Camunda BPM na Kubernetes

Používáte Kubernetes? Jste připraveni přesunout své instance Camunda BPM z virtuálních počítačů, nebo je možná jen zkusit spustit na Kubernetes? Podívejme se na některé běžné konfigurace a jednotlivé položky, které lze přizpůsobit vašim konkrétním potřebám.

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

Autoři

Alastair Firth (Alastair Firth) – Senior Site Reliability Engineer v týmu Camunda Cloud;
Lars Lange (Lars Lange) – inženýr DevOps ve společnosti Camunda.

Stručně řečeno:

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

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

Co je Camunda BPM

Camunda BPM je open source platforma pro řízení obchodních procesů a automatizaci rozhodování, která spojuje podnikové uživatele a vývojáře softwaru. Je ideální pro koordinaci a propojování lidí, (mikro) služeb nebo dokonce robotů! Více o různých případech použití si můžete přečíst na odkaz.

Proč používat Kubernetes

Kubernetes se stal de facto standardem pro běh moderních aplikací na Linuxu. Použitím systémových volání místo emulace hardwaru a schopnosti jádra řídit přepínání paměti a úloh jsou doba spouštění a doba spouštění omezena na minimum. Největší přínos však může přinést standardní API, které Kubernetes poskytuje pro konfiguraci infrastruktury požadované všemi aplikacemi: úložiště, sítě a monitorování. V červnu 2020 mu bylo 6 let a je možná druhým největším open source projektem (po Linuxu). V poslední době aktivně stabilizuje svou funkčnost po rychlé iteraci v posledních několika letech, protože se stává kritickým pro produkční pracovní zátěže po celém světě.

Camunda BPM Engine se může snadno připojit k dalším aplikacím běžícím na stejném clusteru a Kubernetes poskytuje vynikající škálovatelnost, která vám umožní zvýšit náklady na infrastrukturu pouze tehdy, když je to skutečně potřeba (a snadno je podle potřeby snížit).

Kvalita monitorování se také výrazně zlepšila pomocí nástrojů, jako jsou Prometheus, Grafana, Loki, Fluentd a Elasticsearch, které vám umožní centrálně zobrazit všechny pracovní zátěže v clusteru. Dnes se podíváme na to, jak implementovat exportér Prometheus do Java Virtual Machine (JVM).

Cíle

Podívejme se na několik oblastí, kde můžeme přizpůsobit obrázek Camunda BPM Docker (GitHub), aby dobře spolupracoval s Kubernetes.

Protokoly a metriky;
Databázová připojení;
autentizace;
Správa relace.

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

Poznámka: Používáte verzi Enterprise? Dívej se zde a podle potřeby aktualizujte odkazy na obrázky.

Vývoj pracovního postupu

V této ukázce použijeme Skaffold k vytvoření obrázků Docker pomocí Google Cloud Build. Má dobrou podporu pro různé nástroje (jako Kustomize a Helm), nástroje CI a sestavení a poskytovatele infrastruktury. Soubor skaffold.yaml.tmpl obsahuje nastavení pro Google Cloud Build a GKE, což poskytuje velmi jednoduchý způsob, jak provozovat infrastrukturu produkční úrovně.

make skaffold načte kontext Dockerfile do Cloud Build, vytvoří bitovou kopii a uloží ji do GCR a poté aplikuje manifesty na váš cluster. Tohle dělá make skaffold, ale Skaffold má mnoho dalších funkcí.

Pro šablony yaml v Kubernetes používáme kustomize ke správě překryvů yaml bez rozvětvení celého manifestu, což vám umožňuje používat git pull --rebase pro další vylepšení. Teď je to v kubectl a na takové věci to docela funguje.

Envsubst také používáme k naplnění názvu hostitele a ID projektu GCP v souborech *.yaml.tmpl. Můžete vidět, jak to funguje v makefile nebo pokračujte dále.

Předpoklady

Pracovní klastr Kubernetes
Přizpůsobit
Skaffold - pro vytváření vlastních obrazů dockeru a snadné nasazení do GKE
Kopie tohoto kódu
Envsubst

Pracovní postup pomocí manifestů

Pokud nechcete používat kustomize nebo skaffold, můžete se podívat na manifesty v generated-manifest.yaml a přizpůsobte je pracovnímu postupu dle vašeho výběru.

Protokoly a metriky

Prometheus se stal standardem pro shromažďování metrik v Kubernetes. Zaujímá stejné místo jako AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics a další. Je to open source a má výkonný dotazovací jazyk. Vizualizaci svěříme společnosti Grafana – ta je dodávána s velkým množstvím dashboardů, které jsou k dispozici již po vybalení. Jsou vzájemně propojeny a jejich instalace je poměrně snadná prometheus-operátor.

Ve výchozím nastavení používá Prometheus model extrakce <service>/metricsa přidávání kontejnerů postranních vozíků je běžné. Metriky JMX se bohužel nejlépe zaznamenávají v rámci JVM, takže kontejnery postranních vozíků nejsou tak efektivní. Pojďme se spojit jmx_exporter open source z Prometheus do JVM jeho přidáním do obrazu kontejneru, který poskytne cestu /metrics na jiném portu.

Přidejte Prometheus jmx_exporter do kontejneru

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

No, to bylo snadné. Exportér bude sledovat kocoura a zobrazí jeho metriky ve formátu Prometheus na <svc>:9404/metrics

Nastavení exportéru

Pozorného čtenáře možná napadne, kde se to vzalo prometheus-jmx.yaml? V JVM lze spustit mnoho různých věcí a tomcat je jen jednou z nich, takže exportér potřebuje nějakou další konfiguraci. K dispozici jsou standardní konfigurace pro kocoura, divokou mušku, kafku a tak dále zde. Kocoura přidáme jako Konfigurační mapa v Kubernetes a poté jej připojte jako svazek.

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

platform/config └── prometheus-jmx.yaml

Pak přidáme ConfigMapGenerator в kustomization.yaml.tmpl:

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

Tím přidáte každý prvek files[] jako konfigurační prvek ConfigMap. ConfigMapGenerators jsou skvělé, protože hashují konfigurační data a vynucují restart modulu, pokud se změní. Také snižují množství konfigurace v Deployment, protože můžete připojit celou "složku" konfiguračních souborů do jednoho VolumeMount.

Nakonec musíme připojit ConfigMap jako svazek k modulu:

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

Báječné. Pokud Prometheus není nakonfigurován k úplnému vyčištění, možná mu budete muset říct, aby vyčistil pody. Uživatelé Prometheus Operator mohou používat service-monitor.yaml začít. Prozkoumat Service-monitor.yaml, design operátora и ServiceMonitorSpec než začneš.

Rozšíření tohoto vzoru na další případy použití

Všechny soubory, které přidáme do ConfigMapGenerator, budou dostupné v novém adresáři /etc/config. Tuto šablonu můžete rozšířit o připojení jakýchkoli dalších konfiguračních souborů, které potřebujete. Můžete dokonce připojit nový spouštěcí skript. Můžeš použít podcesta pro připojení jednotlivých souborů. Chcete-li aktualizovat soubory xml, zvažte použití xmlstarlet místo sed. Je již součástí obrázku.

Časopisy

Skvělá zpráva! Protokoly aplikací jsou již dostupné na stdout, například s kubectl logs. Fluentd (ve výchozím nastavení nainstalovaný v GKE) přepošle vaše protokoly do Elasticsearch, Loki nebo vaší podnikové protokolovací platformy. Pokud chcete používat jsonify pro protokoly, můžete nainstalovat podle výše uvedené šablony přihlášení.

Databáze

Ve výchozím nastavení bude mít obrázek databázi H2. To pro nás není vhodné a budeme používat Google Cloud SQL s Cloud SQL Proxy – to bude potřeba později k vyřešení interních problémů. Toto je jednoduchá a spolehlivá možnost, pokud nemáte vlastní preference při nastavování databáze. AWS RDS poskytuje podobnou službu.

Bez ohledu na databázi, kterou si vyberete, pokud to není H2, budete muset nastavit příslušné proměnné prostředí v platform/deploy.yaml. Vypadá to nějak 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: Kustomize můžete použít k nasazení do různých prostředí pomocí překrytí: příklad.

Poznámka: použití valueFrom: secretKeyRef. Prosím, použijte tato funkce Kubernetes i během vývoje, aby byla vaše tajemství v bezpečí.

Je pravděpodobné, že již máte preferovaný systém pro správu tajemství Kubernetes. Pokud ne, zde je několik možností: Zašifrovat je pomocí KMS vašeho poskytovatele cloudu a poté je vložit do K8S jako tajemství prostřednictvím kanálu CD − Mozilla SOPS - bude velmi dobře fungovat v kombinaci s tajemstvím Kustomize. Existují další nástroje, jako je dotGPG, které provádějí podobné funkce: Trezor HashiCorp, Přizpůsobte pluginy tajné hodnoty.

Ingress

Pokud se nerozhodnete použít místní přesměrování portů, budete potřebovat nakonfigurovaný Ingress Controller. Pokud nepoužíváte ingress-nginx (Tabulka kormidla), pak s největší pravděpodobností již víte, že je třeba nainstalovat potřebné poznámky ingress-patch.yaml.tmpl nebo platform/ingress.yaml. Pokud používáte ingress-nginx a vidíte vstupní třídu nginx s nástrojem pro vyrovnávání zatížení, který na ni ukazuje, a externím záznamem DNS nebo DNS se zástupnými znaky, můžete jít. V opačném případě nakonfigurujte Ingress Controller a DNS nebo tyto kroky přeskočte a ponechte přímé připojení k modulu.

TLS

Pokud používáte certifikační manažer nebo kube-lego a letsencrypt - certifikáty pro nové přihlášení budou získány automaticky. V opačném případě otevřete ingress-patch.yaml.tmpl a přizpůsobte jej tak, aby vyhovoval vašim potřebám.

Zahájení!

Pokud jste dodrželi vše napsané výše, pak příkaz make skaffold HOSTNAME=<you.example.com> by měl spustit dostupnou instanci v <hostname>/camunda

Pokud jste své přihlášení nenastavili na veřejnou adresu URL, můžete je přesměrovat pomocí localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 na localhost:8080/camunda

Počkejte několik minut, dokud nebude kocour zcela připraven. Certifikačnímu správci bude chvíli trvat, než ověří název domény. Poté můžete sledovat protokoly pomocí dostupných nástrojů, jako je nástroj 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

Povolení

To je pro konfiguraci Camunda BPM relevantnější než Kubernetes, ale je důležité si uvědomit, že ve výchozím nastavení je ověřování v REST API zakázáno. Můžeš povolit základní autentizaci nebo použijte jinou metodu jako JWT. Můžete použít configmaps a svazky k načtení xml nebo xmlstarlet (viz výše) k úpravě existujících souborů v obrazu a buď použít wget, nebo je načíst pomocí init kontejneru a sdíleného svazku.

Správa relace

Stejně jako mnoho jiných aplikací zpracovává Camunda BPM relace v JVM, takže pokud chcete spouštět více replik, můžete povolit pevné relace (například pro ingress-nginx), který bude existovat, dokud replika nezmizí, nebo nastavte atribut Max-Age pro soubory cookie. Pro robustnější řešení můžete nasadit Session Manager v Tomcat. Lars má samostatný příspěvek na toto 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 '/^</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

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

Použili jsme twemproxy před úložištěm Google Cloud Memorystore s memcached-session-manager (podporuje Redis) jej spustit.

Měřítko

Pokud již relacím rozumíte, pak prvním (a často i posledním) omezením škálování Camunda BPM může být připojení k databázi. Částečné přizpůsobení je již k dispozici "z krabice" Zakažme také intialSize v souboru settings.xml. Přidat Horizontal Pod Autoscaler (HPA) a můžete snadno automaticky škálovat počet lusků.

Požadavky a omezení

В platform/deployment.yaml Uvidíte, že jsme pole zdrojů napevno zakódovali. To funguje dobře s HPA, ale může vyžadovat další konfiguraci. K tomu je vhodná náplast kustomize. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl

Výkon

Nainstalovali jsme tedy Camunda BPM na Kubernetes s metrikami Prometheus, protokoly, H2 databází, TLS a Ingress. Přidali jsme jar soubory a konfigurační soubory pomocí ConfigMaps a Dockerfile. Mluvili jsme o výměně dat do svazků a přímo do proměnných prostředí z tajemství. Kromě toho jsme poskytli přehled nastavení Camundy pro více replik a ověřené API.

reference

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/XNUMX/XNUMX, překlad články Alastair Firth, Lars Lange

Zdroj: www.habr.com

Spuštění Camunda BPM na Kubernetes