🥇Lansere Camunda BPM i Kubernetes

Bruker du Kubernetes? Klar for å flytte Camunda BPM-instansene dine fra virtuelle maskiner, eller kanskje bare prøve å kjøre dem på Kubernetes? La oss se på noen vanlige konfigurasjoner og individuelle elementer som kan tilpasses dine spesifikke behov.

Det forutsettes at du allerede har brukt Kubernetes før. Hvis ikke, hvorfor ikke ta en titt på veiledningen og starte din første klynge?

Forfattere

Alastair Firth er senior Site Reliability Engineer i Camunda Cloud-teamet;
Lars Lange er 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

Vel, det fungerte sannsynligvis ikke, siden du ikke har installert skaffold og kustomize. Da kan du lese videre!

Hva er Camunda BPM

Camunda BPM er en plattform med åpen kildekode for håndtering av forretningsprosesser og automatisering av beslutningstaking, som forener forretningsbrukere og programvareutviklere. Den er perfekt for å koordinere og samle mennesker, (mikro) tjenester eller til og med roboter! Les mer om forskjellige bruksområder på lenken.

Hvorfor bruke Kubernetes

Kubernetes har blitt de facto-standarden for å kjøre moderne applikasjoner på Linux. Takket være bruken av systemkall i stedet for emulering av maskinvare og kjernens evner til å håndtere minne og oppgaveveksling, minimeres oppstartstid og kjøretid. Men det største fortrinnet kan være det standard API-grensesnittet som Kubernetes tilbyr for å konfigurere infrastrukturen som alle applikasjoner trenger: lagring, nettverk og overvåking. I juni 2020 fylte det 6 år, og det er kanskje det nest største prosjektet med åpen kildekode (etter Linux). Nylig har det aktivt stabilisert funksjonaliteten etter raske iterasjoner de siste årene, ettersom dette blir kritisk for produksjonsbelastninger over hele verden.

Camunda BPM-motoren kan enkelt kobles til andre applikasjoner som kjører i samme klynge, og Kubernetes gir utmerket skalerbarhet, noe som lar deg øke infrastrukturkostnadene bare når det virkelig er nødvendig (og enkelt redusere dem etter behov).

Kvaliteten på overvåkingen forbedres også betydelig med verktøy som Prometheus, Grafana, Loki, Fluentd og Elasticsearch, som gjør det mulig å sentralt se alle arbeidsbelastninger i klyngen. I dag skal vi se på hvordan vi implementerer Prometheus-exporteren på en Java Virtual Machine (JVM).

Mål

La oss se på noen områder der vi kan konfigurere Docker-bildet for Camunda BPM (github), slik at det fungerer godt med Kubernetes.

Logger og metrikker;
Databaseforbindelser;
Autentisering;
Sessionhåndtering.

Vi vil se på flere måter å oppnå disse målene og demonstrere hele prosessen visuelt.

Merk: Bruker du Enterprise-versjonen? Sjekk her og oppdater lenkene til bildene ved behov.

Utvikling av arbeidsflyt

I denne demonstrasjonen vil vi bruke Skaffold for å bygge Docker-bilder med Google Cloud Build. Det har god støtte for forskjellige verktøy (som Kustomize og Helm), CI og bygningsverktøy, samt leverandører av infrastruktur. Filen skaffold.yaml.tmpl inneholder innstillinger for Google Cloud Build og GKE, noe som gir en veldig enkel måte å kjøre infrastruktur i industrikvalitet på.

make skaffold vil laste opp Dockerfile-konteksten til Cloud Build, bygge bildet og lagre det i GCR, og deretter anvende manifestene på klyngen din. Det er det som gjøres make skaffold, men Skaffold har mange andre muligheter.

For YAML-maler i Kubernetes bruker vi kustomize for å administrere YAML-overlays uten å splitte hele manifestet, noe som lar deg bruke git pull --rebase for videre forbedringer. Nå er det i kubectl, og det fungerer greit for slike ting.

Vi bruker også envsubst for å fylle inn vertsnavnet og prosjekt-ID-en for GCP i filene *.yaml.tmpl. Du kan se hvordan dette fungerer i makefile eller bare fortsette videre.

Forutsetninger

Arbeidsklynge Kubernetes
Kustomize
Skaffold – for å lage egne docker-bilder og enkelt distribuere til GKE
En kopi av denne koden
Envsubst

Arbeidsflyt med manifestene

Hvis du ikke vil bruke kustomize eller skaffold, kan du referere til manifestene i generated-manifest.yaml og tilpasse dem til arbeidsflyten din.

Logger og metrikker

