Pagpapatakbo ng Camunda BPM sa Kubernetes

Pagpapatakbo ng Camunda BPM sa Kubernetes

Gumagamit ka ba ng Kubernetes? Handa nang ilipat ang iyong mga instance ng Camunda BPM mula sa mga virtual machine, o baka subukan lang na patakbuhin ang mga ito sa Kubernetes? Tingnan natin ang ilang karaniwang configuration at indibidwal na item na maaaring iayon sa iyong mga partikular na pangangailangan.

Ipinapalagay na nagamit mo na ang Kubernetes dati. Kung hindi, bakit hindi tingnan pamumuno at hindi simulan ang iyong unang kumpol?

Mga May-akda

  • Alastair Firth (Alastair Firth) - Senior Site Reliability Engineer sa Camunda Cloud team;
  • Lars Lange (Lars Lange) - DevOps engineer sa Camunda.

Sa madaling salita:

git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold

Okay, malamang na hindi ito gumana dahil wala kang naka-install na skaffold at kustomize. Well pagkatapos basahin sa!

Ano ang Camunda BPM

Ang Camunda BPM ay isang open source na business process management at decision automation platform na nag-uugnay sa mga user ng negosyo at software developer. Ito ay perpekto para sa pag-coordinate at pagkonekta ng mga tao, (micro) na mga serbisyo o kahit na mga bot! Maaari kang magbasa nang higit pa tungkol sa iba't ibang mga kaso ng paggamit sa link.

Bakit gumamit ng Kubernetes

Ang Kubernetes ay naging de facto na pamantayan para sa pagpapatakbo ng mga modernong application sa Linux. Sa pamamagitan ng paggamit ng mga system call sa halip na hardware emulation at ang kakayahan ng kernel na pamahalaan ang memorya at paglipat ng gawain, ang oras ng pag-boot at oras ng pagsisimula ay pinananatiling pinakamababa. Gayunpaman, ang pinakamalaking benepisyo ay maaaring magmula sa karaniwang API na ibinibigay ng Kubernetes para i-configure ang imprastraktura na kinakailangan ng lahat ng application: storage, networking, at monitoring. Ito ay naging 2020 na taong gulang noong Hunyo 6 at marahil ang pangalawang pinakamalaking open source na proyekto (pagkatapos ng Linux). Kamakailan lamang ay aktibong nagpapatatag ng functionality nito pagkatapos ng mabilis na pag-ulit sa nakalipas na ilang taon dahil nagiging kritikal ito sa mga workload sa produksyon sa buong mundo.

Ang Camunda BPM Engine ay madaling kumonekta sa iba pang mga application na tumatakbo sa parehong cluster, at ang Kubernetes ay nagbibigay ng mahusay na scalability, na nagbibigay-daan sa iyong taasan ang mga gastos sa imprastraktura kapag talagang kinakailangan (at madaling bawasan ang mga ito kung kinakailangan).

Ang kalidad ng pagsubaybay ay lubos ding napabuti gamit ang mga tool tulad ng Prometheus, Grafana, Loki, Fluentd at Elasticsearch, na nagbibigay-daan sa iyong sentral na tingnan ang lahat ng mga workload sa isang cluster. Ngayon ay titingnan natin kung paano ipatupad ang Prometheus exporter sa Java Virtual Machine (JVM).

Mga Layunin

Tingnan natin ang ilang lugar kung saan maaari nating i-customize ang larawan ng Camunda BPM Docker (github) upang maayos itong makipag-ugnayan sa Kubernetes.

  1. Mga tala at sukatan;
  2. Mga koneksyon sa database;
  3. Authentication;
  4. Pamamahala ng session.

Titingnan natin ang ilang paraan upang makamit ang mga layuning ito at malinaw na ipapakita ang buong proseso.

Nota: Ginagamit mo ba ang bersyon ng Enterprise? Tingnan mo dito at i-update ang mga link ng larawan kung kinakailangan.

Pag-unlad ng daloy ng trabaho

