Používate Kubernetes? Chcete presunúť svoje inštancie Camunda BPM z virtuálnych strojov, alebo len vyskúšať spustiť ich na Kubernetes? Poďme sa pozrieť na niektoré bežné konfigurácie a jednotlivé prvky, ktoré môžete prispôsobiť vašim konkrétnym potrebám.
Predpokladá sa, že ste už s Kubernetes pracovali. Ak nie, prečo sa nepozrieť na a nespustiť svoj prvý klaster?
Autori
- je senior site reliability engineer v tíme Camunda Cloud;
- je DevOps inžinier v Camunda.
Ak to zhrnieme:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
No, pravdepodobne to nefungovalo, pretože nemáte nainštalované skaffold a kustomize. Tak čítajte ďalej!
Čo je to Camunda BPM
Camunda BPM je platforma s otvoreným zdrojovým kódom na správu obchodných procesov a automatizáciu rozhodovania, ktorá spája obchodných používateľov a softvérových vývojárov. Ideálne sa hodí na koordináciu a spojenie ľudí, (mikro) služieb alebo dokonca botov! Viac informácií o rôznych možnostiach použitia nájdete na .
Prečo používať Kubernetes
Kubernetes sa stal de facto štandardom pre spúšťanie moderných aplikácií na Linuxe. Vďaka používaniu systémových volaní namiesto emulácie hardvérovej úrovne a možnostiam jadra riadiť pamäť a prepínanie úloh sa čas zavádzania a spúšťania minimalizuje. Najväčšiu výhodu však môže poskytnúť štandardné API, ktoré Kubernetes poskytuje na prispôsobenie infraštruktúry potrebnej všetkým aplikáciám: úložisko, sieť a monitorovanie. V júni 2020 oslavoval 6 rokov a je to pravdepodobne druhý najväčší projekt s otvoreným zdrojovým kódom (po Linuxe). V poslednej dobe aktívne stabilizuje svoje funkcie po rýchlej iterácii posledných niekoľkých rokov, pretože sa to stáva kľúčovým pre produkčné zaťaženia po celom svete.
Camunda BPM Engine sa môže ľahko pripojiť k ďalším aplikáciám, ktoré bežia v rovnakom klastri, a Kubernetes poskytuje vynikajúcu škálovateľnosť, čo umožňuje zvyšovať náklady na infraštruktúru iba vtedy, keď je to naozaj potrebné (a ľahko ich znižovať podľa potreby).
Kvalita monitorovania sa tiež významne zlepšuje použitím nástrojov ako Prometheus, Grafana, Loki, Fluentd a Elasticsearch, ktoré umožňujú centralizovane prezerať všetky pracovné záťaže klastru. Dnes sa pozrieme na to, ako implementovať exportéra Prometheus do Java virtuálneho stroja (JVM).
Ciele
Pozrime sa na niekoľko oblastí, kde môžeme nakonfigurovať Docker obraz Camunda BPM (), aby dobre interagoval s Kubernetes.
- Logy a metriky;
- Pripojenia k databáze;
- Autentifikácia;
- Správa relácií.
Preskúmame niekoľko spôsobov, ako dosiahnuť tieto ciele, a názorne ukážeme celý proces.
Poznámka: Používate verziu Enterprise? Pozrite sa na a aktualizujte odkazy na obrazy pri potrebe.
Vývoj pracovného postupu
V tejto ukážke budeme používať Skaffold na vytváranie Docker obrazov pomocou Google Cloud Build. Má dobrú podporu rôznych nástrojov (ako Kustomize a Helm), CI a nástrojov na zostavovanie, ako aj poskytovateľov infraštruktúry. Súbor skaffold.yaml.tmpl obsahuje nastavenia pre Google Cloud Build a GKE, čo zabezpečuje veľmi jednoduchý spôsob spustenia infraštruktúry priemyselnej úrovne.
make skaffold načíta kontext Dockerfile do Cloud Build, vytvorí obraz a uloží ho do GCR, a potom aplikuje manifesty na váš klaster. To je to, čo robí make skaffold, ale Skaffold má mnoho ďalších funkcií.
Na šablóny yaml v Kubernetes používame kustomize na správu overlay-ov yaml bez rozvetvenia celého manifestu, čo vám umožňuje používať git pull --rebase na ďalšie zlepšenia. Momentálne je to v kubectl a funguje to celkom dobre na takéto veci.
Taktiež používame envsubst na vyplnenie názvu hostiteľa a identifikátora projektu GCP v súboroch * .yaml.tmpl. Môžete si pozrieť, ako to funguje v makefile alebo jednoducho prejsť ďalej.
Požiadavky
- Pracovný klaster
- — na vytvorenie vlastných Docker obrazov a jednoduché nasadenie do GKE
- Kópia tohto kódu
- Envsubst
Pracovný postup pomocou manifestov
Ak nechcete používať kustomize alebo skaffold, môžete sa odvolať na manifesty v generated-manifest.yaml a prispôsobiť ich pracovného postupu podľa vášho výberu.
Logy a metriky
Prometheus sa stal štandardom pre zhromažďovanie metrik v Kubernetes. Zaberá rovnakú niku ako AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics a ďalšie. Má otvorený zdrojový kód a silný jazyk dopytov. Vizualizáciu prenecháme na Grafana — dodáva sa s veľkým množstvom panelov monitorovania, ktoré sú k dispozícii priamo. Sú vzájomne prepojené a relatívne jednoduché na inštaláciu s .
Predvolene Prometheus používa model extrakcie /metrics, a pridávanie sidecar kontajnerov na to je bežná prax. Bohužiaľ, metriky JMX sa najlepšie zhromažďujú vnútri JVM, takže sidecar kontajnery nie sú tak efektívne. Poďme pripojiť s otvoreným zdrojom od Prometheus k JVM, pridaním do obrazu kontajnera, ktorý poskytne cestu /metrics na inom porte.
Pridajte Prometheus jmx_exporter do kontajnera
-- 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 bolo jednoduché. Exportér bude monitorovať tomcat a zobrazovať jeho metriky vo formáte Prometheus na adrese :9404/metrics
Nastavenie exportéra
Pozorný čitateľ sa môže pýtať, odkiaľ sa vzal prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны . Pridáme tomcat ako v Kubernetes a potom ho namontujeme ako zväzok.
Najprv pridáme konfiguračný súbor exportéra do našej priečinky platform/config/
platforma\/konfigurácia
└── prometheus-jmx.yaml
Potom pridáme v kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Toto pridá každý prvok files[] ako prvok konfiguračného ConfigMap. ConfigMapGenerators sú dobré v tom, že hashujú údaje v konfigurácii a iniciujú reštart podu, ak sa zmenia. Tiež znižujú objem konfigurácie v nasadení, pretože môžete namontovať celú "zložku" konfiguračných súborov do jedného VolumeMount.
Nakoniec musíme namontovať ConfigMap ako zväzok k podu:
-- platform/deployment.yaml
apiVersion: apps/v1
druh: Deployment
[...]
špecifikácia:
šablóna:
špecifikácia:
[...]
objemy:
- name: config
configMap:
názov: config
predvolenéRežim: 0744
kontajnery:
- názov: camunda-bpm
objemMounts:
- mountPath: /etc/config/
názov: config
[...]
Skvele. Ak Prometheus nie je nastavený na úplné čistenie, možno budete musieť povedať mu, aby vyčistil pody. Používatelia Prometheus Operator môžu používať service-monitor.yaml na začatie práce. Preskúmajte Service-monitor.yaml, a predtým ako sa pustíte.
Distribúcia tejto šablóny na ďalšie možnosti použitia
Všetky súbory, ktoré pridávame do ConfigMapGenerator, budú dostupné v novom adresári /etc/config. Môžete rozšíriť túto šablónu na pripojenie akýchkoľvek ďalších konfiguračných súborov, ktoré potrebujete. Môžete dokonca pripojiť nový spúšťač. Môžete použiť na pripojenie jednotlivých súborov. Na aktualizáciu xml súborov zvážte použitie namiesto sed. Ten je už zahrnutý v obraze.
Žurnály
Skvelé správy! Žurnály aplikácií sú už dostupné na stdout, napríklad pomocou kubectl logs. Fluentd (je predvolene nainštalovaný v GKE) presmeruje vaše žurnály do Elasticsearch, Loki alebo na vašu podnikovú platformu žurnálov. Ak chcete použiť jsonify pre žurnály, môžete sa riadiť vyššie uvedenou šablónou na nastavenie .
Databáza
Predvolene bude mať obraz databázu H2. To nám nevyhovuje a použijeme Google Cloud SQL s Cloud SQL Proxy – to bude potrebné neskôr na riešenie interných úloh. To je jednoduchá a spoľahlivá možnosť, ak nemáte vlastné preferencie v nastavení databázy. AWS RDS poskytuje podobnú službu.
Bez ohľadu na to, ktorú databázu si vyberiete, pokiaľ to nie je H2, budete musieť nastaviť príslušné premenné prostredia v platform/deploy.yaml. Vyzerá to približne takto:
-- platform/deployment.yaml
apiVersion: apps/v1
druh: Deployment
[...]
špecifikácia:
šablóna:
špecifikácia:
[...]
kontajnery:
- názov: 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žiť Kustomize na nasadenie v rôznych prostrediach pomocou overlay: .
Poznámka: použitie valueFrom: secretKeyRef. Prosím, použite aj počas vývoja, aby ste ochránili svoje tajomstvá.
Je veľmi pravdepodobné, že už máte preferovaný systém správy tajomstiev Kubernetes. Ak nie, tu sú niektoré možnosti: šifrovanie pomocou KMS vášho poskytovateľa cloudu a následné implementovanie ich do K8S ako tajomstiev prostredníctvom CD pipeline – — bude veľmi dobre spolupracovať s tajomstvom Kustomize. Existujú aj ďalšie nástroje, ako dotGPG – plnia podobné funkcie: , .
Ingress
Ak sa nerozhodnete použiť presmerovanie miestneho portu, budete potrebovať nastavený Ingress Controller. Ak nepoužívate () potom určite viete, že musíte nastaviť potrebné anotácie v ingress-patch.yaml.tmpl alebo platform/ingress.yamlAk používate ingress-nginx a vidíte nginx ingress class s vyvažovačom zaťaženia, ktorý naň odkazuje a externým DNS alebo záznamom podstrapkového DNS, – všetko je pripravené. V opačnom prípade nastavte Ingress Controller a DNS alebo preskočte tieto kroky a nechajte priame pripojenie k podu.
TLS
Ak používate alebo kube-lego a letsencrypt – certifikáty pre nový vstup budú získané automaticky. V opačnom prípade otvorte ingress-patch.yaml.tmpl a nastavte ho podľa svojich potrieb.
Spustenie!
Ak ste sa riadili všetkým, čo je napísané vyššie, tím make skaffold HOSTNAME= by mal spustiť dostupný inštanciu v /camunda
Ak ste nevystavili vstup cez verejnú URL, môžete ho presmerovať z localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 na localhost:8080/camunda
Čakajte niekoľko minút, kým bude tomcat úplne pripravený. Cert-manager bude potrebovať nejaký čas na overenie doménového mena. Po tom môžete sledovať záznamy pomocou dostupných nástrojov – napríklad takého nástroja, ako je kubetail, alebo jednoducho pomocou kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Nasledujúce kroky
Autorizácia
Toto viac súvisí s nastavením Camunda BPM, než s Kubernetes, ale je dôležité poznamenať, že predvolene je v REST API autentifikácia vypnutá. Môžete alebo použiť inú metódu, napríklad . Môžete používať configmaps a objemy na načítanie xml, alebo xmlstarlet (pozri vyššie) na úpravu existujúcich súborov v obraze, a tiež buď používať wget, alebo ich načítať pomocou init kontajnera a zdieľaného objemu.
Správa relácií
Rovnako ako mnoho iných aplikácií, Camunda BPM spravuje relácie v JVM, takže ak chcete spustiť niekoľko replik, môžete zapnúť sticky sessions (), ktoré budú existovať, pokiaľ replikát nezmizne, alebo nastaviť atribút Max-Age pre súbory cookie. Ako spoľahlivejšie riešenie môžete nasadiť Session Manager v Tomcat. Lars má o tom príspevok, ale niečo ako:
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žiť xmlstarlet namiesto sed
Použili sme pred Google Cloud Memorystore, s (podporuje Redis) na jeho spustenie.
Škálovanie
Ak už ste sa oboznámili so reláciami, prvým (a často posledným) obmedzením pre škálovanie Camunda BPM môže byť pripojenie k databáze. Čiastočné nastavenie je dostupné už. Tiež vypneme initialSize v súbore settings.xml. Pridajte a jednoducho budete môcť automaticky škálovať počet podov.
Požiadavky a obmedzenia
V platform/deployment.yaml uvidíte, že sme tvrdo zakódovali pole zdrojov. To dobre funguje s HPA, ale môže vyžadovať ďalšie nastavenie. Na to sa hodí patch kustomize. Pozrite sa na ingress-patch.yaml.tmpl a . /kustomization.yaml.tmpl
Záver
Takže sme nainštalovali Camunda BPM na Kubernetes s metrikami Prometheus, logmi, databázou H2, TLS a Ingress. Pridali sme súbory jar a konfiguračné súbory pomocou ConfigMaps a Dockerfile. Hovorili sme o výmene dát s volumami a priamo v premenných prostredia zo secrets. Navyše sme poskytli prehľad nastavenia Camunda pre niekoľko replik a autentifikovaného API.
Odkazy
github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes
│
├── generated-manifest.yaml <- manifest na použitie bez kustomize
├── obrázky
│ └── camunda-bpm
│ └── Dockerfile <- overlay docker image
├── ingress-patch.yaml.tmpl <- konkrétna konfigurácia ingressu
├── kustomization.yaml.tmpl <- hlavná Kustomization
├── Makefile <- make úlohy
├── namespace.yaml
├── platforma
│ ├── konfigurácia
│ │ └── prometheus-jmx.yaml <- konfigurácia promethus exportéra
│ ├── deployment.yaml <- hlavný deployment
│ ├── ingress.yaml
│ ├── kustomization.yaml <- "base" kustomization
│ ├── service-monitor.yaml <- príklad konfigurácie prometheus-operator
│ └── service.yaml
└── skaffold.yaml.tmpl <- skaffold smernice
05.08.2020, preklad Alastair Firth, Lars Lange
Zdroj: habr.com
