🥇Camunda BPM-ის გაშვება Kubernetes

იყენებ კუბერნეტესს? მზად ხართ გადაიტანოთ თქვენი Camunda BPM ინსტანციები ვირტუალური მანქანებიდან, ან იქნებ უბრალოდ სცადოთ მათი გაშვება Kubernetes-ზე? მოდით შევხედოთ რამდენიმე საერთო კონფიგურაციას და ცალკეულ ელემენტებს, რომლებიც შეიძლება მორგებული იყოს თქვენს კონკრეტულ საჭიროებებზე.

იგი ვარაუდობს, რომ თქვენ იყენებდით Kubernetes ადრე. თუ არა, რატომ არ გადახედე ხელმძღვანელობა და არ დაიწყო შენი პირველი კლასტერი?

ავტორები

ალასტერ ფერტი (Alastair Firth) - საიტის საიმედოობის უფროსი ინჟინერი Camunda Cloud-ის გუნდში;
ლარს ლანგე (ლარს ლანგე) - DevOps-ის ინჟინერი კამუნდაში.

Მოკლედ:

git clone https://github.com/camunda-cloud/camunda-examples.git cd camunda-examples/camunda-bpm-demo make skaffold

კარგი, ალბათ არ მუშაობდა, რადგან არ გაქვს დაყენებული სკაფოლდი და კუსტომიზი. კარგი მაშინ წაიკითხე!

რა არის კამუნდა BPM

Camunda BPM არის ღია კოდის ბიზნეს პროცესის მართვისა და გადაწყვეტილების ავტომატიზაციის პლატფორმა, რომელიც აკავშირებს ბიზნეს მომხმარებლებს და პროგრამული უზრუნველყოფის შემქმნელებს. იდეალურია ადამიანების, (მიკრო) სერვისების ან თუნდაც ბოტების კოორდინაციისა და დასაკავშირებლად! შეგიძლიათ მეტი წაიკითხოთ სხვადასხვა გამოყენების შემთხვევების შესახებ აქ ლინკები.

რატომ გამოვიყენოთ Kubernetes

Kubernetes თანამედროვე აპლიკაციების გაშვების დე ფაქტო სტანდარტი გახდა. Linuxაპარატურული ემულაციის ნაცვლად სისტემური ზარების გამოყენებით და ბირთვისთვის მეხსიერებისა და დავალებების გადართვის მართვის უფლების მიცემით, ჩატვირთვისა და გაშვების დრო მინიმუმამდეა დაყვანილი. თუმცა, ყველაზე დიდი უპირატესობა შეიძლება მოდიოდეს სტანდარტული API-დან, რომელსაც Kubernetes უზრუნველყოფს ყველა აპლიკაციისთვის საჭირო ინფრასტრუქტურის კონფიგურაციისთვის: შენახვა, ქსელი და მონიტორინგი. მან მეექვსე წლისთავი 2020 წლის ივნისში აღნიშნა, რაც მას შესაძლოა მეორე უდიდეს ღია კოდის პროექტად აქცევს (მას შემდეგ Linux). ბოლო რამდენიმე წლის განმავლობაში სწრაფი იტერაციის შემდეგ, ის აქტიურად ასტაბილურებს თავის ფუნქციონალურობას, რადგან ის კრიტიკულად მნიშვნელოვანი ხდება მთელ მსოფლიოში წარმოების სამუშაო დატვირთვებისთვის.

Camunda BPM Engine ადვილად დაუკავშირდება სხვა აპლიკაციებს, რომლებიც მუშაობენ იმავე კლასტერზე, ხოლო Kubernetes უზრუნველყოფს შესანიშნავ მასშტაბურობას, რაც საშუალებას გაძლევთ გაზარდოთ ინფრასტრუქტურის ხარჯები მხოლოდ მაშინ, როდესაც ნამდვილად საჭიროა (და მარტივად შეამციროთ ისინი საჭიროებისამებრ).

მონიტორინგის ხარისხი ასევე მნიშვნელოვნად გაუმჯობესებულია ისეთი ინსტრუმენტებით, როგორიცაა Prometheus, Grafana, Loki, Fluentd და Elasticsearch, რაც საშუალებას გაძლევთ ცენტრალურად ნახოთ ყველა სამუშაო დატვირთვა კლასტერში. დღეს ჩვენ განვიხილავთ, თუ როგორ უნდა დანერგოთ პრომეთეს ექსპორტიორი Java ვირტუალურ მანქანაში (JVM).

მიზნები

მოდით შევხედოთ რამდენიმე სფეროს, სადაც შეგვიძლია Camunda BPM Docker სურათის მორგება (გითუბი) ისე, რომ ის კარგად ურთიერთქმედებს Kubernetes-თან.

