ແລ່ນ Camunda BPM ໃນ Kubernetes

ເຈົ້າໃຊ້ Kubernetes ບໍ? ພ້ອມແລ້ວທີ່ຈະຍ້າຍຕົວຢ່າງ Camunda BPM ຂອງທ່ານອອກຈາກເຄື່ອງ virtual, ຫຼືບາງທີພຽງແຕ່ລອງໃຊ້ພວກມັນຢູ່ໃນ Kubernetes ບໍ? ໃຫ້ເບິ່ງຢູ່ໃນບາງການຕັ້ງຄ່າທົ່ວໄປແລະລາຍການສ່ວນບຸກຄົນທີ່ສາມາດປັບແຕ່ງໄດ້ຕາມຄວາມຕ້ອງການສະເພາະຂອງທ່ານ.

ມັນສົມມຸດວ່າທ່ານເຄີຍໃຊ້ Kubernetes ມາກ່ອນ. ຖ້າບໍ່ແມ່ນ, ເປັນຫຍັງບໍ່ເບິ່ງ ຄູ່ມື ແລະບໍ່ເລີ່ມຕົ້ນກຸ່ມທໍາອິດຂອງເຈົ້າບໍ?

ຜູ້ຂຽນ

• Alastair Firth (Alastair Firth) - ວິສະວະກອນຄວາມຫນ້າເຊື່ອຖືຂອງເວັບໄຊອາວຸໂສໃນທີມງານ Camunda Cloud;
• Lars Lange (Lars Lange) - ວິສະວະກອນ DevOps ຢູ່ Camunda.

ໃນສັ້ນ:

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


ຕົກລົງ, ມັນອາດຈະບໍ່ເຮັດວຽກເພາະວ່າທ່ານບໍ່ມີ skaffold ແລະ customize ຕິດຕັ້ງ. ແລ້ວອ່ານຕໍ່!

Camunda BPM ແມ່ນຫຍັງ

Camunda BPM ເປັນແຫຼ່ງເປີດຂະບວນການບໍລິຫານທຸລະກິດ ແລະເວທີການຕັດສິນໃຈອັດຕະໂນມັດທີ່ເຊື່ອມຕໍ່ຜູ້ໃຊ້ທຸລະກິດ ແລະນັກພັດທະນາຊອບແວ. ມັນແມ່ນເຫມາະສົມສໍາລັບການປະສານງານແລະການເຊື່ອມຕໍ່ປະຊາຊົນ, (ຈຸລະພາກ) ບໍລິການຫຼືແມ້ກະທັ້ງ bots! ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບກໍລະນີການນໍາໃຊ້ທີ່ແຕກຕ່າງກັນທີ່ ການເຊື່ອມຕໍ່.

ເປັນຫຍັງຕ້ອງໃຊ້ Kubernetes

Kubernetes ໄດ້ກາຍເປັນມາດຕະຖານທີ່ແທ້ຈິງສໍາລັບການແລ່ນຄໍາຮ້ອງສະຫມັກທີ່ທັນສະໄຫມໃນ Linux. ໂດຍການນໍາໃຊ້ການໂທລະບົບແທນທີ່ຈະເປັນການຈໍາລອງຮາດແວແລະຄວາມສາມາດຂອງ kernel ໃນການຈັດການຫນ່ວຍຄວາມຈໍາແລະການສັບປ່ຽນຫນ້າວຽກ, ເວລາບູດແລະເວລາເລີ່ມຕົ້ນແມ່ນເກັບໄວ້ເປັນຕໍາ່ສຸດທີ່. ຢ່າງໃດກໍ່ຕາມ, ຜົນປະໂຫຍດທີ່ໃຫຍ່ທີ່ສຸດອາດຈະມາຈາກ API ມາດຕະຖານທີ່ Kubernetes ສະຫນອງໃຫ້ເພື່ອກໍານົດໂຄງສ້າງພື້ນຖານທີ່ຕ້ອງການໂດຍທຸກຄໍາຮ້ອງສະຫມັກ: ການເກັບຮັກສາ, ເຄືອຂ່າຍ, ແລະການຕິດຕາມ. ມັນມີອາຍຸ 2020 ປີໃນເດືອນມິຖຸນາ 6 ແລະບາງທີອາດຈະເປັນໂຄງການແຫຼ່ງເປີດທີ່ໃຫຍ່ທີ່ສຸດທີສອງ (ຫຼັງຈາກ Linux). ບໍ່ດົນມານີ້, ມັນໄດ້ຖືກປັບປຸງຢ່າງຫ້າວຫັນໃນການທໍາງານຂອງຕົນຫຼັງຈາກ iteration ຢ່າງໄວວາໃນໄລຍະສອງສາມປີຜ່ານມາຍ້ອນວ່າມັນກາຍເປັນສິ່ງສໍາຄັນຕໍ່ວຽກງານການຜະລິດໃນທົ່ວໂລກ.

