ProHoster > Blog > Pentadbiran > Menjalankan Camunda BPM di Kubernetes

Menjalankan Camunda BPM di Kubernetes

Menjalankan Camunda BPM di Kubernetes

Adakah anda menggunakan Kubernetes? Bersedia untuk mengalihkan kejadian BPM Camunda anda daripada mesin maya, atau mungkin cuba jalankannya pada Kubernetes? Mari lihat beberapa konfigurasi biasa dan item individu yang boleh disesuaikan dengan keperluan khusus anda.

Ia menganggap bahawa anda telah menggunakan Kubernetes sebelum ini. Jika tidak, mengapa tidak lihat panduan dan tidak memulakan kluster pertama anda?

Authors

  • Alastair Firth (Alastair Firth) - Jurutera Kebolehpercayaan Tapak Kanan pada pasukan Awan Camunda;
  • Lars Lange (Lars Lange) - Jurutera DevOps di Camunda.

Secara ringkasnya, maka:

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

Okey, ia mungkin tidak berjaya kerana anda tidak memasang skaffold dan kustomize. Baiklah baca terus!

Apa itu Camunda BPM

Camunda BPM ialah platform pengurusan proses perniagaan sumber terbuka dan platform automasi keputusan yang menghubungkan pengguna perniagaan dan pembangun perisian. Ia sesuai untuk menyelaras dan menghubungkan orang, perkhidmatan (mikro) atau bot! Anda boleh membaca lebih lanjut tentang kes penggunaan yang berbeza di pautan.

Mengapa menggunakan Kubernetes

Kubernetes telah menjadi standard de facto untuk menjalankan aplikasi moden di Linux. Dengan menggunakan panggilan sistem dan bukannya emulasi perkakasan dan keupayaan kernel untuk mengurus memori dan penukaran tugas, masa but dan masa permulaan dikekalkan pada tahap minimum. Walau bagaimanapun, faedah terbesar mungkin datang daripada API standard yang Kubernetes sediakan untuk mengkonfigurasi infrastruktur yang diperlukan oleh semua aplikasi: storan, rangkaian dan pemantauan. Ia berusia 2020 tahun pada Jun 6 dan mungkin merupakan projek sumber terbuka kedua terbesar (selepas Linux). Ia baru-baru ini secara aktif menstabilkan fungsinya selepas lelaran pantas sejak beberapa tahun lalu kerana ia menjadi kritikal kepada beban kerja pengeluaran di seluruh dunia.

Enjin Camunda BPM boleh menyambung dengan mudah ke aplikasi lain yang berjalan pada kluster yang sama, dan Kubernetes menyediakan kebolehskalaan yang sangat baik, membolehkan anda meningkatkan kos infrastruktur hanya apabila benar-benar diperlukan (dan mengurangkannya dengan mudah mengikut keperluan).

Kualiti pemantauan juga bertambah baik dengan alat seperti Prometheus, Grafana, Loki, Fluentd dan Elasticsearch, yang membolehkan anda melihat semua beban kerja secara berpusat dalam kelompok. Hari ini kita akan melihat bagaimana untuk melaksanakan pengeksport Prometheus ke dalam Mesin Maya Java (JVM).

Objektif

Mari lihat beberapa kawasan di mana kita boleh menyesuaikan imej Camunda BPM Docker (github) supaya ia berinteraksi dengan baik dengan Kubernetes.

  1. Log dan metrik;
  2. Sambungan pangkalan data;
  3. Pengesahan;
  4. Pengurusan sesi.

Kami akan melihat beberapa cara untuk mencapai matlamat ini dan menunjukkan keseluruhan proses dengan jelas.

Nota: Adakah anda menggunakan versi Enterprise? Tengok di sini dan kemas kini pautan imej mengikut keperluan.

Pembangunan aliran kerja

