🥇Zagon Camunda BPM v Kubernetes

Uporabljate Kubernetes? Ste pripravljeni preseliti svoje instance Camunda BPM z virtualnih strojev ali pa celo preizkusiti njihovo zagon na Kubernetes? Poglejmo nekatere pogoste konfiguracije in posamezne elemente, ki jih je mogoče prilagoditi vašim specifičnim potrebam.

Predpostavljamo, da ste že uporabljali Kubernetes. Če ne, zakaj ne bi preverili vodnik in zagnali svojega prvega klasterja?

Avtorji

Alastair Firth je višji inženir za zanesljivost spletnih strani (Site Reliability Engineer) v ekipi Camunda Cloud;
Lars Lange je inženir za DevOps v Camunda.

Na kratko:

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

Verjetno to ni delovalo, ker nimate nameščenih skaffold in kustomize. No, berite naprej!

Kaj je Camunda BPM

Camunda BPM je platforma z odprtokodnim izvorom za upravljanje poslovnih procesov in avtomatizacijo odločanja, ki združuje poslovne uporabnike in razvijalce programske opreme. Idealna je za usklajevanje in povezovanje ljudi, (mikro) storitev ali celo botov! Več o različnih primerih uporabe si lahko preberete na linku.

Zakaj uporabljati Kubernetes

Kubernetes je postal de facto standard za zagon sodobnih aplikacij v Linuxu. Z uporabo sistemskih klicev namesto emulacije strojne opreme in zmožnostmi jedra za upravljanje pomnilnika in preklapljanja nalog se čas nalaganja in čas zagona zmanjšata na minimum. Vendar pa največjo prednost prinaša standardni API, ki ga Kubernetes zagotavlja za konfiguracijo infrastrukture, potrebne za vse aplikacije: shranjevanje, omrežje in spremljanje. Junija 2020 je dopolnil 6 let in je verjetno drugi največji projekt z odprtokodno kodo (za Linuxom). V zadnjem času aktivno stabilizira svojo funkcionalnost po hitrih iteracijah v preteklih letih, saj postaja kritično pomemben za proizvodne obremenitve po vsem svetu.

Camunda BPM Engine se lahko enostavno poveže z drugimi aplikacijami, ki delujejo v istem klasterju, medtem ko Kubernetes zagotavlja odlično skalabilnost, kar omogoča povečanje stroškov infrastrukture le takrat, ko je to res potrebno (in enostavno zmanjšanje, ko to ni več potrebno).

Kakovost nadzora se znatno izboljšuje s pomočjo orodij, kot so Prometheus, Grafana, Loki, Fluentd in Elasticsearch, ki omogočajo centralizirano gledanje vseh delovnih obremenitev clustra. Danes bomo obravnavali, kako implementirati Prometheus eksportera v Java virtualni stroj (JVM).

Циљеви

Oglejmo si nekaj področij, kjer lahko prilagodimo Docker sliko Camunda BPM (github), da bo dobro sodelovala s Kubernetes.

Dnevniki in metrike;
Povezave z bazo podatkov;
Avtentikacija;
Upravljanje sej.

Pogledujemo več načinov za dosego teh ciljev in prikazali bomo celoten postopek.

Napomena: Uporabljate Enterprise različico? Oglejte si ovde in posodobite povezave do slik, kjer bo to potrebno.

Razvoj delovnega procesa

V tej demonstraciji bomo uporabili Skaffold za ustvarjanje Docker slik z uporabo Google Cloud Build. Ima dobro podporo za različna orodja (takšna kot Kustomize in Helm), CI in orodja za gradnjo ter ponudnike infrastrukture. Datoteka skaffold.yaml.tmpl vključuje nastavitve za Google Cloud Build in GKE, kar omogoča zelo preprost način za zagon industrijske infrastrukture.

make skaffold naloži kontekst Dockerfile v Cloud Build, ustvari sliko in jo shrani v GCR, nato pa uporabi manifestacije v vašem clustru. To je tisto, kar make skaffold, vendar ima Skaffold še veliko drugih možnosti.

Za yaml predloge v Kubernetes uporabljamo kustomize za upravljanje yaml prekrivanj brez razvejanjem celotnega manifesta, kar vam omogoča uporabo git pull --rebase za nadaljnja izboljšanja. Sedaj je v kubectl in dobro deluje za takšne stvari.

Prav tako uporabljamo envsubst za izpolnjevanje imena gostitelja in identifikatorja projekta GCP v datotekah *.yaml.tmpl. Lahko si ogledate, kako to deluje v makefile ali pa preprosto nadaljujte naprej.

Potrebni pogoji

Delujoč cluster Kubernetes
Kustomize
Skaffold — za ustvarjanje lastnih docker slik in enostavno nameščanje v GKE
Kopija tega kode
Envsubst

Delovni proces z manifesti