Camunda BPM Engine ສາມາດເຊື່ອມຕໍ່ກັບແອັບພລິເຄຊັນອື່ນໆທີ່ເຮັດວຽກຢູ່ໃນກຸ່ມດຽວກັນໄດ້ຢ່າງງ່າຍດາຍ, ແລະ Kubernetes ສະຫນອງການຂະຫຍາຍທີ່ດີ, ຊ່ວຍໃຫ້ທ່ານສາມາດເພີ່ມຄ່າໃຊ້ຈ່າຍໃນພື້ນຖານໂຄງລ່າງພຽງແຕ່ເມື່ອຕ້ອງການແທ້ໆ (ແລະຫຼຸດຜ່ອນພວກມັນໄດ້ງ່າຍຕາມຄວາມຕ້ອງການ).

ຄຸນະພາບຂອງການຕິດຕາມຍັງໄດ້ຮັບການປັບປຸງຢ່າງຫຼວງຫຼາຍດ້ວຍເຄື່ອງມືເຊັ່ນ Prometheus, Grafana, Loki, Fluentd ແລະ Elasticsearch, ຊ່ວຍໃຫ້ທ່ານສາມາດເບິ່ງວຽກທັງຫມົດໃນກຸ່ມເປັນສູນກາງ. ມື້ນີ້ພວກເຮົາຈະເບິ່ງວິທີການປະຕິບັດການສົ່ງອອກ Prometheus ເຂົ້າໄປໃນ Java Virtual Machine (JVM).

ຈຸດປະສົງ

ໃຫ້ເບິ່ງບາງພື້ນທີ່ທີ່ພວກເຮົາສາມາດປັບແຕ່ງຮູບພາບ Camunda BPM Docker (GitHub) ເພື່ອໃຫ້ມັນພົວພັນກັບ Kubernetes ໄດ້ດີ.

1. ບັນທຶກແລະການວັດແທກ;
2. ການເຊື່ອມຕໍ່ຖານຂໍ້ມູນ;
3. ການຢັ້ງຢືນ;
4. ການຈັດການເຊດຊັນ.

ພວກເຮົາຈະເບິ່ງວິທີການຈໍານວນຫນຶ່ງເພື່ອບັນລຸເປົ້າຫມາຍເຫຼົ່ານີ້ແລະສະແດງໃຫ້ເຫັນຢ່າງຈະແຈ້ງຂະບວນການທັງຫມົດ.

Примечание: ເຈົ້າໃຊ້ສະບັບ Enterprise ບໍ? ເບິ່ງ ທີ່ນີ້ ແລະປັບປຸງການເຊື່ອມຕໍ່ຮູບພາບຕາມຄວາມຕ້ອງການ.

ການພັດທະນາຂະບວນການເຮັດວຽກ

ໃນການສາທິດນີ້, ພວກເຮົາຈະໃຊ້ Skaffold ເພື່ອສ້າງຮູບພາບ Docker ໂດຍໃຊ້ Google Cloud Build. ມັນມີການສະຫນັບສະຫນູນທີ່ດີສໍາລັບເຄື່ອງມືຕ່າງໆ (ເຊັ່ນ Kustomize ແລະ Helm), CI ແລະສ້າງເຄື່ອງມື, ແລະຜູ້ໃຫ້ບໍລິການດ້ານໂຄງສ້າງພື້ນຖານ. ໄຟລ໌ skaffold.yaml.tmpl ລວມມີການຕັ້ງຄ່າສໍາລັບ Google Cloud Build ແລະ GKE, ສະຫນອງວິທີການງ່າຍດາຍຫຼາຍເພື່ອດໍາເນີນການໂຄງສ້າງພື້ນຖານລະດັບການຜະລິດ.

