Դուք օգտվո՞ւմ եք Kubernetes-ից: Պատրա՞ստ եք ձեր Camunda BPM օրինակները տեղափոխել վիրտուալ մեքենաներից, կամ գուցե պարզապես փորձեք դրանք գործարկել Kubernetes-ում: Եկեք նայենք որոշ ընդհանուր կոնֆիգուրացիաների և առանձին տարրերի, որոնք կարող են հարմարեցվել ձեր հատուկ կարիքներին:
Այն ենթադրում է, որ դուք նախկինում օգտագործել եք Kubernetes: Եթե ոչ, ապա ինչու չնայեք և չե՞ք սկսել ձեր առաջին կլաստերը:
Բառը
- (Alastair Firth) - Կայքի հուսալիության ավագ ինժեներ Camunda Cloud թիմում;
- (Լարս Լանգ) - 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):
Նպատակը
Եկեք նայենք մի քանի ոլորտների, որտեղ մենք կարող ենք հարմարեցնել Camunda BPM Docker պատկերը () այնպես, որ այն լավ համագործակցի Kubernetes-ի հետ:
- Տեղեկամատյաններ և չափումներ;
- Տվյալների բազայի միացումներ;
- Նույնականացում;
- Նիստի կառավարում.
Մենք կդիտարկենք այս նպատակներին հասնելու մի քանի ուղիներ և հստակ ցույց կտանք ամբողջ գործընթացը:
ՆշումՕգտագործո՞ւմ եք Enterprise տարբերակը: Նայել և անհրաժեշտության դեպքում թարմացրեք պատկերների հղումները:
Աշխատանքային հոսքի զարգացում
Այս ցուցադրությունում մենք կօգտագործենք Skaffold-ը՝ Google Cloud Build-ի միջոցով Docker պատկերներ ստեղծելու համար: Այն լավ աջակցություն ունի տարբեր գործիքների (օրինակ՝ Kustomize և Helm), CI և build գործիքների և ենթակառուցվածքների մատակարարների համար: Ֆայլ skaffold.yaml.tmpl ներառում է կարգավորումներ Google Cloud Build-ի և GKE-ի համար՝ տրամադրելով արտադրական մակարդակի ենթակառուցվածքի գործարկման շատ պարզ միջոց:
make skaffold կբեռնի Dockerfile համատեքստը Cloud Build-ում, կկառուցի պատկերը և կպահի այն GCR-ում, այնուհետև կկիրառի մանիֆեստները ձեր կլաստերի վրա: Սա այն է, ինչ անում է make skaffold, բայց Skaffold-ն ունի շատ այլ հատկանիշներ։
Kubernetes-ում yaml ձևանմուշների համար մենք օգտագործում ենք kustomize՝ կառավարելու yaml ծածկույթները՝ առանց ամբողջ մանիֆեստը ճեղքելու, ինչը թույլ է տալիս օգտագործել git pull --rebase հետագա բարելավումների համար: Հիմա այն kubectl-ում է ու բավականին լավ է աշխատում նման բաների համար։
Մենք նաև օգտագործում ենք envsubst՝ *.yaml.tmpl ֆայլերում հոսթի անունը և GCP նախագծի ID-ն համալրելու համար: Դուք կարող եք տեսնել, թե ինչպես է այն աշխատում makefile կամ պարզապես շարունակեք հետագա:
Նախադրյալներ
- Աշխատանքային կլաստեր
- - Ձեր սեփական դոկերի պատկերները ստեղծելու և GKE-ում հեշտ տեղակայման համար
- Այս կոդի պատճենը
- Envsubst
Աշխատանքային հոսք՝ օգտագործելով մանիֆեստներ
Եթե դուք չեք ցանկանում օգտագործել kustomize կամ skaffold, կարող եք դիմել մանիֆեստներին generated-manifest.yaml և հարմարեցրեք դրանք ձեր ընտրած աշխատանքի ընթացքին:
Տեղեկամատյաններ և չափումներ
Պրոմեթևսը դարձել է Kubernetes-ում չափումներ հավաքելու չափանիշ: Այն զբաղեցնում է նույն տեղը, ինչ 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
Դե, դա հեշտ էր: Արտահանողը կվերահսկի tomcat-ը և կցուցադրի դրա չափումները Պրոմեթևս ձևաչափով <svc>:9404/metrics
Արտահանողի կարգավորում
Ուշադիր ընթերցողը կարող է զարմանալ, թե որտեղից է այն եկել prometheus-jmx.yaml? Կան բազմաթիվ տարբեր բաներ, որոնք կարող են աշխատել JVM-ում, և tomcat-ը դրանցից մեկն է, ուստի արտահանողին անհրաժեշտ է լրացուցիչ կոնֆիգուրացիա: Հասանելի են ստանդարտ կոնֆիգուրացիաներ կատվի, վայրի թռչնի, կաֆկայի և այլնի համար . Մենք կավելացնենք tomcat որպես Kubernetes-ում և այնուհետև տեղադրեք այն որպես ծավալ:
Նախ, մենք ավելացնում ենք արտահանողի կազմաձևման ֆայլը մեր հարթակ/կոնֆիգ/ գրացուցակում
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 Operator-ի օգտատերերը կարող են օգտվել service-monitor.yaml սկսելու համար: Հետազոտել Service-monitor.yaml, и սկսելուց առաջ:
Ընդլայնելով այս օրինաչափությունը այլ օգտագործման դեպքերի վրա
Բոլոր ֆայլերը, որոնք մենք ավելացնում ենք ConfigMapGenerator-ին, հասանելի կլինեն նոր գրացուցակում /etc/config. Դուք կարող եք ընդլայնել այս ձևանմուշը՝ ձեզ անհրաժեշտ ցանկացած այլ կազմաձևման ֆայլ տեղադրելու համար: Դուք նույնիսկ կարող եք տեղադրել նոր գործարկման սցենար: Դուք կարող եք օգտագործել առանձին ֆայլեր տեղադրելու համար: Xml ֆայլերը թարմացնելու համար օգտագործեք sed-ի փոխարեն. Այն արդեն ներառված է նկարում։
Ամսագրեր
Հրաշալի լուր։ Հավելվածների տեղեկամատյաններն արդեն հասանելի են stdout-ում, օրինակ՝ with 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 ներթափանցման դաս, որի վրա մատնանշված է բեռի հավասարակշռիչը և արտաքին 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-ում: Դու կարող ես կամ օգտագործել այլ մեթոդ, ինչպիսին է . Դուք կարող եք օգտագործել կազմաձևեր և ծավալներ՝ xml բեռնելու համար, կամ xmlstarlet (տե՛ս վերևում)՝ պատկերում առկա ֆայլերը խմբագրելու համար, և կամ օգտագործել wget կամ բեռնել դրանք՝ օգտագործելով init կոնտեյներ և ընդհանուր ծավալ:
Նիստի կառավարում
Ինչպես շատ այլ հավելվածներ, 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
Նշումsed-ի փոխարեն կարող եք օգտագործել xmlstarlet
Մենք օգտագործեցինք Google Cloud Memorystore-ի դիմաց, հետ (աջակցում է Redis-ին) այն գործարկելու համար:
Scaling
Եթե դուք արդեն հասկանում եք նիստերը, ապա Camunda BPM-ի չափման առաջին (և հաճախ վերջին) սահմանափակումը կարող է լինել տվյալների բազայի հետ կապը: Մասնակի հարմարեցումն արդեն հասանելի է»« Եկեք նաև անջատենք intialSize-ը settings.xml ֆայլում: Ավելացնել և դուք հեշտությամբ կարող եք ավտոմատ կերպով չափել պատիճների քանակը:
Դիմումներ և սահմանափակումներ
В platform/deployment.yaml Դուք կտեսնեք, որ մենք կոշտ կոդավորել ենք ռեսուրսների դաշտը: Սա լավ է աշխատում HPA-ի հետ, բայց կարող է պահանջել լրացուցիչ կոնֆիգուրացիա: Kustomize patch-ը հարմար է դրա համար: Սմ. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
Արտադրողականություն
Այսպիսով, մենք տեղադրեցինք Camunda BPM-ը Kubernetes-ում Prometheus-ի չափումների, տեղեկամատյանների, H2 տվյալների բազայի, TLS-ի և Ingress-ի միջոցով: Մենք ավելացրել ենք jar ֆայլեր և կազմաձևման ֆայլեր՝ օգտագործելով ConfigMaps և Dockerfile: Մենք խոսեցինք տվյալների փոխանակման մասին ծավալների և ուղղակիորեն շրջակա միջավայրի փոփոխականների գաղտնիքներից: Բացի այդ, մենք տրամադրեցինք մի քանի կրկնօրինակների և վավերացված API-ի համար Camunda-ի ստեղծման ակնարկ:
Սայլակ
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/XNUMX/XNUMX, թարգմանություն Ալասթեր Ֆերթ, Լարս Լանգ
Source: www.habr.com