Gebruik jy Kubernetes? Gereed om jou Camunda BPM-gevalle uit virtuele masjiene te skuif, of dalk net probeer om dit op Kubernetes te laat loop? Kom ons kyk na 'n paar algemene konfigurasies en individuele items wat by jou spesifieke behoeftes aangepas kan word.
Dit neem aan dat u al voorheen Kubernetes gebruik het. Indien nie, hoekom nie 'n blik op en nie jou eerste groep begin nie?
Skrywers
- (Alastair Firth) - Senior Terreinbetroubaarheidsingenieur op die Camunda Cloud-span;
- (Lars Lange) - DevOps-ingenieur by Camunda.
In kort:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Goed, dit het waarskynlik nie gewerk nie, want jy het nie skaffold en kustomize geïnstalleer nie. Wel, lees dan verder!
Wat is Camunda BPM
Camunda BPM is 'n oopbron-besigheidsprosesbestuur- en besluitoutomatiseringsplatform wat besigheidsgebruikers en sagteware-ontwikkelaars verbind. Dit is ideaal om mense, (mikro) dienste of selfs bots te koördineer en te verbind! Jy kan meer lees oor die verskillende gebruiksgevalle by .
Waarom Kubernetes gebruik
Kubernetes het die de facto-standaard geword om moderne toepassings op Linux te laat loop. Deur stelseloproepe in plaas van hardeware-emulasie te gebruik en die kern se vermoë om geheue en taakwisseling te bestuur, word selflaaityd en opstarttyd tot 'n minimum beperk. Die grootste voordeel kan egter kom uit die standaard API wat Kubernetes verskaf om die infrastruktuur op te stel wat deur alle toepassings vereis word: berging, netwerk en monitering. Dit het in Junie 2020 6 jaar oud geword en is miskien die tweede grootste oopbronprojek (na Linux). Dit het onlangs sy funksionaliteit aktief gestabiliseer ná vinnige herhaling oor die afgelope paar jaar, aangesien dit krities raak vir produksie-werkladings regoor die wêreld.
Camunda BPM Engine kan maklik koppel aan ander toepassings wat op dieselfde groep werk, en Kubernetes bied uitstekende skaalbaarheid, wat jou toelaat om infrastruktuurkoste te verhoog net wanneer dit regtig nodig is (en dit maklik te verminder soos nodig).
Die kwaliteit van monitering word ook aansienlik verbeter met nutsmiddels soos Prometheus, Grafana, Loki, Fluentd en Elasticsearch, wat jou in staat stel om alle werkladings in 'n groep sentraal te bekyk. Vandag sal ons kyk hoe om die Prometheus-uitvoerder in die Java Virtual Machine (JVM) te implementeer.
Doelwitte
Kom ons kyk na 'n paar gebiede waar ons die Camunda BPM Docker-beeld kan aanpas () sodat dit goed met Kubernetes interaksie het.
- Logs en metrieke;
- Databasisverbindings;
- Verifikasie;
- Sessiebestuur.
Ons sal na verskeie maniere kyk om hierdie doelwitte te bereik en die hele proses duidelik te wys.
Let daarop: Gebruik jy die Enterprise-weergawe? Kyk en werk prentskakels op soos nodig.
Werkvloei ontwikkeling
In hierdie demonstrasie sal ons Skaffold gebruik om Docker-beelde te bou met Google Cloud Build. Dit het goeie ondersteuning vir verskeie instrumente (soos Kustomize en Helm), CI en bou-gereedskap, en infrastruktuurverskaffers. lêer skaffold.yaml.tmpl sluit instellings vir Google Cloud Build en GKE in, wat 'n baie eenvoudige manier bied om produksiegraad-infrastruktuur te bestuur.
make skaffold sal die Dockerfile-konteks in Cloud Build laai, die prent bou en dit in GCR stoor, en dan die manifeste op jou groepering toepas. Dit is wat dit doen make skaffold, maar Skaffold het baie ander kenmerke.
Vir yaml-sjablone in Kubernetes gebruik ons kustomize om yaml-oorlegsels te bestuur sonder om die hele manifes te vervurk, sodat jy dit kan gebruik git pull --rebase vir verdere verbeterings. Nou is dit in kubectl en dit werk nogal goed vir sulke dinge.
Ons gebruik ook envsubst om die gasheernaam en GCP-projek-ID in die *.yaml.tmpl-lêers te vul. Jy kan sien hoe dit werk in makefile of gaan net verder.
Die nodige voorwaardes
- Werkgroepering
- - vir die skep van u eie docker-beelde en maklike implementering na GKE
- Afskrif van hierdie kode
- Envsubst
Werkvloei deur gebruik te maak van manifeste
As jy nie kustomize of skaffold wil gebruik nie, kan jy verwys na die manifeste in generated-manifest.yaml en pas dit aan by die werkvloei van jou keuse.
Logs en metrieke
Prometheus het die standaard geword vir die insameling van metrieke in Kubernetes. Dit beslaan dieselfde nis as AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics en ander. Dit is oopbron en het 'n kragtige navraagtaal. Ons sal die visualisering aan Grafana toevertrou - dit kom met 'n groot aantal dashboards wat uit die boks beskikbaar is. Hulle is aan mekaar gekoppel en is relatief maklik om mee te installeer .
By verstek gebruik Prometheus die ekstraksiemodel <service>/metrics, en die byvoeging van syspanhouers hiervoor is algemeen. Ongelukkig word JMX-statistieke die beste binne die JVM aangeteken, so syspanhouers is nie so doeltreffend nie. Kom ons verbind oopbron van Prometheus na die JVM deur dit by die houerbeeld te voeg wat die pad sal verskaf /metrics op 'n ander hawe.
Voeg Prometheus jmx_exporter by die houer
-- 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
Wel, dit was maklik. Die uitvoerder sal tomcat monitor en sy maatstawwe in Prometheus-formaat vertoon by <svc>:9404/metrics
Uitvoerder opstelling
Die aandagtige leser mag wonder waar dit vandaan kom prometheus-jmx.yaml? Daar is baie verskillende dinge wat in die JVM kan loop, en tomcat is net een van hulle, so die uitvoerder benodig 'n paar bykomende konfigurasie. Standaardkonfigurasies vir tomcat, wildfly, kafka en so meer is beskikbaar . Ons sal tomcat byvoeg as in Kubernetes en monteer dit dan as 'n volume.
Eerstens voeg ons die uitvoerder-konfigurasielêer by ons platform/config/-gids
platform/config
└── prometheus-jmx.yaml
Dan voeg ons by в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Dit sal elke element byvoeg files[] as 'n ConfigMap-konfigurasie-element. ConfigMapGenerators is wonderlik omdat hulle die konfigurasiedata hash en 'n pod herbegin as dit verander. Hulle verminder ook die hoeveelheid konfigurasie in Ontplooiing aangesien jy 'n hele "vouer" van konfigurasielêers in een VolumeMount kan monteer.
Ten slotte moet ons die ConfigMap as 'n volume op die pod monteer:
-- 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
[...]
Wonderlik. As Prometheus nie gekonfigureer is om 'n volledige skoonmaak te doen nie, moet jy dit dalk sê om die peule skoon te maak. Prometheus Operator-gebruikers kan gebruik service-monitor.yaml om te begin. Verken Service-monitor.yaml, и voor jy begin.
Brei hierdie patroon uit na ander gebruiksgevalle
Alle lêers wat ons by ConfigMapGenerator voeg, sal in die nuwe gids beskikbaar wees /etc/config. U kan hierdie sjabloon uitbrei om enige ander konfigurasielêers wat u benodig, te monteer. Jy kan selfs 'n nuwe opstartskrif monteer. Jy kan gebruik om individuele lêers te monteer. Om xml-lêers op te dateer, oorweeg dit om in plaas van sed. Dit is reeds by die beeld ingesluit.
Tydskrifte
Goeie nuus! Toepassing logs is reeds beskikbaar op stdout, byvoorbeeld met kubectl logs. Fluentd (by verstek geïnstalleer in GKE) sal jou logs aanstuur na Elasticsearch, Loki of jou onderneming se logplatform. As jy jsonify vir logs wil gebruik, kan jy die bogenoemde sjabloon volg om te installeer .
databasis
By verstek sal die prent 'n H2-databasis hê. Dit is nie geskik vir ons nie, en ons sal Google Cloud SQL met Cloud SQL Proxy gebruik - dit sal later nodig wees om interne probleme op te los. Dit is 'n eenvoudige en betroubare opsie as jy nie jou eie voorkeure het in die opstel van die databasis nie. AWS RDS bied 'n soortgelyke diens.
Ongeag die databasis wat jy kies, tensy dit H2 is, sal jy die toepaslike omgewingsveranderlikes in platform/deploy.yaml. Dit lyk so iets:
-- 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
[...]
Let daarop: Jy kan Kustomize gebruik om na verskillende omgewings te ontplooi met 'n oorleg: .
Let daarop: gebruik valueFrom: secretKeyRef. Gebruik asseblief selfs tydens ontwikkeling om jou geheime veilig te hou.
Dit is waarskynlik dat u reeds 'n voorkeurstelsel het om Kubernetes-geheime te bestuur. Indien nie, hier is 'n paar opsies: Enkripteer hulle met jou wolkverskaffer se KMS en spuit hulle dan in K8S as geheime via die CD-pyplyn − - sal baie goed werk in kombinasie met Kustomize-geheime. Daar is ander gereedskap, soos dotGPG, wat soortgelyke funksies verrig: , .
Ingang
Tensy jy kies om plaaslike poortaanstuur te gebruik, sal jy 'n gekonfigureerde Ingress Controller nodig hê. As jy nie gebruik nie () dan weet jy heel waarskynlik reeds dat jy die nodige aantekeninge in moet installeer ingress-patch.yaml.tmpl of platform/ingress.yaml. As jy ingress-nginx gebruik en 'n nginx-ingangklas sien met 'n lasbalanseerder wat daarna wys en 'n eksterne DNS of wildcard DNS-inskrywing, is jy goed om te gaan. Andersins, stel die Ingress Controller en DNS op, of slaan hierdie stappe oor en behou die direkte verbinding met die peul.
TLS
As u gebruik of kube-lego en letsencrypt - sertifikate vir die nuwe aanmelding sal outomaties verkry word. Andersins, maak oop ingress-patch.yaml.tmpl en pas dit aan om by jou behoeftes te pas.
Begin!
As jy alles gevolg het wat hierbo geskryf is, dan is die opdrag make skaffold HOSTNAME=<you.example.com> moet 'n beskikbare instansie begin in <hostname>/camunda
As jy nie jou aanmelding op 'n publieke URL gestel het nie, kan jy dit herlei localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 op localhost:8080/camunda
Wag 'n paar minute totdat tomcat heeltemal gereed is. Sert-bestuurder sal tyd neem om die domeinnaam te verifieer. U kan dan die logboeke monitor met behulp van beskikbare gereedskap soos 'n instrument soos kubetail, of bloot met behulp van kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Volgende stappe
magtiging
Dit is meer relevant vir die opstel van Camunda BPM as Kubernetes, maar dit is belangrik om daarop te let dat verifikasie by verstek in die REST API gedeaktiveer is. Jy kan of gebruik 'n ander metode soos . Jy kan configmaps en volumes gebruik om xml te laai, of xmlstarlet (sien hierbo) om bestaande lêers in die prent te wysig, en óf wget gebruik óf dit laai met 'n init-houer en 'n gedeelde volume.
Sessiebestuur
Soos baie ander toepassings, hanteer Camunda BPM sessies in die JVM, so as jy verskeie replikas wil laat loop, kan jy taai sessies aktiveer (), wat sal bestaan totdat die replika verdwyn, of stel die Max-Age-kenmerk vir koekies in. Vir 'n meer robuuste oplossing, kan u Sessiebestuurder in Tomcat ontplooi. Lars het oor hierdie onderwerp, maar iets soos:
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
Let daarop: jy kan xmlstarlet in plaas van sed gebruik
Ons het gebruik voor Google Cloud Memorystore, met (ondersteun Redis) om dit uit te voer.
Skaal
As jy reeds sessies verstaan, dan kan die eerste (en dikwels die laaste) beperking om Camunda BPM te skaal die verbinding met die databasis wees. Gedeeltelike aanpassing is reeds beskikbaar "" Kom ons deaktiveer ook intialSize in die settings.xml-lêer. Voeg by en jy kan die aantal peule maklik outomaties skaal.
Versoeke en beperkings
В platform/deployment.yaml Jy sal sien dat ons die hulpbronneveld hardgekodeer het. Dit werk goed met HPA, maar kan addisionele konfigurasie vereis. Die kustomize-pleister is geskik hiervoor. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
Output
Ons het dus Camunda BPM op Kubernetes geïnstalleer met Prometheus-statistieke, logs, H2-databasis, TLS en Ingress. Ons het jar-lêers en konfigurasielêers bygevoeg deur ConfigMaps en Dockerfile te gebruik. Ons het gepraat oor die uitruil van data na volumes en direk na omgewingsveranderlikes uit geheime. Daarbenewens het ons 'n oorsig verskaf van die opstel van Camunda vir veelvuldige replikas en 'n geverifieerde API.
verwysings
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, vertaling Alastair Firth, Lars Lange
Bron: will.com