Če ne želite uporabljati kustomize ali skaffold, se lahko obrnete na manifeste v generated-manifest.yaml in jih prilagodite svojemu delovnemu toku po izbiri.

Dnevniki in metrike

Prometheus je standard za sakupljanje metrika u Kubernetesu. On zauzima istu nišu kao AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics i drugi. Ima otvoreni izvorni kod i moćan jezik upita. Vizualizaciju prepuštamo Grafani — dolazi s velikim brojem dostupnih panela za nadzor od samog početka. Oni su međusobno povezani i relativno lako se instaliraju prometheus-operator.

Podrazumevano, Prometheus koristi model povlačenja /metrics, a dodavanje sidecar kontejnera za to je uobičajeno. Nažalost, JMX metrike se najbolje beleže unutar JVM-a, pa sidecar kontejneri nisu tako efikasni. Povežimo jmx_exporter otvoreni izvor od Prometheus-a sa JVM-om tako što ćemo ga dodati u sliku kontejnera koja će omogućiti pristup /metrics na drugom portu.

Dodajte Prometheus jmx_exporter u kontejner

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

Pa, bilo je lako. Eksporter će nadgledati tomcat i prikazati njegove metrike u Prometheus formatu na :9404/metrics

Podešavanje eksportera

Pažljiv čitalac se možda može zapitati, odakle dolazi prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны ovde. Dodaćemo tomcat kao ConfigMap u Kubernetes, a zatim ćemo ga montirati kao volumen.

Prvo, dodajemo datoteku konfiguracije eksportera u našu direktoriju platform/config/

platforma/config └── prometheus-jmx.yaml

Zatim dodajemo ConfigMapGenerator u kustomization.yaml.tmpl:

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

Ovo će dodati svaki element files[] kao element konfiguracije ConfigMap. ConfigMapGenerators su korisni jer hashiraju podatke u konfiguraciji i iniciraju ponovni start pod-a ako se promeni. Takođe smanjuju volumen konfiguracije u Deploymentu, budući da možete montirati celu 'mapu' konfiguracionih datoteka u jednom VolumeMount-u.

Na kraju, potrebno je montirati ConfigMap kao volumen u pod:

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

Odlično. Ako Prometheus nije podešen za potpuni čišćenje, možda ćete morati reći njemu da Obrabiti podove. Korisnici Prometheus Operator mogu koristiti service-monitor.yaml da bi započeli. Istražite Service-monitor.yaml, dizajn operatora in ServiceMonitorSpec pre nego što krenete.

Širenje ovog obrasca na druge upotrebe

Sve datoteke koje dodajemo u ConfigMapGenerator biće dostupne u novom katalogu /etc/config. Lahko razširite to predlogo za montažo vseh drugih potrebnih konfiguracijskih datotek. Lahko celo montirate nov zagonski skript. Uporabite lahko subPath za montiranje posameznih datotek. Za posodabljanje xml-datotek razmislite o uporabi xmlstarlet namesto sed. Ta je že vključen v sliko.

Dnevniki

Odlične novice! Dnevniki aplikacij so že na voljo na stdout, na primer z uporabo kubectl logs. Fluentd (privzeto nameščen v GKE) bo preusmeril vaše dnevnike v Elasticsearch, Loki ali na vašo podjetniško platformo za dnevnike. Če želite uporabiti jsonify za dnevnike, lahko sledite zgoraj omenjeni predlogi za nastavitev logback.

База данных

Privzeto bo slika imela bazo podatkov H2. To nam ne ustreza, in uporabljali bomo Google Cloud SQL s Cloud SQL Proxy — to bo potrebni kasneje za reševanje notranjih nalog. To je preprosta in zanesljiva izbira, če nimate svojih nastavitev za bazo podatkov. AWS RDS ponuja podobno storitev.

Ne glede na to, katero bazo podatkov izberete, razen H2, boste morali nastaviti ustrezne okoljske spremenljivke v platform/deploy.yaml. To izgleda približno tako:

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

Napomena: Lahko uporabite Kustomize za razmestitev v različnih okoljih z uporabo overlay: primer.

Napomena: uporaba valueFrom: secretKeyRef. Prosimo, uporabite to funkcijo Kubernetes tudi med razvojem, da zaščitite svoje skrivnosti.

Zelo verjetno imate že svojo priljubljeno sistemsko upravljanje skrivnosti Kubernetes. Če ne, so tu nekatere možnosti: šifriranje z uporabo KMS vašega oblačnega ponudnika in nato vnašanje le-teh v K8S kot skrivnosti preko CD-pipe — MozillaSOPS bo dobro deloval skupaj s skrivnostmi Kustomize. Obstajajo tudi drugi orodja, kot je dotGPG — ta opravljajo podobne funkcije: HashiCorp Vault, Kustomize Secret Value Plugins.

Ingress