make skaffold ຈະໂຫລດ Dockerfile context ເຂົ້າໄປໃນ Cloud Build, ສ້າງຮູບພາບແລະເກັບໄວ້ໃນ GCR, ແລະຫຼັງຈາກນັ້ນນໍາໃຊ້ manifests ກັບ cluster ຂອງທ່ານ. ນີ້ແມ່ນສິ່ງທີ່ມັນເຮັດ make skaffold, ແຕ່ Skaffold ມີລັກສະນະອື່ນໆຈໍານວນຫຼາຍ.

ສໍາລັບແມ່ແບບ yaml ໃນ Kubernetes, ພວກເຮົາໃຊ້ kustomize ເພື່ອຈັດການການວາງຊ້ອນ yaml ໂດຍບໍ່ມີການ forking manifest ທັງຫມົດ, ໃຫ້ທ່ານສາມາດນໍາໃຊ້. git pull --rebase ສໍາລັບການປັບປຸງຕື່ມອີກ. ໃນປັດຈຸບັນມັນຢູ່ໃນ kubectl ແລະມັນເຮັດວຽກໄດ້ດີສໍາລັບສິ່ງດັ່ງກ່າວ.

ພວກເຮົາຍັງໃຊ້ envsubst ເພື່ອຕື່ມຂໍ້ມູນຊື່ໂຮສ ແລະ ID ໂຄງການ GCP ໃນໄຟລ໌ *.yaml.tmpl. ທ່ານສາມາດເບິ່ງວິທີການເຮັດວຽກຢູ່ໃນ makefile ຫຼືພຽງແຕ່ສືບຕໍ່ຕື່ມອີກ.

ເງື່ອນໄຂທີ່ ຈຳ ເປັນ

• ກຸ່ມວຽກ Kubernetes
• ປັບແຕ່ງ
• Skaffold - ສໍາລັບການສ້າງຮູບພາບ docker ຂອງທ່ານເອງແລະງ່າຍທີ່ຈະນໍາໃຊ້ກັບ GKE
• ສຳເນົາລະຫັດນີ້
• Envsubst

ຂັ້ນຕອນການເຮັດວຽກໂດຍໃຊ້ manifests

ຖ້າທ່ານບໍ່ຕ້ອງການໃຊ້ kustomize ຫຼື skaffold, ທ່ານສາມາດອ້າງອີງເຖິງ manifests ໃນ generated-manifest.yaml ແລະປັບໃຫ້ເຂົາເຈົ້າກັບຂະບວນການເຮັດວຽກທີ່ທ່ານເລືອກ.

ບັນທຶກແລະການວັດແທກ

Prometheus ໄດ້ກາຍເປັນມາດຕະຖານສໍາລັບການເກັບກໍາ metrics ໃນ Kubernetes. ມັນຄອບຄອງ niche ດຽວກັນກັບ AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics ແລະອື່ນໆ. ມັນເປັນແຫຼ່ງເປີດແລະມີພາສາສອບຖາມທີ່ມີປະສິດທິພາບ. ພວກເຮົາຈະມອບສາຍຕາໃຫ້ກັບ Grafana - ມັນມາພ້ອມກັບ dashboards ຈໍານວນຫລາຍທີ່ມີຢູ່ໃນກ່ອງ. ພວກເຂົາເຈົ້າໄດ້ຖືກເຊື່ອມຕໍ່ກັບກັນແລະກັນແລະຂ້ອນຂ້າງງ່າຍທີ່ຈະຕິດຕັ້ງກັບ prometheus-operator.