Dalam demo ini, kami akan menggunakan Skaffold untuk membina imej Docker menggunakan Google Cloud Build. Ia mempunyai sokongan yang baik untuk pelbagai alatan (seperti Kustomize dan Helm), alat CI dan binaan serta penyedia infrastruktur. Fail skaffold.yaml.tmpl termasuk tetapan untuk Google Cloud Build dan GKE, menyediakan cara yang sangat mudah untuk menjalankan infrastruktur gred pengeluaran.

make skaffold akan memuatkan konteks Dockerfile ke dalam Cloud Build, membina imej dan menyimpannya dalam GCR, dan kemudian menggunakan manifes pada kluster anda. Inilah yang dilakukannya make skaffold, tetapi Skaffold mempunyai banyak ciri lain.

Untuk templat yaml dalam Kubernetes, kami menggunakan kustomize untuk mengurus tindanan yaml tanpa memotong keseluruhan manifes, membolehkan anda menggunakan git pull --rebase untuk penambahbaikan selanjutnya. Kini ia berada dalam kubectl dan ia berfungsi dengan baik untuk perkara sedemikian.

Kami juga menggunakan envsubst untuk mengisi nama hos dan ID projek GCP dalam fail *.yaml.tmpl. Anda boleh melihat bagaimana ia berfungsi makefile atau teruskan sahaja.

Prasyarat

  • Kelompok kerja Kubernetes
  • Sesuaikan
  • Skaffold - untuk mencipta imej docker anda sendiri dan penggunaan mudah ke GKE
  • Salinan kod ini
  • Envsubst

Aliran kerja menggunakan manifes

Jika anda tidak mahu menggunakan kustomize atau skaffold, anda boleh merujuk kepada manifes dalam generated-manifest.yaml dan menyesuaikannya dengan aliran kerja pilihan anda.

Log dan metrik

Prometheus telah menjadi standard untuk mengumpul metrik dalam Kubernetes. Ia menduduki niche yang sama seperti AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics dan lain-lain. Ia adalah sumber terbuka dan mempunyai bahasa pertanyaan yang berkuasa. Kami akan mempercayakan visualisasi kepada Grafana - ia disertakan dengan sejumlah besar papan pemuka yang tersedia di luar kotak. Mereka bersambung antara satu sama lain dan agak mudah untuk dipasang prometheus-operator.

Secara lalai, Prometheus menggunakan model pengekstrakan <service>/metrics, dan menambahkan bekas kereta sampingan untuk ini adalah perkara biasa. Malangnya, metrik JMX paling baik dilog dalam JVM, jadi bekas kereta sampingan tidak begitu cekap. Jom sambung jmx_exporter sumber terbuka dari Prometheus ke JVM dengan menambahkannya pada imej kontena yang akan menyediakan laluan /metrics pada pelabuhan yang berbeza.

Tambahkan Prometheus jmx_exporter pada bekas

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

Nah, itu mudah. Pengeksport akan memantau tomcat dan memaparkan metriknya dalam format Prometheus di <svc>:9404/metrics

Persediaan pengeksport

Pembaca yang penuh perhatian mungkin tertanya-tanya dari mana asalnya prometheus-jmx.yaml? Terdapat banyak perkara berbeza yang boleh dijalankan dalam JVM, dan tomcat hanyalah salah satu daripadanya, jadi pengeksport memerlukan beberapa konfigurasi tambahan. Konfigurasi standard untuk tomcat, wildfly, kafka dan sebagainya tersedia di sini. Kami akan menambah tomcat sebagai Peta Konfigurasi dalam Kubernetes dan kemudian lekapkannya sebagai volum.

Pertama, kami menambah fail konfigurasi pengeksport ke direktori platform/config/ kami

platform/config
└── prometheus-jmx.yaml

Kemudian kita tambah ConfigMapGenerator в kustomization.yaml.tmpl:

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