ჟურნალები და მეტრიკა;
მონაცემთა ბაზის კავშირები;
ავთენტიფიკაცია;
სესიის მენეჯმენტი.

ჩვენ განვიხილავთ ამ მიზნების მისაღწევად რამდენიმე გზას და ნათლად ვაჩვენებთ მთელ პროცესს.

შენიშვნა: იყენებთ Enterprise ვერსიას? შეხედე აქ და საჭიროების შემთხვევაში განაახლეთ სურათების ბმულები.

სამუშაო პროცესის განვითარება

ამ დემო ვერსიაში ჩვენ გამოვიყენებთ Skaffold-ს Docker სურათების შესაქმნელად Google Cloud Build-ის გამოყენებით. მას აქვს კარგი მხარდაჭერა სხვადასხვა ხელსაწყოებისთვის (როგორიცაა Kustomize და Helm), CI და build ინსტრუმენტები და ინფრასტრუქტურის პროვაიდერები. ფაილი skaffold.yaml.tmpl მოიცავს Google Cloud Build-ისა და GKE-ის პარამეტრებს, რაც უზრუნველყოფს წარმოების დონის ინფრასტრუქტურის გაშვების ძალიან მარტივ გზას.

make skaffold ჩატვირთავს Dockerfile კონტექსტს Cloud Build-ში, ააშენებს სურათს და შეინახავს მას GCR-ში და შემდეგ გამოიყენებს მანიფესტებს თქვენს კლასტერზე. ამას აკეთებს make skaffold, მაგრამ Skaffold-ს ბევრი სხვა ფუნქცია აქვს.

Yaml-ის შაბლონებისთვის Kubernetes-ში, ჩვენ ვიყენებთ kustomize-ს, რათა ვმართოთ yaml გადაფარვები მთელი მანიფესტის გატეხვის გარეშე, რაც საშუალებას გაძლევთ გამოიყენოთ git pull --rebase შემდგომი გაუმჯობესებისთვის. ახლა კუბექტლშია და საკმაოდ კარგად მუშაობს ასეთ რამეებზე.

ჩვენ ასევე ვიყენებთ envsubst-ს ჰოსტის სახელის და GCP პროექტის ID-ის დასამატებლად *.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-ში, ამიტომ გვერდითი კარის კონტეინერები არც ისე ეფექტურია. მოდით დავაკავშიროთ jmx_ექსპორტიორი ღია წყარო Prometheus-დან JVM-მდე მისი დამატებით კონტეინერის სურათზე, რომელიც უზრუნველყოფს გზას /metrics სხვა პორტზე.

დაამატეთ Prometheus jmx_exporter კონტეინერში

-- images/camunda-bpm/Dockerfile FROM camunda/camunda-bpm-platform:tomcat-7.11.0

## პრომეთეს ექსპორტიორის დამატება
გაუშვით 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 არის რეზერვირებული prometheus-jmx პორტი
გარემო 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 მხოლოდ ერთ-ერთი მათგანია, ამიტომ ექსპორტიორს დამატებითი კონფიგურაცია სჭირდება. ხელმისაწვდომია ტომკატის, ველური ბუზის, კაფკას და ა.შ. სტანდარტული კონფიგურაციები აქ. ჩვენ დავამატებთ tomcat როგორც ConfigMap Kubernetes-ში და შემდეგ დაამონტაჟეთ როგორც მოცულობა.

პირველ რიგში, ჩვენ ვამატებთ ექსპორტიორის კონფიგურაციის ფაილს ჩვენს პლატფორმაზე/config/ დირექტორიაში

platform/config └── prometheus-jmx.yaml

შემდეგ დავამატებთ ConfigMapGenerator в 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 [...]

მშვენიერია. თუ პრომეთე არ არის კონფიგურირებული სრული გასუფთავებისთვის, შეიძლება მოგიწიოთ უთხარით, რომ გაასუფთავოს ღეროები. პრომეთეს ოპერატორის მომხმარებლებს შეუძლიათ გამოიყენონ service-monitor.yaml დასაწყებად. Გამოკვლევა Service-monitor.yaml, ოპერატორის დიზაინი и ServiceMonitorSpec სანამ დაიწყებ.

ამ ნიმუშის გაფართოება სხვა გამოყენების შემთხვევებზე

ყველა ფაილი, რომელსაც ჩვენ დავამატებთ ConfigMapGenerator-ში, ხელმისაწვდომი იქნება ახალ დირექტორიაში /etc/config. თქვენ შეგიძლიათ გააფართოვოთ ეს შაბლონი თქვენთვის საჭირო ნებისმიერი სხვა კონფიგურაციის ფაილის დასამონტაჟებლად. თქვენ შეგიძლიათ ახალი გაშვების სკრიპტის დამონტაჟებაც კი. Შეგიძლია გამოიყენო ქვეგზა ინდივიდუალური ფაილების დამონტაჟება. xml ფაილების განახლებისთვის განიხილეთ გამოყენება xmlstarlet სედ-ის ნაცვლად. ის უკვე შედის სურათში.