ໂດຍຄ່າເລີ່ມຕົ້ນ, Prometheus ໃຊ້ຮູບແບບການສະກັດເອົາ <service>/metrics, ແລະການເພີ່ມຕູ້ຄອນເທນເນີ sidecar ສໍາລັບການນີ້ແມ່ນທົ່ວໄປ. ແຕ່ຫນ້າເສຍດາຍ, JMX metrics ແມ່ນຖືກບັນທຶກທີ່ດີທີ່ສຸດພາຍໃນ 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 ແລະສະແດງ metrics ຂອງມັນໃນຮູບແບບ Prometheus ຢູ່ <svc>:9404/metrics

ຕັ້ງຄ່າຕົວສົ່ງອອກ

ຜູ້ອ່ານທີ່ເອົາໃຈໃສ່ອາດຈະສົງໄສວ່າມັນມາຈາກໃສ prometheus-jmx.yaml? ມີຫຼາຍສິ່ງທີ່ແຕກຕ່າງກັນທີ່ສາມາດດໍາເນີນການໃນ JVM, ແລະ tomcat ແມ່ນພຽງແຕ່ຫນຶ່ງໃນນັ້ນ, ດັ່ງນັ້ນຜູ້ສົ່ງອອກຕ້ອງການບາງການຕັ້ງຄ່າເພີ່ມເຕີມ. ການຕັ້ງຄ່າມາດຕະຖານສໍາລັບ tomcat, wildfly, kafka ແລະອື່ນໆແມ່ນມີຢູ່ ທີ່ນີ້. ພວກເຮົາຈະເພີ່ມ tomcat ເປັນ ConfigMap ໃນ Kubernetes ແລະຫຼັງຈາກນັ້ນ mount ມັນເປັນປະລິມານ.

ທໍາອິດ, ພວກເຮົາເພີ່ມໄຟລ໌ການຕັ້ງຄ່າຜູ້ສົ່ງອອກໄປຍັງເວທີ / config / ໄດເລກະທໍລີຂອງພວກເຮົາ

platform/config
└── prometheus-jmx.yaml


ຫຼັງຈາກນັ້ນ, ພວກເຮົາເພີ່ມ ConfigMapGenerator в 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 ຂໍ້ມູນການຕັ້ງຄ່າແລະບັງຄັບໃຫ້ pod restart ຖ້າມັນມີການປ່ຽນແປງ. ພວກເຂົາເຈົ້າຍັງຫຼຸດຜ່ອນຈໍານວນການຕັ້ງຄ່າໃນ Deployment ນັບຕັ້ງແຕ່ທ່ານສາມາດ mount "ໂຟນເດີ" ທັງຫມົດຂອງໄຟລ໌ການຕັ້ງຄ່າໃນ VolumeMount.

ສຸດທ້າຍ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຕິດຕັ້ງ ConfigMap ເປັນປະລິມານກັບ 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
[...]

ອັດສະຈັນ. ຖ້າ 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 ເປັນຄວາມລັບຜ່ານທໍ່ CD − Mozilla SOPS - ຈະເຮັດວຽກໄດ້ດີຫຼາຍໃນການປະສົມປະສານກັບຄວາມລັບ Kustomize. ມີເຄື່ອງມືອື່ນໆ, ເຊັ່ນ: dotGPG, ທີ່ປະຕິບັດຫນ້າທີ່ຄ້າຍຄືກັນ: HashiCorp Vault, ປັບແຕ່ງ Plugins ມູນຄ່າລັບ.

Ingress

