Дали користите Kubernetes? Подготвени сте да ги преместите вашите примери на Camunda BPM надвор од виртуелните машини или можеби само да пробате да ги извршите на Kubernetes? Ајде да погледнеме некои вообичаени конфигурации и поединечни ставки што може да се прилагодат на вашите специфични потреби.
Се претпоставува дека сте користеле Kubernetes претходно. Ако не, зошто да не погледнете и да не го започнете вашиот прв кластер?
Автори
- (Аластер Фирт) - Виш инженер за доверливост на локацијата во тимот на Camunda Cloud;
- (Ларс Ланг) - инженер за DevOps во Камунда.
Накратко:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Добро, веројатно не работеше затоа што немаш инсталирано скеле и кустомиз. Па, тогаш прочитајте!
Што е Камунда БПМ
Камунда BPM е платформа за управување со деловни процеси и автоматизација на одлуки со отворен код што ги поврзува деловните корисници и развивачите на софтвер. Идеален е за координирање и поврзување луѓе, (микро) услуги или дури и ботови! Можете да прочитате повеќе за различните случаи на употреба на .
Зошто да користите Kubernetes
Kubernetes стана де факто стандард за водење модерни апликации на Linux. Со користење на системски повици наместо хардверска емулација и способност на кернелот да управува со меморијата и префрлувањето задачи, времето на подигање и времето на стартување се сведени на минимум. Сепак, најголемата придобивка може да дојде од стандардниот API што Kubernetes го обезбедува за конфигурирање на инфраструктурата потребна за сите апликации: складирање, вмрежување и следење. Наполни 2020 години во јуни 6 година и е можеби вториот најголем проект со отворен код (по Linux). Неодамна активно ја стабилизира својата функционалност по брзото повторување во текот на изминатите неколку години, бидејќи станува критично за обемот на производство низ целиот свет.
Camunda BPM Engine може лесно да се поврзе со други апликации што работат на истиот кластер, а Kubernetes обезбедува одлична приспособливост, овозможувајќи ви да ги зголемите трошоците за инфраструктура само кога навистина е потребно (и лесно да ги намалите по потреба).
Квалитетот на следењето е исто така значително подобрен со алатки како што се Prometheus, Grafana, Loki, Fluentd и Elasticsearch, овозможувајќи ви централно да ги прегледувате сите оптоварувања во кластер. Денес ќе разгледаме како да го имплементираме извозникот Prometheus во Java Virtual Machine (JVM).
Цели
Ајде да погледнеме неколку области каде што можеме да ја прилагодиме сликата на Camunda BPM Docker () така што добро комуницира со 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 за да го пополниме името на домаќинот и ID на проектот GCP во датотеките *.yaml.tmpl. Можете да видите како функционира во makefile или само продолжи понатаму.
Предуслови
- Работен кластер
- - за создавање на сопствени докер слики и лесно распоредување на GKE
- Копија од овој код
- Envsubst
Работен тек со користење на манифестации
Ако не сакате да користите kustomize или skaffold, можете да се повикате на манифестациите во generated-manifest.yaml и приспособете ги на работниот тек по ваш избор.
Дневници и метрика
Прометеј стана стандард за собирање метрика во Кубернетес. Ја зазема истата ниша како и AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics и други. Тој е со отворен код и има моќен јазик за пребарување. Визуелизацијата ќе и ја довериме на Grafana - доаѓа со голем број контролни табли достапни надвор од кутијата. Тие се поврзани едни со други и се релативно лесни за инсталирање .
Стандардно, Прометеј го користи моделот на екстракција <service>/metrics, и вообичаено е додавањето на контејнери за странична кола за ова. За жал, метриките на JMX најдобро се регистрираат во рамките на JVM, така што контејнерите на страничните кола не се толку ефикасни. Ајде да се поврземе отворен код од Прометеј до 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
Па, тоа беше лесно. Извозникот ќе ја следи мачката и ќе ја прикаже неговата метрика во формат Прометеј на <svc>:9404/metrics
Поставување на извозник
Внимателниот читател може да се запраша од каде потекнува prometheus-jmx.yaml? Постојат многу различни работи што можат да работат во JVM, а Tomcat е само една од нив, така што на извозникот му треба дополнителна конфигурација. Достапни се стандардни конфигурации за мачор, дива мува, кафка и така натаму . Ќе додадеме мачор како во Kubernetes и потоа монтирајте го како волумен.
Прво, ја додаваме конфигурациската датотека на извозникот во нашиот директориум на платформа/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-датотеките, размислете за користење наместо сед. Веќе е вклучен во сликата.
Списанија
Одлична вест! Дневниците на апликациите се веќе достапни на 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. Ве молиме, користете дури и за време на развојот за да ги зачувате вашите тајни безбедни.
Веројатно веќе имате претпочитан систем за управување со тајните на Кубернет. Ако не, еве неколку опции: да ги шифрирате со KMS на вашиот облак провајдер и потоа да ги вбризгате во K8S како тајни преку цевководот на ЦД - - ќе работи многу добро во комбинација со тајните на Kustomize. Постојат и други алатки, како што е dotGPG, кои вршат слични функции: , .
Целосно
Освен ако не изберете да користите локално препраќање порти, ќе ви треба конфигуриран контролер за влез. Ако не користите () тогаш најверојатно веќе знаете дека треба да ги инсталирате потребните прибелешки ingress-patch.yaml.tmpl или platform/ingress.yaml. Ако користите ingress-nginx и гледате класа за влез на nginx со балансирач на оптоварување што покажува кон неа и надворешен DNS или DNS влез со џокер, можете да одите. Во спротивно, конфигурирајте ги контролорот за влез и 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
Почекајте неколку минути додека мачката не е целосно подготвена. Серт-менаџерот ќе потрае некое време за да го потврди името на доменот. Потоа можете да ги следите дневниците користејќи достапни алатки како алатка како kubetail или едноставно користејќи kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Следни чекори
Овластување
Ова е порелевантно за конфигурирање на Camunda BPM отколку за Kubernetes, но важно е да се забележи дека стандардно, автентикацијата е оневозможена во REST API. Ти можеш или користете друг метод како . Можете да користите конфигурациски мапи и волумени за да вчитате xml или xmlstarlet (видете погоре) за да ги уредувате постоечките датотеки на сликата и или да користите wget или да ги вчитате со помош на иницијален контејнер и споделен волумен.
Управување со сесии
Како и многу други апликации, Camunda BPM се справува со сесии во JVM, па ако сакате да извршувате повеќе реплики, можете да овозможите лепливи сесии (), кој ќе постои додека репликата не исчезне, или поставете го атрибутот 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
Ние употребивме пред Google Cloud Memorystor, со (поддржува 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, превод Аластер Фирт, Ларс Ланге
Извор: www.habr.com