កំពុងដំណើរការ Camunda BPM នៅលើ Kubernetes

តើអ្នកកំពុងប្រើ Kubernetes មែនទេ? ត្រៀមខ្លួនរួចរាល់ហើយដើម្បីផ្លាស់ទីវត្ថុ Camunda BPM របស់អ្នកចេញពីម៉ាស៊ីននិម្មិត ឬប្រហែលជាគ្រាន់តែព្យាយាមដំណើរការពួកវានៅលើ Kubernetes? សូមក្រឡេកមើលការកំណត់ទូទៅមួយចំនួន និងធាតុនីមួយៗដែលអាចតម្រូវទៅតាមតម្រូវការជាក់លាក់របស់អ្នក។

វាសន្មត់ថាអ្នកធ្លាប់ប្រើ Kubernetes ពីមុនមក។ បើ​មិន​អ៊ីចឹង​ទេ​មើល​ទៅ ភាពជាអ្នកដឹកនាំ ហើយមិនចាប់ផ្តើមចង្កោមដំបូងរបស់អ្នកទេ?

អ្នកនិពន្ធ

• Alastair Firth (Alastair Firth) - វិស្វករភាពជឿជាក់នៃគេហទំព័រជាន់ខ្ពស់នៅលើក្រុម Camunda Cloud;
• ឡាស ឡាង (Lars Lange) - វិស្វករ DevOps នៅ Camunda ។

និយាយឱ្យខ្លី៖

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


មិនអីទេ វាប្រហែលជាមិនដំណើរការទេ ដោយសារតែអ្នកមិនមាន skaffold និង ប្ដូរតាមបំណង។ អញ្ចឹងអានបន្ត!

Camunda BPM ជាអ្វី?

Camunda BPM គឺជាកម្មវិធីគ្រប់គ្រងដំណើរការអាជីវកម្មប្រភពបើកចំហ និងវេទិកាស្វ័យប្រវត្តិកម្មនៃការសម្រេចចិត្ត ដែលភ្ជាប់អ្នកប្រើប្រាស់អាជីវកម្ម និងអ្នកបង្កើតកម្មវិធី។ វាល្អសម្រាប់ការសម្របសម្រួល និងភ្ជាប់មនុស្ស សេវាកម្ម (មីក្រូ) ឬសូម្បីតែរូបយន្ត! អ្នកអាចអានបន្ថែមអំពីករណីប្រើប្រាស់ផ្សេងៗនៅ តំណភ្ជាប់.

ហេតុអ្វីត្រូវប្រើ Kubernetes

Kubernetes បានក្លាយជាស្តង់ដារជាក់ស្តែងសម្រាប់ដំណើរការកម្មវិធីទំនើបនៅលើលីនុច។ ដោយប្រើការហៅទូរសព្ទជាប្រព័ន្ធជំនួសឱ្យការត្រាប់តាមផ្នែករឹង និងសមត្ថភាពរបស់ខឺណែលក្នុងការគ្រប់គ្រងអង្គចងចាំ និងការផ្លាស់ប្តូរភារកិច្ច ពេលវេលាចាប់ផ្ដើម និងពេលចាប់ផ្ដើមត្រូវបានរក្សាទុកនៅអប្បបរមា។ ទោះជាយ៉ាងណាក៏ដោយ អត្ថប្រយោជន៍ដ៏ធំបំផុតអាចមកពី API ស្តង់ដារដែល Kubernetes ផ្តល់ឲ្យដើម្បីកំណត់រចនាសម្ព័ន្ធហេដ្ឋារចនាសម្ព័ន្ធដែលទាមទារដោយកម្មវិធីទាំងអស់៖ ការផ្ទុក បណ្តាញ និងការត្រួតពិនិត្យ។ វាមានអាយុ 2020 ឆ្នាំនៅក្នុងខែមិថុនា ឆ្នាំ 6 ហើយប្រហែលជាគម្រោងប្រភពបើកចំហធំបំផុតទីពីរ (បន្ទាប់ពីលីនុច) ។ ថ្មីៗនេះ វាត្រូវបានធ្វើឱ្យមានស្ថេរភាពមុខងាររបស់ខ្លួនយ៉ាងសកម្ម បន្ទាប់ពីដំណើរការឡើងវិញយ៉ាងឆាប់រហ័សក្នុងរយៈពេលប៉ុន្មានឆ្នាំចុងក្រោយនេះ ដោយសារវាក្លាយជាកត្តាសំខាន់សម្រាប់បន្ទុកផលិតកម្មនៅជុំវិញពិភពលោក។