ເວັ້ນເສຍແຕ່ວ່າທ່ານເລືອກທີ່ຈະໃຊ້ການສົ່ງຕໍ່ພອດທ້ອງຖິ່ນ, ທ່ານຈະຕ້ອງມີ Ingress Controller ທີ່ກໍາຫນົດຄ່າ. ຖ້າເຈົ້າບໍ່ໃຊ້ ingress-nginx (ຕາຕະລາງຫມວກກັນກະທົບ) ຫຼັງຈາກນັ້ນທ່ານອາດຈະຮູ້ແລ້ວວ່າທ່ານຈໍາເປັນຕ້ອງຕິດຕັ້ງຄໍາບັນຍາຍທີ່ຈໍາເປັນໃນ ingress-patch.yaml.tmpl ຫຼື platform/ingress.yaml. ຖ້າທ່ານກໍາລັງໃຊ້ ingress-nginx ແລະເບິ່ງຫ້ອງຮຽນ ingress nginx ທີ່ມີ load balancer ຊີ້ໄປຫາມັນແລະ DNS ພາຍນອກຫຼື wildcard DNS entry, ທ່ານດີທີ່ຈະໄປ. ຖ້າບໍ່ດັ່ງນັ້ນ, ຕັ້ງຄ່າ Ingress Controller ແລະ DNS, ຫຼືຂ້າມຂັ້ນຕອນເຫຼົ່ານີ້ແລະຮັກສາການເຊື່ອມຕໍ່ໂດຍກົງກັບ pod.

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 ແລະປະລິມານເພື່ອໂຫລດ xml, ຫຼື xmlstarlet (ເບິ່ງຂ້າງເທິງ) ເພື່ອແກ້ໄຂໄຟລ໌ທີ່ມີຢູ່ໃນຮູບພາບ, ແລະບໍ່ວ່າຈະໃຊ້ wget ຫຼືໂຫຼດໃຫ້ເຂົາເຈົ້າໂດຍໃຊ້ init container ແລະປະລິມານທີ່ແບ່ງປັນ.

ການຈັດການເຊດຊັນ

ເຊັ່ນດຽວກັນກັບຄໍາຮ້ອງສະຫມັກອື່ນໆຈໍານວນຫຼາຍ, Camunda BPM ຈັດການເຊດຊັນໃນ JVM, ດັ່ງນັ້ນຖ້າທ່ານຕ້ອງການດໍາເນີນການ replicas ຫຼາຍ, ທ່ານສາມາດເປີດໃຊ້ກອງປະຊຸມຫນຽວ (ຕົວຢ່າງສໍາລັບ ingress-nginx), ເຊິ່ງຈະມີຈົນກ່ວາການຈໍາລອງຈະຫາຍໄປ, ຫຼືກໍານົດຄຸນສົມບັດ Max-Age ສໍາລັບ cookies. ສໍາລັບການແກ້ໄຂທີ່ເຂັ້ມແຂງກວ່າ, ທ່ານສາມາດປັບໃຊ້ Session Manager ໃນ Tomcat. Lars ມີ ຕອບແຍກຕ່າງຫາກ ກ່ຽວກັບຫົວຂໍ້ນີ້, ແຕ່ບາງສິ່ງບາງຢ່າງເຊັ່ນ:

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-manage (ສະ​ຫນັບ​ສະ​ຫນູນ Redis​) ເພື່ອ​ດໍາ​ເນີນ​ການ​ມັນ​.

ການປັບຂະໜາດ

ຖ້າທ່ານເຂົ້າໃຈກອງປະຊຸມແລ້ວ, ທໍາອິດ (ແລະເລື້ອຍໆສຸດທ້າຍ) ການຈໍາກັດການຂະຫຍາຍ Camunda BPM ອາດຈະເປັນການເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນ. ການປັບແຕ່ງບາງສ່ວນແມ່ນມີຢູ່ແລ້ວ "ຈາກຫ້ອງດັ່ງກ່າວ" ໃຫ້ປິດການໃຊ້ງານ intialSize ໃນໄຟລ໌ settings.xml. ເພີ່ມ Horizontal Pod Autoscaler (HPA) ແລະທ່ານໄດ້ຢ່າງງ່າຍດາຍສາມາດຂະຫຍາຍຈໍານວນຂອງຝັກໄດ້.

ການຮ້ອງຂໍແລະຂໍ້ຈໍາກັດ

В platform/deployment.yaml ທ່ານ​ຈະ​ເຫັນ​ວ່າ​ພວກ​ເຮົາ​ໄດ້​ຍາກ​ລະ​ຫັດ​ພາກ​ສະ​ຫນາມ​ຊັບ​ພະ​ຍາ​ກອນ​. ອັນນີ້ໃຊ້ໄດ້ດີກັບ HPA, ແຕ່ອາດຈະຕ້ອງການການຕັ້ງຄ່າເພີ່ມເຕີມ. ແຜ່ນ customize ແມ່ນເຫມາະສົມສໍາລັບການນີ້. ຊັງ​ຕີ​ແມັດ. 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