🥇Lansering av Camunda BPM i Kubernetes

Använder du Kubernetes? Är du redo att flytta dina Camunda BPM-instanser från virtuella maskiner, eller kanske bara testa att köra dem på Kubernetes? Låt oss titta på några vanliga konfigurationer och delar som kan anpassas till dina specifika behov.

Det förutsätts att du redan har använt Kubernetes tidigare. Om inte, varför inte kolla in en guide och sätta igång med din första kluster?

Författare

Alastair Firth är site reliability engineer i Camunda Cloud-teamet;
Lars Lange är DevOps-ingenjör på Camunda.

Kort sagt:

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

Sannolikt funkade det inte eftersom du inte har skaffat skaffold och kustomize. Så läs vidare!

Vad är Camunda BPM

Camunda BPM är en öppen källkodsplattform för affärsprocesshantering och automatisering av beslutsfattande, som förenar affärsanvändare och programvaruutvecklare. Den är perfekt för att koordinera och förena människor, (mikro) tjänster eller till och med bottar! Läs mer om olika användningsfall på länken.

Varför använda Kubernetes

Kubernetes har blivit de facto-standarden för att köra moderna applikationer i Linux. Genom att använda systemanrop istället för hårdvaruemulering och möjligheterna i kärnan att hantera minne och processväxling minimeras både uppstartstid och drifttid. Det största fördelen är dock det standardiserade API som Kubernetes tillhandahåller för att konfigurera den infrastruktur som alla applikationer behöver: lagring, nätverk och övervakning. I juni 2020 firade det 6 år och det är förmodligen det näst största projektet med öppen källkod (efter Linux). På senare tid har det stabiliserat sin funktionalitet efter snabba iterationer under de senaste åren, då detta blir kritiskt för produktionsbelastningar världen över.

Camunda BPM-motorn kan enkelt kopplas till andra applikationer som körs i samma kluster, och Kubernetes ger utmärkt skalbarhet, vilket möjliggör för att öka kostnaderna för infrastrukturen endast när det verkligen behövs (och enkelt minska dem vid behov).

Kvaliteten på övervakningen förbättras också av verktyg som Prometheus, Grafana, Loki, Fluentd och Elasticsearch, som möjliggör centraliserad visning av alla arbetsbelastningar i klustret. Idag kommer vi att titta på hur man implementerar en Prometheus-exportör i en Java-virtuell maskin (JVM).

Målsättningar

Låt oss titta på några områden där vi kan konfigurera Docker-bilden för Camunda BPM (github), så att den fungerar bra med Kubernetes.

Loggar och metrik;
Databasanslutningar;
Autentisering;
Sessionhantering.

Vi kommer att utforska flera sätt att uppnå dessa mål och visa hela processen visuellt.

Anmärkning: Använder du Enterprise-versionen? Titta på här och uppdatera länkarna till bilder vid behov.

Utveckling av arbetsflöde

I denna demonstration kommer vi att använda Skaffold för att bygga Docker-bilder med hjälp av Google Cloud Build. Det har bra stöd för olika verktyg (såsom Kustomize och Helm), CI och byggverktyg samt infrastruktursleverantörer. Filen skaffold.yaml.tmpl innehåller inställningar för Google Cloud Build och GKE, vilket innebär ett mycket enkelt sätt att köra industriell infrastruktur.

make skaffold laddar Dockerfile-kontexten till Cloud Build, skapar en bild och sparar den i GCR, och tillämpar sedan manifesterna på ditt kluster. Det är vad make skaffoldgör, men Skaffold har många andra funktioner.

För yaml-mallar i Kubernetes använder vi kustomize för att hantera yaml-overlays utan att behöva grena hela manifestet, vilket gör att du kan använda git pull --rebase för ytterligare förbättringar. Det nu i kubectl och fungerar ganska bra för sådana saker.

Vi använder också envsubst för att fylla i värdnamnet och GCP-projektets ID i filerna * .yaml.tmpl. Du kan se hur det fungerar i makefile eller bara fortsätta vidare.

Nödvändiga förutsättningar

Arbetskluster Kubernetes
Kustomize
Skaffold — för att skapa egna docker-bilder och enkelt distribuera i GKE
En kopia av denna kod
Envsubst

Arbetsflöde med hjälp av manifester

Om du inte vill använda kustomize eller skaffold kan du hänvisa till manifesten i generated-manifest.yaml och anpassa dem till det arbetsflöde du väljer.

Loggar och metrik

Prometheus har blivit standard för insamling av metrik i Kubernetes. Det tar en liknande plats som AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics och andra. Det har öppen källkod och ett kraftfullt frågespråk. Vi överlåter visualiseringen till Grafana – den levereras med ett stort antal färdiga instrumentpaneler. Dessa är kopplade till varandra och relativt enkla att installera. prometheus-operator.

