🥇Стартиране на Camunda BPM в Kubernetes

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

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

Автори

Аластер Фърт (Alastair Firth) е старши инженер по надеждност на сайта (Site Reliability Engineer) в екипа на Camunda Cloud;
Ларс Ланге (Lars Lange) е DevOps инженер в Camunda.

В кратце:

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

Добре, вероятно това не е сработило, тъй като нямате инсталирани skaffold и kustomize. Е, тогава продължете да четете!

Какво е Camunda BPM

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

Защо да използвам Kubernetes

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

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

Качеството на мониторинга също значително се подобрява с помощта на инструменти като Prometheus, Grafana, Loki, Fluentd и Elasticsearch, които позволяват централизирано преглеждане на всички работни натоварвания на клъстера. Днес ще разгледаме как да внедрим експортер на Prometheus в Java (JVM) виртуална машина.

Цели

Нека разгледаме някои области, в които можем да конфигурираме Docker образа на Camunda BPM (github), за да взаимодействат добре с Kubernetes.

Логове и метрики;
Свръзки с база данни;
Аутентикация;
Управление на сесии.

Ние ще разгледаме няколко начина за постигане на тези цели и наочо ще покажем целия процес.

Забележка: Използвате ли версия 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 или просто продължете напред.

Необходими условия

Работен клъстер Kubernetes
Kustomize
Skaffold — за създаване на собствени Docker образи и лесно разгръщане в GKE
Копие на този код
Envsubst

Работен поток с помощта на манифестите

Ако не искате да използвате kustomize или skaffold, можете да се обърнете към манифестите в generated-manifest.yaml и да ги адаптирате към работния поток по ваше желание.

Логове и метрики

Prometheus стана стандарт за събиране на метрики в Kubernetes. Той заема същото място като AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics и други. Има отворен код и мощен език за запитвания. Визуализацията ще се поеме от Grafana — тя предлага голямо количество табла за мониторинг, налични от самото начало. Те са свързани помежду си и сравнително лесни за инсталиране с prometheus-operator.

По подразбиране Prometheus използва модел на извличане /metrics, и добавянето на sidecar контейнери за това е често срещано явление. За съжаление, метриките JMX се регистрират най-добре вътре в 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 и ще показва неговите метрики в формат Prometheus на адрес :9404/metrics

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

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

Първо, добавяме файла за конфигурация на експортера в нашата директория platform/config/

платформа/конфигурация └── prometheus-jmx.yaml

След това добавяме ConfigMapGenerator в kustomization.yaml.tmpl:

-- platform/kustomization.yaml.tmpl apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization [...] configMapGenerator: - name: config файлове: - 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. Можете да разширите този шаблон за монтиране на всякакви други необходими конфигурационни файлове. Можете дори да монтирате нов скрипт за стартиране. Можете да използвате subPath за монтиране на отделни файлове. За актуализиране на xml файлове, обмислете използването на xmlstarlet вместо sed. Той вече е включен в образа.

Лога

Отлични новини! Логовете на приложенията вече са налични на stdout, например, с помощта на kubectl logs. Fluentd (той е инсталиран по подразбиране в GKE) ще пренасочи логовете ви в Elasticsearch, Loki или на вашата корпоративна платформа за логове. Ако искате да използвате jsonify за логовете, можете да следвате предоставения по-горе шаблон за инсталиране logback.

База данни.

По подразбиране образът ще има база данни 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 за разгръщане в различни среди с помощта на overlay: пример.

Забележка: използване valueFrom: secretKeyRef. Моля, използвайте тази функция на Kubernetes дори по време на разработка, за да запазите тайните си в безопасност.

Вероятно вече имате предпочитана система за управление на тайни в Kubernetes. Ако не, ето някои опции: шифроване с помощта на KMS на вашия облачен доставчик и след това внедряване в K8S като тайни чрез CD конвейер — MozillaSOPS — ще работи много добре с тайните на Kustomize. Има и други инструменти, като dotGPG — те изпълняват подобни функции: HashiCorp Vault, Kustomize Secret Value Plugins.

Ingress

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

TLS

Ако използвате cert-manager или kube-lego и letsencrypt – сертификатите за новото влизане ще бъдат получени автоматично. В противен случай, отворете ingress-patch.yaml.tmpl и го конфигурирайте според потребностите си.

Стартиране!

Ако сте се придържали към всичко написано по-горе, то командата make skaffold 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 аутентификацията е деактивирана. Можете да включите основната аутентификация или да използвате друг метод, например JWT. Можете да използвате configmaps и обеми за зареждане на xml, или xmlstarlet (вижте по-горе) за редактиране на съществуващи файлове в образа, както и или да използвате wget, или да ги заредите с помощта на init контейнер и споделен обем.

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

Както много други приложения, Camunda BPM обработва сесиите в JVM, така че, ако искате да стартирате няколко реплики, можете да включите sticky sessions (например, за 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 '/^/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-manager (поддържа Redis) за неговото изпълнение.

Мащабиране

Ако вече сте разбрали сесиите, то първото (и често последно) ограничение за мащабиране на Camunda BPM може да бъде свързването към базата данни. Частична настройка е налична вече "извън кутията". Също така ще изключим initialSize в файла settings.xml. Добавете HorizontalPodAutoscaler (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 <- манифест за ползване без kustomize ├── изображения │ └── camunda-bpm │ └── Dockerfile <- overlay docker образ ├── ingress-patch.yaml.tmpl <- конфигурация на ingress, специфична за сайта ├── kustomization.yaml.tmpl <- основен Kustomization ├── Makefile <- цели за изграждане ├── namespace.yaml ├── платформа │ ├── конфигурация │ │ └── prometheus-jmx.yaml <- конфигурационен файл за експортер на prometheus │ ├── deployment.yaml <- основно разгръщане │ ├── ingress.yaml │ ├── kustomization.yaml <- "основен" kustomization │ ├── service-monitor.yaml <- примерна конфигурация на prometheus-operator │ └── service.yaml └── skaffold.yaml.tmpl <- директиви на skaffold

05.08.2020 г., превод на статията Alastair Firth, Lars Lange

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