🥇 Ekzekutimi i Camunda BPM në Kubernetes

A po përdorni Kubernetes? Gati për të zhvendosur instancat tuaja të Camunda BPM nga makinat virtuale, apo ndoshta thjesht provoni t'i ekzekutoni ato në Kubernetes? Le të shohim disa konfigurime të zakonshme dhe artikuj individualë që mund të përshtaten për nevojat tuaja specifike.

Supozon se keni përdorur Kubernetes më parë. Nëse jo, pse të mos hidhni një sy udhëheqja dhe të mos filloni grupin tuaj të parë?

Autorët

Alastair Firth (Alastair Firth) - Inxhinier i lartë i besueshmërisë së sitit në ekipin e Camunda Cloud;
Lars Lange (Lars Lange) - Inxhinier DevOps në Camunda.

Shkurtimisht:

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

Mirë, ndoshta nuk funksionoi sepse nuk keni të instaluar skelet dhe kustomize. Epo atëherë lexoni!

Çfarë është Camunda BPM

Camunda BPM është një platformë me burim të hapur të menaxhimit të procesit të biznesit dhe automatizimit të vendimeve që lidh përdoruesit e biznesit dhe zhvilluesit e softuerit. Është ideal për koordinimin dhe lidhjen e njerëzve, (mikro) shërbimeve apo edhe robotëve! Mund të lexoni më shumë rreth rasteve të ndryshme të përdorimit në lidhje.

Pse të përdorni Kubernetes

