Използвате 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 (), за да взаимодействат добре с 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 или просто продължете напред.
Необходими условия
- Работен клъстер
- — за създаване на собствени Docker образи и лесно разгръщане в GKE
- Копие на този код
- Envsubst
Работен поток с помощта на манифестите
Ако не искате да използвате kustomize или skaffold, можете да се обърнете към манифестите в generated-manifest.yaml и да ги адаптирате към работния поток по ваше желание.
Логове и метрики
Prometheus стана стандарт за събиране на метрики в Kubernetes. Той заема същото място като AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics и други. Има отворен код и мощен език за запитвания. Визуализацията ще се поеме от Grafana — тя предлага голямо количество табла за мониторинг, налични от самото начало. Те са свързани помежду си и сравнително лесни за инсталиране с .
По подразбиране Prometheus използва модел на извличане /metrics, и добавянето на sidecar контейнери за това е често срещано явление. За съжаление, метриките JMX се регистрират най-добре вътре в JVM, така че sidecar контейнерите не са толкова ефективни. Нека свържем с отворен код от 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 като в Kubernetes и след това ще го монтираме като том.
Първо, добавяме файла за конфигурация на експортера в нашата директория platform/config/
платформа/конфигурация
└── prometheus-jmx.yaml
След това добавяме в 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, и преди да продължите.
Разпространение на този шаблон към други случаи на употреба
Всички файлове, които добавяме в ConfigMapGenerator, ще бъдат достъпни в новата директория /etc/config. Можете да разширите този шаблон за монтиране на всякакви други необходими конфигурационни файлове. Можете дори да монтирате нов скрипт за стартиране. Можете да използвате за монтиране на отделни файлове. За актуализиране на 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 за разгръщане в различни среди с помощта на overlay: .
Забележка: използване valueFrom: secretKeyRef. Моля, използвайте дори по време на разработка, за да запазите тайните си в безопасност.
Вероятно вече имате предпочитана система за управление на тайни в Kubernetes. Ако не, ето някои опции: шифроване с помощта на KMS на вашия облачен доставчик и след това внедряване в K8S като тайни чрез CD конвейер — — ще работи много добре с тайните на Kustomize. Има и други инструменти, като dotGPG — те изпълняват подобни функции: , .
Ingress
Освен ако не решите да използвате пренасочване на локален порт, ще ви е необходим настроен Ingress Controller. Ако не използвате () вероятно вече знаете, че трябва да зададете необходимите анотации в ingress-patch.yaml.tmpl или platform/ingress.yaml. Ако използвате ingress-nginx и виждате nginx ingress клас с балансировчик на натоварването, който сочи към него и външен DNS или запис за подмяна на DNS, всичко е готово. В противен случай, конфигурирайте Ingress Controller и DNS или пропуснете тези стъпки и оставете директна връзка към пода.
TLS
Ако използвате или 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 аутентификацията е деактивирана. Можете да или да използвате друг метод, например . Можете да използвате configmaps и обеми за зареждане на xml, или xmlstarlet (вижте по-горе) за редактиране на съществуващи файлове в образа, както и или да използвате wget, или да ги заредите с помощта на init контейнер и споделен обем.
Управление на сесиите
Както много други приложения, Camunda BPM обработва сесиите в JVM, така че, ако искате да стартирате няколко реплики, можете да включите sticky sessions (), които ще съществуват, докато репликата не изчезне, или да зададете атрибута 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
Използвахме пред Google Cloud Memorystore, с (поддържа Redis) за неговото изпълнение.
Мащабиране
Ако вече сте разбрали сесиите, то първото (и често последно) ограничение за мащабиране на Camunda BPM може да бъде свързването към базата данни. Частична настройка е налична вече "". Също така ще изключим initialSize в файла settings.xml. Добавете и лесно ще можете автоматично да мащабирате броя на подовете.
Запитвания и ограничения
В 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