Camunda BPM Engine អាចភ្ជាប់ទៅកម្មវិធីផ្សេងទៀតដែលដំណើរការនៅលើចង្កោមតែមួយបានយ៉ាងងាយស្រួល ហើយ Kubernetes ផ្តល់នូវសមត្ថភាពធ្វើមាត្រដ្ឋានដ៏ល្អឥតខ្ចោះ ដែលអនុញ្ញាតឱ្យអ្នកបង្កើនការចំណាយលើហេដ្ឋារចនាសម្ព័ន្ធតែនៅពេលដែលពិតជាត្រូវការ (និងងាយស្រួលកាត់បន្ថយវាតាមតម្រូវការ)។

គុណភាពនៃការត្រួតពិនិត្យក៏ត្រូវបានធ្វើឱ្យប្រសើរឡើងយ៉ាងខ្លាំងជាមួយនឹងឧបករណ៍ដូចជា Prometheus, Grafana, Loki, Fluentd និង Elasticsearch ដែលអនុញ្ញាតឱ្យអ្នកមើលពីកណ្តាលនៃបន្ទុកការងារនៅក្នុងចង្កោមមួយ។ ថ្ងៃនេះយើងនឹងមើលពីរបៀបអនុវត្តការនាំចេញ Prometheus ទៅក្នុង Java Virtual Machine (JVM)។

គោលបំណង

សូមក្រឡេកមើលតំបន់មួយចំនួនដែលយើងអាចប្ដូររូបភាព Camunda BPM Docker តាមបំណង (GitHub) ដូច្នេះវាធ្វើអន្តរកម្មបានល្អជាមួយ Kubernetes ។

1. កំណត់ហេតុនិងម៉ែត្រ;
2. ការតភ្ជាប់មូលដ្ឋានទិន្នន័យ;
3. ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ;
4. ការគ្រប់គ្រងសម័យ។

យើងនឹងពិនិត្យមើលវិធីជាច្រើនដើម្បីសម្រេចបាននូវគោលដៅទាំងនេះ ហើយបង្ហាញយ៉ាងច្បាស់នូវដំណើរការទាំងមូល។

ការកត់សម្គាល់៖ តើអ្នកកំពុងប្រើកំណែសហគ្រាសទេ? មើល នៅទីនេះ និងធ្វើបច្ចុប្បន្នភាពតំណភ្ជាប់រូបភាពតាមតម្រូវការ។

ការអភិវឌ្ឍន៍លំហូរការងារ

នៅក្នុងការបង្ហាញនេះ យើងនឹងប្រើ Skaffold ដើម្បីបង្កើតរូបភាព Docker ដោយប្រើ Google Cloud Build។ វាមានការគាំទ្រដ៏ល្អសម្រាប់ឧបករណ៍ផ្សេងៗ (ដូចជា Kustomize និង Helm) CI និងឧបករណ៍សាងសង់ និងអ្នកផ្តល់ហេដ្ឋារចនាសម្ព័ន្ធ។ ឯកសារ skaffold.yaml.tmpl រួមបញ្ចូលការកំណត់សម្រាប់ Google Cloud Build និង GKE ដោយផ្តល់នូវវិធីសាមញ្ញបំផុតក្នុងការដំណើរការហេដ្ឋារចនាសម្ព័ន្ធកម្រិតផលិតកម្ម។

