Bruger du Kubernetes? Klar til at flytte dine Camunda BPM-instanser fra virtuelle maskiner, eller måske bare prøve at køre dem på Kubernetes? Lad os se på nogle almindelige konfigurationer og individuelle elementer, som kan tilpasses dine specifikke behov.
Det antages, at du allerede har brugt Kubernetes før. Hvis ikke, hvorfor ikke tage et kig på og starte dit første kluster?
Forfattere
- er Site Reliability Engineer i Camunda Cloud-teamet;
- 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
Nå, det fungerede sandsynligvis ikke, da du ikke har installeret skaffold og kustomize. Så læs videre!
Hvad er Camunda BPM
Camunda BPM er en open source-platform til styring af forretningsprocesser og automatisering af beslutningstagning, der samler forretningsbrugere og softwareudviklere. Den er ideel til at koordinere og forene mennesker, (mikro)services eller endda bots! Læs mere om forskellige anvendelsesmuligheder på .
Hvorfor bruge Kubernetes
Kubernetes er blevet de facto-standarden for kørsel af moderne applikationer på Linux. Ved at bruge systemopkald i stedet for hardwareemulering og med kernen, der styrer hukommelse og opgavevending, minimeres opstartstider og starttider. Men det største fordele kommer fra det standard API, som Kubernetes tilbyder til konfiguration af den infrastruktur, alle applikationer har brug for: lager, netværk og overvågning. I juni 2020 fyldte det 6 år, og det er måske det næststørste open source-projekt (efter Linux). Det har for nylig aktivt stabiliseret sin funktionalitet efter hurtige iterationer i de seneste par år, da dette er blevet kritisk vigtigt for produktionsbelastninger over hele verden.
Camunda BPM Engine kan nemt tilslutte sig andre applikationer, der kører i det samme kluster, og Kubernetes tilbyder fremragende skalerbarhed, hvilket gør det muligt at øge omkostningerne til infrastruktur kun når det er nødvendigt (og nemt reducere dem, når det er nødvendigt).
Kvaliteten af overvågningen forbedres også betydeligt med værktøjer som Prometheus, Grafana, Loki, Fluentd og Elasticsearch, som gør det muligt at centralt overvåge alle arbejdsbelastninger i klyngen. I dag vil vi se på, hvordan man implementerer en Prometheus-exportør i en Java Virtual Machine (JVM).
Mål
Lad os se på nogle områder, hvor vi kan konfigurere Docker-billedet af Camunda BPM (), så det fungerer godt sammen med Kubernetes.
- Logs og metrics;
- Databaseforbindelser;
- Godkendelse;
- Session management.
Vi vil gennemgå nogle metoder til at realisere disse mål og tydeligt vise hele processen.
Bemærk: Bruger du en Enterprise-version? Tjek og opdater links til billeder om nødvendigt.
Udvikling af arbejdsgang
I denne demonstration vil vi bruge Skaffold til at bygge Docker-billeder med Google Cloud Build. Det har god støtte til forskellige værktøjer (som Kustomize og Helm), CI og build-værktøjer samt infrastrukturleverandører. Filen skaffold.yaml.tmpl inkluderer indstillinger for Google Cloud Build og GKE, hvilket giver en meget enkel måde at køre industriklassens infrastruktur på.
make skaffold vil uploade Dockerfile-kontexten til Cloud Build, oprette billedet og gemme det i GCR, og derefter anvende manifesterne til din klynge. Det er, hvad make skaffold, men Skaffold har mange andre muligheder.
Til yaml-skabeloner i Kubernetes bruger vi kustomize til at håndtere overlays af yaml uden at opdele hele manifestet, hvilket gør det muligt for dig at bruge git pull --rebase til yderligere forbedringer. Den er nu i kubectl og fungerer fint til sådanne ting.
Vi bruger også envsubst til at udfylde hostname og GCP-projekt-id i filer med * .yaml.tmpl. Du kan se, hvordan det fungerer i makefile eller bare fortsætte videre.
Krav
- Arbejdsklynge
- — til at oprette dine egne docker-billeder og nemt deploye i GKE
- En kopi af denne kode
- Envsubst
Arbejdsgang ved hjælp af manifester
Hvis du ikke vil bruge kustomize eller skaffold, kan du henvise til manifestet i generated-manifest.yaml og tilpasse dem til din ønskede arbejdsgang.
Logs og metrics
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 har åben kildekode og et kraftfuldt forespørgselssprog. Visualiseringen overlader vi til Grafana — det leveres med et stort antal dashboards, der er tilgængelige fra starten. De er sammenknyttede og relativt nemme at installere med .
Som standard bruger Prometheus en udtrækningsmodel /metrics, og at tilføje sidecar-containere til dette er almindeligt. Desværre registreres JMX-metrics bedst inde i JVM, så sidecar-containere er ikke så effektive. Lad os tilslutte den åbne kildekode fra Prometheus til JVM ved at tilføje den til containerens billede, der giver en sti /metrics på en anden port.
Tilføj Prometheus jmx_exporter til containeren
-- 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å, det var let. Eksportøren vil overvåge tomcat og vise dens metrics i Prometheus-format på adressen :9404/metrics
Konfiguration af eksportøren
Den opmærksomme læser måtte spørge, hvor prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны kom fra. Vi vil tilføje tomcat som i Kubernetes, og derefter montere det som et volumen.
Først tilføjer vi eksportørens konfigurationsfil til vores directory platform/config/
platform/config
└── prometheus-jmx.yaml
Derefter tilføjer vi i kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
filer:
- config/prometheus-jmx.yaml
Dette vil tilføje hvert element files[] som et element i ConfigMap-konfigurationen. ConfigMapGenerators er gode, fordi de hash'er dataene i konfigurationen og udløser en genstart af pod'en, hvis den ændres. De reducerer også konfigurationsstørrelsen i Deployment, da du kan montere hele "mappen" med konfigurationsfiler i én VolumeMount.
Til sidst skal vi montere ConfigMap som et volumen til pod'en:
-- 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
[...]
Fantastisk. Hvis Prometheus ikke er indstillet til at rydde fuldt ud, skal du måske bede den om at rydde pod'erne. Brugere af Prometheus Operator kan bruge service-monitor.yaml for at komme i gang. Undersøg Service-monitor.yaml, og før du går i gang.
Udbredelsen af denne skabelon til andre anvendelsesmuligheder
Alle filer, som 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 nødvendige konfigurationsfiler. Du kan endda montere et nyt opstartsskript. Du kan bruge til at montere individuelle filer. For at opdatere XML-filer, overvej at bruge i stedet for sed. Det er allerede inkluderet i billedet.
Logfiler
Gode nyheder! Applikationslogfiler er allerede tilgængelige på stdout, for eksempel ved hjælp af kombineres. Fluentd (det er forudinstalleret i GKE) vil omdirigere dine logfiler til Elasticsearch, Loki, eller til din virksomheds logplatform. Hvis du vil bruge jsonify til logfiler, kan du følge den skabelon, der er nævnt ovenfor, for at installere .
Database
Som standard vil billedet have en H2-database. Det er ikke passende for os, og vi vil bruge Google Cloud SQL med Cloud SQL Proxy - det vil være nødvendigt senere for at løse interne opgaver. Dette er en enkel og pålidelig løsning, hvis du ikke har dine egne præferencer til databaseopsætning. AWS RDS tilbyder en lignende service.
Uanset hvilken database du vælger, hvis det ikke er H2, skal du konfigurere de relevante miljøvariabler i platform/deploy.yaml. Det ser omtrent sådan ud:
-- platform/deployment.yaml
apiVersion: apps/v1
kind: Deployment
[...]
spec:
template:
spec:
[...]
containers:
- name: camunda-bpm
miljø:
- navn: DB_DRIVER
værdi: org.postgresql.Driver
- navn: DB_URL
værdi: jdbc:postgresql://postgres-proxy.db:5432/process-engine
- navn: DB_USERNAME
værdiFra:
hemmelighedsNøgleReference:
navn: cambpm-db-credentials
nøgle: db_username
- navn: DB_PASSWORD
værdiFra:
hemmelighedsNøgleReference:
navn: cambpm-db-credentials
nøgle: db_password
[...]
Bemærk: Du kan bruge Kustomize til at implementere i forskellige miljøer ved hjælp af overlay: .
Bemærk: brug af valueFrom: secretKeyRef. Venligst brug selv under udvikling for at holde dine hemmeligheder sikre.
Det er meget muligt, at du allerede har et foretrukket Kubernetes hemmelighedsstyringssystem. Hvis ikke, så her er nogle muligheder: kryptering ved hjælp af KMS fra din cloud-udbyder, og så implementering i K8S som hemmeligheder gennem en CD-pipeline - vil fungere rigtig godt sammen med Kustomize hemmeligheder. Der er også andre værktøjer som dotGPG - de udfører lignende funktioner: , .
Ingress
Hvis du ikke vælger at bruge port forwarding, skal du have en konfigureret Ingress Controller. Hvis du ikke bruger () så ved du sandsynligvis allerede, at du skal sætte de nødvendige annoteringer i ingress-patch.yaml.tmpl eller platform/ingress.yaml. Hvis du bruger ingress-nginx og ser nginx ingress-klasse med en load balancer, der peger på det og en ekstern DNS eller wildcard DNS-post, så er alting klar. Ellers skal du konfigurere Ingress Controller og DNS eller springe disse trin over og lade forbindelsen gå direkte til pod'en.
TLS
Hvis du bruger eller kube-lego og letsencrypt — certificater til den nye indgang vil blive opnået automatisk. Ellers skal du åbne ingress-patch.yaml.tmpl og konfigurere det til dine behov.
Kør!
Hvis du har fulgt alt ovenstående, så skulle kommandoen make skaffold HOSTNAME= starte en tilgængelig instans på /camunda
Hvis du ikke har eksponeret indgangen via en offentlig URL, så kan du videresende det fra localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 og få en fungerende kommando. localhost:8080/camunda
Vent et par minutter, indtil tomcat er helt klar. Cert-manager vil tage lidt tid til at verificere domænenavnet. Derefter kan du overvåge logfilerne med de tilgængelige værktøjer — for eksempel et værktøj som kubetail, eller blot med kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Næste skridt
Godkendelse
Dette handler mere om konfiguration af Camunda BPM end Kubernetes, men det er vigtigt at bemærke, at autentificering er deaktiveret som standard i REST API. Du kan eller bruge en anden metode, såsom . Du kan bruge configmaps og volumer til at indlæse xml, eller xmlstarlet (se ovenfor) til at redigere eksisterende filer i billedet, samt enten bruge wget eller indlæse dem via en init-container og et delt volumen.
Session Management
Ligesom mange andre applikationer behandler Camunda BPM sessioner i JVM, så hvis du ønsker at køre flere replikaer, kan du aktivere sticky sessions (), som vil eksistere, indtil replikaen forsvinder, eller angive Max-Age attributten for cookies. Som en mere pålidelig løsning kan du implementere Session Manager i Tomcat. Lars har om dette emne, men noget i retning af:
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
Bemærk: du kan bruge xmlstarlet i stedet for sed
Vi har brugt før Google Cloud Memorystore, med (understøtter Redis) til at køre den.
Skalering
Hvis du allerede har styr på sessioner, kan den første (og ofte sidste) begrænsning for skalering af Camunda BPM være forbindelsen til databasen. Delvis konfiguration er allerede tilgængelig "". Vi slukker også for initialSize i filen settings.xml. Tilføj og du kan nemt automatisere skaleringen af antallet af pods.
Anmodninger og begrænsninger
I platform/deployment.yaml vil du se, at vi har hardkodet ressourcens felt. Det fungerer godt med HPA, men kan kræve yderligere konfiguration. En kustomization patch vil være passende. Se ingress-patch.yaml.tmpl og ./kustomization.yaml.tmpl
Output
Nu har vi installeret Camunda BPM på Kubernetes med Prometheus-metrics, logs, H2-database, TLS og Ingress. Vi har tilføjet jar-filer og konfigurationsfiler ved hjælp af ConfigMaps og Dockerfile. Vi har diskuteret dataudveksling med volumes og direkte i miljøvariabler fra secrets. Derudover har vi givet et overblik over konfigurationen af Camunda for flere replikaer og et godkendt API.
Links
github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes
│
├── generated-manifest.yaml <- manifest til brug uden kustomize
├── billeder
│ └── camunda-bpm
│ └── Dockerfile <- overlay docker image
├── ingress-patch.yaml.tmpl <- site-specifik ingress konfiguration
├── kustomization.yaml.tmpl <- hoved Kustomization
├── Makefile <- make targets
├── namespace.yaml
├── platform
│ ├── config
│ │ └── prometheus-jmx.yaml <- prometheus eksportør konfigurationsfil
│ ├── deployment.yaml <- hoved deployment
│ ├── ingress.yaml
│ ├── kustomization.yaml <- "base" kustomization
│ ├── service-monitor.yaml <- eksempel prometheus-operator konfiguration
│ └── service.yaml
└── skaffold.yaml.tmpl <- skaffold direktiver
05.08.2020, oversættelse Alastair Firth, Lars Lange
Kilde: habr.com