Ini akan menambah setiap elemen files[] sebagai elemen konfigurasi ConfigMap. ConfigMapGenerators bagus kerana mereka mencincang data konfigurasi dan memaksa pod dimulakan semula jika ia berubah. Ia juga mengurangkan jumlah konfigurasi dalam Deployment kerana anda boleh melekapkan keseluruhan "folder" fail konfigurasi dalam satu VolumeMount.

Akhir sekali, kita perlu memasang ConfigMap sebagai volum ke 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
[...]

Hebat. Jika Prometheus tidak dikonfigurasikan untuk melakukan pembersihan penuh, anda mungkin perlu memberitahunya untuk membersihkan pod. Pengguna Prometheus Operator boleh menggunakan service-monitor.yaml untuk memulakan. Meneroka Service-monitor.yaml, reka bentuk pengendali и ServiceMonitorSpec sebelum awak mula.

Melanjutkan corak ini kepada kes penggunaan lain

Semua fail yang kami tambahkan pada ConfigMapGenerator akan tersedia dalam direktori baharu /etc/config. Anda boleh melanjutkan templat ini untuk memasang sebarang fail konfigurasi lain yang anda perlukan. Anda juga boleh memasang skrip permulaan baharu. Anda boleh gunakan subPath untuk melekapkan fail individu. Untuk mengemas kini fail xml, pertimbangkan untuk menggunakan xmlstarlet bukannya sed. Ia sudah termasuk dalam imej.

Majalah

Berita baik! Log aplikasi sudah tersedia di stdout, contohnya dengan kubectl logs. Fluentd (dipasang secara lalai dalam GKE) akan memajukan log anda ke Elasticsearch, Loki atau platform pengelogan perusahaan anda. Jika anda ingin menggunakan jsonify untuk log maka anda boleh mengikuti templat di atas untuk memasang log masuk.

Pangkalan data

Secara lalai, imej akan mempunyai pangkalan data H2. Ini tidak sesuai untuk kami dan kami akan menggunakan Google Cloud SQL dengan Cloud SQL Proxy - ini akan diperlukan kemudian untuk menyelesaikan masalah dalaman. Ini adalah pilihan yang mudah dan boleh dipercayai jika anda tidak mempunyai pilihan anda sendiri dalam menyediakan pangkalan data. AWS RDS menyediakan perkhidmatan yang serupa.

Tidak kira pangkalan data yang anda pilih, melainkan ia H2, anda perlu menetapkan pembolehubah persekitaran yang sesuai dalam platform/deploy.yaml. Ia kelihatan seperti ini:

-- 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: Anda boleh menggunakan Kustomize untuk digunakan ke persekitaran yang berbeza menggunakan tindanan: contoh.

Nota: penggunaan valueFrom: secretKeyRef. Sila guna ciri Kubernetes ini walaupun semasa pembangunan untuk memastikan rahsia anda selamat.

Kemungkinan anda sudah mempunyai sistem pilihan untuk mengurus rahsia Kubernetes. Jika tidak, berikut ialah beberapa pilihan: Menyulitkannya dengan KMS pembekal awan anda dan kemudian menyuntiknya ke dalam K8S sebagai rahsia melalui saluran paip CD − SOPS Mozilla - akan berfungsi dengan baik dalam kombinasi dengan rahsia Kustomize. Terdapat alat lain, seperti dotGPG, yang melaksanakan fungsi yang serupa: Bilik Kebal HashiCorp, Sesuaikan Pemalam Nilai Rahsia.

Ingress

Melainkan anda memilih untuk menggunakan pemajuan port tempatan, anda memerlukan Pengawal Ingress yang dikonfigurasikan. Jika anda tidak menggunakan masuk-nginx (Carta helm) maka kemungkinan besar anda sudah tahu bahawa anda perlu memasang anotasi yang diperlukan dalam ingress-patch.yaml.tmpl atau platform/ingress.yaml. Jika anda menggunakan ingress-nginx dan melihat kelas ingress nginx dengan pengimbang beban menghala kepadanya dan DNS luaran atau entri DNS kad bebas, anda boleh pergi. Jika tidak, konfigurasikan Pengawal Ingress dan DNS, atau langkau langkah ini dan kekalkan sambungan terus ke pod.