ჟურნალები

Დიდი ამბები! აპლიკაციის ჟურნალები უკვე ხელმისაწვდომია 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 მილსადენის მეშვეობით − Mozilla SOPS - ძალიან კარგად იმუშავებს Kustomize Secrets-თან ერთად. არსებობს სხვა ინსტრუმენტები, როგორიცაა dotGPG, რომლებიც ასრულებენ მსგავს ფუნქციებს: HashiCorp სარდაფით, საიდუმლო ღირებულების დანამატების მორგება.

Ingress

თუ არ აირჩევთ ადგილობრივი პორტის გადამისამართების გამოყენებას, დაგჭირდებათ კონფიგურირებული Ingress Controller. თუ არ იყენებ ingress-nginx (ჩაფხუტის სქემა) მაშინ დიდი ალბათობით უკვე იცით, რომ საჭირო ანოტაციების დაყენება გჭირდებათ ingress-patch.yaml.tmpl ან platform/ingress.yaml. თუ იყენებთ ingress-nginx-ს და ხედავთ nginx-ის შეყვანის კლასს დატვირთვის ბალანსერით, რომელიც მიუთითებს მასზე და გარე DNS ან wildcard 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 on localhost:8080/camunda

დაელოდეთ რამდენიმე წუთს, სანამ ტომარა მთლიანად მზად იქნება. Cert-მენეჯერს გარკვეული დრო დასჭირდება დომენის სახელის გადამოწმებას. შემდეგ შეგიძლიათ აკონტროლოთ ჟურნალები ხელმისაწვდომი ხელსაწყოების გამოყენებით, როგორიცაა ინსტრუმენტი, როგორიცაა kubetail, ან უბრალოდ kubectl-ის გამოყენებით:

kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f

შემდეგი ნაბიჯები

ავტორიზაცია

ეს უფრო მეტად ეხება Camunda BPM-ის კონფიგურაციას, ვიდრე Kubernetes-ს, მაგრამ მნიშვნელოვანია აღინიშნოს, რომ ნაგულისხმევად, ავთენტიფიკაცია გამორთულია REST API-ში. Შენ შეგიძლია ძირითადი ავთენტიფიკაციის ჩართვა ან გამოიყენეთ სხვა მეთოდი, როგორიცაა J.W.T.. თქვენ შეგიძლიათ გამოიყენოთ კონფიგურაციის რუკები და ტომები xml ჩასატვირთად, ან xmlstarlet (იხ. ზემოთ) სურათზე არსებული ფაილების რედაქტირებისთვის, ან გამოიყენოთ wget ან ჩატვირთოთ ისინი საწყისი კონტეინერის და გაზიარებული ტომის გამოყენებით.

სესიის მენეჯმენტი

ბევრი სხვა აპლიკაციის მსგავსად, Camunda BPM ამუშავებს სესიებს JVM-ში, ასე რომ, თუ გსურთ მრავალი ასლის გაშვება, შეგიძლიათ ჩართოთ წებოვანი სესიები (მაგალითად ingress-nginx-ისთვის), რომელიც იარსებებს მანამ, სანამ რეპლიკა არ გაქრება, ან დააყენეთ 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/ &&

სედ -ი '/^ /ი
<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="redis://redis-proxy.db:22121"
წებოვანი="ყალბი"
sessionBackupAsync="ყალბი"
storageKeyPrefix="კონტექსტი"
დაბლოკვის რეჟიმი = "ავტომატური"
/>' conf/context.xml

შენიშვნა: შეგიძლიათ გამოიყენოთ xmlstarlet sed-ის ნაცვლად

ჩვენ გამოვიყენეთ twemproxy Google Cloud Memorystor-ის წინ, თან memcached-session-manager (მხარდაჭერილია Redis) გასაშვებად.

სკალირება

თუ უკვე გესმით სესიები, მაშინ პირველი (და ხშირად ბოლო) შეზღუდვა Camunda BPM-ის სკალირებისას შეიძლება იყოს მონაცემთა ბაზასთან კავშირი. ნაწილობრივი პერსონალიზაცია უკვე ხელმისაწვდომია "ყუთიდან" მოდით ასევე გამორთოთ intialSize ფაილში settings.xml. დამატება ჰორიზონტალური პოდის ავტოსკალერი (HPA) და თქვენ შეგიძლიათ მარტივად ავტომატურად გააფართოვოთ წიპწების რაოდენობა.

მოთხოვნები და შეზღუდვები

В 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