make skaffold នឹងផ្ទុកបរិបទ Dockerfile ទៅក្នុង Cloud Build បង្កើតរូបភាព ហើយរក្សាទុកវានៅក្នុង GCR ហើយបន្ទាប់មកអនុវត្ត manifests ទៅ cluster របស់អ្នក។ នេះជាអ្វីដែលវាធ្វើ make skaffoldប៉ុន្តែ Skaffold មានមុខងារជាច្រើនទៀត។

សម្រាប់គំរូ yaml នៅក្នុង Kubernetes យើងប្រើ kustomize ដើម្បីគ្រប់គ្រងការលាបលើ yaml ដោយមិនចាំបាច់បិទ manifest ទាំងមូល ដែលអនុញ្ញាតឱ្យអ្នកប្រើ git pull --rebase សម្រាប់ការកែលម្អបន្ថែមទៀត។ ឥឡូវនេះវាស្ថិតនៅក្នុង kubectl ហើយវាដំណើរការល្អសម្រាប់រឿងបែបនេះ។

យើងក៏ប្រើ envsubst ដើម្បីបញ្ចូលឈ្មោះម៉ាស៊ីន និងលេខសម្គាល់គម្រោង GCP នៅក្នុងឯកសារ *.yaml.tmpl ។ អ្នកអាចមើលពីរបៀបដែលវាដំណើរការនៅក្នុង makefile ឬគ្រាន់តែបន្តទៅមុខទៀត។

លក្ខខណ្ឌចាំបាច់

• ចង្កោមការងារ Kubernetes
• ប្ដូរតាមបំណង
• Skaffold - សម្រាប់ការបង្កើតរូបភាព docker ផ្ទាល់ខ្លួនរបស់អ្នក និងងាយស្រួលក្នុងការដាក់ពង្រាយទៅ GKE
• ច្បាប់ចម្លងនៃលេខកូដនេះ។
• Envsubst

លំហូរការងារដោយប្រើ manifests

ប្រសិនបើអ្នកមិនចង់ប្រើ kustomize ឬ skaffold អ្នកអាចយោងទៅ manifests នៅក្នុង generated-manifest.yaml ហើយ​សម្រប​ពួកគេ​ទៅតាម​ដំណើរការ​ការងារ​នៃ​ជម្រើស​របស់អ្នក។

កំណត់ហេតុនិងម៉ែត្រ

Prometheus បានក្លាយជាស្តង់ដារសម្រាប់ការប្រមូលម៉ែត្រនៅក្នុង Kubernetes ។ វាកាន់កាប់ទីផ្សារពិសេសដូចគ្នានឹង AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics និងផ្សេងទៀត។ វាជាប្រភពបើកចំហ និងមានភាសាសំណួរដ៏មានឥទ្ធិពល។ យើងនឹងប្រគល់ការមើលឃើញទៅ Grafana - វាភ្ជាប់មកជាមួយផ្ទាំងគ្រប់គ្រងមួយចំនួនធំដែលអាចរកបានចេញពីប្រអប់។ ពួកវាត្រូវបានភ្ជាប់ទៅគ្នាទៅវិញទៅមក និងមានភាពងាយស្រួលក្នុងការដំឡើងជាមួយ prometheus-ប្រតិបត្តិករ.

តាមលំនាំដើម Prometheus ប្រើគំរូស្រង់ចេញ <service>/metricsហើយការបន្ថែមធុងដាក់រថយន្តសម្រាប់នេះគឺជារឿងធម្មតា។ ជាអកុសល រង្វាស់ JMX ត្រូវបានកត់ត្រាយ៉ាងល្អបំផុតនៅក្នុង JVM ដូច្នេះកុងតឺន័រ sidecar មិនមានប្រសិទ្ធភាពដូចនោះទេ។ តោះភ្ជាប់ jmx_exporter ប្រភពបើកចំហពី Prometheus ទៅ JVM ដោយបន្ថែមវាទៅរូបភាពកុងតឺន័រដែលនឹងផ្តល់ផ្លូវ /metrics នៅលើច្រកផ្សេង។

បន្ថែម Prometheus jmx_exporter ទៅកុងតឺន័រ

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