Sa demo na ito, gagamitin namin ang Skaffold para bumuo ng mga larawan ng Docker gamit ang Google Cloud Build. Mayroon itong magandang suporta para sa iba't ibang tool (tulad ng Kustomize at Helm), CI at build tool, at mga provider ng imprastraktura. file skaffold.yaml.tmpl may kasamang mga setting para sa Google Cloud Build at GKE, na nagbibigay ng napakasimpleng paraan upang magpatakbo ng imprastraktura sa antas ng produksyon.

make skaffold ilo-load ang konteksto ng Dockerfile sa Cloud Build, bubuo ng imahe at iimbak ito sa GCR, at pagkatapos ay ilalapat ang mga manifest sa iyong cluster. Ito ang ginagawa nito make skaffold, ngunit ang Skaffold ay may maraming iba pang mga tampok.

Para sa mga template ng yaml sa Kubernetes, ginagamit namin ang kustomize upang pamahalaan ang mga overlay ng yaml nang hindi kinukuha ang buong manifest, na nagbibigay-daan sa iyong gamitin git pull --rebase para sa karagdagang pagpapabuti. Ngayon ito ay nasa kubectl at ito ay gumagana nang maayos para sa mga ganoong bagay.

Gumagamit din kami ng envsubst para i-populate ang hostname at GCP project ID sa *.yaml.tmpl file. Makikita mo kung paano ito gumagana sa makefile o magpatuloy lang.

Mga kinakailangan

  • Kumpol ng trabaho Kubernetes
  • I-customize
  • Skaffold - para sa paglikha ng iyong sariling mga docker na imahe at madaling pag-deploy sa GKE
  • Kopya ng code na ito
  • Envsubst

Daloy ng trabaho gamit ang mga manifest

Kung ayaw mong gumamit ng kustomize o skaffold, maaari kang sumangguni sa mga manifest sa generated-manifest.yaml at iakma ang mga ito sa workflow na iyong pinili.

Mga log at sukatan

Ang Prometheus ay naging pamantayan para sa pagkolekta ng mga sukatan sa Kubernetes. Sinasakop nito ang parehong angkop na lugar gaya ng AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics at iba pa. Ito ay open source at may malakas na query language. Ipagkakatiwala namin ang visualization sa Grafana - kasama ito ng malaking bilang ng mga dashboard na available sa labas ng kahon. Ang mga ito ay konektado sa isa't isa at medyo madaling i-install prometheus-operator.

Bilang default, ginagamit ng Prometheus ang modelo ng pagkuha <service>/metrics, at ang pagdaragdag ng mga sidecar container para dito ay karaniwan. Sa kasamaang palad, ang mga sukatan ng JMX ay pinakamahusay na naka-log sa loob ng JVM, kaya ang mga sidecar container ay hindi kasing episyente. Kumonekta tayo jmx_exporter open source mula sa Prometheus hanggang sa JVM sa pamamagitan ng pagdaragdag nito sa imahe ng lalagyan na magbibigay ng landas /metrics sa ibang port.

Idagdag ang Prometheus jmx_exporter sa lalagyan

-- 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

Well, madali lang iyon. Susubaybayan ng exporter ang tomcat at ipapakita ang mga sukatan nito sa format na Prometheus sa <svc>:9404/metrics

Setup ng exporter

Maaaring magtaka ang matulungin na mambabasa kung saan ito nanggaling prometheus-jmx.yaml? Mayroong maraming iba't ibang mga bagay na maaaring tumakbo sa JVM, at ang tomcat ay isa lamang sa mga ito, kaya ang exporter ay nangangailangan ng ilang karagdagang configuration. Available ang mga karaniwang configuration para sa tomcat, wildfly, kafka at iba pa dito. Magdaragdag kami ng tomcat bilang ConfigMap sa Kubernetes at pagkatapos ay i-mount ito bilang isang volume.

Una, idinaragdag namin ang file ng pagsasaayos ng exporter sa aming direktoryo ng platform/config/

platform/config
└── prometheus-jmx.yaml

Pagkatapos ay idagdag namin ConfigMapGenerator в kustomization.yaml.tmpl:

-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...] configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml

Idaragdag nito ang bawat elemento files[] bilang isang elemento ng pagsasaayos ng ConfigMap. Mahusay ang ConfigMapGenerators dahil hina-hash nila ang data ng configuration at pinipilit ang isang pod restart kung magbabago ito. Binabawasan din ng mga ito ang dami ng configuration sa Deployment dahil maaari mong i-mount ang isang buong "folder" ng mga configuration file sa isang VolumeMount.

Sa wakas, kailangan nating i-mount ang ConfigMap bilang volume sa 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
[...]

Kahanga-hanga. Kung hindi naka-configure ang Prometheus na gumawa ng ganap na paglilinis, maaaring kailanganin mong sabihin dito na linisin ang mga pod. Maaaring gamitin ng mga user ng Prometheus Operator service-monitor.yaml upang makapagsimula. Galugarin Service-monitor.yaml, disenyo ng operator и ServiceMonitorSpec bago ka magsimula.

Pagpapalawak ng pattern na ito sa iba pang mga kaso ng paggamit

Ang lahat ng mga file na idinaragdag namin sa ConfigMapGenerator ay magiging available sa bagong direktoryo /etc/config. Maaari mong palawigin ang template na ito upang i-mount ang anumang iba pang mga configuration file na kailangan mo. Maaari ka ring mag-mount ng bagong startup script. Pwede mong gamitin subPath upang i-mount ang mga indibidwal na file. Upang i-update ang mga xml file, isaalang-alang ang paggamit xmlstarlet sa halip na sed. Kasama na ito sa larawan.

Mga magasin

Magandang balita! Available na ang mga log ng application sa stdout, halimbawa sa kubectl logs. Ipapasa ng Fluentd (naka-install bilang default sa GKE) ang iyong mga log sa Elasticsearch, Loki, o sa iyong platform sa pag-log ng enterprise. Kung nais mong gumamit ng jsonify para sa mga log, maaari mong sundin ang template sa itaas upang mai-install pag-logback.

Database

Bilang default, ang larawan ay magkakaroon ng H2 database. Hindi ito angkop para sa amin, at gagamitin namin ang Google Cloud SQL sa Cloud SQL Proxy - kakailanganin ito sa ibang pagkakataon upang malutas ang mga panloob na problema. Ito ay isang simple at maaasahang opsyon kung wala kang sariling mga kagustuhan sa pagse-set up ng database. Nagbibigay ang AWS RDS ng katulad na serbisyo.

Anuman ang database na pipiliin mo, maliban kung ito ay H2, kakailanganin mong itakda ang naaangkop na mga variable ng kapaligiran sa platform/deploy.yaml. Mukhang ganito:

-- 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
[...]

Nota: Maaari mong gamitin ang Kustomize upang i-deploy sa iba't ibang mga kapaligiran gamit ang isang overlay: halimbawa.

Nota: paggamit valueFrom: secretKeyRef. Mangyaring, gamitin itong tampok na Kubernetes kahit na sa panahon ng pag-unlad upang panatilihing ligtas ang iyong mga lihim.

Malamang na mayroon ka nang gustong sistema para sa pamamahala ng mga lihim ng Kubernetes. Kung hindi, narito ang ilang mga opsyon: I-encrypt ang mga ito gamit ang KMS ng iyong cloud provider at pagkatapos ay i-inject ang mga ito sa K8S bilang mga lihim sa pamamagitan ng CD pipeline − MozillaSOPS - gagana nang mahusay sa kumbinasyon ng mga lihim ng Kustomize. Mayroong iba pang mga tool, tulad ng dotGPG, na gumaganap ng mga katulad na function: HashiCorp Vault, I-customize ang Mga Lihim na Halaga ng Plugin.

Pagpasok

Maliban kung pipiliin mong gumamit ng lokal na pagpapasa ng port, kakailanganin mo ng naka-configure na Ingress Controller. Kung hindi mo gagamitin pagpasok-nginx (Helm chart) pagkatapos ay malamang na alam mo na na kailangan mong i-install ang mga kinakailangang anotasyon sa ingress-patch.yaml.tmpl o platform/ingress.yaml. Kung gumagamit ka ng ingress-nginx at nakakita ng isang nginx ingress class na may load balancer na nakaturo dito at isang external na DNS o wildcard DNS entry, handa ka nang umalis. Kung hindi, i-configure ang Ingress Controller at DNS, o laktawan ang mga hakbang na ito at panatilihin ang direktang koneksyon sa pod.

