Ĉu vi uzas Kubernetes? Preta movi viajn Camunda BPM-instancojn el virtualaj maŝinoj, aŭ eble simple provu ruli ilin sur Kubernetes? Ni rigardu kelkajn komunajn agordojn kaj individuajn aĵojn kiuj povas esti adaptitaj al viaj specifaj bezonoj.
Ĝi supozas, ke vi antaŭe uzis Kubernetes. Se ne, kial ne rigardi kaj ne komenci vian unuan areton?
aŭtoroj
- (Alastair Firth) - Senior Site Reliability Engineer sur la Camunda Cloud-teamo;
- (Lars Lange) - DevOps-inĝeniero ĉe Camunda.
Mallonge:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Bone, ĝi verŝajne ne funkciis ĉar vi ne havas skaffold kaj kustomize instalitaj. Nu do legu plu!
Kio estas Camunda BPM
Camunda BPM estas malfermfonta komercproceza administrado kaj decida aŭtomatiga platformo, kiu ligas komercajn uzantojn kaj programistojn. Ĝi estas ideala por kunordigi kaj konekti homojn, (mikro-) servojn aŭ eĉ robotojn! Vi povas legi pli pri la malsamaj uzkazoj ĉe .
Kial uzi Kubernetes
Kubernetes fariĝis la fakta normo por ruli modernajn aplikojn en Linukso. Uzante sistemvokojn anstataŭ aparatara emulado kaj la kapablo de la kerno administri memoron kaj taskoŝanĝon, ektempo kaj ektempo estas minimumaj. Tamen, la plej granda profito povas veni de la norma API, kiun Kubernetes provizas por agordi la infrastrukturon postulatan de ĉiuj aplikoj: stokado, retoj kaj monitorado. Ĝi fariĝis 2020-jara en junio 6 kaj eble estas la dua plej granda malfermkoda projekto (post Linukso). Ĝi lastatempe aktive stabiligis sian funkciecon post rapida ripeto dum la lastaj jaroj, ĉar ĝi fariĝas kritika por produktaj laborkvantoj tra la mondo.
Camunda BPM Engine povas facile konektiĝi al aliaj aplikaĵoj kurantaj sur la sama areto, kaj Kubernetes disponigas bonegan skaleblon, ebligante vin pliigi infrastrukturkostojn nur kiam vere necesas (kaj facile redukti ilin laŭbezone).
La kvalito de monitorado ankaŭ estas multe plibonigita per iloj kiel Prometheus, Grafana, Loki, Fluentd kaj Elasticsearch, permesante al vi centre rigardi ĉiujn laborŝarĝojn en areto. Hodiaŭ ni rigardos kiel efektivigi la eksportilon Prometheus en la Java Virtuala Maŝino (JVM).
Objektivoj
Ni rigardu kelkajn areojn, kie ni povas personecigi la bildon de Camunda BPM Docker () por ke ĝi bone interagas kun Kubernetes.
- Registroj kaj metrikoj;
- Datumbazaj konektoj;
- Aŭtentikigo;
- Administrado de sesio.
Ni rigardos plurajn manierojn atingi ĉi tiujn celojn kaj klare montros la tutan procezon.
Примечание: Ĉu vi uzas la Enterprise version? Rigardu kaj ĝisdatigi bildligilojn laŭbezone.
Evoluo de laborfluo
En ĉi tiu pruvo, ni uzos Skaffold por konstrui Docker-bildojn per Google Cloud Build. Ĝi havas bonan subtenon por diversaj iloj (kiel Kustomize kaj Helm), CI kaj konstruaj iloj kaj infrastrukturaj provizantoj. Dosiero skaffold.yaml.tmpl inkluzivas agordojn por Google Cloud Build kaj GKE, provizante tre simplan manieron funkciigi produktadnivelan infrastrukturon.
make skaffold ŝarĝos la Dockerfile-kuntekston en Cloud Build, konstruos la bildon kaj stokos ĝin en GCR, kaj poste aplikas la manifestojn al via areto. Jen kion ĝi faras make skaffold, sed Skaffold havas multajn aliajn funkciojn.
Por yaml-ŝablonoj en Kubernetes, ni uzas kustomize por administri yaml-kovraĵojn sen forki la tutan manifeston, permesante al vi uzi git pull --rebase por pliaj plibonigoj. Nun ĝi estas en kubectl kaj ĝi funkcias sufiĉe bone por tiaj aferoj.
Ni ankaŭ uzas envsubst por plenigi la gastigan nomon kaj GCP-projektan ID en la dosieroj *.yaml.tmpl. Vi povas vidi kiel ĝi funkcias makefile aŭ simple daŭrigu plu.
La necesaj kondiĉoj
- Laborgrupo
- - por krei viajn proprajn docker-bildojn kaj facilan deplojadon al GKE
- Kopio de ĉi tiu kodo
- Envsubst
Laborfluo uzante manifestojn
Se vi ne volas uzi kustomize aŭ skaffold, vi povas rilati al la manifestoj en generated-manifest.yaml kaj adaptu ilin al la laborfluo de via elekto.
Registroj kaj metrikoj
Prometheus fariĝis la normo por kolektado de metrikoj en Kubernetes. Ĝi okupas la saman niĉon kiel AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics kaj aliaj. Ĝi estas malferma fonto kaj havas potencan demandlingvon. Ni konfidos la bildigon al Grafana - ĝi venas kun granda nombro da paneloj disponeblaj el la skatolo. Ili estas konektitaj unu al la alia kaj estas relative facile instaleblaj .
Defaŭlte, Prometeo uzas la eltiran modelon <service>/metrics, kaj aldoni kromĉarujojn por tio estas ofta. Bedaŭrinde, JMX-metrikoj estas plej bone registritaj ene de la JVM, do kromĉaraj ujoj ne estas tiel efikaj. Ni konektu malfermfonteco de Prometheus al la JVM aldonante ĝin al la ujo-bildo kiu provizos la vojon /metrics sur malsama haveno.
Aldonu Prometheus jmx_exporter al la ujo
-- 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
Nu, tio estis facila. La eksportisto monitoros tomcat kaj montros ĝiajn metrikojn en Prometheus-formato ĉe <svc>:9404/metrics
Agordo de eksportilo
La atentema leganto povas scivoli de kie ĝi venis prometheus-jmx.yaml? Estas multaj malsamaj aferoj, kiuj povas funkcii en la JVM, kaj tomcat estas nur unu el ili, do la eksportanto bezonas iun plian agordon. Normaj agordoj por tomkato, sovaĝa muŝo, kafka kaj tiel plu estas disponeblaj . Ni aldonos tomcat kiel en Kubernetes kaj tiam muntu ĝin kiel volumon.
Unue, ni aldonas la agordan dosieron de eksportilo al nia platformo/config/-dosierujo
platform/config
└── prometheus-jmx.yaml
Tiam ni aldonas в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Ĉi tio aldonos ĉiun elementon files[] kiel ConfigMap agorda elemento. ConfigMapGenerators estas bonegaj ĉar ili hashas la agordajn datumojn kaj devigas pod rekomencon se ĝi ŝanĝiĝas. Ili ankaŭ reduktas la kvanton de agordo en Deployment ĉar vi povas munti tutan "dosierujon" de agordaj dosieroj en unu VolumeMount.
Fine, ni devas munti la ConfigMap kiel volumon al la pod:
-- 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
[...]
Mirinda. Se Prometheus ne estas agordita por fari plenan purigadon, vi eble devos diri al ĝi purigi la podojn. Prometheus Operator uzantoj povas uzi service-monitor.yaml por komenci. Esploru Service-monitor.yaml, и antaŭ ol vi komencas.
Etendante ĉi tiun ŝablonon al aliaj uzkazoj
Ĉiuj dosieroj, kiujn ni aldonas al ConfigMapGenerator, estos disponeblaj en la nova dosierujo /etc/config. Vi povas etendi ĉi tiun ŝablonon por munti aliajn agordajn dosierojn, kiujn vi bezonas. Vi eĉ povas munti novan startskripton. Vi povas uzi por munti individuajn dosierojn. Por ĝisdatigi xml-dosierojn, konsideru uzi anstataŭ sed. Ĝi jam estas inkluzivita en la bildo.
Revuoj
Bonega novaĵo! Aplikaj protokoloj jam haveblas ĉe stdout, ekzemple kun kubectl logs. Fluentd (instalita defaŭlte en GKE) plusendos viajn protokolojn al Elasticsearch, Loki aŭ via entreprena registra platformo. Se vi volas uzi jsonify por protokoloj, vi povas sekvi la supran ŝablonon por instali .
Datumbazo
Defaŭlte, la bildo havos H2-datumbazon. Ĉi tio ne taŭgas por ni, kaj ni uzos Google Cloud SQL kun Cloud SQL Proxy - tio estos bezonata poste por solvi internajn problemojn. Ĉi tio estas simpla kaj fidinda opcio se vi ne havas viajn proprajn preferojn pri agordo de la datumbazo. AWS RDS provizas similan servon.
Sendepende de la datumbazo, kiun vi elektas, krom se ĝi estas H2, vi devos agordi la taŭgajn mediovariablojn en platform/deploy.yaml. Ĝi aspektas kiel ĉi tio:
-- 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
[...]
Примечание: Vi povas uzi Kustomize por disfaldi al malsamaj medioj uzante supermetaĵon: .
Примечание: uzado valueFrom: secretKeyRef. Bonvolu uzi eĉ dum evoluo por konservi viajn sekretojn sekuraj.
Verŝajne vi jam havas preferatan sistemon por administri Kubernetes-sekretojn. Se ne, jen kelkaj opcioj: Ĉifri ilin per la KMS de via nuba provizanto kaj poste injekti ilin en K8S kiel sekretojn per la KD-dukto − - funkcios tre bone kombine kun Kustomize sekretoj. Estas aliaj iloj, kiel dotGPG, kiuj plenumas similajn funkciojn: , .
Ingreso
Krom se vi elektas uzi lokan havensendilon, vi bezonos agorditan Ingress-Regilon. Se vi ne uzas () tiam vi plej verŝajne jam scias, ke vi devas instali la necesajn komentadojn enen ingress-patch.yaml.tmpl aŭ platform/ingress.yaml. Se vi uzas ingress-nginx kaj vidas nginx enirklason kun ŝarĝbalancilo montranta ĝin kaj eksteran DNS aŭ ĵokeran DNS-eniron, vi estas bona por iri. Alie, agordu la Ingress-Regilon kaj DNS, aŭ saltu ĉi tiujn paŝojn kaj konservu la rektan konekton al la pod.
TLS
Se vi uzas aŭ kube-lego kaj letsencrypt - atestiloj por la nova ensaluto estos aŭtomate akiritaj. Alie, malfermu ingress-patch.yaml.tmpl kaj agordu ĝin laŭ viaj bezonoj.
Lanĉu!
Se vi sekvis ĉion skribitan supre, tiam la komando make skaffold HOSTNAME=<you.example.com> devus lanĉi disponeblan petskribon en <hostname>/camunda
Se vi ne agordis vian ensaluton al publika URL, vi povas redirekti ĝin per localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 sur localhost:8080/camunda
Atendu kelkajn minutojn ĝis tomcat estas tute preta. Cert-manaĝero daŭros iom da tempo por kontroli la domajnan nomon. Vi povas tiam kontroli la protokolojn uzante disponeblajn ilojn kiel ilon kiel kubetail, aŭ simple uzante kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Sekvaj paŝoj
Rajtigo
Ĉi tio estas pli grava por agordi Camunda BPM ol Kubernetes, sed gravas noti, ke defaŭlte, aŭtentigo estas malŝaltita en la REST API. Vi povas aŭ uzu alian metodon kiel . Vi povas uzi konfigmapojn kaj volumojn por ŝargi xml, aŭ xmlstarlet (vidu supre) por redakti ekzistantajn dosierojn en la bildo, kaj aŭ uzi wget aŭ ŝargi ilin per init-ujo kaj komuna volumo.
Administrado de sesio
Kiel multaj aliaj aplikoj, Camunda BPM pritraktas sesiojn en la JVM, do se vi volas ruli plurajn kopiojn, vi povas ebligi gluiĝajn sesiojn (), kiu ekzistos ĝis la kopio malaperos, aŭ starigos la atributon Max-Age por kuketoj. Por pli fortika solvo, vi povas disfaldi Session Manager en Tomcat. Lars havas pri ĉi tiu temo, sed io kiel:
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
Примечание: vi povas uzi xmlstarlet anstataŭ sed
Ni uzis antaŭ Google Cloud Memorystore, kun (subtenas Redis) ruli ĝin.
Skalo
Se vi jam komprenas sesiojn, tiam la unua (kaj ofte la lasta) limigo por grimpi Camunda BPM eble estas la konekto al la datumbazo. Parta personigo jam disponeblas "" Ni ankaŭ malŝaltu intialSize en la dosiero settings.xml. Aldoni kaj vi povas facile aŭtomate grimpi la nombron da balgoj.
Petoj kaj limigoj
В platform/deployment.yaml Vi vidos, ke ni malfacile kodis la kampon de rimedoj. Ĉi tio funkcias bone kun HPA, sed eble postulas plian agordon. La kustomize diakilo taŭgas por ĉi tio. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
konkludo
Do ni instalis Camunda BPM sur Kubernetes kun Prometheus-metrikoj, protokoloj, H2-datumbazo, TLS kaj Ingress. Ni aldonis jar-dosierojn kaj agordajn dosierojn per ConfigMaps kaj Dockerfile. Ni parolis pri interŝanĝado de datumoj al volumoj kaj rekte al mediaj variabloj el sekretoj. Krome, ni provizis superrigardon pri agordo de Camunda por pluraj kopioj kaj aŭtentikigita API.
referencoj
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, traduko Alastair Firth, Lars Lange
fonto: www.habr.com