ជាការប្រសើរណាស់ នោះជាការងាយស្រួល។ អ្នកនាំចេញនឹងត្រួតពិនិត្យ tomcat និងបង្ហាញរង្វាស់របស់វាជាទម្រង់ Prometheus នៅ <svc>:9404/metrics

ការដំឡើងអ្នកនាំចេញ

អ្នកអានដែលចាប់អារម្មណ៍ប្រហែលជាឆ្ងល់ថាតើវាមកពីណា prometheus-jmx.yaml? មានរបស់ផ្សេងគ្នាជាច្រើនដែលអាចដំណើរការនៅក្នុង JVM ហើយ tomcat គឺគ្រាន់តែជារបស់មួយក្នុងចំណោមពួកគេ ដូច្នេះអ្នកនាំចេញត្រូវការការកំណត់បន្ថែមមួយចំនួន។ ការកំណត់រចនាសម្ព័ន្ធស្តង់ដារសម្រាប់ tomcat, wildfly, kafka ជាដើម។ នៅទីនេះ. យើងនឹងបន្ថែម tomcat ជា ConfigMap នៅក្នុង Kubernetes ហើយបន្ទាប់មកម៉ោនវាជាកម្រិតសំឡេង។

ជាដំបូង យើងបន្ថែមឯកសារកំណត់រចនាសម្ព័ន្ធអ្នកនាំចេញទៅវេទិកា/កំណត់រចនាសម្ព័ន្ធ/ថតរបស់យើង។

platform/config
└── prometheus-jmx.yaml


បន្ទាប់មកយើងបន្ថែម ឧបករណ៍បង្កើតផែនទី в kustomization.yaml.tmpl:

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


វានឹងបន្ថែមធាតុនីមួយៗ files[] ជាធាតុកំណត់រចនាសម្ព័ន្ធ ConfigMap ។ ConfigMapGenerators គឺអស្ចារ្យណាស់ ព្រោះវា hash data configuration and force a pod restart if it change. ពួកគេក៏កាត់បន្ថយចំនួននៃការកំណត់រចនាសម្ព័ន្ធនៅក្នុងការដាក់ឱ្យប្រើប្រាស់ផងដែរ ចាប់តាំងពីអ្នកអាចភ្ជាប់ "ថត" ទាំងមូលនៃឯកសារកំណត់រចនាសម្ព័ន្ធនៅក្នុង VolumeMount មួយ។

ជាចុងក្រោយ យើងត្រូវភ្ជាប់ ConfigMap ជាកម្រិតសំឡេងទៅកាន់ផតៈ

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

អស្ចារ្យ។ ប្រសិនបើ Prometheus មិនត្រូវបានកំណត់រចនាសម្ព័ន្ធដើម្បីធ្វើការសម្អាតពេញលេញទេ អ្នកប្រហែលជាត្រូវប្រាប់វាឱ្យសម្អាតផត។ អ្នកប្រើប្រាស់ Prometheus Operator អាចប្រើប្រាស់បាន។ service-monitor.yaml ដើម្បីចាប់ផ្តើម។ រុករក Service-monitor.yaml, ការរចនាប្រតិបត្តិករ и ServiceMonitorSpec មុន​ពេល​អ្នក​ចាប់ផ្ដើម។

ពង្រីកគំរូនេះទៅករណីប្រើប្រាស់ផ្សេងទៀត។

ឯកសារទាំងអស់ដែលយើងបន្ថែមទៅ ConfigMapGenerator នឹងមាននៅក្នុងថតថ្មី។ /etc/config. អ្នកអាចពង្រីកគំរូនេះ ដើម្បីភ្ជាប់ឯកសារកំណត់រចនាសម្ព័ន្ធផ្សេងទៀតដែលអ្នកត្រូវការ។ អ្នកថែមទាំងអាចភ្ជាប់ស្គ្រីបចាប់ផ្តើមថ្មីបានទៀតផង។ លោក​អ្នក​អាច​ប្រើ ផ្លូវរង ដើម្បីភ្ជាប់ឯកសារនីមួយៗ។ ដើម្បីធ្វើបច្ចុប្បន្នភាពឯកសារ xml សូមពិចារណាប្រើ xmlstarlet ជំនួសឱ្យ sed ។ វាត្រូវបានបញ្ចូលក្នុងរូបភាពរួចហើយ។

