Använder du Kubernetes? Är du redo att flytta dina Camunda BPM-instanser från virtuella maskiner, eller kanske bara prova att köra dem på Kubernetes? Låt oss titta på några vanliga konfigurationer och enskilda artiklar som kan skräddarsys efter dina specifika behov.
Det förutsätter att du har använt Kubernetes tidigare. Om inte, varför inte ta en titt på och inte starta ditt första kluster?
Författare
- (Alastair Firth) - Senior Site Reliability Engineer på Camunda Cloud-teamet;
- (Lars Lange) - DevOps-ingenjör på Camunda.
Kort sagt, då:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Okej, det fungerade förmodligen inte eftersom du inte har skaffold och kustomize installerat. Nåväl, läs vidare!
Vad är Camunda BPM
Camunda BPM är en öppen källkodsplattform för affärsprocesshantering och beslutsautomatisering som kopplar samman företagsanvändare och mjukvaruutvecklare. Den är idealisk för att koordinera och koppla samman människor, (mikro)tjänster eller till och med bots! Du kan läsa mer om de olika användningsfallen på .
Varför använda Kubernetes
Kubernetes har blivit de facto-standarden för att köra moderna applikationer på Linux. Genom att använda systemanrop istället för hårdvaruemulering och kärnans förmåga att hantera minnes- och uppgiftsbyte, hålls starttid och starttid på ett minimum. Den största fördelen kan dock komma från standard-API som Kubernetes tillhandahåller för att konfigurera den infrastruktur som krävs av alla applikationer: lagring, nätverk och övervakning. Det fyllde 2020 år i juni 6 och är kanske det näst största open source-projektet (efter Linux). Det har nyligen aktivt stabiliserat sin funktionalitet efter snabb iteration under de senaste åren eftersom det blir avgörande för produktionsarbetsbelastningar runt om i världen.
Camunda BPM Engine kan enkelt ansluta till andra applikationer som körs på samma kluster, och Kubernetes ger utmärkt skalbarhet, vilket gör att du kan öka infrastrukturkostnaderna endast när det verkligen behövs (och enkelt minska dem vid behov).
Kvaliteten på övervakningen förbättras också avsevärt med verktyg som Prometheus, Grafana, Loki, Fluentd och Elasticsearch, vilket gör att du centralt kan se alla arbetsbelastningar i ett kluster. Idag ska vi titta på hur man implementerar Prometheus-exportören i Java Virtual Machine (JVM).
mål
Låt oss titta på några områden där vi kan anpassa Camunda BPM Docker-bilden () så att den interagerar bra med Kubernetes.
- Loggar och mätvärden;
- Databasanslutningar;
- Autentisering;
- Sessionshantering.
Vi kommer att titta på flera sätt att uppnå dessa mål och tydligt visa hela processen.
Notera: Använder du Enterprise-versionen? Se och uppdatera bildlänkar vid behov.
Arbetsflödesutveckling
I den här demon kommer vi att använda Skaffold för att bygga Docker-bilder med Google Cloud Build. Den har bra stöd för olika verktyg (som Kustomize och Helm), CI och byggverktyg och infrastrukturleverantörer. Fil skaffold.yaml.tmpl innehåller inställningar för Google Cloud Build och GKE, vilket ger ett mycket enkelt sätt att köra produktionsklassad infrastruktur.
make skaffold kommer att ladda Dockerfile-kontexten till Cloud Build, bygga bilden och lagra den i GCR och sedan tillämpa manifesten på ditt kluster. Detta är vad den gör make skaffold, men Skaffold har många andra funktioner.
För yaml-mallar i Kubernetes använder vi kustomize för att hantera yaml-överlägg utan att splittra hela manifestet, så att du kan använda git pull --rebase för ytterligare förbättringar. Nu finns det i kubectl och det 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 *.yaml.tmpl-filerna. Du kan se hur det fungerar i makefile eller bara fortsätta vidare.
förutsättningar
- Arbetskluster
- - för att skapa dina egna docker-avbildningar och enkel distribution till GKE
- Kopia av denna kod
- Envsubst
Arbetsflöde med hjälp av manifest
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 mätvärden
Prometheus har blivit standarden för att samla in mätvärden i Kubernetes. Den upptar samma nisch som AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics och andra. Det är öppen källkod och har ett kraftfullt frågespråk. Vi kommer att anförtro visualiseringen till Grafana - den kommer med ett stort antal instrumentpaneler tillgängliga direkt ur lådan. De är kopplade till varandra och är relativt lätta att installera med .
Som standard använder Prometheus extraktionsmodellen <service>/metrics, och att lägga till sidovagnsbehållare för detta är vanligt. Tyvärr loggas JMX-mått bäst inom JVM, så sidovagnscontainrar är inte lika effektiva. Låt oss ansluta öppen källkod från Prometheus till JVM genom att lägga till den i behållarbilden som kommer att tillhandahålla sökvägen /metrics på en annan hamn.
Lägg till Prometheus jmx_exporter till behållaren
-- 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
Det var lätt. Exportören kommer att övervaka Tomcat och visa dess mätvärden i Prometheus-format på <svc>:9404/metrics
Exportörinställningar
Den uppmärksamme läsaren kan undra var den kom ifrån prometheus-jmx.yaml? Det finns många olika saker som kan köras i JVM, och tomcat är bara en av dem, så exportören behöver lite extra konfiguration. Standardkonfigurationer för tomcat, wildfly, kafka och så vidare finns tillgängliga . Vi kommer att lägga till Tomcat som i Kubernetes och sedan montera den som en volym.
Först lägger vi till exportörens konfigurationsfil till vår plattform/config/-katalog
platform/config
└── prometheus-jmx.yaml
Sedan lägger vi till в 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 ett ConfigMap-konfigurationselement. ConfigMapGenerators är bra eftersom de hash konfigurationsdata och tvingar en pod omstart om den ändras. De minskar också mängden konfiguration i Deployment eftersom du kan montera en hel "mapp" med konfigurationsfiler i ett VolumeMount.
Slutligen måste vi montera ConfigMap som en volym till podden:
-- 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
[...]
Underbar. Om Prometheus inte är konfigurerad för att göra en fullständig rensning, kan du behöva be den att städa upp baljorna. Prometheus Operator-användare kan använda service-monitor.yaml för att starta. Utforska Service-monitor.yaml, и innan du börjar.
Utvidga detta mönster till andra användningsfall
Alla filer vi lägger till i ConfigMapGenerator kommer att vara tillgängliga i den nya katalogen /etc/config. Du kan utöka den här mallen för att montera alla andra konfigurationsfiler du behöver. Du kan till och med montera ett nytt startskript. Du kan använda för att montera enskilda filer. För att uppdatera xml-filer, överväg att använda istället för sed. Den finns redan med i bilden.
Tidningar
Goda nyheter! Applikationsloggar finns redan på stdout, till exempel med kubectl logs. Fluentd (installerat som standard i GKE) kommer att vidarebefordra dina loggar till Elasticsearch, Loki eller din företagsloggningsplattform. Om du vill använda jsonify för loggar kan du följa mallen ovan för att installera .
databas
Som standard kommer bilden att ha en H2-databas. Detta är inte lämpligt för oss, och vi kommer att använda Google Cloud SQL med Cloud SQL Proxy - detta kommer att behövas senare för att lösa interna problem. Detta är ett enkelt och pålitligt alternativ om du inte har dina egna preferenser för att ställa in databasen. AWS RDS tillhandahåller en liknande tjänst.
Oavsett vilken databas du väljer, om det inte är H2, måste du ställa in lämpliga miljövariabler i platform/deploy.yaml. Det ser ut ungefär så här:
-- 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
[...]
Notera: Du kan använda Kustomize för att distribuera till olika miljöer med hjälp av en överlagring: .
Notera: användning valueFrom: secretKeyRef. Snälla använd även under utveckling för att hålla dina hemligheter säkra.
Det är troligt att du redan har ett föredraget system för att hantera Kubernetes-hemligheter. Om inte, här är några alternativ: Kryptera dem med din molnleverantörs KMS och sedan injicera dem i K8S som hemligheter via CD-pipeline − - kommer att fungera mycket bra i kombination med Kustomize secrets. Det finns andra verktyg, som dotGPG, som utför liknande funktioner: , .
Ingress
Om du inte väljer att använda lokal portvidarebefordran behöver du en konfigurerad Ingress Controller. Om du inte använder () då vet du troligen redan att du behöver installera de nödvändiga anteckningarna i ingress-patch.yaml.tmpl eller platform/ingress.yaml. Om du använder ingress-nginx och ser en nginx ingress-klass med en lastbalanserare som pekar på den och en extern DNS- eller jokertecken-DNS-post, är du bra att gå. Annars konfigurerar du Ingress Controller och DNS, eller hoppar över dessa steg och behåller den direkta anslutningen till podden.
TLS
Om du använder eller kube-lego och letsencrypt - certifikat för den nya inloggningen erhålls automatiskt. Annars, öppna ingress-patch.yaml.tmpl och anpassa den efter dina behov.
Lansera!
Om du följde allt som skrevs ovan, då kommandot make skaffold HOSTNAME=<you.example.com> bör starta en tillgänglig instans i <hostname>/camunda
Om du inte har ställt in din inloggning till en offentlig URL kan du omdirigera den med localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 på localhost:8080/camunda
Vänta några minuter tills tomcat är helt redo. Cert-manager kommer att ta lite tid att verifiera domännamnet. Du kan sedan övervaka loggarna med hjälp av tillgängliga verktyg som ett verktyg som kubetail, eller helt enkelt med kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Nästa steg
Bemyndigande
Detta är mer relevant för att konfigurera Camunda BPM än Kubernetes, men det är viktigt att notera att som standard är autentisering inaktiverad i REST API. Du kan eller använd en annan metod som . Du kan använda configmaps och volymer för att ladda xml, eller xmlstarlet (se ovan) för att redigera befintliga filer i bilden, och antingen använda wget eller ladda dem med en init-behållare och en delad volym.
Sessionshantering
Som många andra applikationer hanterar Camunda BPM sessioner i JVM, så om du vill köra flera repliker kan du aktivera sticky sessioner (), som kommer att finnas tills repliken försvinner, eller ställ in attributet Max-Age för cookies. För en mer robust lösning kan du distribuera Session Manager i Tomcat. Lars har 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 '/^</Context>/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
Notera: du kan använda xmlstarlet istället för sed
Vi använde framför Google Cloud Memorystore, med (stöder Redis) för att köra den.
Skalning
Om du redan förstår sessioner kan den första (och ofta sista) begränsningen för att skala Camunda BPM vara anslutningen till databasen. Delvis anpassning är redan tillgänglig "" Låt oss också inaktivera intialSize i filen settings.xml. Lägg till och du kan enkelt automatiskt skala antalet poddar.
Förfrågningar och begränsningar
В platform/deployment.yaml Du kommer att se att vi har hårdkodat resursfältet. Detta fungerar bra med HPA, men kan kräva ytterligare konfiguration. Kustomize-plåstret är lämpligt för detta. Centimeter. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
Utgång
Så vi installerade Camunda BPM på Kubernetes med Prometheus-mått, loggar, H2-databas, TLS och Ingress. Vi lade till jar-filer och konfigurationsfiler med ConfigMaps och Dockerfile. Vi pratade om att utbyta data till volymer och direkt till miljövariabler från hemligheter. Dessutom gav vi en översikt över hur du konfigurerar Camunda för flera repliker och ett autentiserat API.
referenser
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
05.08.2020/XNUMX/XNUMX, översättning Alastair Firth, Lars Lange
Källa: will.com