Brûke jo Kubernetes? Klear om jo Camunda BPM-eksimplaren út firtuele masines te ferpleatsen, of miskien gewoan besykje se op Kubernetes te rinnen? Litte wy nei guon mienskiplike konfiguraasjes en yndividuele items sjen dy't kinne wurde oanpast oan jo spesifike behoeften.
It giet derfan út dat jo Kubernetes earder hawwe brûkt. As net, wêrom dan net efkes sjen en net begjinne jo earste kluster?
skriuwers
- (Alastair Firth) - Senior Site Reliability Engineer op it Camunda Cloud-team;
- (Lars Lange) - DevOps yngenieur by Camunda.
Koartsein:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Okee, it hat wierskynlik net wurke, om't jo gjin skaffold en kustomize hawwe ynstalleare. No dan lês fierder!
Wat is Camunda BPM
Camunda BPM is in iepen boarne platfoarm foar bedriuwsprosesbehear en beslútautomatisaasje dat saaklike brûkers en software-ûntwikkelders ferbynt. It is ideaal foar it koördinearjen en ferbinen fan minsken, (mikro) tsjinsten of sels bots! Jo kinne mear lêze oer de ferskillende gebrûk gefallen op .
Wêrom brûke Kubernetes
Kubernetes is de de facto standert wurden foar it útfieren fan moderne applikaasjes op Linux. Troch systeemoproppen te brûken ynstee fan hardware-emulaasje en de mooglikheid fan 'e kernel om ûnthâld- en taakwikseling te behearjen, wurde opstarttiid en opstarttiid op in minimum beheind. It grutste foardiel kin lykwols komme fan 'e standert API dy't Kubernetes leveret om de ynfrastruktuer te konfigurearjen dy't nedich is troch alle applikaasjes: opslach, netwurking en tafersjoch. It waard 2020 jier âld yn juny 6 en is miskien it op ien nei grutste iepen boarne-projekt (nei Linux). It hat koartlyn har funksjonaliteit aktyf stabilisearre nei rappe iteraasje yn 'e ôfrûne jierren, om't it kritysk wurdt foar produksjewurkbelêstingen oer de heule wrâld.
Camunda BPM Engine kin maklik ferbine mei oare applikaasjes dy't rinne op deselde kluster, en Kubernetes jout poerbêst scalability, sadat jo fergrutsje ynfrastruktuer kosten allinnich as echt nedich (en maklik ferminderje se as nedich).
De kwaliteit fan tafersjoch wurdt ek gâns ferbettere mei ark lykas Prometheus, Grafana, Loki, Fluentd en Elasticsearch, wêrtroch jo alle workloads sintraal yn in kluster kinne besjen. Hjoed sille wy sjen hoe't jo de Prometheus-eksporteur ymplementearje yn 'e Java Virtual Machine (JVM).
Objektiven
Litte wy nei in pear gebieten sjen wêr't wy de Camunda BPM Docker-ôfbylding kinne oanpasse () sadat it goed ynteraksje mei Kubernetes.
- Logboeken en metriken;
- databankferbiningen;
- Autentikaasje;
- Sesje behear.
Wy sille ferskate manieren besjen om dizze doelen te berikken en it heule proses dúdlik sjen te litten.
remark: Brûk jo de Enterprise ferzje? Sjen en update ôfbylding keppelings as nedich.
Workflow ûntwikkeling
Yn dizze demo sille wy Skaffold brûke om Docker-ôfbyldings te bouwen mei Google Cloud Build. It hat goede stipe foar ferskate ark (lykas Kustomize en Helm), CI en build ark, en ynfrastruktuer providers. Map skaffold.yaml.tmpl omfettet ynstellings foar Google Cloud Build en GKE, en biedt in heul ienfâldige manier om ynfrastruktuer fan produksjeklasse út te fieren.
make skaffold sil de Dockerfile-kontekst yn Cloud Build laden, de ôfbylding bouwe en it opslaan yn GCR, en dan de manifesten tapasse op jo kluster. Dit is wat it docht make skaffold, mar Skaffold hat in protte oare funksjes.
Foar yaml-sjabloanen yn Kubernetes brûke wy kustomize om yaml-overlays te behearjen sûnder it hiele manifest te forkearen, wêrtroch jo kinne brûke git pull --rebase foar fierdere ferbetterings. No is it yn kubectl en it wurket goed foar sokke dingen.
Wy brûke ek envsubst om de hostnamme en GCP-projekt-ID yn te foljen yn 'e *.yaml.tmpl-bestannen. Jo kinne sjen hoe't it wurket yn makefile of gewoan fierder gean.
Beskikberens
- Wurk kluster
- - foar it meitsjen fan jo eigen dockerôfbyldings en maklike ynset nei GKE
- Kopy fan dizze koade
- Envsubst
Workflow mei help fan manifesten
As jo gjin kustomize of skaffold brûke wolle, kinne jo ferwize nei de manifesten yn generated-manifest.yaml en oanpasse se oan 'e workflow fan jo kar.
Logboeken en metriken
Prometheus is de standert wurden foar it sammeljen fan metriken yn Kubernetes. It beslacht deselde niche as AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics en oaren. It is iepen boarne en hat in krêftige query-taal. Wy sille de fisualisaasje tafertrouwe oan Grafana - it komt mei in grut oantal dashboards beskikber út 'e doaze. Se binne ferbûn mei elkoar en binne relatyf maklik te ynstallearjen mei .
Standert brûkt Prometheus it ekstraksjemodel <service>/metrics, en it tafoegjen fan sidecarcontainers foar dit is gewoanlik. Spitigernôch wurde JMX-metriken it bêste oanmeld yn 'e JVM, dus sidecar-konteners binne net sa effisjint. Litte wy ferbine iepen boarne fan Prometheus nei de JVM troch it ta te foegjen oan 'e kontenerôfbylding dy't it paad sil leverje /metrics op in oare haven.
Foegje Prometheus jmx_exporter ta oan de kontener
-- 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
No, dat wie maklik. De eksporteur sil tomcat kontrolearje en syn metriken werjaan yn Prometheus-formaat by <svc>:9404/metrics
Eksporteur opset
De oandachtige lêzer kin him ôffreegje wêr't it wei kaam prometheus-jmx.yaml? D'r binne in protte ferskillende dingen dy't kinne rinne yn 'e JVM, en tomcat is mar ien fan har, sadat de eksporteur wat ekstra konfiguraasje nedich hat. Standert konfiguraasjes foar tomcat, wildfly, kafka ensafuorthinne binne beskikber . Wy sille tafoegje tomcat as yn Kubernetes en montearje it dan as in folume.
Earst foegje wy it konfiguraasjebestân fan de eksporteur ta oan ús platfoarm/config/ map
platform/config
└── prometheus-jmx.yaml
Dan foegje wy ta в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Dit sil elk elemint tafoegje files[] as in ConfigMap konfiguraasje elemint. ConfigMapGenerators binne geweldich om't se de konfiguraasjegegevens hashje en in pod opnij starte as it feroaret. Se ferminderje ek de hoemannichte konfiguraasje yn Deployment, om't jo in folsleine "map" fan konfiguraasjetriemmen kinne montearje yn ien VolumeMount.
Uteinlik moatte wy de ConfigMap as in folume op 'e pod montearje:
-- 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
[...]
Prachtich. As Prometheus net is ynsteld om in folsleine skjinmeitsjen te dwaan, moatte jo it miskien fertelle om de pods op te romjen. Prometheus Operator brûkers kinne brûke service-monitor.yaml om te begjinnen. Ferkenne Service-monitor.yaml, и foardat'st begjinst.
Dit patroan útwreidzje nei oare gebrûksgefallen
Alle bestannen dy't wy tafoegje oan ConfigMapGenerator sille beskikber wêze yn 'e nije map /etc/config. Jo kinne dit sjabloan útwreidzje om alle oare konfiguraasjebestannen te mount dy't jo nedich binne. Jo kinne sels in nij opstartskript montearje. Jo kinne brûke om yndividuele bestannen te mount. Om xml-bestannen te aktualisearjen, besykje te brûken ynstee fan sed. It is al opnommen yn 'e ôfbylding.
Tydskriften
Geweldich nijs! Applikaasje logs binne al beskikber op stdout, bygelyks mei kubectl logs. Fluentd (standert ynstalleare yn GKE) sil jo logs trochstjoere nei Elasticsearch, Loki, of jo bedriuwslogplatfoarm. As jo jsonify wolle brûke foar logs, dan kinne jo it boppesteande sjabloan folgje om te ynstallearjen .
Databank
Standert sil de ôfbylding in H2-database hawwe. Dit is net geskikt foar ús, en wy sille Google Cloud SQL brûke mei Cloud SQL Proxy - dit sil letter nedich wêze om ynterne problemen op te lossen. Dit is in ienfâldige en betroubere opsje as jo gjin eigen foarkar hawwe by it ynstellen fan de databank. AWS RDS leveret in ferlykbere tsjinst.
Nettsjinsteande de databank dy't jo kieze, útsein as it H2 is, moatte jo de passende omjouwingsfariabelen ynstelle yn platform/deploy.yaml. It sjocht der sa út:
-- 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
[...]
remark: Jo kinne Kustomize brûke om te ynsetten nei ferskate omjouwings mei in overlay: .
remark: gebrûk valueFrom: secretKeyRef. Graach brûke sels tidens ûntwikkeling om jo geheimen feilich te hâlden.
It is wierskynlik dat jo al in foarkarssysteem hawwe foar it behearen fan Kubernetes-geheimen. As net, binne hjir wat opsjes: Se fersiferje mei de KMS fan jo wolkprovider en ynjeksje se dan yn K8S as geheimen fia de CD-pipeline - - sil heul goed wurkje yn kombinaasje mei Kustomize-geheimen. D'r binne oare ark, lykas dotGPG, dy't ferlykbere funksjes útfiere: , .
Ingress
Behalven as jo kieze om lokale poarte trochstjoere te brûken, sille jo in ynstelde Ingress Controller nedich hawwe. As jo net brûke () dan witte jo nei alle gedachten al dat jo de nedige annotaasjes moatte ynstallearje yn ingress-patch.yaml.tmpl of platform/ingress.yaml. As jo ingress-nginx brûke en in nginx-yngongsklasse sjogge mei in loadbalancer dy't derop wiist en in eksterne DNS- as jokerteken DNS-yngong, dan binne jo goed om te gean. Oars, konfigurearje de Ingress Controller en DNS, of skip dizze stappen oer en hâld de direkte ferbining mei de pod.
TLS
As jo brûke of kube-lego en letsencrypt - sertifikaten foar de nije oanmelding wurde automatysk krigen. Oars, iepen ingress-patch.yaml.tmpl en oanpasse it oan jo behoeften.
Launch!
As jo alles hjirboppe skreaun hawwe folge, dan it kommando make skaffold HOSTNAME=<you.example.com> moat in beskikbere eksimplaar lansearje yn <hostname>/camunda
As jo jo oanmelding net ynsteld hawwe op in iepenbiere URL, kinne jo it omliede mei localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 op localhost:8080/camunda
Wachtsje in pear minuten oant tomcat folslein klear is. Cert-manager sil wat tiid nimme om de domeinnamme te ferifiearjen. Jo kinne dan de logs kontrolearje mei beskikbere ark lykas in ark lykas kubetail, of gewoan mei kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Folgjende stappen
Oanmelde
Dit is relevanter foar it konfigurearjen fan Camunda BPM dan Kubernetes, mar it is wichtich om te notearjen dat standert ferifikaasje is útskeakele yn 'e REST API. Do kinst of brûk in oare metoade lykas . Jo kinne configmaps en folumes brûke om xml te laden, of xmlstarlet (sjoch hjirboppe) om besteande bestannen yn 'e ôfbylding te bewurkjen, en brûke wget of laden se mei in init-container en in dielde folume.
Sesje behear
Lykas in protte oare applikaasjes, behannelet Camunda BPM sesjes yn 'e JVM, dus as jo meardere replika's wolle útfiere, kinne jo kleverige sesjes ynskeakelje (), dy't sil bestean oant de replika ferdwynt, of set it Max-Age attribút foar cookies yn. Foar in robúste oplossing kinne jo Session Manager yn Tomcat ynsette. Lars hat oer dit ûnderwerp, mar soksawat as:
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
remark: jo kinne xmlstarlet brûke ynstee fan sed
Wy brûkten foar Google Cloud Memorystore, mei (stipe Redis) om it út te fieren.
Skaalfergrutting
As jo sesjes al begripe, dan kin de earste (en faaks de lêste) beheining foar skaalfergrutting fan Camunda BPM de ferbining wêze mei de databank. Diele oanpassing is al beskikber "" Litte wy intialSize ek útskeakelje yn it settings.xml-bestân. Add en jo kinne it oantal pods maklik automatysk skaalje.
Fersiken en beheiningen
В platform/deployment.yaml Jo sille sjen dat wy it boarnefjild hurd kodearre hawwe. Dit wurket goed mei HPA, mar kin ekstra konfiguraasje nedich wêze. De kustomize patch is geskikt foar dit. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
konklúzje
Dat wy ynstalleare Camunda BPM op Kubernetes mei Prometheus-metriken, logs, H2-database, TLS en Ingress. Wy hawwe jar-bestannen en konfiguraasjebestannen tafoege mei ConfigMaps en Dockerfile. Wy prate oer it útwikseljen fan gegevens nei folumes en direkt nei omjouwingsfariabelen út geheimen. Derneist levere wy in oersjoch fan it ynstellen fan Camunda foar meardere replika's en in autentike API.
referinsjes
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, oersetting Alastair Firth, Lars Lange
Boarne: www.habr.com