TLS

Sekiranya anda menggunakan pengurus sijil atau kube-lego dan letsencrypt - sijil untuk log masuk baharu akan diperoleh secara automatik. Jika tidak, buka ingress-patch.yaml.tmpl dan menyesuaikannya mengikut keperluan anda.

Pelancaran!

Jika anda mengikuti semua yang ditulis di atas, maka arahannya make skaffold HOSTNAME=<you.example.com> harus melancarkan contoh yang tersedia dalam <hostname>/camunda

Jika anda belum menetapkan log masuk anda kepada URL awam, anda boleh mengubah hala dengannya localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 pada localhost:8080/camunda

Tunggu beberapa minit sehingga tomcat siap sepenuhnya. Pengurus sijil akan mengambil sedikit masa untuk mengesahkan nama domain. Anda kemudian boleh memantau log menggunakan alat yang tersedia seperti alat seperti kubetail, atau hanya menggunakan kubectl:

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

Langkah seterusnya

Kebenaran

Ini lebih berkaitan dengan mengkonfigurasi Camunda BPM daripada Kubernetes, tetapi adalah penting untuk ambil perhatian bahawa secara lalai, pengesahan dilumpuhkan dalam REST API. Awak boleh membolehkan pengesahan asas atau gunakan kaedah lain seperti J.W.T.. Anda boleh menggunakan peta konfigurasi dan jilid untuk memuatkan xml, atau xmlstarlet (lihat di atas) untuk mengedit fail sedia ada dalam imej, dan sama ada menggunakan wget atau memuatkannya menggunakan bekas init dan volum dikongsi.

Pengurusan sesi

Seperti banyak aplikasi lain, Camunda BPM mengendalikan sesi dalam JVM, jadi jika anda ingin menjalankan berbilang replika, anda boleh mendayakan sesi melekit (contohnya untuk ingress-nginx), yang akan wujud sehingga replika itu hilang, atau tetapkan atribut Umur Maks untuk kuki. Untuk penyelesaian yang lebih mantap, anda boleh menggunakan Pengurus Sesi dalam Tomcat. Lars telah jawatan berasingan mengenai topik ini, tetapi sesuatu seperti:

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: anda boleh menggunakan xmlstarlet dan bukannya sed

Kami menggunakan twemproksi di hadapan Google Cloud Memorystore, dengan memcached-session-manager (menyokong Redis) untuk menjalankannya.

Penskalaan

Jika anda sudah memahami sesi, maka had pertama (dan selalunya yang terakhir) untuk menskalakan Camunda BPM mungkin sambungan kepada pangkalan data. Penyesuaian separa sudah tersedia "Dari kotak itu" Mari juga lumpuhkan intialSize dalam fail settings.xml. Tambah Autoscaler Pod Mendatar (HPA) dan anda boleh menskalakan bilangan pod secara automatik.

Permintaan dan sekatan

В platform/deployment.yaml Anda akan melihat bahawa kami telah mengekod keras medan sumber. Ini berfungsi dengan baik dengan HPA, tetapi mungkin memerlukan konfigurasi tambahan. Tampalan kustomize sesuai untuk ini. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl

Output

Jadi kami memasang Camunda BPM pada Kubernetes dengan metrik Prometheus, log, pangkalan data H2, TLS dan Ingress. Kami menambah fail jar dan fail konfigurasi menggunakan ConfigMaps dan Dockerfile. Kami bercakap tentang menukar data kepada volum dan terus kepada pembolehubah persekitaran daripada rahsia. Selain itu, kami memberikan gambaran keseluruhan tentang menyediakan Camunda untuk berbilang replika dan API yang disahkan.

rujukan

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, terjemahan Perkara Alastair Firth, Lars Lange

Sumber: www.habr.com

Tambah komen