🥇Lansare Camunda BPM în Kubernetes

Folosiți Kubernetes? Sunteți pregătiți să migrați instanțele dvs. Camunda BPM de pe mașini virtuale sau poate doriți doar să încercați să le rulați pe Kubernetes? Să examinăm câteva configurații comune și elemente individuale care pot fi adaptate nevoilor dumneavoastră specifice.

Se presupune că ați folosit deja Kubernetes. Dacă nu, de ce să nu aruncați o privire la ghid și să vă lansați primul cluster?

Autori

Alastair Firth (Alastair Firth) este inginer senior de fiabilitate a site-ului (Site Reliability Engineer) în echipa Camunda Cloud;
Lars Lange (Lars Lange) este inginer DevOps la Camunda.

Pe scurt:

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

Ei bine, este probabil că nu a funcționat, deoarece nu aveți instalate skaffold și kustomize. Atunci continuați să citiți!

Ce este Camunda BPM

Camunda BPM este o platformă open-source pentru gestionarea proceselor de afaceri și automatizarea deciziilor care reunește utilizatorii de afaceri și dezvoltatorii de software. Este perfectă pentru coordonarea și integrarea oamenilor, (micro)serviciilor sau chiar a boților! Puteți citi mai multe despre diferitele utilizări la linkul.

De ce să folosiți Kubernetes

Kubernetes a devenit standardul de facto pentru rularea aplicațiilor moderne pe Linux. Datorită utilizării apelurilor de sistem în loc de emularea nivelului hardware și capacităților nucleului de a gestiona memoria și comutarea sarcinilor de lucru, timpul de pornire și timpul de execuție sunt reduse la minimum. Cu toate acestea, cel mai mare beneficiu poate proveni din API-ul standard pe care Kubernetes îl oferă pentru configurarea infrastructurii necesare pentru toate aplicațiile: stocare, rețea și monitorizare. În iunie 2020, a împlinit 6 ani, iar acesta este, fără îndoială, al doilea cel mai mare proiect open-source (după Linux). Recent, el își stabilizează activ funcționalitățile după o iterație rapidă în ultimii câțiva ani, pe măsură ce devine critic pentru sarcinile de lucru din întreaga lume.

Motorul Camunda BPM poate fi conectat cu ușurință la alte aplicații care rulează în același cluster, iar Kubernetes oferă o scalabilitate excelentă, permițând creșterea costurilor de infrastructură doar atunci când este cu adevărat necesar (și reducerea lor cu ușurință pe măsură ce este necesar).

Calitatea monitorizării se îmbunătățește semnificativ și cu ajutorul unor instrumente precum Prometheus, Grafana, Loki, Fluentd și Elasticsearch, care permit vizualizarea centralizată a tuturor sarcinilor de lucru din cluster. Astăzi vom discuta despre cum să implementăm un exportator Prometheus în o mașină virtuală Java (JVM).

Obiective

Hai să explorăm câteva domenii în care putem configura imaginea Docker Camunda BPM (github), astfel încât să funcționeze bine cu Kubernetes.

Jurnalele și metricele;
Conexiuni la baza de date;
Autentificarea;
Gestionarea sesiunilor.

Vom explora câteva metode de implementare a acestor obiective și vom ilustra întregul proces.

Notă: Utilizezi versiunea Enterprise? Verifică aici și actualizează linkurile către imagini, dacă este necesar.

Dezvoltarea fluxului de lucru

În această demonstrație, vom folosi Skaffold pentru a crea imagini Docker cu ajutorul Google Cloud Build. Acesta oferă un suport bun pentru diferite instrumente (cum ar fi Kustomize și Helm), CI și instrumente de construire, precum și furnizori de infrastructură. Fișierul skaffold.yaml.tmpl include setări pentru Google Cloud Build și GKE, oferind astfel o modalitate foarte simplă de a lansa infrastructura de nivel industrial.

make skaffold va încărca contextul Dockerfile în Cloud Build, va crea imaginea și o va salva în GCR, apoi va aplica manifeștele la clusterul tău. Acesta este rolul make skaffold, dar Skaffold are multe alte funcționalități.

Pentru șabloanele yaml din Kubernetes, folosim kustomize pentru a gestiona suprapunerile yaml fără a ramifica întregul manifest, permițându-vă să folosiți git pull --rebase pentru îmbunătățiri ulterioare. Acum este în kubectl și funcționează destul de bine pentru astfel de lucruri.

De asemenea, folosim envsubst pentru a umple numele gazdei și identificatorul proiectului GCP în fișierele * .yaml.tmpl. Poți vedea cum funcționează acest lucru în makefile sau poți continua pur și simplu mai departe.

Cerințe necesare

Cluster de lucru Kubernetes
Kustomize
Skaffold — pentru a crea propriile imagini Docker și pentru a desfășura cu ușurință în GKE
O copie a acestui cod
Envsubst

Flux de lucru cu manifești

Dacă nu dorești să folosești kustomize sau skaffold, poți face referire la manifești în generated-manifest.yaml și să le adaptezi la fluxul de lucru dorit.