Če se ne odločite za preusmeritev lokalnega vrata, boste potrebovali nastavljeni Ingress Controller. Če ne uporabljate ingress-nginx (Helm chart) potem verjetno že veste, da morate nastaviti ustrezne anotacije v ingress-patch.yaml.tmpl ili platform/ingress.yamlČe uporabljate ingress-nginx in vidite nginx ingress razred z ravnotežjem obremenitve, ki kaže nanj, in zunanjim DNS-om ali zapisom nadomestnega DNS-a, je vse pripravljeno. V nasprotnem primeru nastavite Ingress Controller in DNS ali preskočite te korake in pustite neposredno povezavo na pod.

, čeprav se tega zelo sramuje.

Če uporabljate cert-manager ali kube-lego in letsencrypt – certifikati za nov vstop bodo pridobljeni samodejno. V nasprotnem primeru odprite ingress-patch.yaml.tmpl in ga prilagodite svojim potrebam.

Začetek!

Če ste se držali vsega napisanega zgoraj, bi ukaz make skaffold HOSTNAME= moral zagnati dostopno instanco v /camunda

Če niste nastavili vnosa prek javnega URL-ja, ga lahko preusmerite z localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 na localhost:8080/camunda

Počakajte nekaj minut, da bo tomcat popolnoma pripravljen. Cert-manageru bo vzelo nekaj časa, da preveri domensko ime. Po tem lahko spremljate dnevnike s standardnimi orodji - na primer z orodjem, kot je kubetail, ali pa preprosto z uporabo kubectl:

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

Naslednji koraki

Avtorizacija

To zadeva bolj nastavitev Camunda BPM kot Kubernetes, vendar je pomembno poudariti, da je privzeto avtentifikacija v REST API-ju izključena. Lahko vklopite osnovno avtentifikacijo ali uporabite drugo metodo, na primer JWT. Uporabite lahko configmaps in volumne za nalaganje xml, ali xmlstarlet (glej zgoraj) za urejanje obstoječih datotek v sliki, prav tako pa lahko uporabite wget ali jih naložite s pomočjo init kontejnerja in skupnega volumna.

Upravljanje sej

Kot mnoge druge aplikacije, Camunda BPM upravlja seje v JVM, zato, če želite zagnati več replik, lahko omogočite sticky sessions (na primer za ingress-nginx), ki bodo obstajale, dokler replika ne izgine, ali določite atribut Max-Age za piškotke. Kot bolj zanesljivo rešitev lahko razporedite Session Manager v Tomcat. Lars ima poseben prispevek o tem temo, vendar nekaj takega:

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

Napomena: lahko uporabite xmlstarlet namesto sed

Uporabljali smo twemproxy pred Google Cloud Memorystore, s memcached-session-manager (podpira Redis) za njegovo zagon.

Skaliranje

Če ste se že spoprijeli s seje, je prvo (in pogosto zadnje) omejitev za širitev Camunda BPM lahko povezava z bazo podatkov. Delna nastavitev je že na voljo "iz škatle". Prav tako bomo onemogočili intialSize v datoteki settings.xml. Dodajte HorizontalPodAutoscaler (HPA) in lahko enostavno samodejno prilagajate število podov.

Zahteve in omejitve

V platform/deployment.yaml videli boste, da smo trdo kodirali polje virov. To dobro deluje z HPA, vendar je lahko potrebna dodatna nastavitev. Za to je primeren kustomize patch. Glejte ingress-patch.yaml.tmpl in ./kustomization.yaml.tmpl

Izlaz

Tako smo namestili Camunda BPM na Kubernetes z metrikami Prometheus, dnevniki, bazo podatkov H2, TLS in Ingress. Dodali smo datoteke jar in datoteke za konfiguracijo z uporabo ConfigMaps in Dockerfile. Pogovarjali smo se o izmenjavi podatkov z volumni in neposredno v okoljske spremenljivke iz skrivnosti. Poleg tega smo pregledali nastavitev Camunda za več replik in overjen API.

Povezave

github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes │ ├── generated-manifest.yaml <- manifest za uporabo brez kustomize ├── slike │ └── camunda-bpm │ └── Dockerfile <- overlay docker image ├── ingress-patch.yaml.tmpl <- specifična nastavitev ingress za spletno stran ├── kustomization.yaml.tmpl <- glavna Kustomization ├── Makefile <- make targets ├── namespace.yaml ├── platforma │ ├── konfiguracija │ │ └── prometheus-jmx.yaml <- konfiguracija prometheus exporterja │ ├── deployment.yaml <- glavni deployment │ ├── ingress.yaml │ ├── kustomization.yaml <- "base" kustomization │ ├── service-monitor.yaml <- primer konfiguracije prometheus-operatorja │ └── service.yaml └── skaffold.yaml.tmpl <- skaffold direktive

05.08.2020, prevod članka Alastair Firth, Lars Lange

Izvor: habr.com