Сиз Kubernetes колдонуп жатасызбы? Camunda BPM инстанцияларын виртуалдык машиналардан жылдырууга даярсызбы же жөн гана Kubernetesте иштетип көрүңүзбү? Келгиле, кээ бир жалпы конфигурацияларды жана сиздин конкреттүү муктаждыктарыңызга ылайыкташтырылган жеке элементтерди карап көрөлү.
Бул сиз мурда Kubernetes колдонгон деп болжолдойт. Эгерде жок болсо, анда эмне үчүн карап көрөлү жана биринчи кластериңизди баштабай жатасызбы?
Authors
- (Alastair Firth) - Камунда Cloud командасынын сайттын ишенимдүүлүгү боюнча улук инженер;
- (Ларс Ланге) - Камундадагы DevOps инженери.
Кыскасы:
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'та заманбап тиркемелерди иштетүү үчүн де-факто стандарты болуп калды. Аппараттык камсыздоонун эмуляциясынын ордуна системалык чалууларды колдонуу жана ядронун эстутумду жана тапшырмаларды которууну башкаруу жөндөмдүүлүгүн колдонуу менен жүктөө убактысы жана ишке киргизүү убактысы минималдуу деңгээлде сакталат. Бирок, эң чоң пайда Kubernetes бардык тиркемелерге талап кылынган инфраструктураны конфигурациялоо үчүн берген стандарттык APIден келип чыгышы мүмкүн: сактоо, тармактык жана мониторинг. Ал 2020-жылдын июнь айында 6 жашка толду жана, балким, экинчи ири ачык булактуу долбоор (Linux'тан кийин). Ал акыркы бир нече жыл ичинде тез итерациядан кийин өзүнүн функционалдуулугун жигердүү турукташтырып жатат, анткени ал дүйнө жүзү боюнча өндүрүштүк жүктөм үчүн маанилүү болуп калды.
Camunda BPM Engine бир эле кластерде иштеген башка тиркемелерге оңой туташа алат жана Kubernetes инфраструктуралык чыгымдарды чындап эле керек болгондо гана көбөйтүүгө (жана керек болсо, аларды оңой кыскартууга) мүмкүндүк берүүчү эң сонун масштабдуулукту камсыз кылат.
Мониторингдин сапаты Prometheus, Grafana, Loki, Fluentd жана Elasticsearch сыяктуу инструменттердин жардамы менен бир топ жакшыртылып, кластердеги бардык жүктөмдөрдү борборлоштурулган түрдө көрүүгө мүмкүндүк берет. Бүгүн биз Prometheus экспорттоочусун Java виртуалдык машинасына (JVM) кантип киргизүүнү карап чыгабыз.
максаттары
Келгиле, Camunda BPM Docker сүрөтүн ыңгайлаштыра турган бир нече аймактарды карап көрөлү () Кубернетес менен жакшы иштеши үчүн.
- Журналдар жана көрсөткүчтөр;
- Маалыматтар базасы байланыштары;
- аутентификация;
- Сессияны башкаруу.
Бул максаттарга жетүү үчүн биз бир нече жолдорду карап чыгабыз жана бүт процессти ачык көрсөтөбүз.
пикир: Сиз Enterprise версиясын колдонуп жатасызбы? Кара жана зарыл болсо, сүрөт шилтемелерин жаңыртыңыз.
Иш процессин өнүктүрүү
Бул демонстрацияда биз Google Cloud Build аркылуу Docker сүрөттөрүн куруу үчүн Skaffold колдонобуз. Ал ар кандай куралдарды (мисалы, Kustomize жана Helm), CI жана куруу куралдарын жана инфраструктура провайдерлерин жакшы колдоого алат. Файл skaffold.yaml.tmpl өндүрүш деңгээлиндеги инфраструктураны иштетүүнүн өтө жөнөкөй жолун камсыз кылган Google Cloud Build жана GKE үчүн жөндөөлөрдү камтыйт.
make skaffold Dockerfile контекстин Cloud Buildге жүктөйт, сүрөттү түзүп, GCRде сактайт, андан кийин манифесттерди кластериңизге колдонот. Бул эмне кылат make skaffold, бирок Skaffold башка көптөгөн өзгөчөлүктөргө ээ.
Kubernetes'теги yaml шаблондору үчүн биз kustomize'ди толугу менен манифестти айрыбастан yaml катмарларын башкаруу үчүн колдонобуз. git pull --rebase андан ары жакшыртуу үчүн. Азыр ал kubectlде жана мындай нерселер үчүн абдан жакшы иштейт.
Биз ошондой эле *.yaml.tmpl файлдарына хосттун атын жана GCP долбоорунун идентификаторун толтуруу үчүн envsubst колдонобуз. Анын кантип иштээрин көрө аласыз makefile же андан ары улантыңыз.
Талаптар
- Жумушчу кластер
- - өзүңүздүн докер сүрөттөрүңүздү түзүү жана 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, жана бул үчүн каптал контейнерлерди кошуу кеңири таралган. Тилекке каршы, 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
Ооба, бул оңой эле. Экспорттоочу tomcatты көзөмөлдөп, анын метрикасын Prometheus форматында көрсөтөт <svc>:9404/metrics
Экспорттоочу жөндөө
Кунт коюп окуган окурман бул кайдан келген деп таң калышы мүмкүн prometheus-jmx.yaml? JVMде иштей турган ар кандай нерселер бар, жана tomcat алардын бири гана, ошондуктан экспорттоочуга кошумча конфигурация керек. Tomcat, wildfly, kafka жана башкалар үчүн стандарттуу конфигурациялар бар . Биз 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 сонун, анткени алар конфигурация маалыматтарын хэштешет жана ал өзгөрсө, поддонду кайра иштетүүгө мажбурлайт. Алар ошондой эле Жайгаштыруудагы конфигурациянын көлөмүн азайтат, анткени конфигурация файлдарынын бүтүндөй "папкасын" бир 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 операторунун колдонуучулары колдоно алышат 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 Прокси менен колдонобуз - бул ички көйгөйлөрдү чечүү үчүн кийинчерээк керек болот. Бул жөнөкөй жана ишенимдүү вариант, эгерде сизде маалымат базасын орнотууда өз каалооңуз жок. 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ге компакт-диск каналы аркылуу киргизүү - - Kustomize сырлары менен айкалышта абдан жакшы иштейт. Ушундай эле функцияларды аткарган dotGPG сыяктуу башка куралдар бар: , .
өтүшү
Жергиликтүү порт багыттоосун колдонууну тандабасаңыз, конфигурацияланган Ingress Controller керек болот. Эгер колдонбосоңуз () анда сиз керектүү аннотацияларды орнотуу керек экенин билесиз ingress-patch.yaml.tmpl же platform/ingress.yaml. Эгерде сиз ingress-nginx колдонуп жатсаңыз жана аны көрсөткөн жүк балансы бар nginx кириш классын жана тышкы 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
Томкат толугу менен даяр болгонго чейин бир нече мүнөт күтө туруңуз. Cert-менеджер домен атын текшерүү үчүн бир аз убакыт талап кылынат. Андан кийин сиз кубетейл сыяктуу курал сыяктуу колдо болгон куралдарды колдонуп журналдарды көзөмөлдөй аласыз же жөн гана kubectl аркылуу:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
кийинки кадамдар
укук берүү
Бул Kubernetesке караганда Camunda BPMди конфигурациялоого көбүрөөк тиешелүү, бирок демейки шартта REST APIде аутентификация өчүрүлгөнүн белгилей кетүү маанилүү. Сенин колуңдан келет же башка ыкманы колдонуңуз . Сиз конфигмациялык карталарды жана томдорду xml жүктөө үчүн, же сүрөттөгү файлдарды оңдоо үчүн xmlstarlet (жогоруда караңыз) колдонсоңуз болот, же wgetти колдонсоңуз же аларды init контейнери жана жалпы көлөм аркылуу жүктөңүз.
Сессияны башкаруу
Көптөгөн башка тиркемелер сыяктуу эле, Camunda BPM JVMдеги сессияларды башкарат, андыктан бир нече репликаларды иштеткиңиз келсе, жабышчаак сеанстарды иштете аласыз (), ал реплика жок болмоюнча болот же кукилер үчүн Max-Age атрибутун орнотуңуз. Күчтүүраак чечим үчүн, 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
пикир: sedдин ордуна xmlstarlet колдоно аласыз
колдондук менен Google Cloud Memorystore алдында (Redis колдойт) аны иштетүү үчүн.
Масштабдоо
Эгер сиз сеанстарды түшүнгөн болсоңуз, анда Camunda BPM масштабын кеңейтүүгө биринчи (жана көбүнчө акыркы) чектөө маалымат базасына туташуу болушу мүмкүн. Жарым-жартылай ыңгайлаштыруу мурунтан эле жеткиликтүү "" Ошондой эле settings.xml файлында intialSizeди өчүрөлү. кошуу жана сиз автоматтык түрдө подкасттардын санын оңой эле масштабдай аласыз.
Сурамдар жана чектөөлөр
В platform/deployment.yaml Биз ресурстар талаасын катуу коддогонубузду көрөсүз. Бул HPA менен жакшы иштейт, бирок кошумча конфигурацияны талап кылышы мүмкүн. Бул үчүн kustomize патч ылайыктуу. См. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
жыйынтыктоо
Ошентип, биз Prometheus метрикалары, журналдары, H2 маалымат базасы, TLS жана Ingress менен Kubernetesке Camunda BPM орноттук. ConfigMaps жана Dockerfile аркылуу jar файлдарын жана конфигурация файлдарын коштук. Биз маалыматтарды көлөмгө жана түздөн-түз сырлардан чөйрө өзгөрмөлөрүнө алмашуу жөнүндө сүйлөштүк. Мындан тышкары, биз бир нече репликалар жана аныктыгы текшерилген 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, котормо Аластэр Ферт, Ларс Ланге
Source: www.habr.com