اجرای Camunda BPM در Kubernetes

اجرای Camunda BPM در Kubernetes

آیا از Kubernetes استفاده می کنید؟ آیا آماده‌اید نمونه‌های Camunda BPM خود را از ماشین‌های مجازی خارج کنید، یا شاید فقط سعی کنید آنها را در Kubernetes اجرا کنید؟ بیایید به برخی از پیکربندی‌های متداول و موارد فردی که می‌توانند با نیازهای خاص شما تنظیم شوند، نگاهی بیاندازیم.

فرض بر این است که قبلا از Kubernetes استفاده کرده اید. اگر نه، چرا به آن نگاه نکنید رهبری و اولین خوشه خود را شروع نکنید؟

نویسنده

  • آلستر فرث (Alastair Firth) - مهندس ارشد قابلیت اطمینان سایت در تیم Camunda Cloud.
  • لارس لانگ (لارس لانگ) - مهندس DevOps در کاموندا.

به طور خلاصه، پس:

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

بسیار خوب، احتمالاً کار نمی کند زیرا شما skaffold و kustomize را نصب نکرده اید. خوب پس ادامه مطلب را بخوانید!

کاموندا BPM چیست؟

Camunda BPM یک پلت فرم مدیریت فرآیند کسب و کار و اتوماسیون تصمیم گیری منبع باز است که کاربران تجاری و توسعه دهندگان نرم افزار را به هم متصل می کند. این برای هماهنگی و اتصال افراد، خدمات (میکرو) یا حتی ربات ها ایده آل است! می توانید در مورد موارد استفاده مختلف بیشتر بخوانید پیوند.

چرا از Kubernetes استفاده کنید

Kubernetes به استاندارد واقعی برای اجرای برنامه های کاربردی مدرن در لینوکس تبدیل شده است. با استفاده از تماس های سیستمی به جای شبیه سازی سخت افزاری و توانایی هسته برای مدیریت حافظه و سوئیچینگ وظایف، زمان بوت و زمان راه اندازی به حداقل می رسد. با این حال، بزرگترین مزیت ممکن است از API استانداردی حاصل شود که Kubernetes برای پیکربندی زیرساخت مورد نیاز همه برنامه ها ارائه می دهد: ذخیره سازی، شبکه و نظارت. این پروژه در ژوئن 2020 6 ساله شد و شاید دومین پروژه بزرگ منبع باز (پس از لینوکس) باشد. اخیراً به طور فعال عملکرد خود را پس از تکرار سریع در چند سال گذشته تثبیت کرده است زیرا برای حجم کاری تولید در سراسر جهان بسیار مهم است.

Camunda BPM Engine می‌تواند به راحتی به سایر برنامه‌های در حال اجرا در همان کلاستر متصل شود و Kubernetes مقیاس‌پذیری عالی را ارائه می‌کند و به شما امکان می‌دهد هزینه‌های زیرساخت را تنها در صورت نیاز افزایش دهید (و به راحتی آن‌ها را در صورت نیاز کاهش دهید).

کیفیت مانیتورینگ نیز با ابزارهایی مانند Prometheus، Grafana، Loki، Fluentd و Elasticsearch بسیار بهبود یافته است و به شما این امکان را می‌دهد تا به صورت متمرکز همه بارهای کاری را در یک کلاستر مشاهده کنید. امروز به نحوه پیاده سازی صادرکننده Prometheus در ماشین مجازی جاوا (JVM) خواهیم پرداخت.

اهداف

بیایید به چند منطقه نگاه کنیم که در آن می‌توانیم تصویر Camunda BPM Docker را سفارشی کنیم (گیتهاب) به طوری که به خوبی با 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 ذخیره می‌کند و سپس مانیفست‌ها را در خوشه شما اعمال می‌کند. این کاری است که انجام می دهد make skaffold، اما Skaffold دارای بسیاری از ویژگی های دیگر است.

برای الگوهای yaml در Kubernetes، ما از kustomize برای مدیریت همپوشانی‌های yaml بدون جدا کردن کل مانیفست استفاده می‌کنیم و به شما امکان می‌دهد از آن استفاده کنید. git pull --rebase برای بهبودهای بیشتر الان تو kubectl هست و برای اینجور چیزا خیلی خوب جواب میده.

ما همچنین از envsubst برای پر کردن نام میزبان و شناسه پروژه GCP در فایل های *.yaml.tmpl استفاده می کنیم. می توانید ببینید که چگونه کار می کند makefile یا فقط ادامه دهید

پیش نیازها

گردش کار با استفاده از مانیفست

اگر نمی خواهید از kustomize یا skaffold استفاده کنید، می توانید به مانیفست در مراجعه کنید 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

خوب، این آسان بود. صادرکننده تامکت را رصد می کند و معیارهای آن را در قالب پرومتئوس نشان می دهد <svc>:9404/metrics

راه اندازی صادرکننده