Som standard använder Prometheus en uthämtningsmodell /metrics, och att lägga till sidecar-containrar för detta är något vanligt. Tyvärr registreras JMX-metrik bäst inuti JVM, så sidecar-containrar är inte lika effektiva. Låt oss ansluta jmx_exporter öppen källkod från Prometheus till JVM genom att lägga till den i containerns bild, vilket ger en väg /metrics på en annan port.

Lägg till Prometheus jmx_exporter i containern

-- images/camunda-bpm/Dockerfile FRÅN 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åväl, det var enkelt. Exportören kommer att övervaka tomcat och visa dess metrik i Prometheus-format på adressen :9404/metrics

Konfiguration av exportören

Den uppmärksamma läsaren kan fråga sig varifrån prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны härkommer. Vi kommer att lägga till tomcat som ConfigMap i Kubernetes, och sedan montera det som en volym.

Först lägger vi till exportörens konfigurationsfil i vår katalog platform/config/

plattform/config └── prometheus-jmx.yaml

Därefter lägger vi till ConfigMapGenerator på kustomization.yaml.tmpl:

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

Detta kommer att lägga till varje element files[] som en konfigurationspost i ConfigMap. ConfigMapGenerators är bra eftersom de hash-kodifierar konfigurationsdata och initierar en omstart av podden om den ändras. De minskar också volymen av konfigurationer i Deployment, eftersom du kan montera hela "mappen" av konfigurationsfiler i en och samma VolumeMount.

Slutligen behöver vi montera ConfigMap som en volym till podden:

-- plattform/deployment.yaml apiVersion: apps/v1 typ: Distribution [...] specifikation: mall: specifikation: [...] volymer: - name: config konfigurationsKarta: namn: konfiguration standardläge: 0744 containrar: - namn: camunda-bpm volymMontering: - monteringsväg: /etc/config/ namn: konfiguration [...]

Perfekt. Om Prometheus inte är inställt för att rensa helt kanske du behöver be den att rensa poddar. Användare av Prometheus Operator kan använda service-monitor.yaml för att komma igång. Granska Service-monitor.yaml, operator design och ServiceMonitorSpec innan du går vidare.

Spridningen av denna mall till andra användningsfall

Alla filer som vi lägger till i ConfigMapGenerator kommer att vara tillgängliga i den nya katalogen. /etc/config. Du kan utöka denna mall för att montera andra nödvändiga konfigurationsfiler. Du kan till och med montera ett nytt startskript. Du kan använda subPath för att montera enskilda filer. För att uppdatera xml-filer, överväg att använda xmlstarlet istället för sed. Det ingår redan i bilden.

Loggar

Bra nyheter! Applikationsloggar finns redan tillgängliga på stdout, till exempel med hjälp av kubectl logs. Fluentd (det är förinstallerat i GKE) vidarebefordrar dina loggar till Elasticsearch, Loki eller din företagsloggningsplattform. Om du vill använda jsonify för loggar kan du följa ovanstående mall för installation logback.

Databas

Som standard kommer bilden att ha en H2-databas. Det passar oss inte, och vi kommer att använda Google Cloud SQL med Cloud SQL Proxy — det behövs senare för att lösa interna uppgifter. Det är ett enkelt och tillförlitligt alternativ om du inte har egna preferenser för databasinställningar. AWS RDS erbjuder en liknande tjänst.

Oavsett vilken databas du väljer, så länge det inte är H2, måste du ställa in de relevanta miljövariablerna i platform/deploy.yaml. Det ser ungefär ut så här:

-- plattform/deployment.yaml apiVersion: apps/v1 typ: Distribution [...] specifikation: mall: specifikation: [...] containrar: - namn: camunda-bpm miljö: - namn: DB_DRIVER värde: org.postgresql.Driver - namn: DB_URL värde: jdbc:postgresql://postgres-proxy.db:5432/process-engine - namn: DB_USERNAME valueFrom: secretKeyRef: namn: cambpm-db-credentials nyckel: db_username - namn: DB_PASSWORD valueFrom: secretKeyRef: namn: cambpm-db-credentials nyckel: db_password [...]

Anmärkning: Du kan använda Kustomize för att distribuera i olika miljöer med hjälp av overlay: exempel.

Anmärkning: användning valueFrom: secretKeyRef. Vänligen använd denna Kubernetes-funktion även under utvecklingen för att hålla dina hemligheter säkra.