ទស្សនាវដ្តី

ព័ត៌មាន​អស្ចារ្យ! កំណត់ហេតុកម្មវិធីមានរួចហើយនៅលើ stdout ឧទាហរណ៍ជាមួយ kubectl logs. Fluentd (ដំឡើងតាមលំនាំដើមក្នុង GKE) នឹងបញ្ជូនកំណត់ហេតុរបស់អ្នកទៅ Elasticsearch, Loki ឬវេទិកាកត់ត្រាសហគ្រាសរបស់អ្នក។ ប្រសិនបើអ្នកចង់ប្រើ jsonify សម្រាប់កំណត់ហេតុ នោះអ្នកអាចធ្វើតាមគំរូខាងលើដើម្បីដំឡើង ត្រលប់មកវិញ.

មូលដ្ឋានទិន្នន័យ

តាមលំនាំដើម រូបភាពនឹងមានមូលដ្ឋានទិន្នន័យ H2 ។ វា​មិន​ស័ក្តិសម​សម្រាប់​យើង​ទេ ហើយ​យើង​នឹង​ប្រើ Google Cloud SQL ជាមួយ Cloud SQL Proxy - វា​នឹង​ត្រូវ​ការ​ពេល​ក្រោយ​ដើម្បី​ដោះស្រាយ​បញ្ហា​ខាងក្នុង។ នេះគឺជាជម្រើសដ៏សាមញ្ញ និងអាចទុកចិត្តបាន ប្រសិនបើអ្នកមិនមានចំណូលចិត្តផ្ទាល់ខ្លួនរបស់អ្នកក្នុងការដំឡើងមូលដ្ឋានទិន្នន័យ។ AWS RDS ផ្តល់សេវាកម្មស្រដៀងគ្នា។

ដោយមិនគិតពីមូលដ្ឋានទិន្នន័យដែលអ្នកជ្រើសរើស លុះត្រាតែវាជា H2 អ្នកនឹងត្រូវកំណត់អថេរបរិស្ថានសមស្របនៅក្នុង platform/deploy.yaml. វាមើលទៅដូចនេះ៖

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

ការកត់សម្គាល់៖ អ្នក​អាច​ប្រើ Kustomize ដើម្បី​ដាក់​ឱ្យ​ប្រើ​ក្នុង​បរិស្ថាន​ផ្សេង​គ្នា​ដោយ​ប្រើ​ការ​ត្រួត​លើ​គ្នា៖ ឧទាហរណ៍.

ការកត់សម្គាល់: ការប្រើប្រាស់ valueFrom: secretKeyRef. សូម​ប្រើ លក្ខណៈពិសេស Kubernetes នេះ។ សូម្បីតែក្នុងអំឡុងពេលអភិវឌ្ឍដើម្បីរក្សាអាថ៌កំបាំងរបស់អ្នកឱ្យមានសុវត្ថិភាព។

វាទំនងជាថាអ្នកមានប្រព័ន្ធដែលពេញចិត្តសម្រាប់ការគ្រប់គ្រងអាថ៌កំបាំង Kubernetes រួចហើយ។ ប្រសិនបើមិនមានទេ នេះគឺជាជម្រើសមួយចំនួន៖ ការអ៊ិនគ្រីបពួកវាជាមួយ KMS របស់អ្នកផ្តល់សេវាពពករបស់អ្នក ហើយបន្ទាប់មកបញ្ចូលពួកវាទៅក្នុង K8S ជាអាថ៌កំបាំងតាមរយៈបំពង់ស៊ីឌី − Mozilla SOPS - នឹងដំណើរការបានយ៉ាងល្អនៅក្នុងការរួមបញ្ចូលគ្នាជាមួយ Kustomize អាថ៌កំបាំង។ មានឧបករណ៍ផ្សេងទៀតដូចជា dotGPG ដែលអនុវត្តមុខងារស្រដៀងគ្នានេះ៖ ហាស់ស៊ីកូបវ៉ាក, ប្ដូរកម្មវិធីជំនួយតម្លៃសម្ងាត់តាមបំណង.