خواننده با دقت ممکن است تعجب کند که از کجا آمده است prometheus-jmx.yaml? چیزهای مختلفی می توانند در JVM اجرا شوند و تامکت تنها یکی از آنهاست، بنابراین صادرکننده به پیکربندی اضافی نیاز دارد. تنظیمات استاندارد برای گربه تام، مگس وحشی، کافکا و غیره در دسترس هستند اینجا. ما تامکت را به عنوان اضافه خواهیم کرد 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 عالی هستند زیرا داده های پیکربندی را هش می کنند و در صورت تغییر یک پاد را مجبور به راه اندازی مجدد می کنند. آنها همچنین مقدار پیکربندی در Deployment را کاهش می دهند زیرا می توانید کل "پوشه" فایل های پیکربندی را در یک VolumeMount قرار دهید.

در نهایت، ما باید ConfigMap را به عنوان یک حجم به pod mount کنیم:

-- 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 - موزیلا SOPS - در ترکیب با رازهای Kustomize بسیار خوب کار خواهد کرد. ابزارهای دیگری مانند dotGPG وجود دارد که عملکردهای مشابهی را انجام می دهد: خرک HashiCorp, سفارشی کردن پلاگین های مخفی ارزش.

ورود

مگر اینکه بخواهید از حمل و نقل پورت محلی استفاده کنید، به یک کنترلر ورودی پیکربندی شده نیاز دارید. اگر استفاده نمی کنید ingress-nginx (نمودار هلم) پس به احتمال زیاد قبلاً می دانید که باید حاشیه نویسی های لازم را در آن نصب کنید ingress-patch.yaml.tmpl یا platform/ingress.yaml. اگر از ingress-nginx استفاده می‌کنید و کلاس ورودی nginx را می‌بینید که یک بار متعادل کننده به آن اشاره می‌کند و یک DNS خارجی یا ورودی DNS wildcard، خوب هستید. در غیر این صورت، 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

چند دقیقه صبر کنید تا تامکت کاملا آماده شود. Cert-manager مدتی طول می کشد تا نام دامنه را تأیید کند. سپس می‌توانید گزارش‌ها را با استفاده از ابزارهای موجود مانند ابزاری مانند kubetail یا به سادگی با استفاده از kubectl نظارت کنید:

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

مراحل بعدی

اجازه

این بیشتر به پیکربندی کاموندا BPM مربوط می شود تا Kubernetes، اما توجه به این نکته مهم است که به طور پیش فرض، احراز هویت در REST API غیرفعال است. تو می توانی احراز هویت اولیه را فعال کنید یا از روش دیگری مانند J.W.T.. می توانید از کانفیگ مپ ها و حجم ها برای بارگیری xml یا xmlstarlet (به بالا مراجعه کنید) برای ویرایش فایل های موجود در تصویر استفاده کنید و یا از wget استفاده کنید یا آنها را با استفاده از یک ظرف اولیه و یک حجم مشترک بارگذاری کنید.

مدیریت جلسه

مانند بسیاری از برنامه های کاربردی دیگر، کاموندا 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

یادداشت: می توانید به جای sed از xmlstarlet استفاده کنید

ما با استفاده از twemproxy روبروی Google Cloud Memorystore، با memcached-session-manager (Redis را پشتیبانی می کند) تا آن را اجرا کند.

مقیاس بندی

اگر قبلاً جلسات را درک کرده اید، اولین (و اغلب آخرین) محدودیت برای مقیاس بندی کاموندا BPM ممکن است اتصال به پایگاه داده باشد. سفارشی سازی جزئی در حال حاضر موجود است "از جعبه" بیایید intialSize را نیز در فایل settings.xml غیرفعال کنیم. اضافه کردن Autoscaler Pod Horizontal (HPA) و به راحتی می توانید تعداد غلاف ها را به صورت خودکار مقیاس کنید.

درخواست ها و محدودیت ها

В platform/deployment.yaml خواهید دید که ما فیلد منابع را سخت کدگذاری کرده ایم. این به خوبی با HPA کار می کند، اما ممکن است نیاز به پیکربندی اضافی داشته باشد. پچ kustomize برای این کار مناسب است. سانتی متر. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl

نتیجه

بنابراین ما Camunda BPM را با معیارهای Prometheus، گزارش‌ها، پایگاه داده H2، TLS و Ingress روی Kubernetes نصب کردیم. ما فایل‌های jar و فایل‌های پیکربندی را با استفاده از ConfigMaps و Dockerfile اضافه کردیم. ما در مورد تبادل داده ها به حجم و مستقیماً به متغیرهای محیطی از اسرار صحبت کردیم. علاوه بر این، ما یک نمای کلی از راه اندازی کاموندا برای چندین نسخه مشابه و یک 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، ترجمه مقاله آلستر فیرث، لارس لانگ

منبع: www.habr.com

اضافه کردن نظر