โปรโฮสต์ > บล็อก > การบริหาร > ใช้งาน Camunda BPM บน Kubernetes

ใช้งาน Camunda BPM บน Kubernetes

ใช้งาน Camunda BPM บน Kubernetes

คุณใช้ Kubernetes หรือไม่? พร้อมที่จะย้าย Camunda BPM instance ของคุณออกจากเครื่องเสมือนแล้ว หรืออาจลองใช้งานบน Kubernetes ได้แล้ว มาดูการกำหนดค่าทั่วไปและแต่ละรายการที่สามารถปรับแต่งให้เหมาะกับความต้องการเฉพาะของคุณได้

จะถือว่าคุณเคยใช้ Kubernetes มาก่อน ถ้าไม่ทำไมไม่ลองดู ความเป็นผู้นำ และไม่เริ่มคลัสเตอร์แรกของคุณใช่ไหม

ผู้เขียน

ในระยะสั้น:

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 ได้กลายเป็นมาตรฐานสำหรับการใช้งานแอปพลิเคชันสมัยใหม่บน Linux ด้วยการใช้การเรียกระบบแทนการจำลองฮาร์ดแวร์และความสามารถของเคอร์เนลในการจัดการหน่วยความจำและการสลับงาน เวลาบูตและเวลาเริ่มต้นระบบจะถูกเก็บไว้ให้น้อยที่สุด อย่างไรก็ตาม ประโยชน์สูงสุดอาจมาจาก API มาตรฐานที่ Kubernetes มอบให้เพื่อกำหนดค่าโครงสร้างพื้นฐานที่จำเป็นสำหรับแอปพลิเคชันทั้งหมด ได้แก่ พื้นที่เก็บข้อมูล เครือข่าย และการตรวจสอบ มีอายุครบ 2020 ปีในเดือนมิถุนายน 6 และอาจเป็นโครงการโอเพ่นซอร์สที่ใหญ่เป็นอันดับสอง (รองจาก Linux) เมื่อเร็วๆ นี้บริษัทได้รักษาเสถียรภาพการทำงานอย่างแข็งขันหลังจากการทำซ้ำอย่างรวดเร็วในช่วงไม่กี่ปีที่ผ่านมา เนื่องจากกลายเป็นเรื่องสำคัญต่อปริมาณงานการผลิตทั่วโลก

Camunda BPM Engine สามารถเชื่อมต่อกับแอปพลิเคชันอื่นๆ ที่ทำงานบนคลัสเตอร์เดียวกันได้อย่างง่ายดาย และ Kubernetes มอบความสามารถในการปรับขนาดที่ยอดเยี่ยม ช่วยให้คุณเพิ่มต้นทุนโครงสร้างพื้นฐานเมื่อจำเป็นจริงๆ เท่านั้น (และลดค่าใช้จ่ายได้อย่างง่ายดายตามความจำเป็น)

คุณภาพของการตรวจสอบยังได้รับการปรับปรุงอย่างมากด้วยเครื่องมือต่างๆ เช่น Prometheus, Grafana, Loki, Fluentd และ Elasticsearch ซึ่งช่วยให้คุณสามารถดูปริมาณงานทั้งหมดในคลัสเตอร์จากส่วนกลางได้ วันนี้เราจะมาดูวิธีการใช้ Prometheus Exporter ใน 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 ลงใน Cloud Build สร้างอิมเมจและจัดเก็บไว้ใน GCR จากนั้นใช้ไฟล์ Manifest กับคลัสเตอร์ของคุณ นี่คือสิ่งที่มันทำ make skaffoldแต่ Skaffold มีคุณสมบัติอื่นๆ อีกมากมาย

สำหรับเทมเพลต yaml ใน Kubernetes เราใช้ kustomize เพื่อจัดการการซ้อนทับ yaml โดยไม่ต้องแยกไฟล์ Manifest ทั้งหมด ซึ่งทำให้คุณสามารถใช้ git pull --rebase เพื่อการปรับปรุงเพิ่มเติม ตอนนี้มันอยู่ใน kubectl และใช้งานได้ค่อนข้างดีสำหรับสิ่งเหล่านี้

นอกจากนี้เรายังใช้ envsubst เพื่อเติมชื่อโฮสต์และรหัสโปรเจ็กต์ GCP ในไฟล์ *.yaml.tmpl คุณสามารถดูวิธีการทำงานได้ใน makefile หรือเพียงแค่ดำเนินการต่อไป

ข้อกำหนดเบื้องต้น

  • คลัสเตอร์การทำงาน Kubernetes
  • ปรับแต่ง
  • นั่งร้าน - สำหรับการสร้างอิมเมจนักเทียบท่าของคุณเองและปรับใช้กับ GKE ได้อย่างง่ายดาย
  • สำเนารหัสนี้
  • สารบัญ

เวิร์กโฟลว์โดยใช้รายการ

หากคุณไม่ต้องการใช้ kustomize หรือ skaffold คุณสามารถอ้างถึงไฟล์ Manifest ได้ generated-manifest.yaml และปรับให้เข้ากับขั้นตอนการทำงานที่คุณเลือก

บันทึกและตัวชี้วัด

Prometheus ได้กลายเป็นมาตรฐานสำหรับการรวบรวมตัววัดใน Kubernetes โดยอยู่ในกลุ่มเดียวกับ AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics และอื่นๆ เป็นโอเพ่นซอร์สและมีภาษาคิวรีที่ทรงพลัง เราจะมอบความไว้วางใจให้กับ Grafana ซึ่งมาพร้อมกับแดชบอร์ดจำนวนมากที่พร้อมใช้งานทันที เชื่อมต่อถึงกันและติดตั้งง่าย โพรมีธีอุสโอเปอเรเตอร์.

