Выкарыстоўваеце 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