TLS

Kung gumagamit ka sertipikadong tagapamahala o kube-lego at letsencrypt - awtomatikong makukuha ang mga certificate para sa bagong login. Kung hindi, buksan ingress-patch.yaml.tmpl at i-customize ito upang umangkop sa iyong mga pangangailangan.

Ilunsad!

Kung sinunod mo ang lahat ng nakasulat sa itaas, pagkatapos ay ang utos make skaffold HOSTNAME=<you.example.com> dapat maglunsad ng available na instance sa <hostname>/camunda

Kung hindi mo pa naitakda ang iyong login sa isang pampublikong URL, maaari mo itong i-redirect gamit ang localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 sa localhost:8080/camunda

Maghintay ng ilang minuto hanggang sa ganap na handa ang tomcat. Ang Cert-manager ay magtatagal upang ma-verify ang domain name. Pagkatapos ay maaari mong subaybayan ang mga log gamit ang mga magagamit na tool tulad ng isang tool tulad ng kubetail, o simpleng paggamit ng kubectl:

kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f

Mga susunod na hakbang

Awtorisasyon

Ito ay mas nauugnay sa pag-configure ng Camunda BPM kaysa sa Kubernetes, ngunit mahalagang tandaan na bilang default, ang pagpapatotoo ay hindi pinagana sa REST API. Kaya mo paganahin ang pangunahing pagpapatunay o gumamit ng ibang paraan tulad ng J.W.T.. Maaari kang gumamit ng mga configmap at volume upang i-load ang xml, o xmlstarlet (tingnan sa itaas) upang i-edit ang mga umiiral nang file sa larawan, at alinman ay gumamit ng wget o i-load ang mga ito gamit ang init na lalagyan at isang nakabahaging volume.

Pamamahala ng session

Tulad ng maraming iba pang mga application, pinangangasiwaan ng Camunda BPM ang mga session sa JVM, kaya kung gusto mong magpatakbo ng maraming replika, maaari mong paganahin ang mga malagkit na session (halimbawa para sa ingress-nginx), na iiral hanggang sa mawala ang replica, o itakda ang Max-Age attribute para sa cookies. Para sa isang mas matatag na solusyon, maaari mong i-deploy ang Session Manager sa Tomcat. meron si Lars hiwalay na post sa paksang ito, ngunit tulad ng:

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

Nota: maaari mong gamitin ang xmlstarlet sa halip na sed

Ginamit namin twemproxy sa harap ng Google Cloud Memorystore, na may memcached-session-manager (sinusuportahan ang Redis) upang patakbuhin ito.

Pagsusukat

Kung naiintindihan mo na ang mga session, ang una (at kadalasan ang huli) na limitasyon sa pag-scale ng Camunda BPM ay maaaring ang koneksyon sa database. Available na ang bahagyang pag-customize "mula sa kahon" I-disable din natin ang intialSize sa settings.xml file. Idagdag Horizontal Pod Autoscaler (HPA) at madali mong awtomatikong masusukat ang bilang ng mga pod.

Mga kahilingan at paghihigpit

В platform/deployment.yaml Makikita mo na na-hard-code namin ang field ng mga mapagkukunan. Gumagana ito nang maayos sa HPA, ngunit maaaring mangailangan ng karagdagang configuration. Ang customize patch ay angkop para dito. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl

Pagbubuhos

Kaya nag-install kami ng Camunda BPM sa Kubernetes na may Prometheus metrics, logs, H2 database, TLS at Ingress. Nagdagdag kami ng mga jar file at configuration file gamit ang ConfigMaps at Dockerfile. Napag-usapan namin ang tungkol sa pagpapalitan ng data sa mga volume at direkta sa mga variable ng kapaligiran mula sa mga lihim. Bilang karagdagan, nagbigay kami ng pangkalahatang-ideya ng pag-set up ng Camunda para sa maraming replika at isang napatotohanan na API.

sanggunian

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, pagsasalin Artikulo Alastair Firth, Lars Lange

Pinagmulan: www.habr.com

Magdagdag ng komento