ตามค่าเริ่มต้น Prometheus จะใช้โมเดลการแยกข้อมูล <service>/metricsและการเพิ่มตู้คอนเทนเนอร์สำหรับสิ่งนี้เป็นเรื่องปกติ น่าเสียดายที่ตัววัด JMX ได้รับการบันทึกไว้ดีที่สุดภายใน JVM ดังนั้นคอนเทนเนอร์ไซด์คาร์จึงไม่มีประสิทธิภาพเท่าที่ควร มาเชื่อมต่อกัน 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/ ของเรา

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 มีประโยชน์มากเนื่องจากจะแฮชข้อมูลการกำหนดค่าและบังคับให้พ็อดรีสตาร์ทหากมีการเปลี่ยนแปลง นอกจากนี้ยังลดจำนวนการกำหนดค่าในการปรับใช้เนื่องจากคุณสามารถเมานต์ "โฟลเดอร์" ทั้งหมดของไฟล์การกำหนดค่าได้ใน 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.xml แทนที่จะเป็น 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 Secrets มีเครื่องมืออื่นๆ เช่น dotGPG ที่ทำหน้าที่คล้ายกัน: ห้องนิรภัย HashiCorp, ปรับแต่งปลั๊กอินค่าลับ.

สิทธิในการเข้า

ยกเว้นกรณีที่คุณเลือกใช้การส่งต่อพอร์ตภายในเครื่อง คุณจะต้องมี Ingress Controller ที่กำหนดค่าไว้ ถ้าไม่ใช้ ทางเข้า-nginx (แผนภูมิหางเสือ) คุณน่าจะรู้อยู่แล้วว่าจำเป็นต้องติดตั้งคำอธิบายประกอบที่จำเป็น ingress-patch.yaml.tmpl หรือ platform/ingress.yaml. หากคุณใช้ ingress-nginx และเห็นคลาสทางเข้า nginx ที่มีโหลดบาลานเซอร์ชี้ไปที่คลาสนั้น และ DNS ภายนอกหรือรายการ DNS แบบ wildcard คุณก็พร้อมแล้ว มิฉะนั้น ให้กำหนดค่า Ingress Controller และ DNS หรือข้ามขั้นตอนเหล่านี้และคงการเชื่อมต่อโดยตรงกับพ็อดไว้

TLS

หากคุณกำลังใช้ ใบรับรองผู้จัดการ หรือ kube-lego และ Letencrypt - ใบรับรองสำหรับการเข้าสู่ระบบใหม่จะได้รับโดยอัตโนมัติ มิฉะนั้นให้เปิด 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

รอสักครู่จนกว่าแมวตัวผู้จะพร้อมอย่างสมบูรณ์ ผู้จัดการใบรับรองจะใช้เวลาสักครู่ในการตรวจสอบชื่อโดเมน จากนั้น คุณสามารถตรวจสอบบันทึกโดยใช้เครื่องมือที่มีอยู่ เช่น เครื่องมืออย่าง kubetail หรือเพียงแค่ใช้ kubectl:

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

ขั้นตอนถัดไป

การอนุญาต

สิ่งนี้เกี่ยวข้องกับการกำหนดค่า Camunda BPM มากกว่า Kubernetes แต่สิ่งสำคัญที่ควรทราบคือตามค่าเริ่มต้น การรับรองความถูกต้องจะถูกปิดใช้งานใน REST API คุณสามารถ เปิดใช้งานการรับรองความถูกต้องขั้นพื้นฐาน หรือใช้วิธีอื่นเช่น จว. คุณสามารถใช้ configmaps และวอลุ่มเพื่อโหลด xml หรือ xmlstarlet (ดูด้านบน) เพื่อแก้ไขไฟล์ที่มีอยู่ในรูปภาพ และใช้ wget หรือโหลดโดยใช้คอนเทนเนอร์เริ่มต้นและวอลุ่มที่ใช้ร่วมกัน

การจัดการเซสชัน

เช่นเดียวกับแอปพลิเคชันอื่นๆ 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

เราใช้ ทูมพรอกซี ที่ด้านหน้า Google Cloud Memorystore พร้อมด้วย memcached-เซสชันผู้จัดการ (รองรับ Redis) เพื่อเรียกใช้

มาตราส่วน

หากคุณเข้าใจเซสชันอยู่แล้ว ข้อจำกัดแรก (และมักจะเป็นครั้งสุดท้าย) ในการปรับขนาด Camunda BPM อาจเป็นการเชื่อมต่อกับฐานข้อมูล การปรับแต่งบางส่วนมีอยู่แล้ว "จากกล่อง" มาปิดการใช้งาน intialSize ในไฟล์ settings.xml ด้วย เพิ่ม ตัวปรับขนาดพ็อดแนวนอนอัตโนมัติ (HPA) และคุณสามารถปรับขนาดจำนวนพ็อดโดยอัตโนมัติได้อย่างง่ายดาย

คำขอและข้อจำกัด

В platform/deployment.yaml คุณจะเห็นว่าเราได้ฮาร์ดโค้ดฟิลด์ทรัพยากรแล้ว ซึ่งทำงานได้ดีกับ HPA แต่อาจต้องมีการกำหนดค่าเพิ่มเติม แพทช์ปรับแต่งเองเหมาะสำหรับสิ่งนี้ ซม. 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 แปล บทความ อลาสแตร์ เฟิร์ธ, ลาร์ส แลงจ์

ที่มา: will.com

เพิ่มความคิดเห็น