A po përdorni Kubernetes? Gati për të zhvendosur instancat tuaja të Camunda BPM nga makinat virtuale, apo ndoshta thjesht provoni t'i ekzekutoni ato në Kubernetes? Le të shohim disa konfigurime të zakonshme dhe artikuj individualë që mund të përshtaten për nevojat tuaja specifike.
Supozon se keni përdorur Kubernetes më parë. Nëse jo, pse të mos hidhni një sy dhe të mos filloni grupin tuaj të parë?
Autorët
- (Alastair Firth) - Inxhinier i lartë i besueshmërisë së sitit në ekipin e Camunda Cloud;
- (Lars Lange) - Inxhinier DevOps në Camunda.
Shkurtimisht:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Mirë, ndoshta nuk funksionoi sepse nuk keni të instaluar skelet dhe kustomize. Epo atëherë lexoni!
Çfarë është Camunda BPM
Camunda BPM është një platformë me burim të hapur të menaxhimit të procesit të biznesit dhe automatizimit të vendimeve që lidh përdoruesit e biznesit dhe zhvilluesit e softuerit. Është ideal për koordinimin dhe lidhjen e njerëzve, (mikro) shërbimeve apo edhe robotëve! Mund të lexoni më shumë rreth rasteve të ndryshme të përdorimit në .
Pse të përdorni Kubernetes
Kubernetes është bërë standardi de fakto për ekzekutimin e aplikacioneve moderne në Linux. Duke përdorur thirrjet e sistemit në vend të emulimit të harduerit dhe aftësinë e kernelit për të menaxhuar memorien dhe ndërrimin e detyrave, koha e nisjes dhe koha e nisjes mbahen në minimum. Sidoqoftë, përfitimi më i madh mund të vijë nga API standarde që Kubernetes ofron për të konfiguruar infrastrukturën e kërkuar nga të gjitha aplikacionet: ruajtja, rrjetëzimi dhe monitorimi. Ai mbushi 2020 vjeç në qershor 6 dhe është ndoshta projekti i dytë më i madh me burim të hapur (pas Linux). Kohët e fundit, ai ka stabilizuar në mënyrë aktive funksionalitetin e tij pas përsëritjes së shpejtë gjatë viteve të fundit, pasi bëhet kritike për ngarkesat e prodhimit në mbarë botën.
Camunda BPM Engine mund të lidhet lehtësisht me aplikacione të tjera që funksionojnë në të njëjtin grup dhe Kubernetes ofron shkallëzim të shkëlqyeshëm, duke ju lejuar të rrisni kostot e infrastrukturës vetëm kur është vërtet e nevojshme (dhe t'i reduktoni lehtësisht sipas nevojës).
Cilësia e monitorimit është përmirësuar gjithashtu shumë me mjete të tilla si Prometheus, Grafana, Loki, Fluentd dhe Elasticsearch, duke ju lejuar të shikoni në qendër të gjitha ngarkesat e punës në një grup. Sot do të shohim se si të implementojmë eksportuesin Prometheus në Makinën Virtuale Java (JVM).
qëllimet
Le të shohim disa fusha ku mund të personalizojmë imazhin e Camunda BPM Docker () në mënyrë që të ndërveprojë mirë me Kubernetes.
- Regjistrat dhe metrikat;
- Lidhjet e bazës së të dhënave;
- Autentifikimi;
- Menaxhimi i sesionit.
Ne do të shikojmë disa mënyra për të arritur këto qëllime dhe do të tregojmë qartë të gjithë procesin.
Shënim: A po përdorni versionin Enterprise? Shikoni dhe përditësoni lidhjet e imazhit sipas nevojës.
Zhvillimi i rrjedhës së punës
Në këtë demonstrim, ne do të përdorim Skaffold për të ndërtuar imazhe Docker duke përdorur Google Cloud Build. Ka mbështetje të mirë për mjete të ndryshme (të tilla si Kustomize dhe Helm), CI dhe mjete ndërtimi dhe ofruesit e infrastrukturës. Skedari skaffold.yaml.tmpl përfshin cilësimet për Google Cloud Build dhe GKE, duke ofruar një mënyrë shumë të thjeshtë për të drejtuar infrastrukturën e nivelit të prodhimit.
make skaffold do të ngarkojë kontekstin Dockerfile në Cloud Build, do të ndërtojë imazhin dhe do ta ruajë në GCR dhe më pas do të aplikojë manifestet në grupin tuaj. Kjo është ajo që bën make skaffold, por Skaffold ka shumë veçori të tjera.
Për shabllonet yaml në Kubernetes, ne përdorim kustomize për të menaxhuar mbivendosjet e yaml pa depërtuar të gjithë manifestin, duke ju lejuar të përdorni git pull --rebase për përmirësime të mëtejshme. Tani është në kubectl dhe funksionon mjaft mirë për gjëra të tilla.
Ne përdorim gjithashtu envsubst për të mbushur emrin e hostit dhe ID-në e projektit GCP në skedarët *.yaml.tmpl. Ju mund të shihni se si funksionon në makefile ose thjesht vazhdoni më tej.
parakushtet
- Grupi i punës
- - për krijimin e imazheve tuaja të dokerit dhe vendosjen e lehtë në GKE
- Kopje e këtij kodi
- Envsubst
Rrjedha e punës duke përdorur manifestet
Nëse nuk dëshironi të përdorni kustomize ose skaffold, mund t'i referoheni manifesteve në generated-manifest.yaml dhe përshtatni ato me rrjedhën e punës sipas zgjedhjes suaj.
Regjistrat dhe metrikat
Prometheus është bërë standardi për mbledhjen e metrikës në Kubernetes. Ai zë të njëjtin vend si AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics dhe të tjerë. Është me burim të hapur dhe ka një gjuhë të fuqishme pyetjesh. Ne do t'ia besojmë vizualizimin Grafana - ajo vjen me një numër të madh tabelash të disponueshme jashtë kutisë. Ato janë të lidhura me njëra-tjetrën dhe janë relativisht të lehta për t'u instaluar .
Si parazgjedhje, Prometheus përdor modelin e nxjerrjes <service>/metrics, dhe shtimi i kontejnerëve të karrigeve anësore për këtë është i zakonshëm. Fatkeqësisht, metrikat JMX regjistrohen më së miri brenda JVM, kështu që kontejnerët e karrigeve anësore nuk janë aq efikase. Le të lidhemi burim i hapur nga Prometheus në JVM duke e shtuar atë në imazhin e kontejnerit i cili do të sigurojë shtegun /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
Epo, ishte e lehtë. Eksportuesi do të monitorojë tomcat dhe do të shfaqë matjet e tij në formatin Prometheus në <svc>:9404/metrics
Konfigurimi i eksportuesit
Lexuesi i vëmendshëm mund të pyesë veten se nga erdhi prometheus-jmx.yaml? Ka shumë gjëra të ndryshme që mund të funksionojnë në JVM, dhe tomcat është vetëm një prej tyre, kështu që eksportuesi ka nevojë për disa konfigurime shtesë. Ekzistojnë konfigurime standarde për tomcat, mizën e egër, kafka dhe kështu me radhë . Ne do të shtojmë tomcat si në Kubernetes dhe më pas vendoseni si vëllim.
Së pari, ne shtojmë skedarin e konfigurimit të eksportuesit në direktorinë tonë të platformës/config/
platform/config
└── prometheus-jmx.yaml
Më pas shtojmë в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Kjo do të shtojë çdo element files[] si një element konfigurimi ConfigMap. ConfigMapGenerators janë të shkëlqyera sepse hasin të dhënat e konfigurimit dhe detyrojnë një rinisje të pod nëse ndryshon. Ato gjithashtu zvogëlojnë sasinë e konfigurimit në Deployment pasi mund të montoni një "dosje" të tërë skedarësh konfigurimi në një VolumeMount.
Më në fund, ne duhet të montojmë ConfigMap si një vëllim në pod:
-- 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
[...]
E mrekullueshme. Nëse Prometheus nuk është konfiguruar për të bërë një pastrim të plotë, mund t'ju duhet t'i thoni që të pastrojë bishtet. Përdoruesit e Operatorit Prometheus mund të përdorin service-monitor.yaml per te filluar. Eksploroni Service-monitor.yaml, и para se të filloni.
Zgjerimi i këtij modeli në raste të tjera përdorimi
Të gjithë skedarët që shtojmë në ConfigMapGenerator do të jenë të disponueshëm në drejtorinë e re /etc/config. Ju mund ta zgjeroni këtë shabllon për të montuar çdo skedar tjetër konfigurimi që ju nevojitet. Ju madje mund të montoni një skript të ri fillestar. Ju mund të përdorni për të montuar skedarë individualë. Për të përditësuar skedarët xml, merrni parasysh përdorimin në vend të sed. Është përfshirë tashmë në imazh.
Revista
Lajm i madh! Regjistrat e aplikacioneve janë tashmë të disponueshme në stdout, për shembull me kubectl logs. Fluentd (i instaluar si parazgjedhje në GKE) do t'i përcjellë regjistrat tuaja te Elasticsearch, Loki ose platforma juaj e regjistrimit të ndërmarrjes. Nëse dëshironi të përdorni jsonify për regjistrat, atëherë mund të ndiqni shabllonin e mësipërm për ta instaluar .
bazës së të dhënave
Si parazgjedhje, imazhi do të ketë një bazë të dhënash H2. Kjo nuk është e përshtatshme për ne dhe ne do të përdorim Google Cloud SQL me Cloud SQL Proxy - kjo do të nevojitet më vonë për të zgjidhur problemet e brendshme. Ky është një opsion i thjeshtë dhe i besueshëm nëse nuk keni preferencat tuaja në konfigurimin e bazës së të dhënave. AWS RDS ofron një shërbim të ngjashëm.
Pavarësisht nga databaza që zgjidhni, përveç nëse është H2, do t'ju duhet të vendosni variablat e duhura të mjedisit në platform/deploy.yaml. Duket diçka si kjo:
-- 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
[...]
Shënim: Mund të përdorni Kustomize për t'u vendosur në mjedise të ndryshme duke përdorur një mbivendosje: .
Shënim: përdorimi valueFrom: secretKeyRef. Ju lutem, përdorni edhe gjatë zhvillimit për të mbajtur sekretet tuaja të sigurta.
Ka të ngjarë që ju tashmë keni një sistem të preferuar për menaxhimin e sekreteve të Kubernetes. Nëse jo, këtu janë disa opsione: Kriptimi i tyre me KMS-në e ofruesit tuaj të cloud dhe më pas injektimi i tyre në K8S si sekrete nëpërmjet tubacionit të CD-së − - do të funksionojë shumë mirë në kombinim me sekretet e Kustomize. Ka mjete të tjera, të tilla si dotGPG, që kryejnë funksione të ngjashme: , .
Hyrje
Nëse nuk zgjidhni të përdorni përcjelljen e portit lokal, do t'ju duhet një kontrollues i konfiguruar i hyrjes. Nëse nuk përdorni () atëherë me shumë mundësi ju tashmë e dini se duhet të instaloni shënimet e nevojshme në ingress-patch.yaml.tmpl ose platform/ingress.yaml. Nëse jeni duke përdorur ingress-nginx dhe shihni një klasë hyrëse nginx me një balancues ngarkese që tregon drejt tij dhe një hyrje të jashtme DNS ose karakteristike të DNS-së, ju jeni gati të shkoni. Përndryshe, konfiguroni kontrolluesin e hyrjes dhe DNS, ose kapërceni këto hapa dhe mbani lidhjen e drejtpërdrejtë me podin.
TLS
Nëse jeni duke përdorur ose kube-lego dhe letsencrypt - certifikatat për hyrjen e re do të merren automatikisht. Përndryshe, hapeni ingress-patch.yaml.tmpl dhe personalizoni atë për t'iu përshtatur nevojave tuaja.
Nisja!
Nëse keni ndjekur gjithçka që është shkruar më lart, atëherë komanda make skaffold HOSTNAME=<you.example.com> duhet të lëshojë një shembull të disponueshëm në <hostname>/camunda
Nëse nuk e keni vendosur hyrjen tuaj në një URL publike, mund ta ridrejtoni atë me localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 mbi localhost:8080/camunda
Prisni disa minuta derisa tomcat të jetë plotësisht gati. Menaxherit të certifikatës do t'i duhet pak kohë për të verifikuar emrin e domenit. Më pas mund të monitoroni regjistrat duke përdorur mjete të disponueshme si një mjet si kubetail, ose thjesht duke përdorur kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Hapat e ardhshëm
Autorizim
Kjo është më e rëndësishme për konfigurimin e Camunda BPM sesa Kubernetes, por është e rëndësishme të theksohet se si parazgjedhje, vërtetimi është i çaktivizuar në REST API. Ti mundesh ose përdorni një metodë tjetër si p.sh . Ju mund të përdorni konfigurimin dhe vëllimet për të ngarkuar xml, ose xmlstarlet (shih më lart) për të modifikuar skedarët ekzistues në imazh dhe ose të përdorni wget ose t'i ngarkoni ato duke përdorur një kontejner fillestar dhe një vëllim të përbashkët.
Menaxhimi i sesionit
Ashtu si shumë aplikacione të tjera, Camunda BPM trajton seancat në JVM, kështu që nëse dëshironi të ekzekutoni kopje të shumta, mund të aktivizoni sesione ngjitëse (), i cili do të ekzistojë derisa kopja të zhduket, ose vendosni atributin Max-Age për cookies. Për një zgjidhje më të fuqishme, mund të vendosni Session Manager 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 '/^</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
Shënim: mund të përdorni xmlstarlet në vend të sed
Ne kemi përdorur përballë Google Cloud Memorystor, me (mbështet Redis) për ta ekzekutuar.
Shkallëzimi
Nëse tashmë i kuptoni sesionet, atëherë kufizimi i parë (dhe shpesh i fundit) për shkallëzimin e Camunda BPM mund të jetë lidhja me bazën e të dhënave. Përshtatja e pjesshme është tashmë në dispozicion "" Le të çaktivizojmë gjithashtu intialSize në skedarin settings.xml. Shtoni dhe ju lehtë mund të shkallëzoni automatikisht numrin e pods.
Kërkesat dhe kufizimet
В platform/deployment.yaml Do të shihni që ne e kemi koduar me forcë fushën e burimeve. Kjo funksionon mirë me HPA, por mund të kërkojë konfigurim shtesë. Patch-i kustomize është i përshtatshëm për këtë. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
Prodhim
Kështu që ne instaluam Camunda BPM në Kubernetes me metrikë Prometheus, regjistrat, bazën e të dhënave H2, TLS dhe Ingress. Ne shtuam skedarë jar dhe skedarë konfigurimi duke përdorur ConfigMaps dhe Dockerfile. Ne folëm për shkëmbimin e të dhënave në vëllime dhe drejtpërdrejt në variablat e mjedisit nga sekretet. Përveç kësaj, ne dhamë një përmbledhje të konfigurimit të Camunda për kopje të shumta dhe një API të vërtetuar.
Referencat
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, përkthim Alastair Firth, Lars Lange
Burimi: www.habr.com