Kubernetes është bërë standardi de facto për ekzekutimin e aplikacioneve moderne në LinuxDuke përdorur thirrjet e sistemit në vend të emulimit të harduerit dhe duke i lejuar bërthamës të menaxhojë memorien dhe ndërrimin e detyrave, kohët e nisjes dhe të nisjes minimizohen. Megjithatë, përparësia më e madhe mund të vijë nga API-ja standarde që Kubernetes ofron për konfigurimin e infrastrukturës së nevojshme nga të gjitha aplikacionet: ruajtja, rrjetëzimi dhe monitorimi. Ai festoi përvjetorin e gjashtë në qershor 2020, duke e bërë ndoshta projektin e dytë më të madh me burim të hapur (pas LinuxKohët e fundit, pas një përsëritjeje të shpejtë gjatë viteve të fundit, ajo ka qenë duke e stabilizuar në mënyrë aktive funksionalitetin e saj, pasi bëhet kritike për ngarkesat e punës së prodhimit në të gjithë botën.

Camunda BPM Engine mund të lidhet lehtësisht me aplikacione të tjera që funksionojnë në të njëjtin grup dhe Kubernetes ofron shkallëzim të shkëlqyeshëm, duke ju lejuar të rrisni kostot e infrastrukturës vetëm kur është vërtet e nevojshme (dhe t'i reduktoni lehtësisht sipas nevojës).

Cilësia e monitorimit është përmirësuar gjithashtu shumë me mjete të tilla si Prometheus, Grafana, Loki, Fluentd dhe Elasticsearch, duke ju lejuar të shikoni në qendër të gjitha ngarkesat e punës në një grup. Sot do të shohim se si të implementojmë eksportuesin Prometheus në Makinën Virtuale Java (JVM).

qëllimet

Le të shohim disa fusha ku mund të personalizojmë imazhin e Camunda BPM Docker (Github) në mënyrë që të ndërveprojë mirë me Kubernetes.

Regjistrat dhe metrikat;
Lidhjet e bazës së të dhënave;
Autentifikimi;
Menaxhimi i sesionit.

Ne do të shikojmë disa mënyra për të arritur këto qëllime dhe do të tregojmë qartë të gjithë procesin.

Shënim: A po përdorni versionin Enterprise? Shikoni këtu dhe përditësoni lidhjet e imazhit sipas nevojës.

Zhvillimi i rrjedhës së punës

Në këtë demonstrim, ne do të përdorim Skaffold për të ndërtuar imazhe Docker duke përdorur Google Cloud Build. Ka mbështetje të mirë për mjete të ndryshme (të tilla si Kustomize dhe Helm), CI dhe mjete ndërtimi dhe ofruesit e infrastrukturës. Skedari skaffold.yaml.tmpl përfshin cilësimet për Google Cloud Build dhe GKE, duke ofruar një mënyrë shumë të thjeshtë për të drejtuar infrastrukturën e nivelit të prodhimit.

make skaffold do të ngarkojë kontekstin Dockerfile në Cloud Build, do të ndërtojë imazhin dhe do ta ruajë në GCR dhe më pas do të aplikojë manifestet në grupin tuaj. Kjo është ajo që bën make skaffold, por Skaffold ka shumë veçori të tjera.

Për shabllonet yaml në Kubernetes, ne përdorim kustomize për të menaxhuar mbivendosjet e yaml pa depërtuar të gjithë manifestin, duke ju lejuar të përdorni git pull --rebase për përmirësime të mëtejshme. Tani është në kubectl dhe funksionon mjaft mirë për gjëra të tilla.

Ne përdorim gjithashtu envsubst për të mbushur emrin e hostit dhe ID-në e projektit GCP në skedarët *.yaml.tmpl. Ju mund të shihni se si funksionon në makefile ose thjesht vazhdoni më tej.

parakushtet

Grupi i punës Kubernetes
Personalizoje
Skeli - për krijimin e imazheve tuaja të dokerit dhe vendosjen e lehtë në GKE
Kopje e këtij kodi
Envsubst

Rrjedha e punës duke përdorur manifestet

Nëse nuk dëshironi të përdorni kustomize ose skaffold, mund t'i referoheni manifesteve në generated-manifest.yaml dhe përshtatni ato me rrjedhën e punës sipas zgjedhjes suaj.

Regjistrat dhe metrikat

Prometheus është bërë standardi për mbledhjen e metrikës në Kubernetes. Ai zë të njëjtin vend si AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics dhe të tjerë. Është me burim të hapur dhe ka një gjuhë të fuqishme pyetjesh. Ne do t'ia besojmë vizualizimin Grafana - ajo vjen me një numër të madh tabelash të disponueshme jashtë kutisë. Ato janë të lidhura me njëra-tjetrën dhe janë relativisht të lehta për t'u instaluar prometeu-operator.

Si parazgjedhje, Prometheus përdor modelin e nxjerrjes <service>/metrics, dhe shtimi i kontejnerëve të karrigeve anësore për këtë është i zakonshëm. Fatkeqësisht, metrikat JMX regjistrohen më së miri brenda JVM, kështu që kontejnerët e karrigeve anësore nuk janë aq efikase. Le të lidhemi jmx_eksportues burim i hapur nga Prometheus në JVM duke e shtuar atë në imazhin e kontejnerit i cili do të sigurojë shtegun /metrics në një port tjetër.

Shto Prometheus jmx_exporter në kontejner

-- images/camunda-bpm/Dockerfile FROM camunda/camunda-bpm-platform:tomcat-7.11.0

## Shto eksportuesin e Prometeut
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 është porta e rezervuar prometheus-jmx
ENV CATALINA_OPTS -javaagent:lib/
jmx_prometheus_javaagent-0.11.0.jar=9404:/etc/config/prometheus-jmx.yaml

Epo, ishte e lehtë. Eksportuesi do të monitorojë tomcat dhe do të shfaqë matjet e tij në formatin Prometheus në <svc>:9404/metrics

Konfigurimi i eksportuesit

Lexuesi i vëmendshëm mund të pyesë veten se nga erdhi prometheus-jmx.yaml? Ka shumë gjëra të ndryshme që mund të funksionojnë në JVM, dhe tomcat është vetëm një prej tyre, kështu që eksportuesi ka nevojë për disa konfigurime shtesë. Ekzistojnë konfigurime standarde për tomcat, mizën e egër, kafka dhe kështu me radhë këtu. Ne do të shtojmë tomcat si ConfigMap në Kubernetes dhe më pas vendoseni si vëllim.

Së pari, ne shtojmë skedarin e konfigurimit të eksportuesit në direktorinë tonë të platformës/config/

platform/config └── prometheus-jmx.yaml

Më pas shtojmë ConfigMapGenerator в kustomization.yaml.tmpl:

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

Kjo do të shtojë çdo element files[] si një element konfigurimi ConfigMap. ConfigMapGenerators janë të shkëlqyera sepse hasin të dhënat e konfigurimit dhe detyrojnë një rinisje të pod nëse ndryshon. Ato gjithashtu zvogëlojnë sasinë e konfigurimit në Deployment pasi mund të montoni një "dosje" të tërë skedarësh konfigurimi në një VolumeMount.

Më në fund, ne duhet të montojmë ConfigMap si një vëllim në 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 [...]

E mrekullueshme. Nëse Prometheus nuk është konfiguruar për të bërë një pastrim të plotë, mund t'ju duhet t'i thoni që të pastrojë bishtet. Përdoruesit e Operatorit Prometheus mund të përdorin service-monitor.yaml per te filluar. Eksploroni Service-monitor.yaml, dizajni i operatorit и ServiceMonitorSpec para se të filloni.

Zgjerimi i këtij modeli në raste të tjera përdorimi

Të gjithë skedarët që shtojmë në ConfigMapGenerator do të jenë të disponueshëm në drejtorinë e re /etc/config. Ju mund ta zgjeroni këtë shabllon për të montuar çdo skedar tjetër konfigurimi që ju nevojitet. Ju madje mund të montoni një skript të ri fillestar. Ju mund të përdorni nënshteg për të montuar skedarë individualë. Për të përditësuar skedarët xml, merrni parasysh përdorimin xmlstarlet në vend të sed. Është përfshirë tashmë në imazh.

Revista

Lajm i madh! Regjistrat e aplikacioneve janë tashmë të disponueshme në stdout, për shembull me kubectl logs. Fluentd (i instaluar si parazgjedhje në GKE) do t'i përcjellë regjistrat tuaja te Elasticsearch, Loki ose platforma juaj e regjistrimit të ndërmarrjes. Nëse dëshironi të përdorni jsonify për regjistrat, atëherë mund të ndiqni shabllonin e mësipërm për ta instaluar logback.

bazës së të dhënave

Si parazgjedhje, imazhi do të ketë një bazë të dhënash H2. Kjo nuk është e përshtatshme për ne dhe ne do të përdorim Google Cloud SQL me Cloud SQL Proxy - kjo do të nevojitet më vonë për të zgjidhur problemet e brendshme. Ky është një opsion i thjeshtë dhe i besueshëm nëse nuk keni preferencat tuaja në konfigurimin e bazës së të dhënave. AWS RDS ofron një shërbim të ngjashëm.

Pavarësisht nga databaza që zgjidhni, përveç nëse është H2, do t'ju duhet të vendosni variablat e duhura të mjedisit në platform/deploy.yaml. Duket diçka si kjo:

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

Shënim: Mund të përdorni Kustomize për t'u vendosur në mjedise të ndryshme duke përdorur një mbivendosje: shembull.

Shënim: përdorimi valueFrom: secretKeyRef. Ju lutem, përdorni kjo veçori e Kubernetes edhe gjatë zhvillimit për të mbajtur sekretet tuaja të sigurta.

Ka të ngjarë që ju tashmë keni një sistem të preferuar për menaxhimin e sekreteve të Kubernetes. Nëse jo, këtu janë disa opsione: Kriptimi i tyre me KMS-në e ofruesit tuaj të cloud dhe më pas injektimi i tyre në K8S si sekrete nëpërmjet tubacionit të CD-së − Mozilla SOPS - do të funksionojë shumë mirë në kombinim me sekretet e Kustomize. Ka mjete të tjera, të tilla si dotGPG, që kryejnë funksione të ngjashme: HashiCorp Vault, Personalizo shtojcat me vlerë sekrete.

Hyrje

Nëse nuk zgjidhni të përdorni përcjelljen e portit lokal, do t'ju duhet një kontrollues i konfiguruar i hyrjes. Nëse nuk përdorni hyrje-nginx (Tabela e helmetit) atëherë me shumë mundësi ju tashmë e dini se duhet të instaloni shënimet e nevojshme në ingress-patch.yaml.tmpl ose platform/ingress.yaml. Nëse jeni duke përdorur ingress-nginx dhe shihni një klasë hyrëse nginx me një balancues ngarkese që tregon drejt tij dhe një hyrje të jashtme DNS ose karakteristike të DNS-së, ju jeni gati të shkoni. Përndryshe, konfiguroni kontrolluesin e hyrjes dhe DNS, ose kapërceni këto hapa dhe mbani lidhjen e drejtpërdrejtë me podin.

TLS

Nëse jeni duke përdorur cert-menaxher ose kube-lego dhe letsencrypt - certifikatat për hyrjen e re do të merren automatikisht. Përndryshe, hapeni ingress-patch.yaml.tmpl dhe personalizoni atë për t'iu përshtatur nevojave tuaja.

Nisja!

Nëse keni ndjekur gjithçka që është shkruar më lart, atëherë komanda make skaffold HOSTNAME=<you.example.com> duhet të lëshojë një shembull të disponueshëm në <hostname>/camunda

Nëse nuk e keni vendosur hyrjen tuaj në një URL publike, mund ta ridrejtoni atë me localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 mbi localhost:8080/camunda

Prisni disa minuta derisa tomcat të jetë plotësisht gati. Menaxherit të certifikatës do t'i duhet pak kohë për të verifikuar emrin e domenit. Më pas mund të monitoroni regjistrat duke përdorur mjete të disponueshme si një mjet si kubetail, ose thjesht duke përdorur kubectl:

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

Hapat e ardhshëm

Autorizim

Kjo është më e rëndësishme për konfigurimin e Camunda BPM sesa Kubernetes, por është e rëndësishme të theksohet se si parazgjedhje, vërtetimi është i çaktivizuar në REST API. Ti mundesh aktivizoni vërtetimin bazë ose përdorni një metodë tjetër si p.sh J.W.T.. Ju mund të përdorni konfigurimin dhe vëllimet për të ngarkuar xml, ose xmlstarlet (shih më lart) për të modifikuar skedarët ekzistues në imazh dhe ose të përdorni wget ose t'i ngarkoni ato duke përdorur një kontejner fillestar dhe një vëllim të përbashkët.

Menaxhimi i sesionit

Ashtu si shumë aplikacione të tjera, Camunda BPM trajton seancat në JVM, kështu që nëse dëshironi të ekzekutoni kopje të shumta, mund të aktivizoni sesione ngjitëse (për shembull për ingress-nginx), i cili do të ekzistojë derisa kopja të zhduket, ose vendosni atributin Max-Age për cookies. Për një zgjidhje më të fuqishme, mund të vendosni Session Manager në Tomcat. Lars ka postim i veçantë në këtë temë, por diçka si:

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"
ngjitës="i rremë"
sessionBackupAsync="i rremë"
storageKeyPrefix="konteksti"
Modaliteti i kyçjes="automatik"
/>' conf/context.xml

Shënim: mund të përdorni xmlstarlet në vend të sed

Ne kemi përdorur twemproxy përballë Google Cloud Memorystor, me memcached-session-manager (mbështet Redis) për ta ekzekutuar.

Shkallëzimi

Nëse tashmë i kuptoni sesionet, atëherë kufizimi i parë (dhe shpesh i fundit) për shkallëzimin e Camunda BPM mund të jetë lidhja me bazën e të dhënave. Përshtatja e pjesshme është tashmë në dispozicion "nga kutia" Le të çaktivizojmë gjithashtu intialSize në skedarin settings.xml. Shtoni Shkallues automatik i podeve horizontale (HPA) dhe ju lehtë mund të shkallëzoni automatikisht numrin e pods.

Kërkesat dhe kufizimet

В platform/deployment.yaml Do të shihni që ne e kemi koduar me forcë fushën e burimeve. Kjo funksionon mirë me HPA, por mund të kërkojë konfigurim shtesë. Patch-i kustomize është i përshtatshëm për këtë. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl

Prodhim

Kështu që ne instaluam Camunda BPM në Kubernetes me metrikë Prometheus, regjistrat, bazën e të dhënave H2, TLS dhe Ingress. Ne shtuam skedarë jar dhe skedarë konfigurimi duke përdorur ConfigMaps dhe Dockerfile. Ne folëm për shkëmbimin e të dhënave në vëllime dhe drejtpërdrejt në variablat e mjedisit nga sekretet. Përveç kësaj, ne dhamë një përmbledhje të konfigurimit të Camunda për kopje të shumta dhe një API të vërtetuar.

Referencat

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