Используете 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
Если только вы не решите использовать переадресацию локального порта, вам понадобится настроенный 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