Prometheus har blitt standarden for innsamling av metrikk i Kubernetes. Den dekker samme nisje som AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics og flere. Den har åpen kildekode og et kraftig forespørselsspråk. Visualisering overlater vi til Grafana – den leveres med et stort antall overvåkningspaneler tilgjengelig rett ut av boksen. De er knyttet sammen og relativt enkle å installere med prometheus-operator.

Som standard bruker Prometheus en uthentingsmodell /metrics, og å legge til sidecar-containere for dette er ganske vanlig. Dessverre registreres JMX-metrikkene best innenfor JVM, så sidecar-containere er ikke like effektive. La oss koble til jmx_exporter med åpen kildekode fra Prometheus til JVM, ved å legge den til i beholderbildet som vil gi en rute /metrics på en annen port.

Legg til Prometheus jmx_exporter i beholderen

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

Nå, dette var enkelt. Eksportøren vil overvåke tomcat og vise dens metrikker i Prometheus-format på adressen :9404/metrics

Konfigurering av eksportøren

Den nøye leseren kan spørre seg selv hvor prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны herkom fra. Vi vil legge til tomcat som ConfigMap i Kubernetes, og deretter montere det som en volum.

Først legger vi til konfigurasjonsfilen for eksportøren i vår katalog platform/config/

plattform/config └── prometheus-jmx.yaml

Deretter legger vi til ConfigMapGenerator i 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 legge til hvert element files[] som et konfigurasjonselement for ConfigMap. ConfigMapGenerators er gode fordi de hasher data i konfigurasjonen og initierer omstart av podene dersom det endres. De reduserer også mengden konfigurasjon i Deployment, ettersom du kan montere hele "mappen" med konfigurasjonsfiler i én VolumeMount.

Til slutt må vi montere ConfigMap som et volum til podden:

-- plattform/deployment.yaml apiVersjon: apps/v1 type: Utplassering [...] spesifikasjon: mal: spesifikasjon: [...] volumer: - name: config konfigurasjonskart: navn: konfig standardModus: 0744 containere: - navn: camunda-bpm volumMonteringer: - monteringsSti: /etc/config/ navn: konfig [...]

Flott. Hvis Prometheus ikke er konfigurert for fullstendig opprydning, må du kanskje fortelle den å rydde opp podene. Brukere av Prometheus Operator kan bruke service-monitor.yaml for å komme i gang. Studer Service-monitor.yaml, operatørdesign og ServiceMonitorSpec før du begynner.

Distribusjon av denne malen til andre bruksområder

Alle filene som vi legger til i ConfigMapGenerator, vil være tilgjengelige i den nye katalogen /etc/configDu kan utvide denne malen for å montere eventuelle andre konfigurasjonsfiler du trenger. Du kan til og med montere et nytt oppstartsskript. Du kan bruke subPath til å montere individuelle filer. For å oppdatere xml-filer, vurder å bruke xmlstarlet i stedet for sed. Den er allerede inkludert i bildet.

Logger

Gode nyheter! Applikasjonslogger er nå tilgjengelige på stdout, for eksempel ved hjelp av kombineres. Fluentd (det er forhåndsinstallert i GKE) vil omdirigere loggene dine til Elasticsearch, Loki eller til din bedrifts loggplattform. Hvis du ønsker å bruke jsonify for loggene, kan du følge malen ovenfor for å installere logback.

Database

Som standard vil bildet ha en H2-database. Dette fungerer ikke for oss, og vi vil bruke Google Cloud SQL med Cloud SQL Proxy — dette vil bli nødvendig senere for interne oppgaver. Dette er et enkelt og pålitelig alternativ hvis du ikke har egne preferanser for databaseløsninger. AWS RDS tilbyr en lignende tjeneste.

Uansett hvilken database du velger, med mindre det er H2, må du sette de nødvendige miljøvariablene i platform/deploy.yaml. Dette ser omtrent slik ut:

-- plattform/deployment.yaml apiVersjon: apps/v1 type: Utplassering [...] spesifikasjon: mal: spesifikasjon: [...] containere: - navn: camunda-bpm miljø: - navn: DB_DRIVER verdi: org.postgresql.Driver - navn: DB_URL verdi: jdbc:postgresql://postgres-proxy.db:5432/process-engine - navn: DB_USERNAME verdiFra: secretKeyRef: navn: cambpm-db-credentials nøkkel: db_username - navn: DB_PASSWORD verdiFra: secretKeyRef: navn: cambpm-db-credentials nøkkel: db_password [...]

Merk: Du kan bruke Kustomize for distribusjon i forskjellige miljøer ved hjelp av overlay: eksempel.

