Bruker du Kubernetes? Klar til å flytte dine Camunda BPM-forekomster ut av virtuelle maskiner, eller kanskje bare prøve å kjøre dem på Kubernetes? La oss se på noen vanlige konfigurasjoner og individuelle elementer som kan skreddersys til dine spesifikke behov.
Det forutsetter at du har brukt Kubernetes før. Hvis ikke, hvorfor ikke ta en titt 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 oppsummert:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Ok, det fungerte sannsynligvis ikke fordi du ikke har installert skaffold og kustomize. Vel, les videre!
Hva er Camunda BPM
Camunda BPM er en åpen kildekodeplattform for forretningsprosessadministrasjon og beslutningsautomatisering som kobler sammen forretningsbrukere og programvareutviklere. Den er ideell for å koordinere og koble sammen mennesker, (mikro)tjenester eller til og med roboter! Du kan lese mer om de ulike brukstilfellene på .
Hvorfor bruke Kubernetes
Kubernetes har blitt de facto-standarden for å kjøre moderne applikasjoner på Linux. Ved å bruke systemanrop i stedet for maskinvareemulering og kjernens evne til å administrere minne og oppgavebytte, holdes oppstartstid og oppstartstid på et minimum. Den største fordelen kan imidlertid komme fra standard API som Kubernetes gir for å konfigurere infrastrukturen som kreves av alle applikasjoner: lagring, nettverk og overvåking. Det fylte 2020 år i juni 6 og er kanskje det nest største åpen kildekodeprosjektet (etter Linux). Den har nylig aktivt stabilisert funksjonaliteten etter rask iterasjon de siste årene, ettersom den blir kritisk for produksjonsarbeidsmengder rundt om i verden.
Camunda BPM Engine kan enkelt koble til andre applikasjoner som kjører på samme klynge, og Kubernetes gir utmerket skalerbarhet, slik at du kun kan øke infrastrukturkostnadene når det virkelig er nødvendig (og enkelt redusere dem etter behov).
Kvaliteten på overvåking er også kraftig forbedret med verktøy som Prometheus, Grafana, Loki, Fluentd og Elasticsearch, slik at du sentralt kan se alle arbeidsbelastninger i en klynge. I dag skal vi se på hvordan du implementerer Prometheus-eksportøren i Java Virtual Machine (JVM).
mål
La oss se på noen få områder der vi kan tilpasse Camunda BPM Docker-bildet () slik at den samhandler godt med Kubernetes.
- Logger og beregninger;
- Database tilkoblinger;
- Autentisering;
- Sesjonsledelse.
Vi skal se på flere måter å nå disse målene på og tydelig vise hele prosessen.
Note: Bruker du Enterprise-versjonen? Se og oppdater bildelenker etter behov.
Arbeidsflytutvikling
I denne demoen vil vi bruke Skaffold til å bygge Docker-bilder ved hjelp av Google Cloud Build. Den har god støtte for ulike verktøy (som Kustomize og Helm), CI og byggeverktøy og infrastrukturleverandører. Fil skaffold.yaml.tmpl inkluderer innstillinger for Google Cloud Build og GKE, som gir en veldig enkel måte å kjøre infrastruktur i produksjonsgrad.
make skaffold vil laste Dockerfile-konteksten inn i Cloud Build, bygge bildet og lagre det i GCR, og deretter bruke manifestene på klyngen din. Dette er hva den gjør make skaffold, men Skaffold har mange andre funksjoner.
For yaml-maler i Kubernetes bruker vi kustomize for å administrere yaml-overlegg uten å forkaste hele manifestet, slik at du kan bruke git pull --rebase for ytterligere forbedringer. Nå er det i kubectl og det fungerer ganske bra for slike ting.
Vi bruker også envsubst til å fylle ut vertsnavnet og GCP-prosjekt-IDen i *.yaml.tmpl-filene. Du kan se hvordan det fungerer i makefile eller bare fortsett videre.
Forutsetninger
- Arbeidsklynge
- - for å lage dine egne docker-bilder og enkel distribusjon til GKE
- Kopi av denne koden
- Envsubst
Arbeidsflyt ved hjelp av manifester
Hvis du ikke ønsker å bruke kustomize eller skaffold, kan du henvise til manifestene i generated-manifest.yaml og tilpasse dem til arbeidsflyten du ønsker.
Logger og beregninger
Prometheus har blitt standarden for innsamling av beregninger i Kubernetes. Den har samme nisje som AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics og andre. Det er åpen kildekode og har et kraftig spørrespråk. Vi overlater visualiseringen til Grafana – den kommer med et stort antall dashbord tilgjengelig rett ut av esken. De er koblet til hverandre og er relativt enkle å installere med .
Som standard bruker Prometheus utvinningsmodellen <service>/metrics, og å legge til sidevognsbeholdere for dette er vanlig. Dessverre logges JMX-beregninger best i JVM, så sidevognscontainere er ikke like effektive. La oss koble til åpen kildekode fra Prometheus til JVM ved å legge den til containerbildet som vil gi banen /metrics på en annen havn.
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
Vel, det var lett. Eksportøren vil overvåke tomcat og vise dens beregninger i Prometheus-format på <svc>:9404/metrics
Eksportør oppsett
Den oppmerksomme leseren lurer kanskje på hvor det kom fra prometheus-jmx.yaml? Det er mange forskjellige ting som kan kjøres i JVM, og tomcat er bare en av dem, så eksportøren trenger litt ekstra konfigurasjon. Standardkonfigurasjoner for tomcat, wildfly, kafka og så videre er tilgjengelige . Vi vil legge til tomcat som i Kubernetes og deretter montere den som et volum.
Først legger vi til eksportørkonfigurasjonsfilen til vår plattform/config/-katalog
platform/config
└── prometheus-jmx.yaml
Så legger vi til в 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 ConfigMap-konfigurasjonselement. ConfigMapGenerators er gode fordi de hash konfigurasjonsdataene og tvinger en pod omstart hvis den endres. De reduserer også mengden konfigurasjon i Deployment siden du kan montere en hel "mappe" med konfigurasjonsfiler i ett VolumeMount.
Til slutt må vi montere ConfigMap som et volum 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
[...]
Herlig. Hvis Prometheus ikke er konfigurert til å gjøre en fullstendig opprydding, må du kanskje be den rydde opp i podene. Prometheus Operator-brukere kan bruke service-monitor.yaml for å komme i gang. Utforske Service-monitor.yaml, и før du begynner.
Utvide dette mønsteret til andre brukstilfeller
Alle filer vi legger til i ConfigMapGenerator vil være tilgjengelige i den nye katalogen /etc/config. Du kan utvide denne malen til å montere alle andre konfigurasjonsfiler du trenger. Du kan til og med montere et nytt oppstartsskript. Du kan bruke for å montere individuelle filer. For å oppdatere xml-filer, vurder å bruke i stedet for sed. Den er allerede inkludert i bildet.
Magasiner
Gode nyheter! Applikasjonslogger er allerede tilgjengelig på stdout, for eksempel med kubectl logs. Fluentd (installert som standard i GKE) vil videresende loggene dine til Elasticsearch, Loki eller bedriftens loggingsplattform. Hvis du vil bruke jsonify for logger, kan du følge malen ovenfor for å installere .
Database
Som standard vil bildet ha en H2-database. Dette passer ikke for oss, og vi vil bruke Google Cloud SQL med Cloud SQL Proxy – dette vil være nødvendig senere for å løse interne problemer. Dette er et enkelt og pålitelig alternativ hvis du ikke har dine egne preferanser for å sette opp databasen. AWS RDS tilbyr en lignende tjeneste.
Uansett hvilken database du velger, med mindre det er H2, må du angi de riktige miljøvariablene i platform/deploy.yaml. Det ser omtrent slik ut:
-- 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
[...]
Note: Du kan bruke Kustomize til å distribuere til forskjellige miljøer ved å bruke et overlegg: .
Note: bruk valueFrom: secretKeyRef. Vennligst bruk selv under utvikling for å holde hemmelighetene dine trygge.
Det er sannsynlig at du allerede har et foretrukket system for å administrere Kubernetes-hemmeligheter. Hvis ikke, her er noen alternativer: Kryptere dem med nettskyleverandørens KMS og injisere dem i K8S som hemmeligheter via CD-rørledningen − - vil fungere veldig bra i kombinasjon med Kustomize-hemmeligheter. Det er andre verktøy, for eksempel dotGPG, som utfører lignende funksjoner: , .
Ingress
Med mindre du velger å bruke lokal portvideresending, trenger du en konfigurert Ingress Controller. Hvis du ikke bruker () så vet du mest sannsynlig allerede at du må installere de nødvendige merknadene i ingress-patch.yaml.tmpl eller platform/ingress.yaml. Hvis du bruker ingress-nginx og ser en nginx ingress-klasse med en lastbalanser som peker på den og en ekstern DNS- eller wildcard-DNS-oppføring, er du klar. Ellers kan du konfigurere Ingress Controller og DNS, eller hoppe over disse trinnene og beholde den direkte forbindelsen til poden.
TLS
Hvis du bruker eller kube-lego og letsencrypt - sertifikater for den nye påloggingen hentes automatisk. Ellers åpne ingress-patch.yaml.tmpl og tilpasse den til dine behov.
Lansering!
Hvis du fulgte alt skrevet ovenfor, så kommandoen make skaffold HOSTNAME=<you.example.com> bør starte en tilgjengelig instans i <hostname>/camunda
Hvis du ikke har satt påloggingen til en offentlig URL, kan du omdirigere den med localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 på localhost:8080/camunda
Vent noen minutter til tomcat er helt klar. Cert-manager vil bruke litt tid på å bekrefte domenenavnet. Du kan deretter overvåke loggene ved å bruke tilgjengelige verktøy som et verktøy som kubetail, eller ganske enkelt bruke kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
De neste trinnene
Autorisasjon
Dette er mer relevant for å konfigurere Camunda BPM enn Kubernetes, men det er viktig å merke seg at som standard er autentisering deaktivert i REST API. Du kan eller bruk en annen metode som . Du kan bruke configmaps og volumer for å laste xml, eller xmlstarlet (se ovenfor) for å redigere eksisterende filer i bildet, og enten bruke wget eller laste dem ved hjelp av en init-beholder og et delt volum.
Sesjonsledelse
Som mange andre applikasjoner håndterer Camunda BPM økter i JVM, så hvis du vil kjøre flere replikaer, kan du aktivere klissete økter (), som vil eksistere til replikaen forsvinner, eller angi Max-Age-attributtet for informasjonskapsler. For en mer robust løsning kan du distribuere Session Manager i Tomcat. Lars har om dette emnet, men noe sånt 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
Note: du kan bruke xmlstarlet i stedet for sed
Vi brukte foran Google Cloud Memorystore, med (støtter Redis) for å kjøre den.
skalering
Hvis du allerede forstår økter, kan den første (og ofte den siste) begrensningen for å skalere Camunda BPM være forbindelsen til databasen. Delvis tilpasning er allerede tilgjengelig "" La oss også deaktivere intialSize i filen settings.xml. Legg til og du kan enkelt automatisk skalere antall pods.
Forespørsler og begrensninger
В platform/deployment.yaml Du vil se at vi har hardkodet ressursfeltet. Dette fungerer bra med HPA, men kan kreve ytterligere konfigurasjon. Kutomize-lappen er egnet for dette. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
Utgang
Så vi installerte Camunda BPM på Kubernetes med Prometheus-målinger, logger, H2-database, TLS og Ingress. Vi la til jar-filer og konfigurasjonsfiler ved å bruke ConfigMaps og Dockerfile. Vi snakket om å utveksle data til volumer og direkte til miljøvariabler fra hemmeligheter. I tillegg ga vi en oversikt over oppsett av Camunda for flere replikaer og en autentisert API.
referanser
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, oversettelse Alastair Firth, Lars Lange
Kilde: www.habr.com