Kubernetes istifadə edirsiniz? Camunda BPM nümunələrini virtual maşınlardan köçürməyə hazırsınız və ya sadəcə onları Kubernetes-də işə salmağa cəhd edin? Xüsusi ehtiyaclarınıza uyğunlaşdırıla bilən bəzi ümumi konfiqurasiyalara və fərdi maddələrə baxaq.
Daha əvvəl Kubernetes istifadə etdiyinizi güman edir. Yoxdursa, niyə baxmayaq və ilk klasterinizi başlatmırsınız?
Müəlliflər
- (Alastair Firth) - Camunda Cloud komandasında Saytın Etibarlılığı üzrə Baş Mühəndis;
- (Lars Lange) - Camunda-da DevOps mühəndisi.
Qısa:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Yaxşı, yəqin ki, işləməyib, çünki sizdə skaffold və kustomize quraşdırılmayıb. Yaxşı, sonra oxuyun!
Camunda BPM nədir
Camunda BPM biznes istifadəçilərini və proqram təminatı tərtibatçılarını birləşdirən açıq mənbəli biznes proseslərinin idarə edilməsi və qərarların avtomatlaşdırılması platformasıdır. İnsanları, (mikro) xidmətləri və hətta botları əlaqələndirmək və əlaqələndirmək üçün idealdır! Müxtəlif istifadə halları haqqında ətraflı oxuya bilərsiniz .
Niyə Kubernetes istifadə edin
Kubernetes Linux-da müasir proqramların işlədilməsi üçün faktiki standart halına gəldi. Avadanlıq emulyasiyası və nüvənin yaddaş və tapşırıqların dəyişdirilməsini idarə etmək qabiliyyəti əvəzinə sistem zənglərindən istifadə etməklə, yükləmə vaxtı və işə başlama vaxtı minimuma endirilir. Bununla belə, ən böyük fayda Kubernetes-in bütün tətbiqlər üçün tələb olunan infrastrukturu konfiqurasiya etmək üçün təmin etdiyi standart API-dən gələ bilər: saxlama, şəbəkə və monitorinq. 2020-ci ilin iyununda 6 yaşı tamam oldu və bəlkə də ikinci ən böyük açıq mənbə layihəsidir (Linux-dan sonra). O, son bir neçə il ərzində sürətli iterasiyadan sonra öz funksionallığını aktiv şəkildə sabitləşdirir, çünki bütün dünyada istehsal iş yükləri üçün kritik hala gəlir.
Camunda BPM Mühərriki eyni klasterdə işləyən digər proqramlara asanlıqla qoşula bilir və Kubernetes əla miqyaslılığı təmin edir, infrastruktur xərclərini yalnız həqiqətən ehtiyac duyulduqda artırmağa (və ehtiyac olduqda onları asanlıqla azaltmağa) imkan verir.
Monitorinqin keyfiyyəti Prometheus, Grafana, Loki, Fluentd və Elasticsearch kimi alətlərlə də xeyli yaxşılaşdırılıb və bu, bir klasterdə bütün iş yüklərinə mərkəzləşdirilmiş şəkildə baxmaq imkanı verir. Bu gün biz Prometheus ixracatçısının Java Virtual Maşınına (JVM) necə tətbiq olunacağına baxacağıq.
Məqsədlər
Camunda BPM Docker görüntüsünü fərdiləşdirə biləcəyimiz bir neçə sahəyə baxaq () beləliklə Kubernetes ilə yaxşı qarşılıqlı əlaqədə olur.
- Qeydlər və ölçülər;
- Verilənlər bazası əlaqələri;
- İdentifikasiyası;
- Sessiyanın idarə edilməsi.
Bu məqsədlərə çatmağın bir neçə yolunu nəzərdən keçirəcəyik və bütün prosesi aydın şəkildə göstərəcəyik.
Qeyd: Enterprise versiyasından istifadə edirsiniz? Bax və lazım olduqda şəkil bağlantılarını yeniləyin.
İş axınının inkişafı
Bu demoda biz Google Cloud Build-dən istifadə edərək Docker şəkillərini yaratmaq üçün Skaffold-dan istifadə edəcəyik. Müxtəlif alətlər (Kustomize və Helm kimi), CI və qurma alətləri və infrastruktur təminatçıları üçün yaxşı dəstəyə malikdir. Fayl skaffold.yaml.tmpl istehsal səviyyəli infrastrukturu idarə etmək üçün çox sadə üsul təmin edən Google Cloud Build və GKE üçün parametrləri ehtiva edir.
make skaffold Dockerfile kontekstini Cloud Build-ə yükləyəcək, şəkli yaradacaq və GCR-də saxlayacaq və sonra manifestləri klasterinizə tətbiq edəcək. Etdiyi budur make skaffold, lakin Skaffoldun bir çox başqa xüsusiyyətləri var.
Kubernetesdəki yaml şablonları üçün biz bütün manifesti çəngəlləmədən yaml örtüklərini idarə etmək üçün kustomize-dən istifadə edirik. git pull --rebase daha da təkmilləşdirmələr üçün. İndi kubectl-dədir və belə şeylər üçün olduqca yaxşı işləyir.
Biz həmçinin *.yaml.tmpl fayllarında host adını və GCP layihə ID-sini doldurmaq üçün envsubst-dan istifadə edirik. Bunun necə işlədiyini görə bilərsiniz makefile və ya sadəcə davam edin.
Ön şərtlər
- İş klasteri
- - öz docker şəkillərinizi yaratmaq və GKE-də asan yerləşdirmə üçün
- Bu kodun surəti
- Envsubst
Manifestlərdən istifadə edərək iş axını
Kustomize və ya skaffold istifadə etmək istəmirsinizsə, aşağıdakı manifestlərə müraciət edə bilərsiniz. generated-manifest.yaml və onları seçdiyiniz iş prosesinə uyğunlaşdırın.
Qeydlər və ölçülər
Prometey Kubernetes-də ölçüləri toplamaq üçün standart halına gəldi. O, AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics və başqaları ilə eyni yeri tutur. Açıq mənbədir və güclü sorğu dilinə malikdir. Vizuallaşdırmanı Grafana-ya həvalə edəcəyik - o, qutudan çıxarılan çoxlu sayda tablosuna malikdir. Onlar bir-birinə bağlıdır və quraşdırmaq nisbətən asandır .
Varsayılan olaraq, Prometey ekstraksiya modelindən istifadə edir <service>/metrics, və bunun üçün yan araba konteynerlərinin əlavə edilməsi adi haldır. Təəssüf ki, JMX ölçüləri JVM-də ən yaxşı şəkildə daxil edilir, ona görə də yan vaqon konteynerləri o qədər də səmərəli deyil. Qoşulsun Prometheus-dan JVM-ə yolu təmin edəcək konteyner şəklinə əlavə edərək açıq mənbə /metrics fərqli bir limanda.
Konteynerə Prometheus jmx_exporter əlavə edin
-- 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
Yaxşı, bu asan idi. İxracatçı Tomcat-a nəzarət edəcək və onun ölçülərini Prometheus formatında göstərəcək <svc>:9404/metrics
İxracatçının qurulması
Diqqətli oxucu bunun haradan gəldiyini düşünə bilər prometheus-jmx.yaml? JVM-də işləyə bilən çoxlu müxtəlif şeylər var və tomcat onlardan yalnız biridir, ona görə də ixracatçıya bəzi əlavə konfiqurasiya lazımdır. Tomcat, wildfly, kafka və sair üçün standart konfiqurasiyalar mövcuddur . Tomcat kimi əlavə edəcəyik Kubernetes-də və sonra onu həcm kimi quraşdırın.
Əvvəlcə ixracatçı konfiqurasiya faylını platforma/config/ kataloqumuza əlavə edirik
platform/config
└── prometheus-jmx.yaml
Sonra əlavə edirik в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Bu, hər bir elementi əlavə edəcəkdir files[] ConfigMap konfiqurasiya elementi kimi. ConfigMapGenerators əladır, çünki konfiqurasiya məlumatlarını hash edir və dəyişdikdə podu yenidən işə salmağa məcbur edir. Konfiqurasiya fayllarının bütün "qovluğunu" bir VolumeMount-a quraşdıra bildiyiniz üçün onlar həmçinin Yerləşdirmədə konfiqurasiyanın miqdarını azaldırlar.
Nəhayət, ConfigMap-ı podda bir həcm kimi quraşdırmalıyıq:
-- 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
[...]
Möhtəşəm. Əgər Prometey tam təmizləmə aparmaq üçün konfiqurasiya olunmayıbsa, siz ona podları təmizləməyi deməli ola bilərsiniz. Prometheus Operator istifadəçiləri istifadə edə bilər service-monitor.yaml başlamaq üçün. Araşdırın Service-monitor.yaml, и başlamazdan əvvəl.
Bu nümunəni digər istifadə hallarına genişləndirmək
ConfigMapGenerator-a əlavə etdiyimiz bütün fayllar yeni kataloqda mövcud olacaq /etc/config. Siz lazım olan hər hansı digər konfiqurasiya fayllarını quraşdırmaq üçün bu şablonu genişləndirə bilərsiniz. Siz hətta yeni başlanğıc skriptini quraşdıra bilərsiniz. İstifadə edə bilərsən fərdi faylları quraşdırmaq üçün. xml fayllarını yeniləmək üçün istifadə etməyi düşünün sed əvəzinə. Artıq şəkilə daxil edilib.
Jurnallar
Əla xəbər! Tətbiq qeydləri artıq stdout-da mövcuddur, məsələn kubectl logs. Fluentd (standart olaraq GKE-də quraşdırılıb) qeydlərinizi Elasticsearch, Loki və ya müəssisə giriş platformanıza yönləndirəcək. Qeydlər üçün jsonify istifadə etmək istəyirsinizsə, quraşdırmaq üçün yuxarıdakı şablona əməl edə bilərsiniz .
Verilənlər bazası
Varsayılan olaraq, təsvirin H2 verilənlər bazası olacaq. Bu, bizim üçün uyğun deyil və biz Cloud SQL Proxy ilə Google Cloud SQL-dən istifadə edəcəyik - bu, daxili problemləri həll etmək üçün daha sonra lazım olacaq. Verilənlər bazasını qurmaqda öz seçimləriniz yoxdursa, bu sadə və etibarlı seçimdir. AWS RDS oxşar xidməti təqdim edir.
Seçdiyiniz verilənlər bazasından asılı olmayaraq, H2 olmadığı təqdirdə, müvafiq mühit dəyişənlərini təyin etməlisiniz. platform/deploy.yaml. Bu kimi bir şey görünür:
-- 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
[...]
Qeyd: Üst qatdan istifadə edərək müxtəlif mühitlərə yerləşdirmək üçün Kustomize istifadə edə bilərsiniz: .
Qeyd: istifadə valueFrom: secretKeyRef. Zəhmət olmasa istifadə edin sirlərinizi təhlükəsiz saxlamaq üçün inkişaf zamanı belə.
Çox güman ki, artıq Kubernetes sirlərini idarə etmək üçün üstünlük verdiyiniz sistem var. Əgər belə deyilsə, burada bəzi seçimlər var: Onları bulud provayderinizin KMS ilə şifrələmək və sonra onları CD boru kəməri vasitəsilə sirr kimi K8S-ə daxil etmək − - Kustomize sirləri ilə birlikdə çox yaxşı işləyəcək. Oxşar funksiyaları yerinə yetirən dotGPG kimi digər alətlər də var: , .
Girme
Yerli port yönləndirməsindən istifadə etməyi seçməsəniz, konfiqurasiya edilmiş Giriş Nəzarətçisinə ehtiyacınız olacaq. Əgər istifadə etmirsinizsə () onda siz çox güman ki, lazımi annotasiyaları quraşdırmalı olduğunuzu artıq bilirsiniz ingress-patch.yaml.tmpl və ya platform/ingress.yaml. Əgər siz ingress-nginx istifadə edirsinizsə və yük balanslaşdırıcısı ona işarə edən və xarici DNS və ya wildcard DNS girişi olan nginx giriş sinifini görürsünüzsə, getməyə hazırsınız. Əks halda, Ingress Controller və DNS-ni konfiqurasiya edin və ya bu addımları atlayın və pod ilə birbaşa əlaqəni saxlayın.
TLS
İstifadə edirsinizsə və ya kube-lego və letsencrypt - yeni giriş üçün sertifikatlar avtomatik olaraq alınacaq. Əks halda, açın ingress-patch.yaml.tmpl və ehtiyaclarınıza uyğunlaşdırın.
Başlayın!
Yuxarıda yazılan hər şeyə əməl etmisinizsə, o zaman əmr make skaffold HOSTNAME=<you.example.com> mövcud nümunəni işə salmalıdır <hostname>/camunda
Girişinizi ictimai URL-ə təyin etməmisinizsə, onu ilə yönləndirə bilərsiniz localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 haqqında localhost:8080/camunda
Tomcat tamamilə hazır olana qədər bir neçə dəqiqə gözləyin. Sertifikat meneceri domen adını yoxlamaq üçün bir qədər vaxt aparacaq. Daha sonra kubetail kimi bir alət kimi mövcud alətlərdən istifadə edərək və ya sadəcə kubectl istifadə edərək qeydlərə nəzarət edə bilərsiniz:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Sonrakı addımlar
Icazə
Bu, Kubernetesdən daha çox Camunda BPM konfiqurasiyasına aiddir, lakin qeyd etmək lazımdır ki, defolt olaraq REST API-də autentifikasiya deaktiv edilib. Bacararsan və ya kimi başqa üsuldan istifadə edin . Siz xml yükləmək üçün konfiqurasiya xəritələrindən və həcmlərdən və ya şəkildəki mövcud faylları redaktə etmək üçün xmlstarlet (yuxarıya bax) və ya wget-dən istifadə edə və ya init konteyneri və paylaşılan həcmdən istifadə edərək onları yükləyə bilərsiniz.
Sessiyanın idarə edilməsi
Bir çox digər proqramlar kimi, Camunda BPM JVM-də seansları idarə edir, ona görə də birdən çox replika işlətmək istəyirsinizsə, yapışqan sessiyaları aktivləşdirə bilərsiniz (), replika yox olana qədər mövcud olacaq və ya kukilər üçün Max-Age atributunu təyin edin. Daha möhkəm həll üçün Tomcat-da Sessiya Menecerini yerləşdirə bilərsiniz. Lars var bu mövzuda, lakin belə bir şey:
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
Qeyd: sed əvəzinə xmlstarlet istifadə edə bilərsiniz
istifadə etdik ilə Google Cloud Memorystore qarşısında (Redis-i dəstəkləyir) onu işə salmaq üçün.
Ölçəkləmə
Əgər siz artıq seansları başa düşürsünüzsə, Camunda BPM-nin miqyasının ölçülməsi üçün ilk (və çox vaxt sonuncu) məhdudiyyət verilənlər bazası ilə əlaqə ola bilər. Qismən fərdiləşdirmə artıq mövcuddur "" Həmçinin settings.xml faylında intialSize-i deaktiv edək. əlavə et və siz podların sayını asanlıqla avtomatik olaraq ölçə bilərsiniz.
İstəklər və məhdudiyyətlər
В platform/deployment.yaml Görəcəksiniz ki, biz resurslar sahəsini kodlaşdırmışıq. Bu, HPA ilə yaxşı işləyir, lakin əlavə konfiqurasiya tələb oluna bilər. Kustomize yaması bunun üçün uyğundur. Santimetr. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
Buraxılış
Beləliklə, Camunda BPM-ni Kubernetes-də Prometheus ölçüləri, qeydləri, H2 verilənlər bazası, TLS və Ingress ilə quraşdırdıq. ConfigMaps və Dockerfile istifadə edərək jar faylları və konfiqurasiya faylları əlavə etdik. Biz məlumatların həcmlərə və birbaşa ətraf mühit dəyişənlərinə sirrlərdən mübadiləsi haqqında danışdıq. Bundan əlavə, biz Camunda-nın çoxsaylı replikalar və təsdiqlənmiş API üçün qurulması haqqında ümumi məlumat verdik.
References
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, tərcümə Alastair Firth, Lars Lange
Mənbə: www.habr.com