Det är mycket troligt att du redan har ett föredraget system för hantering av Kubernetes-hemligheter. Om inte, här är några alternativ: kryptera dem med KMS från din molnleverantör, och implementera dem i K8S som hemligheter genom en CD-pipeline — MozillaSOPS — fungerar mycket bra tillsammans med Kustomize-hemligheter. Det finns även andra verktyg, såsom dotGPG — de utför liknande funktioner: HashiCorp Vault, Kustomize Secret Value Plugins.

Ingress

Om du inte väljer att använda port forwarding, behöver du en konfigurerad Ingress Controller. Om du inte använder ingress-nginx (Helm-diagrammet) så vet du förmodligen redan att du måste ange nödvändiga anteckningar i ingress-patch.yaml.tmpl eller platform/ingress.yaml. Om du använder ingress-nginx och ser nginx ingress-klass med en lastbalanserare pekande på den och extern DNS eller en wildcard DNS-post, är allt redo. Annars, konfigurera Ingress Controller och DNS eller hoppa över dessa steg och behåll direktkontakten till podden.

TLS

Om du använder cert-manager eller kube-lego och letsencrypt — certifikaten för den nya ingången kommer att erhållas automatiskt. Annars, öppna ingress-patch.yaml.tmpl och konfigurera det efter dina behov.

Körning!

Om du har följt allt ovanstående, bör kommandot make skaffold HOSTNAME= starta en tillgänglig instans på /camunda

Om du inte har exponerat ingången via en offentlig URL, kan du omdirigera den med localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 till localhost:8080/camunda

Vänta några minuter medan tomcat fullt förbereds. Cert-manager kommer att ta lite tid för att verifiera domännamnet. Efter detta kan du följa loggarna med hjälp av tillgängliga verktyg — till exempel ett sådant verktyg som kubetail, eller bara med kubectl:

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

Följande steg

Behörighet

Detta handlar mer om att konfigurera Camunda BPM än Kubernetes, men det är viktigt att notera att autentisering i REST API är avstängt som standard. Du kan aktivera grundläggande autentisering eller använda en annan metod, till exempel JWT. Du kan använda configmaps och volymer för att ladda xml, eller xmlstarlet (se ovan) för att redigera befintliga filer i bilden, samt antingen använda wget, eller ladda dem med en init-container och en delad volym.

Sessionshantering

Precis som många andra applikationer hanterar Camunda BPM sessioner i JVM, så om du vill köra flera repliker kan du aktivera sticky sessions (till exempel för ingress-nginx), som kommer att finnas så länge repliken finns, eller ställa in Max-Age-attributet för cookies. Som en mer pålitlig lösning kan du distribuera Session Manager i Tomcat. Lars har en separat post om detta ämne, men något i stil med:

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

Anmärkning: du kan använda xmlstarlet istället för sed

Vi använde twemproxy innan Google Cloud Memorystore, med memcached-session-manager (stödjer Redis) för att köra det.

Skalning

Om du har redan hanterat sessionerna, kan den första (och ofta sista) begränsningen för att skala Camunda BPM vara databasanslutningen. Delvis konfiguration finns redan "ovanpå". Vi stänger också av initialSize i filen settings.xml. Lägg till HorizontalPodAutoscaler (HPA) och du kan enkelt automatiskt skala antalet pods.

Förfrågningar och begränsningar

I platform/deployment.yaml du kommer att se att vi har hårdkodat resursfältet. Detta fungerar bra med HPA, men kan behöva ytterligare konfiguration. En kustomize-patch är lämplig för detta ändamål. Se ingress-patch.yaml.tmpl och ./kustomization.yaml.tmpl

Utdata

Nu har vi installerat Camunda BPM på Kubernetes med Prometheus-metriker, loggar, H2-databas, TLS och Ingress. Vi har lagt till jar-filer och konfigurationsfiler med ConfigMaps och Dockerfile. Vi diskuterade databyte mellan volymer och direkt i miljövariabler från hemligheter. Dessutom gav vi en översikt över konfigurationen av Camunda för flera repliker och autentiserad API.

Länkar

github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes │ ├── generated-manifest.yaml <- manifest för användning utan kustomize ├── bilder │ └── camunda-bpm │ └── Dockerfile <- overlay docker image ├── ingress-patch.yaml.tmpl <- site-specifik ingress-konfiguration ├── kustomization.yaml.tmpl <- huvudkustomisering ├── Makefile <- make targets ├── namespace.yaml ├── plattform │ ├── konfiguration │ │ └── prometheus-jmx.yaml <- prometheus exporter konfigurationsfil │ ├── deployment.yaml <- huvuddistribution │ ├── ingress.yaml │ ├── kustomization.yaml <- "bas" kustomisering │ ├── service-monitor.yaml <- exempel på prometheus-operator konfiguration │ └── service.yaml └── skaffold.yaml.tmpl <- skaffold direktiv