Изпълнение на Camunda BPM на Kubernetes

Използвате ли Kubernetes? Готови ли сте да преместите вашите Camunda BPM екземпляри извън виртуални машини или може би просто да опитате да ги стартирате на Kubernetes? Нека да разгледаме някои общи конфигурации и отделни елементи, които могат да бъдат пригодени към вашите специфични нужди.

Предполага се, че сте използвали Kubernetes преди. Ако не, защо не погледнете ръководство и да не стартирате първия си клъстер?

Автори

• Аластър Фърт (Аластър Фърт) – старши инженер по надеждност на сайта в екипа на Camunda Cloud;
• Ларс Ланге (Ларс Ланге) – DevOps инженер в Camunda.

Накратко:

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


Добре, вероятно не е проработило, защото нямате инсталирани скеле и персонализиране. Ами тогава прочетете!

Какво е Camunda BPM

Camunda BPM е платформа с отворен код за управление на бизнес процеси и автоматизация на решения, която свързва бизнес потребители и разработчици на софтуер. Той е идеален за координиране и свързване на хора, (микро) услуги или дори ботове! Можете да прочетете повече за различните случаи на употреба на връзка.

Защо да използвате Kubernetes

Kubernetes се превърна в де факто стандарт за стартиране на съвременни приложения на Linux. Чрез използване на системни повиквания вместо хардуерна емулация и способността на ядрото да управлява паметта и превключването на задачи, времето за стартиране и стартиране се свеждат до минимум. Най-голямата полза обаче може да дойде от стандартния API, който Kubernetes предоставя за конфигуриране на инфраструктурата, изисквана от всички приложения: съхранение, работа в мрежа и наблюдение. Той навърши 2020 години през юни 6 г. и е може би вторият по големина проект с отворен код (след Linux). Напоследък активно стабилизира своята функционалност след бърза итерация през последните няколко години, тъй като става критична за производствените натоварвания по целия свят.

Camunda BPM Engine може лесно да се свърже с други приложения, работещи на същия клъстер, а Kubernetes осигурява отлична мащабируемост, позволявайки ви да увеличите разходите за инфраструктура само когато наистина е необходимо (и лесно да ги намалите, ако е необходимо).

Качеството на мониторинга също е значително подобрено с инструменти като Prometheus, Grafana, Loki, Fluentd и Elasticsearch, което ви позволява да преглеждате централно всички работни натоварвания в клъстер. Днес ще разгледаме как да внедрим експортера на Prometheus във виртуалната машина на Java (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 и след това ще приложи манифестите към вашия клъстер. Това е, което прави make skaffold, но Skaffold има много други функции.

За yaml шаблони в Kubernetes използваме kustomize, за да управляваме yaml наслагвания, без да разклоняваме целия манифест, което ви позволява да използвате git pull --rebase за допълнителни подобрения. Сега е в kubectl и работи доста добре за такива неща.

Ние също използваме envsubst, за да попълним името на хоста и GCP ID на проекта във файловете *.yaml.tmpl. Можете да видите как работи в makefile или просто продължете по-нататък.

Предварителни

• Работен клъстер Kubernetes
• Персонализиране
• Скеле - за създаване на ваши собствени докер изображения и лесно внедряване в GKE
• Копие на този код
• Envsubst

Работен процес с използване на манифести

Ако не искате да използвате 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


Е, това беше лесно. Износителят ще наблюдава tomcat и ще показва неговите показатели във формат Prometheus на <svc>:9404/metrics

Настройка на експортера

Внимателният читател може да се зачуди откъде е дошло prometheus-jmx.yaml? Има много различни неща, които могат да работят в JVM, и tomcat е само едно от тях, така че програмата за експортиране се нуждае от допълнителна конфигурация. Предлагат се стандартни конфигурации за tomcat, wildfly, kafka и т.н тук. Ще добавим tomcat като ConfigMap в Kubernetes и след това го монтирайте като обем.

Първо добавяме конфигурационния файл на експортера към нашата платформа/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 като обем към под:

-- 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, Персонализирайте приставките за тайна стойност.

Влизане

Освен ако не изберете да използвате локално пренасочване на портове, ще ви трябва конфигуриран Ingress Controller. Ако не използвате ingress-nginx (Диаграма на кормилото), тогава най-вероятно вече знаете, че трябва да инсталирате необходимите анотации ingress-patch.yaml.tmpl или platform/ingress.yaml. Ако използвате ingress-nginx и видите входящ клас на nginx с балансьор на натоварването, сочещ към него, и външен DNS или DNS запис със заместващ знак, можете да тръгнете. В противен случай конфигурирайте Ingress Controller и DNS или пропуснете тези стъпки и запазете директната връзка с групата.

TLS

Ако използвате CERT-мениджър или 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 е напълно готов. Мениджърът на сертификати ще отнеме известно време, за да провери името на домейна. След това можете да наблюдавате регистрационните файлове, като използвате налични инструменти като инструмент като 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 контейнер и споделен том.

Управление на сесии

Подобно на много други приложения, 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-мениджър на сесии (поддържа 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 г., превод статии Аластър Фърт, Ларс Ланге

Източник: www.habr.com