A përdorni Kubernetes? A jeni gati të transferoni instancat tuaja të Camunda BPM nga makina virtuale, apo ndoshta thjesht të provoni t'i запуска ili në Kubernetes? Le të shqyrtojmë disa konfiguracione të zakonshme dhe elemente të veçanta që mund të përshtaten sipas nevojave tuaja specifike.
Supozohen se keni përdorur më parë Kubernetes. Nëse jo, pse të mos shikoni në dhe të filloni klasterin tuaj të parë?
Autorët
- — inxhinier i lartë për besueshmërinë e faqes në ekipin e Camunda Cloud;
- — inxhinier DevOps në Camunda.
Në përmbledhje, është:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Mirë, ndoshta nuk ka funksionuar, pasi nuk keni instaluar skaffold dhe kustomize. Atëherë vazhdoni të lexoni!
Çfarë është Camunda BPM
Camunda BPM është një platformë me burim të hapur për menaxhimin e proceseve të biznesit dhe automatizimin e vendimeve, që bashkon përdoruesit e biznesit dhe zhvilluesit e softuerit. Ajo është ideale për koordinimin dhe bashkimin e njerëzve, (mikro) shërbimeve ose madje edhe robotëve! Lexoni më shumë rreth mundësive të ndryshme të përdorimit në .
Pse të përdorni Kubernetes
Kubernetes është bërë standardi de facto për ekzekutimin e aplikacioneve moderne në Linux. Duke përdorur thirrje sistemore në vend të emulimit të nivelit harduerik dhe kapacitetet e bërthamës për menaxhimin e memories dhe përndrrimit të detyrave, koha e ngarkesës dhe koha e ekzekutimit minimizohen. Megjithatë, përfitimi më i madh mund të vijë nga API standard që Kubernetes ofron për konfigurimin e infrastrukturës që nevojitet për të gjitha aplikacionet: ruajtje, rrjet dhe monitorim. Në qershor 2020, ai festoi 6 vjetorin e tij, dhe ndoshta është projekti më i madh me burim të hapur (pas Linux). Kohët e fundit, ai është duke stabilizuar funksionalitetin e tij pas një itere të shpejtë të disa viteve, pasi kjo bëhet jetësore për ngarkesat prodhuese në të gjithë botën.
Camunda BPM Engine mund të lidhet lehtësisht me aplikacione të tjera që funksionojnë në të njëjtin klaster, dhe Kubernetes ofron shkallëzueshmëri të shkëlqyer, duke lejuar rritjen e kostove të infrastrukturës vetëm kur është vërtet e nevojshme (dhe lehtë reduktimin e tyre sipas nevojës).
Cilësia e monitorimit gjithashtu përmirësohet ndjeshëm me mjete të tilla si Prometheus, Grafana, Loki, Fluentd dhe Elasticsearch, duke lejuar shikimin e centralizuar të të gjitha ngarkesave të punës në klaster. Sot do të shqyrtojmë se si të implementojmë eksportuesin Prometheus në makinat Java (JVM).
Qëllimet
Le të shqyrtojmë disa fusha ku mund të përshtatim imazhin Docker të Camunda BPM (), në mënyrë që ai të bashkëpunojë mirë me Kubernetes.
- Dëgjimet dhe metrikat;
- Lidhjet me bazën e të dhënave;
- Autentikimi;
- Menaxhimi i seancave.
Do të shqyrtojmë disa mënyra për të arritur këto qëllime dhe do të ilustrojmë të gjithë procesin.
Shënim: A po përdorni versionin Enterprise? Shikoni dhe azhurnoni lidhjet me imazhet sipas nevojës.
Zhvillimi i punës
Në këtë demonstrim do të përdorim Skaffold për të ndërtuar imazhe Docker duke përdorur Google Cloud Build. Ai ka mbështetje të shkëlqyer për mjete të ndryshme (si Kustomize dhe Helm), CI dhe mjete ndërtimi, si dhe ofrues të infrastrukturës. Skedari skaffold.yaml.tmpl përfshin konfigurimet për Google Cloud Build dhe GKE, që siguron një mënyrë shumë të thjeshtë për të nisur infrastrukturën në nivel industrial.
make skaffold do të ngarkojë kontekstin Dockerfile në Cloud Build, do të krijojë një imazh dhe do ta ruajë atë në GCR, dhe pastaj do të aplikojë manifestet në klasterin tuaj. Kjo është ajo që bën make skaffold, por Skaffold ka shumë mundësi të tjera.
Për shabllonat yaml në Kubernetes ne përdorim kustomize për të menaxhuar mbivendosjet yaml pa treguar të gjithë manifestin, duke ju lejuar të përdorni git pull --rebase për përmirësime të tjera. Aktualisht, është në kubectl dhe kjo funksionon mirë për këto gjëra.
Gjithashtu përdorim envsubst për të mbushur emrin e hostit dhe identifikuesin e projektit GCP në skedarët * .yaml.tmpl. Mund të shikoni se si funksionon në makefile ose thjesht vazhdoni përpara.
Kërkesat e nevojshme
- Një klaster funksional
- — për të krijuar imazhe docker dhe për të lehtësuar shpërndarjen në GKE
- Një kopje e këtij kodi
- Envsubst
Puna me manifestet
Nëse nuk dëshironi të përdorni kustomize ose skaffold, mund të referoheni në manifestet në generated-manifest.yaml dhe t’i përshtatni ato në procesin e punës sipas zgjedhjes tuaj.
Dëgjimet dhe metrikat
Prometheus është bërë standart për grumbullimin e metrikeve në Kubernetes. Ai zë të njëjtën nişë si AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics dhe të tjera. Ai ka kod të hapur dhe një gjuhë kërkese të fuqishme. Vizualizimin do ta marrë Grafana — ajo vjen me një numër të madh panelesh monitorimi të disponueshme jashtë kutisë. Ato janë të lidhura me njëra-tjetrën dhe janë relativisht të lehta për t'u instaluar me .
Në mënyrë të parazgjedhur, Prometheus përdor modelin e tërheqjes /metrics, dhe shtimi i kontejnerëve sidecar për këtë është një praktikë e zakonshme. Fatkeqësisht, metrike JMX regjistrohen më së miri brenda JVM, prandaj kontejnerët sidecar nuk janë aq efektivë. Le të lidhemi me kod të hapur nga Prometheus me JVM, duke e shtuar atë në imazhin e kontejnerit, i cili do të ofrojë një rrugë /metrics në një port tjetër.
Shto Prometheus jmx_exporter në kontejner
-- 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
Mirë, kjo ishte e lehtë. Eksportuesi do të monitorojë tomcat-in dhe do të shfaqë metrike të tij në formatin Prometheus në adresën :9404/metrics
Konfigurimi i eksportuesit
Lexuesi i kujdesshëm mund të pyesë, nga ku erdhi prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны . Ne do të shtojmë tomcat si në Kubernetes, dhe më pas do ta montojmë atë si një volum.
Së pari, ne shtojmë skedarin e konfigurimit të eksportuesit në direktorinë tonë platform/config/
platform/config
└── prometheus-jmx.yaml
Më pas, ne shtojmë në kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
skedarët:
- config/prometheus-jmx.yaml
Kjo do të shtojë çdo element files[] si një element të ConfigMap. ConfigMapGenerators janë të mira sepse ato hash-ojnë të dhënat në konfigurim dhe nisin rinisjen e pod-it nëse ato ndryshojnë. Ato gjithashtu reduktojnë volumin e konfigurimit në Deployment, sepse mund të montoni të gjithë "folderin" e skedarëve të konfigurimit në një VolumeMount.
Në fund, na nevojitet të montojmë ConfigMap si një volum në pod-in:
-- 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
[...]
Shkëlqyeshëm. Nëse Prometheus nuk është i konfiguruar për pastrimin e plotë, mund t'ju duhet të i thoni që të pastroni pod-ët. Përdoruesit e Prometheus Operator mund të përdorin service-monitor.yaml për të filluar. Hidhni një sy Service-monitor.yaml, dhe para se të filloni.
Zgjerimi i këtij modeli në raste të tjera të përdorimit
Të gjitha skedarët që ne shtojmë në ConfigMapGenerator do të jenë të disponueshëm në katalogun e ri /etc/config. Ju mund ta shkëputni këtë model për të montuar çdo skedar tjetër konfigurimi që keni nevojë. Mund të montoni madje një skenar të ri nisjeje. Mund të përdorni për të montuar skedarë të veçantë. Për azhurnimin e skedarëve xml, konsideroni përdorimin e në vend të sed. Ai është tashmë i përfshirë në imazh.
Ditaret
Lajme të shkëlqyera! Ditaret e aplikacioneve janë tashmë të disponueshme në stdout, për shembull, me kubectl logs. Fluentd (ai është instaluar parazgjedhje në GKE) do të drejtojë ditaret tuaja në Elasticsearch, Loki ose në platformën tuaj të korporatës për ditarët. Nëse dëshironi të përdorni jsonify për ditaret, mund të ndiqni modelin e mësipërm për instalimin .
Baza e të dhënave
Në mënyrë të parazgjedhur, imazhi do të ketë një bazë të dhënash H2. Kjo nuk na përshtatet, dhe ne do të përdorim Google Cloud SQL me Cloud SQL Proxy — kjo do të jetë e nevojshme më vonë për zgjidhjen e detyrave të brendshme. Kjo është një zgjidhje e thjeshtë dhe e besueshme, nëse nuk keni preferenca të tjera për konfigurimin e bazës së të dhënave. AWS RDS ofron një shërbim të ngjashëm.
Pavarësisht nga baza e të dhënave që zgjidhni, përveç nëse ajo është H2, do t'ju duhet të vendosni variablat përkatëse të mjedisit në platform/deploy.yaml. Kjo duket rreth kësaj:
-- platform/deployment.yaml
apiVersion: apps/v1
kind: Deployment
[...]
spec:
template:
spec:
[...]
containers:
- name: camunda-bpm
env:
- emri: DB_DRIVER
vlera: org.postgresql.Driver
- emri: DB_URL
vlera: jdbc:postgresql://postgres-proxy.db:5432/process-engine
- emri: DB_USERNAME
vleraNga:
referencëÇelësiSecret:
emri: cambpm-db-credentials
çelësi: db_username
- emri: DB_PASSWORD
vleraNga:
referencëÇelësiSecret:
emri: cambpm-db-credentials
çelësi: db_password
[...]
Shënim: Mund të përdorni Kustomize për të vendosur në mjedise të ndryshme duke përdorur mbuluar: .
Shënim: përdorimi valueFrom: secretKeyRef. Ju lutem, përdorni edhe gjatë zhvillimit, për të ruajtur sekretet tuaja të sigurta.
Ka të ngjarë që ju tashmë keni një sistem preferencial të menaxhimit të sekretëve Kubernetes. Nëse jo, ja disa mundësi: enkriptimi i tyre me KMS nga ofruesi juaj i cloud-it, dhe më pas rreshtimi i tyre në K8S si sekrete përmes një pipeline CD — do të funksionojë shumë mirë me sekretet Kustomize. Ka edhe mjete të tjera, të tilla si dotGPG — ato kryejnë funksione të ngjashme: , .
Ingress
Përveç nëse vendosni të përdorni përcjelljen lokale të portit, do të keni nevojë për një Ingress Controller të konfiguruar. Nëse nuk jeni duke përdorur () atëherë, me siguri, tashmë e dini se duhet të vendosni anotacionet e nevojshme në ingress-patch.yaml.tmpl ose platform/ingress.yaml. Nëse po përdorni ingress-nginx dhe shihni klasën nginx ingress me një balancues ngarkese që e tregon atë dhe DNS-in e jashtëm ose një regjistrim DNS të zëvendësimit, gjithçka është gati. Përndryshe, konfiguroni Ingress Controller dhe DNS-in ose kaloni këto hapa dhe lëreni lidhjen direkte me pod-in.
TLS
Nëse po përdorni ose kube-lego dhe letsencrypt — certifikatat për hyrje të re do të merren automatikisht. Në rast të kundërt, hapni ingress-patch.yaml.tmpl dhe konfiguroni atë sipas nevojave tuaja.
Fillimi!
Nëse keni ndjekur gjithçka që është shkruar më sipër, ekipi make skaffold HOSTNAME= duhet të nisë një instancë të qasshme në /camunda
Nëse nuk keni ekspozuar hyrjen përmes një URL publike, mund ta ridrejtoni atë nga localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 në localhost:8080/camunda
Prisni disa minuta derisa tomcat të jetë plotësisht gati. Cert-manager do të ketë nevojë për disa kohë për të verifikuar emrin e domainit. Pas kësaj, mund të ndiqni logjet duke përdorur mjetet në dispozicion — për shembull, një mjet të tillë si kubetail, ose thjesht me kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Hapat e ardhshëm
Autorizimi
Kjo është më shumë e lidhur me konfigurimin e Camunda BPM sesa me Kubernetes, por është e rëndësishme të theksohet se, si haptazi, në REST API, autentifikimi është i çaktivizuar. Mund të apo të përdorni një metodë tjetër, për shembull . Mund të përdorni configmaps dhe volumet për të ngarkuar xml, ose xmlstarlet (shih më sipër) për të redaktuar skedarët ekzistues në imazh, dhe gjithashtu mund të përdorni wget, ose t'i ngarkoni ato me ndihmën e një kontejneri init dhe një volumi të përbashkët.
Menaxhimi i seancave
Ashtu si shumë aplikacione të tjera, Camunda BPM trajton seancat në JVM, prandaj, nëse dëshironi të nisni disa replika, mund të aktivizoni seancat ngjitëse (), të cilat do të ekzistojnë derisa replica të zhduket, ose të vendosni atributin Max-Age për cookies. Si një zgjidhje më të besueshme, mund të vendosni Menaxherin e Seancave në Tomcat. Lars ka në këtë temë, por diçka si:
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 '/^/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
Shënim: mund të përdorni xmlstarlet në vend të sed
Ne përdorëm para Google Cloud Memorystore, me (mbështet Redis) për ta operuar atë.
Shkallëzimi
Nëse keni arritur të menaxhoni seancat, atëherë kufiri i parë (dhe shpesh i fundit) për skalimin e Camunda BPM mund të jetë lidhja me databazën. Një konfigurim i pjesshëm është i disponueshëm "". Gjithashtu, çaktivizoni intialSize në skedarin settings.xml. Shtoni dhe do të jeni në gjendje të shkalloni automatikisht numrin e pods.
Kërkesat dhe kufizimet
Në platform/deployment.yaml do të shihni se ne kemi koduar ngushtë fushën e burimeve. Kjo funksionon mirë me HPA, por mund të kërkohet konfigurim shtesë. Përdorni patch kustomize. Shih. ingress-patch.yaml.tmpl dhe ./kustomization.yaml.tmpl
Përfundim
Ja, ne e instaluam Camunda BPM në Kubernetes me metrika Prometheus, logje, databazë H2, TLS dhe Ingress. Shtuam skedarët jar dhe skedarët e konfigurimit duke përdorur ConfigMaps dhe Dockerfile. Diskutuam për shkëmbimin e të dhënave me volumet dhe drejtpërdrejt në variablat e ambientit nga sekretet. Krahas kësaj, ofruam një përmbledhje të konfigurimit të Camunda për disa replika dhe API të autentifikuar.
Linke
github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes
│
├── generated-manifest.yaml <- manifest për përdorim pa kustomize
├── images
│ └── camunda-bpm
│ └── Dockerfile <- imazhi i mbushjes së docker
├── ingress-patch.yaml.tmpl <- konfigurimi i hyrjes specifik për site
├── kustomization.yaml.tmpl <- Kustomizimi kryesor
├── Makefile <- targetet e bërjes
├── namespace.yaml
├── platform
│ ├── config
│ │ └── prometheus-jmx.yaml <- skedari i konfigurimit të eksportuesit prometheus
│ ├── deployment.yaml <- bërja kryesore
│ ├── ingress.yaml
│ ├── kustomization.yaml <- kustomizimi "bazë"
│ ├── service-monitor.yaml <- shembulli i konfigurimit të prometheus-operator
│ └── service.yaml
└── skaffold.yaml.tmpl <- direktivat e skafold
05.08.2020, përkthim Alastair Firth, Lars Lange
Burimi: habr.com
