🥇Lancer Camunda BPM på Kubernetes

Bruger du Kubernetes? Klar til at flytte dine Camunda BPM-instanser ud af virtuelle maskiner, eller måske bare prøve at køre dem på Kubernetes? Lad os se på nogle almindelige konfigurationer og individuelle elementer, der kan skræddersyes til dine specifikke behov.

Det forudsætter, at du har brugt Kubernetes før. Hvis ikke, hvorfor så ikke tage et kig på lederskab og ikke starte din første klynge?

Forfattere

Alastair Firth (Alastair Firth) - Senior Site Reliability Engineer på Camunda Cloud-teamet;
Lars Lange (Lars Lange) - DevOps-ingeniør hos Camunda.

Kort sagt:

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

Okay, det virkede nok ikke, fordi du ikke har skaffold og kustomize installeret. Så læs videre!

Hvad er Camunda BPM

Camunda BPM er en open source platform til forretningsprocesstyring og beslutningsautomatisering, der forbinder forretningsbrugere og softwareudviklere. Den er ideel til at koordinere og forbinde mennesker, (mikro)tjenester eller endda bots! Du kan læse mere om de forskellige use cases på link.

Hvorfor bruge Kubernetes

Kubernetes er blevet de facto standarden for at køre moderne applikationer i LinuxVed at bruge systemkald i stedet for hardwareemulering og lade kernen styre hukommelse og opgaveskift, minimeres opstarts- og opstartstider. Den største fordel kan dog komme fra den standard-API, som Kubernetes leverer til konfiguration af den infrastruktur, der er nødvendig for alle applikationer: lagring, netværk og overvågning. Det fejrede sit seksårsjubilæum i juni 2020, hvilket gør det til måske det næststørste open source-projekt (efter LinuxDen har for nylig aktivt stabiliseret sin funktionalitet efter hurtig iteration i løbet af de seneste par år, da den bliver kritisk for produktionsbelastninger over hele verden.

Camunda BPM Engine kan nemt oprette forbindelse til andre applikationer, der kører på den samme klynge, og Kubernetes giver fremragende skalerbarhed, så du kun kan øge infrastrukturomkostningerne, når det virkelig er nødvendigt (og nemt reducere dem efter behov).

Kvaliteten af overvågningen er også væsentligt forbedret med værktøjer som Prometheus, Grafana, Loki, Fluentd og Elasticsearch, hvilket giver dig mulighed for centralt at se alle arbejdsbelastninger i en klynge. I dag skal vi se på, hvordan man implementerer Prometheus-eksportøren i Java Virtual Machine (JVM).

mål

Lad os se på et par områder, hvor vi kan tilpasse Camunda BPM Docker-billedet (github), så den interagerer godt med Kubernetes.

Logfiler og metrikker;
Databaseforbindelser;
Godkendelse;
Sessionsledelse.

Vi vil se på flere måder at nå disse mål på og tydeligt vise hele processen.

Bemærk: Bruger du Enterprise-versionen? Se her og opdatere billedlinks efter behov.

Udvikling af arbejdsgange

I denne demo vil vi bruge Skaffold til at bygge Docker-billeder ved hjælp af Google Cloud Build. Det har god understøttelse af forskellige værktøjer (såsom Kustomize og Helm), CI og build-værktøjer og infrastrukturudbydere. Fil skaffold.yaml.tmpl inkluderer indstillinger for Google Cloud Build og GKE, hvilket giver en meget enkel måde at køre produktionskvalitetsinfrastruktur på.

make skaffold vil indlæse Dockerfile-konteksten i Cloud Build, bygge billedet og gemme det i GCR og derefter anvende manifesterne på din klynge. Dette er, hvad det gør make skaffold, men Skaffold har mange andre funktioner.

Til yaml-skabeloner i Kubernetes bruger vi kustomize til at administrere yaml-overlejringer uden at forgrene hele manifestet, så du kan bruge git pull --rebase for yderligere forbedringer. Nu er det i kubectl, og det fungerer ret godt til sådanne ting.

Vi bruger også envsubst til at udfylde værtsnavnet og GCP-projekt-id'et i *.yaml.tmpl-filerne. Du kan se, hvordan det fungerer i makefile eller bare fortsæt videre.

Forudsætninger

Arbejdsklynge Kubernetes
Tilpas
Skaffold - til at oprette dine egne docker-billeder og nem implementering til GKE
Kopi af denne kode
Envsubst

Workflow ved hjælp af manifester

Hvis du ikke ønsker at bruge kustomize eller skaffold, kan du henvise til manifesterne i generated-manifest.yaml og tilpasse dem til den arbejdsgang, du vælger.

Logfiler og metrikker

Prometheus er blevet standarden for indsamling af metrics i Kubernetes. Det indtager samme niche som AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics og andre. Det er open source og har et kraftfuldt forespørgselssprog. Vi overlader visualiseringen til Grafana - den kommer med et stort antal dashboards, der er tilgængelige direkte fra kassen. De er forbundet med hinanden og er forholdsvis nemme at installere med prometheus-operatør.

Som standard bruger Prometheus ekstraktionsmodellen <service>/metrics, og det er almindeligt at tilføje sidevognsbeholdere til dette. Desværre logges JMX-metrics bedst i JVM, så sidevognscontainere er ikke så effektive. Lad os forbinde jmx_eksportør open source fra Prometheus til JVM ved at føje det til containerbilledet, som vil give stien /metrics på en anden havn.

Tilføj Prometheus jmx_exporter til containeren

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

## Tilføj prometheus-eksportør
KØR 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 er den reserverede prometheus-jmx-port
ENV CATALINA_OPTS -javaagent:lib/
jmx_prometheus_javaagent-0.11.0.jar=9404:/etc/config/prometheus-jmx.yaml

Nå, det var nemt. Eksportøren vil overvåge tomcat og vise dens metrics i Prometheus-format på <svc>:9404/metrics

Eksportør opsætning

Den opmærksomme læser kan undre sig over, hvor det kom fra prometheus-jmx.yaml? Der er mange forskellige ting, der kan køre i JVM, og tomcat er kun en af dem, så eksportøren har brug for noget ekstra konfiguration. Standardkonfigurationer til tomcat, wildfly, kafka og så videre er tilgængelige her. Vi tilføjer tomcat som ConfigMap i Kubernetes og derefter montere den som et volumen.

Først tilføjer vi eksportørens konfigurationsfil til vores platform/config/ bibliotek

platform/config └── prometheus-jmx.yaml

Så tilføjer vi ConfigMapGenerator в kustomization.yaml.tmpl:

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

Dette vil tilføje hvert element files[] som et ConfigMap-konfigurationselement. ConfigMapGenerators er fantastiske, fordi de hash konfigurationsdataene og tvinger en pod-genstart, hvis den ændrer sig. De reducerer også mængden af konfiguration i Deployment, da du kan montere en hel "mappe" af konfigurationsfiler i én VolumeMount.

Til sidst skal vi montere ConfigMap som en volumen til poden:

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

Vidunderlig. Hvis Prometheus ikke er konfigureret til at foretage en fuldstændig oprydning, skal du muligvis bede den om at rydde op i bælgerne. Prometheus Operator-brugere kan bruge service-monitor.yaml at komme i gang. Udforske Service-monitor.yaml, operatørdesign и ServiceMonitorSpec før du starter.

Udvidelse af dette mønster til andre use cases

Alle filer, vi tilføjer til ConfigMapGenerator, vil være tilgængelige i den nye mappe /etc/config. Du kan udvide denne skabelon til at montere andre konfigurationsfiler, du har brug for. Du kan endda montere et nyt opstartsscript. Du kan bruge understi at montere individuelle filer. For at opdatere xml-filer, overvej at bruge xmlstarlet i stedet for sed. Det er allerede inkluderet i billedet.

Magasiner

Gode nyheder! Applikationslogs er allerede tilgængelige på stdout, for eksempel med kubectl logs. Fluentd (installeret som standard i GKE) vil videresende dine logfiler til Elasticsearch, Loki eller din virksomheds logplatform. Hvis du vil bruge jsonify til logfiler, kan du følge ovenstående skabelon for at installere log tilbage.

database

Som standard vil billedet have en H2-database. Dette er ikke egnet for os, og vi vil bruge Google Cloud SQL med Cloud SQL Proxy - dette vil være nødvendigt senere for at løse interne problemer. Dette er en enkel og pålidelig mulighed, hvis du ikke har dine egne præferencer i opsætning af databasen. AWS RDS leverer en lignende service.

Uanset hvilken database du vælger, medmindre det er H2, skal du indstille de relevante miljøvariabler i platform/deploy.yaml. Det ser sådan ud:

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

Bemærk: Du kan bruge Kustomize til at implementere til forskellige miljøer ved hjælp af et overlay: eksempel.

Bemærk: brug valueFrom: secretKeyRef. Brug venligst denne Kubernetes-funktion selv under udvikling for at holde dine hemmeligheder sikre.

Det er sandsynligt, at du allerede har et foretrukket system til at administrere Kubernetes-hemmeligheder. Hvis ikke, her er nogle muligheder: Kryptering af dem med din cloud-udbyders KMS og derefter injicere dem i K8S som hemmeligheder via CD-pipeline − MozillaSOPS - vil fungere meget godt i kombination med Kustomize-hemmeligheder. Der er andre værktøjer, såsom dotGPG, der udfører lignende funktioner: HashiCorp Vault, Tilpas hemmelige værdi-plugins.

Ingress

Medmindre du vælger at bruge lokal portvideresendelse, skal du bruge en konfigureret Ingress Controller. Hvis du ikke bruger ingress-nginx (Hjelmdiagram) så ved du højst sandsynligt allerede, at du skal installere de nødvendige annoteringer i ingress-patch.yaml.tmpl eller platform/ingress.yaml. Hvis du bruger ingress-nginx og ser en nginx ingress-klasse med en load balancer, der peger på den, og en ekstern DNS eller wildcard DNS-indgang, er du god til at gå. Ellers skal du konfigurere Ingress Controller og DNS, eller springe disse trin over og bevare den direkte forbindelse til poden.

TLS

Hvis du bruger cert-manager eller kube-lego og letsencrypt - certifikater til det nye login vil blive hentet automatisk. Ellers åben ingress-patch.yaml.tmpl og skræddersy den, så den passer til dine behov.

Lancering!

Hvis du fulgte alt skrevet ovenfor, så kommandoen make skaffold HOSTNAME=<you.example.com> skal starte en tilgængelig instans i <hostname>/camunda

Hvis du ikke har indstillet dit login til en offentlig URL, kan du omdirigere det med localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 på localhost:8080/camunda

Vent et par minutter, indtil tomcat er helt klar. Cert-manager vil bruge lidt tid på at bekræfte domænenavnet. Du kan derefter overvåge logfilerne ved hjælp af tilgængelige værktøjer såsom et værktøj som kubetail, eller blot ved at bruge kubectl:

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

Næste trin

Tilladelse

Dette er mere relevant for konfiguration af Camunda BPM end Kubernetes, men det er vigtigt at bemærke, at godkendelse som standard er deaktiveret i REST API. Du kan aktivere grundlæggende godkendelse eller brug en anden metode som f.eks J.W.T.. Du kan bruge configmaps og volumener til at indlæse xml, eller xmlstarlet (se ovenfor) til at redigere eksisterende filer i billedet, og enten bruge wget eller indlæse dem ved hjælp af en init-beholder og en delt volumen.

Sessionsledelse

Som mange andre applikationer håndterer Camunda BPM sessioner i JVM, så hvis du vil køre flere replikaer, kan du aktivere sticky sessioner (for eksempel for ingress-nginx), som vil eksistere, indtil replikaen forsvinder, eller indstil Max-Age-attributten for cookies. For en mere robust løsning kan du implementere Session Manager i Tomcat. Lars har separat indlæg om dette emne, men noget som:

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 '/^ /jeg
<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="redis://redis-proxy.db:22121"
klistret="falsk"
sessionBackupAsync="falsk"
storageKeyPrefix="kontekst"
låsetilstand="auto"
/>' conf/kontekst.xml

Bemærk: du kan bruge xmlstarlet i stedet for sed

Vi brugte twemproxy foran Google Cloud Memorystore, med memcached-session-manager (understøtter Redis) for at køre det.

Skalering

Hvis du allerede forstår sessioner, så kan den første (og ofte den sidste) begrænsning til at skalere Camunda BPM være forbindelsen til databasen. Delvis tilpasning er allerede tilgængelig "fra kassen" Lad os også deaktivere intialSize i filen settings.xml. Tilføje Horisontal Pod Autoscaler (HPA) og du kan nemt automatisk skalere antallet af pods.

Anmodninger og begrænsninger

В platform/deployment.yaml Du vil se, at vi har hårdkodet ressourcefeltet. Dette fungerer godt med HPA, men kan kræve yderligere konfiguration. Kutomize-plasteret er velegnet til dette. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl

Output

Så vi installerede Camunda BPM på Kubernetes med Prometheus-metrics, logs, H2-database, TLS og Ingress. Vi tilføjede jar-filer og konfigurationsfiler ved hjælp af ConfigMaps og Dockerfile. Vi talte om at udveksle data til volumener og direkte til miljøvariabler fra hemmeligheder. Derudover gav vi en oversigt over opsætning af Camunda til flere replikaer og en autentificeret API.

RЎSЃS <P "RєRё

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