Merk: bruk av valueFrom: secretKeyRef. Vennligst bruk denne Kubernetes-funksjonen selv under utvikling for å holde hemmelighetene dine trygge.

Det er sannsynlig at du allerede har et foretrukket Kubernetes hemmelighetsadministrasjonssystem. Hvis ikke, her er noen alternativer: kryptering med KMS fra din skytjenesteleverandør, og deretter innføringer i K8S som hemmeligheter via CD-pipelinen — MozillaSOPS — vil fungere veldig bra sammen med Kustomize-hemmeligheter. Det finnes også andre verktøy, som dotGPG — disse utfører lignende funksjoner: HashiCorp Vault, Kustomize Secret Value Plugins.

Ingress

Med mindre du velger å bruke lokal portviderekobling, trenger du en konfigurert Ingress Controller. Hvis du ikke bruker ingress-nginx (Helm-diagram) så vet du sannsynligvis allerede at du må sette nødvendige annotasjoner i ingress-patch.yaml.tmpl eller platform/ingress.yaml. Hvis du bruker ingress-nginx og ser nginx ingress-klasse med en lastbalanserer som peker mot den med ekstern DNS eller wildcard DNS-oppsett, er alt klart. Ellers, konfigurer Ingress Controller og DNS, eller hopp over disse trinnene og la direkte tilkobling til pod-en stå.

TLS

Hvis du bruker cert-manager eller kube-lego og letsencrypt — sertifikatene for den nye inngangen vil bli hentet automatisk. Ellers, åpne ingress-patch.yaml.tmpl og tilpass det etter dine behov.

Kjøring!

Hvis du har fulgt alt som er skrevet ovenfor, bør kommandoen make skaffold HOSTNAME= starte en tilgjengelig instans på /camunda

Hvis du ikke har eksponert inngangen via offentlig URL, kan du videresende den fra localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 En funksjon har blitt localhost:8080/camunda

Vent noen minutter til tomcat er helt klar. Cert-manager trenger litt tid for å verifisere domenenavnet. Etter dette kan du følge med på loggene med tilgjengelige verktøy — for eksempel et verktøy som kubetail, eller bare med kubectl:

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

Neste steg

Autorisering

Dette er mer knyttet til konfigurasjon av Camunda BPM enn Kubernetes, men det er viktig å merke seg at autentisering i REST API er deaktivert som standard. Du kan aktivere grunnleggende autentisering eller bruke en annen metode, for eksempel JWT. Du kan bruke configmaps og volumer for å laste opp xml, eller xmlstarlet (se ovenfor) for å redigere eksisterende filer i bildet, samt enten bruke wget, eller laste dem opp med en init-container og et delt volum.

Sesjonsadministrasjon

Som mange andre applikasjoner håndterer Camunda BPM sesjoner i JVM, så hvis du ønsker å kjøre flere replikater, kan du aktivere sticky sessions (for eksempel, for ingress-nginx), som vil eksistere så lenge replikaen ikke forsvinner, eller angi Max-Age-attributtet for informasjonskapsler. Som et mer pålitelig alternativ kan du distribuere Session Manager i Tomcat. Lars har et eget innlegg om dette emnet, men noe 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 '/^/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

Merk: du kan bruke xmlstarlet i stedet for sed

Vi brukte twemproxy før Google Cloud Memorystore, med memcached-session-manager (støtter Redis) for å få det til å fungere.

Skalering

Når du har fått kontroll på sesjoner, kan den første (og ofte den siste) begrensningen for skalering av Camunda BPM bli tilkoblingen til databasen. Delvis konfigurasjon er allerede tilgjengeligut av boksen. La oss også deaktivere initialSize i settings.xml-filen. Legg til HorizontalPodAutoscaler (HPA) og du kan enkelt automatisk skalere antallet pods.

Forespørsel og begrensninger

I platform/deployment.yaml du vil se at vi har hardkodet ressursfeltet. Dette fungerer godt med HPA, men kan kreve ekstra konfigurasjon. Et kustomize-patch vil være passende. Se på ingress-patch.yaml.tmpl og ./kustomization.yaml.tmpl

Utdata

Vi har nå installert Camunda BPM på Kubernetes med Prometheus-metrikker, logger, H2-database, TLS og Ingress. Vi har lagt til jar-filer og konfigurasjonsfiler, ved å bruke ConfigMaps og Dockerfile. Vi har diskutert datadeling med volumer og direkte inn i miljøvariabler fra hemmeligheter. I tillegg har vi gitt en oversikt over konfigurasjonen av Camunda for flere replikaer og autentisert API.

Lenker

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