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å og ikke starte din første klynge?
Forfattere
- (Alastair Firth) - Senior Site Reliability Engineer på Camunda Cloud-teamet;
- (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å .
Hvorfor bruge Kubernetes
Kubernetes er blevet de facto-standarden for at køre moderne applikationer på Linux. Ved at bruge systemkald i stedet for hardwareemulering og kernens evne til at styre hukommelse og opgaveskift, holdes opstartstid og opstartstid på et minimum. Den største fordel kan dog komme fra den standard-API, som Kubernetes leverer til at konfigurere den infrastruktur, der kræves af alle applikationer: lagring, netværk og overvågning. Det fyldte 2020 år i juni 6 og er måske det næststørste open source-projekt (efter Linux). Det har for nylig aktivt stabiliseret sin funktionalitet efter hurtig iteration i løbet af de sidste par år, da det bliver afgørende for produktionsarbejdsbelastninger rundt om i 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 (), 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 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
- - 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 .
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 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
## 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 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 . Vi tilføjer tomcat som 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 в 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, и 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 at montere individuelle filer. For at opdatere xml-filer, overvej at bruge 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 .
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: .
Bemærk: brug valueFrom: secretKeyRef. Brug venligst 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 − - vil fungere meget godt i kombination med Kustomize-hemmeligheder. Der er andre værktøjer, såsom dotGPG, der udfører lignende funktioner: , .
Ingress
Medmindre du vælger at bruge lokal portvideresendelse, skal du bruge en konfigureret Ingress Controller. Hvis du ikke bruger () 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 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 eller brug en anden metode som f.eks . 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 (), 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 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 '/^</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
Bemærk: du kan bruge xmlstarlet i stedet for sed
Vi brugte foran Google Cloud Memorystore, med (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 "" Lad os også deaktivere intialSize i filen settings.xml. Tilføje 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
05.08.2020/XNUMX/XNUMX, oversættelse Alastair Firth, Lars Lange
Kilde: www.habr.com