Ingress

លុះត្រាតែអ្នកជ្រើសរើសប្រើការបញ្ជូនបន្តច្រកមូលដ្ឋាន អ្នកនឹងត្រូវការឧបករណ៍បញ្ជា Ingress ដែលបានកំណត់រចនាសម្ព័ន្ធ។ ប្រសិនបើអ្នកមិនប្រើ ingress-nginx (គំនូសតាងមួកសុវត្ថិភាព) បន្ទាប់មកអ្នកទំនងជាដឹងរួចហើយថាអ្នកត្រូវដំឡើងចំណារពន្យល់ចាំបាច់នៅក្នុង ingress-patch.yaml.tmpl ឬ platform/ingress.yaml. ប្រសិនបើអ្នកកំពុងប្រើ ingress-nginx ហើយឃើញថ្នាក់ ingress nginx ជាមួយនឹង load balancer ចង្អុលទៅវា និង DNS ខាងក្រៅ ឬ wildcard បញ្ចូល DNS នោះ អ្នកពិតជាល្អក្នុងការទៅ។ បើមិនដូច្នោះទេ កំណត់រចនាសម្ព័ន្ធ Ingress Controller និង DNS ឬរំលងជំហានទាំងនេះ ហើយរក្សាការភ្ជាប់ដោយផ្ទាល់ទៅផត។

TLS បាន

ប្រសិនបើអ្នកកំពុងប្រើ អ្នកគ្រប់គ្រងវិញ្ញាបនប័ត្រ ឬ kube-lego និង letsencrypt - វិញ្ញាបនបត្រសម្រាប់ការចូលថ្មីនឹងត្រូវបានទទួលដោយស្វ័យប្រវត្តិ។ បើមិនដូច្នោះទេបើក ingress-patch.yaml.tmpl និងប្ដូរវាតាមតម្រូវការរបស់អ្នក

បើកដំណើរការ!

ប្រសិនបើអ្នកធ្វើតាមអ្វីគ្រប់យ៉ាងដែលបានសរសេរខាងលើបន្ទាប់មកពាក្យបញ្ជា make skaffold HOSTNAME=<you.example.com> គួរតែបើកដំណើរការឧទាហរណ៍ដែលមាននៅក្នុង <hostname>/camunda

ប្រសិនបើអ្នកមិនបានកំណត់ការចូលរបស់អ្នកទៅ URL សាធារណៈទេ អ្នកអាចប្តូរទិសវាជាមួយ localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 នៅលើ localhost:8080/camunda

រង់ចាំពីរបីនាទីរហូតដល់ tomcat រួចរាល់។ Cert-manager នឹងចំណាយពេលខ្លះដើម្បីផ្ទៀងផ្ទាត់ឈ្មោះដែន។ បន្ទាប់មកអ្នកអាចត្រួតពិនិត្យកំណត់ហេតុដោយប្រើឧបករណ៍ដែលមានដូចជាឧបករណ៍ដូចជា kubetail ឬគ្រាន់តែប្រើ kubectl៖

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


ជំហាន​បន្ទាប់

ការអនុញ្ញាត

នេះពាក់ព័ន្ធនឹងការកំណត់រចនាសម្ព័ន្ធ Camunda BPM ជាង Kubernetes ប៉ុន្តែវាសំខាន់ក្នុងការកត់សម្គាល់ថាតាមលំនាំដើម ការផ្ទៀងផ្ទាត់ត្រូវបានបិទនៅក្នុង REST API ។ អ្នក​អាច បើកការផ្ទៀងផ្ទាត់មូលដ្ឋាន ឬប្រើវិធីផ្សេងទៀតដូចជា J.W.T.. អ្នកអាចប្រើ configmaps និង volumes ដើម្បីផ្ទុក xml ឬ xmlstarlet (សូមមើលខាងលើ) ដើម្បីកែសម្រួលឯកសារដែលមានស្រាប់ក្នុងរូបភាព ហើយប្រើ wget ឬផ្ទុកវាដោយប្រើ init container និង volume ចែករំលែក។

