Використовуєте 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 Engine може легко підключатися до інших програм, що працюють у тому ж кластері, а 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 використовує модель вилучення <service>/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 за адресою <svc>:9404/metrics
Налаштування експортера
Уважний читач може запитати себе, а звідки взявся prometheus-jmx.yaml? Існує багато різних речей, які можуть працювати в JVM, і tomcat - це тільки одна з них, тому експортер потребує деякого додаткового налаштування. Стандартні конфігурації для tomcat, wildfly, kafka і так далі доступні . Ми додамо tomcat як в Kubernetes, а потім змонтуємо його як тому.
По-перше, ми додаємо файл конфігурації експортера до нашої директорії platform/config/
platform/config
└── prometheus-jmx.yaml
Потім ми додаємо в 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, и перед тим, як приступити.
Розповсюдження цього шаблону на інші варіанти використання
Усі файли, які ми додаємо у 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 для розгортання в різних середовищах з використанням оверлею: .
Примітка: використання valueFrom: secretKeyRef. Будь-ласка, використайте навіть під час розробки, щоб зберегти свої секрети у безпеці.
Цілком ймовірно, що у вас вже є найкраща система керування секретами Kubernetes. Якщо ні, то ось деякі варіанти: шифрування їх за допомогою KMS вашого хмарного провайдера, а потім впровадження їх в K8S як секрети через CD-конвеєр. — дуже добре працюватиме у поєднанні з секретами Kustomize. Є й інші інструменти, такі як dotGPG – вони виконують аналогічні функції: , .
Вхід
Якщо ви не вирішите використовувати переадресацію локального порту, вам знадобиться налаштований Ingress Controller. Якщо ви не використовуєте () то, швидше за все, вже знаєте, що вам потрібно встановити необхідні анотації в ingress-patch.yaml.tmpl або platform/ingress.yaml. Якщо ви використовуєте ingress-nginx і бачите nginx ingress class з балансувальником навантаження, що вказує на нього і зовнішній DNS або запис підстановочного DNS, все готово. В іншому випадку налаштуйте Ingress Controller та DNS або пропустіть ці кроки та залиште пряме підключення до поду.
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
Зачекайте кілька хвилин, поки 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 для файлів cookie. Як надійніше рішення можна розгорнути 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
Ми використали перед Google Cloud Memorystore, з (Підтримує Redis) для його запуску.
масштабування
Якщо ви вже розібралися з сесіями, то першим (і часто останнім) обмеженням масштабування Camunda BPM може стати підключення до бази даних. Часткове налаштування доступне вже «». Також відключимо intialSize у файлі 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 <- 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 р., переклад Alastair Firth, Lars Lange
Джерело: habr.com