Jurnalele și metricele

Prometheus a devenit standardul pentru colectarea metricilor în Kubernetes. Acesta ocupă aceeași nișă ca AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics și altele. Are sursă deschisă și un limbaj de interogare puternic. Vizualizarea va fi realizată de Grafana – acesta vine cu un număr mare de panouri de monitorizare disponibile din cutie. Acestea sunt interconectate și relativ ușor de configurat cu prometheus-operator.

Implicit, Prometheus utilizează modelul de extragere /metrics, iar adăugarea containerelor sidecar pentru acest lucru este o practică obișnuită. Din păcate, metricile JMX sunt cel mai bine înregistrate în interiorul JVM, astfel că containerele sidecar nu sunt la fel de eficiente. Să conectăm jmx_exporter un agent deschis de la Prometheus la JVM, adăugându-l în imaginea containerului, care va oferi un mod /metrics pe un alt port.

Adăugați exporter-ul Prometheus jmx în container

-- imagini/camunda-bpm/Dockerfile DE LA 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

Ei bine, a fost ușor. Exporter-ul va monitoriza tomcat și va afișa metricile sale în format Prometheus la adresa :9404/metrics

Configurarea exporter-ului

Cercetătorul atent ar putea să se întrebe, de unde provine prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны aici. Vom adăuga tomcat ca ConfigMap în Kubernetes, iar apoi îl vom monta ca volum.

În primul rând, adăugăm fișierul de configurare al exporter-ului în directorul nostru platform/config/

platformă/config └── prometheus-jmx.yaml

Apoi adăugăm ConfigMapGenerator în kustomization.yaml.tmpl:

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

Aceasta va adăuga fiecare element files[] ca element al ConfigMap-ului de configurare. ConfigMapGenerators sunt utile deoarece hash-ează datele din configurație și inițiază repornirea pod-ului dacă acesta se schimbă. De asemenea, reduc volumul configurației în Deployment, deoarece puteți monta întreaga „folder” de fișiere de configurare într-un singur VolumeMount.

În cele din urmă, trebuie să montăm ConfigMap ca volum la pod:

-- platform/deployment.yaml apiVersion: apps/v1 tip: Deployment [...] spec: template: spec: [...] volumes: - name: config configMap: name: config defaultMode: 0744 containere: - name: camunda-bpm volumeMounts: - mountPath: /etc/config/ name: config [...]

Excelent. Dacă Prometheus nu este configurat pentru a curăța complet, va trebui să-i spui să curețe pod-urile. Utilizatorii Prometheus Operator pot folosi service-monitor.yaml pentru a începe. Studiați Service-monitor.yaml, designul operatorului și ServiceMonitorSpec înainte de a începe.

Distribuirea acestui șablon pentru alte utilizări

Toate fișierele pe care le adăugăm în ConfigMapGenerator vor fi disponibile în noul director /etc/config. Puteți extinde acest șablon pentru a monta orice alte fișiere de configurare necesare. Puteți chiar monta un nou script de pornire. Puteți folosi subPath pentru a monta fișiere individuale. Pentru actualizarea fișierelor xml, luați în considerare utilizarea xmlstarlet în loc de sed. Acesta este deja inclus în imagine.

Jurnale

Vești excelente! Jurnalele aplicațiilor sunt deja disponibile pe stdout, de exemplu, folosind kubectl logs. Fluentd (inclus implicit în GKE) va redirecționa jurnalele dvs. către Elasticsearch, Loki sau către platforma dvs. de jurnalizare corporativă. Dacă doriți să utilizați jsonify pentru jurnale, puteți urma șablonul de mai sus pentru a configura logback.

Baza de date

Implicit, imaginea va avea o bază de date H2. Acest lucru nu ne convine, iar noi vom folosi Google Cloud SQL cu Cloud SQL Proxy — aceasta va fi necesară mai târziu pentru a rezolva sarcini interne. Aceasta este o opțiune simplă și de încredere, dacă nu aveți preferințe personale în configurarea bazei de date. AWS RDS oferă un serviciu similar.

Indiferent de baza de date aleasă, cu excepția H2, va trebui să setați variabilele de mediu corespunzătoare în platform/deploy.yaml. Asta arată cam așa:

-- platform/deployment.yaml apiVersion: apps/v1 tip: Deployment [...] spec: template: spec: [...] containere: - 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 [...]

Notă: Puteți utiliza Kustomize pentru desfășurarea în diverse medii folosind overlay: exemplu.

Notă: utilizarea valueFrom: secretKeyRef. Vă rugăm să folosiți această funcție Kubernetes chiar și în timpul dezvoltării, pentru a vă păstra secretele în siguranță.

Este foarte probabil să aveți deja un sistem preferat de gestionare a secretelor Kubernetes. Dacă nu, iată câteva opțiuni: criptarea acestora cu KMS-ul furnizorului dvs. de cloud, apoi introducerea lor în K8S ca secrete prin intermediul unui pipeline CD — MozillaSOPS — va funcționa foarte bine împreună cu secretele Kustomize. Există și alte instrumente, cum ar fi dotGPG — acestea îndeplinesc funcții similare: HashiCorp Vault, Kustomize Secret Value Plugins.