ការគ្រប់គ្រងសម័យ

ដូចកម្មវិធីផ្សេងទៀតជាច្រើនដែរ Camunda BPM គ្រប់គ្រងវគ្គនៅក្នុង JVM ដូច្នេះប្រសិនបើអ្នកចង់ដំណើរការការចម្លងច្រើន អ្នកអាចបើកវគ្គស្អិត (ឧទាហរណ៍សម្រាប់ ingress-nginx) ដែលនឹងមានរហូតដល់ការចម្លងបាត់ ឬកំណត់គុណលក្ខណៈ Max-Age សម្រាប់ខូគី។ សម្រាប់ដំណោះស្រាយដ៏រឹងមាំ អ្នកអាចដាក់ Session Manager នៅក្នុង Tomcat។ ឡាសមាន ប្រកាសដាច់ដោយឡែក លើប្រធានបទនេះ ប៉ុន្តែអ្វីមួយដូចជា៖

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


ការកត់សម្គាល់៖ អ្នកអាចប្រើ xmlstarlet ជំនួសឱ្យ sed

យើង​បាន​ប្រើ twemproxy នៅពីមុខ Google Cloud Memorystore ជាមួយ memcached-session-manager (គាំទ្រ Redis) ដើម្បីដំណើរការវា។

ការធ្វើមាត្រដ្ឋាន

ប្រសិនបើអ្នកយល់វគ្គរួចហើយ នោះការកំណត់ដំបូង (ហើយជាញឹកញាប់ចុងក្រោយ) ក្នុងការធ្វើមាត្រដ្ឋាន Camunda BPM អាចជាការភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យ។ ការ​ប្ដូរ​តាម​បំណង​ផ្នែក​មាន​រួច​ហើយ"ពីប្រអប់" ចូរយើងបិទ intialSize នៅក្នុងឯកសារ settings.xml ផងដែរ។ បន្ថែម Horizontal Pod Autoscaler (HPA) ហើយ​អ្នក​អាច​ធ្វើ​មាត្រដ្ឋាន​ចំនួន​ផត​បាន​យ៉ាង​ងាយ​ស្រួល។

សំណើ និងការរឹតបន្តឹង

В platform/deployment.yaml អ្នក​នឹង​ឃើញ​ថា​យើង​បាន​សរសេរ​កូដ​យ៉ាង​ខ្លាំង​លើ​វាល​ធនធាន។ វាដំណើរការល្អជាមួយ HPA ប៉ុន្តែអាចតម្រូវឱ្យមានការកំណត់បន្ថែម។ បំណះ kustomize គឺសមរម្យសម្រាប់ការនេះ។ សង់​ទី​ម៉ែ​ត។ ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl

សេចក្តីសន្និដ្ឋាន

ដូច្នេះ យើងបានដំឡើង Camunda BPM នៅលើ Kubernetes ជាមួយនឹងរង្វាស់ Prometheus, កំណត់ហេតុ, មូលដ្ឋានទិន្នន័យ H2, TLS និង Ingress ។ យើងបានបន្ថែមឯកសារ jar និងឯកសារកំណត់រចនាសម្ព័ន្ធដោយប្រើ ConfigMaps និង Dockerfile ។ យើងបាននិយាយអំពីការផ្លាស់ប្តូរទិន្នន័យទៅជាបរិមាណ និងដោយផ្ទាល់ទៅអថេរបរិស្ថានពីអាថ៌កំបាំង។ លើសពីនេះ យើងបានផ្តល់ទិដ្ឋភាពទូទៅនៃការដំឡើង Camunda សម្រាប់ការចម្លងច្រើន និង API ផ្ទៀងផ្ទាត់។

សេចក្តីយោង

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, ការបកប្រែ អត្ថបទ Alastair Firth, Lars Lange

ប្រភព: www.habr.com