Ingress

Dacă nu decideți să utilizați redirecționarea portului local, veți avea nevoie de un Ingress Controller configurat. Dacă nu folosiți ingress-nginx (diagrama Helm) atunci, cel mai probabil, știți deja că trebuie să stabiliți anotările necesare în ingress-patch.yaml.tmpl sau platform/ingress.yaml. Dacă folosiți ingress-nginx și vedeți o clasă nginx ingress cu un mesaj de balansare a încărcării care indică spre el și DNS extern sau o înregistrare wildcard DNS, totul este pregătit. În caz contrar, configurați Ingress Controller-ul și DNS-ul sau săriți peste acești pași și lăsați conexiunea directă către pod.

TLS

Dacă folosești cert-manager sau kube-lego și letsencrypt - certificatele pentru noul ingress vor fi obținute automat. În caz contrar, deschideți ingress-patch.yaml.tmpl și configurați-l conform nevoilor dumneavoastră.

Lansare!

Dacă ați urmat tot ce este scris mai sus, comanda make skaffold HOSTNAME= ar trebui să lanseze o instanță accesibilă în /camunda

Dacă nu ați expus ingress-ul printr-o adresă URL publică, puteți face o redirecționare de la localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 pe localhost:8080/camunda

Așteptați câteva minute până când tomcat este complet pregătit. Cert-manager va avea nevoie de ceva timp pentru a verifica numele de domeniu. După aceasta, puteți urmări jurnalul folosind unelte disponibile - de exemplu, un instrument ca kubetail, sau pur și simplu cu ajutorul kubectl:

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

Următorii pași

Autorizare

Aceasta se referă mai mult la configurarea Camunda BPM decât la Kubernetes, dar este important de menționat că, în mod implicit, în API-ul REST autentificarea este dezactivată. Puteți activa autentificarea de bază sau folosi o altă metodă, de exemplu JWT. Puteți folosi configmaps și volume pentru a încărca xml, sau xmlstarlet (consultați mai sus) pentru a edita fișierele existente din imagine, și de asemenea să folosiți fie wget, fie să le încărcați cu ajutorul unui container init și unei volume partajate.

Gestionarea sesiunilor

Ca și multe alte aplicații, Camunda BPM gestionează sesiunile în JVM, așa că, dacă doriți să rulați mai multe replici, puteți activa sesiuni sticky (de exemplu, pentru ingress-nginx), care vor exista până când replica dispare, sau să setați atributul Max-Age pentru cookie-uri. Ca o soluție mai fiabilă, puteți desfășura un Session Manager în Tomcat. Lars are o postare separată despre asta, dar ceva de genul:

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

Notă: puteați folosi xmlstarlet în loc de sed

Am folosit twemproxy înainte de Google Cloud Memorystore, cu memcached-session-manager (suportă Redis) pentru a-l pune în funcțiune.

Scalare

Dacă deja te-ai familiarizat cu sesiunile, atunci prima (și adesea ultima) limitare în scalarea Camunda BPM poate fi conexiunea la baza de date. Configurarea parțială este disponibilă deja „din cutie”. De asemenea, vom dezactiva intialSize în fișierul settings.xml. Adăugați HorizontalPodAutoscaler (HPA) și veți putea scala automat ușor numărul de poduri.

Cereri și limitări

În platform/deployment.yaml veți observa că am codificat strict câmpul resurselor. Acest lucru funcționează bine cu HPA, dar poate necesita o configurare suplimentară. În acest sens, un patch kustomize este potrivit. Vezi ingress-patch.yaml.tmpl și ./kustomization.yaml.tmpl

Ieșire

Iată că am instalat Camunda BPM pe Kubernetes cu metrici Prometheus, jurnale, baza de date H2, TLS și Ingress. Am adăugat fișiere jar și fișiere de configurare folosind ConfigMaps și Dockerfile. Am discutat despre schimbul de date cu volumele și direct în variabilele de mediu din secrete. În plus, am oferit o prezentare generală a configurării Camunda pentru mai multe replici și API autenticat.

Linkuri

github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes │ ├── generated-manifest.yaml <- manifest pentru utilizare fără kustomize ├── imagini │ └── camunda-bpm │ └── Dockerfile <- imagine docker overlay ├── ingress-patch.yaml.tmpl <- configurație ingress specifică site-ului ├── kustomization.yaml.tmpl <- Kustomization principal ├── Makefile <- ținte de creare ├── namespace.yaml ├── platformă │ ├── config │ │ └── prometheus-jmx.yaml <- fișier de configurare prometheus exporter │ ├── deployment.yaml <- desfășurarea principală │ ├── ingress.yaml │ ├── kustomization.yaml <- kustomization "de bază" │ ├── service-monitor.yaml <- configurație exemplu pentru prometheus-operator │ └── service.yaml └── skaffold.yaml.tmpl <- directive skaffold