Përdorni Kubernetes? Jeni gati të transferoni instancat tuaja të Camunda BPM nga makinave virtuale, ose ndoshta thjesht të provoni t'i lanconi ato në Kubernetes? Le të shqyrtojmë disa konfigurime të zakonshme dhe elemente të veçanta që mund të përshtaten sipas nevojave tuaja të veçanta.
Supozoni se keni përdorur Kubernetes më parë. Nëse jo, pse të mos shikoni në dhe të lançoni klastrin tuaj të parë?
Autoret
- është inxhinier i lartë i besueshmërisë së faqes (Site Reliability Engineer) në ekipin e Camunda Cloud;
- është inxhinier DevOps në Camunda.
Nëse e shprehim shkurtimisht,
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Epo, ndoshta nuk funksionoi, pasi nuk keni instaluar skaffold dhe kustomize. Pra, vazhdoni të lexoni!
Çfarë është Camunda BPM
Camunda BPM është një platformë me kod të hapur për menaxhimin e proceseve të biznesit dhe automatizimin e vendimmarrjeve, që bashkon përdoruesit e biznesit dhe zhvilluesit e softuerit. Ajo është ideale për koordinimin dhe bashkimin e njerëzve, shërbimeve (mikro) ose madje edhe robotëve! Më shumë për raste të ndryshme përdorimi mund të lexoni në .
Pse të përdorim Kubernetes
Kubernetes është bërë standardi de-facto për drejtorimin e aplikacioneve moderne në Linux. Falë përdorimit të thirrjeve sistemike në vend të simulimit të nivelit të harduerit dhe aftësive të bërthamës për të menaxhuar kujtesën dhe kalimin e detyrave, koha e ngarkimit dhe koha e aktivizimit minimizohen. Sidoqoftë, përparësia më e madhe mund të merret nga API standard që Kubernetes ofron për konfigurimin e infrastrukturës së nevojshme për të gjitha aplikacionet: ruajtje, rrjet dhe monitorim. Në qershor 2020, ai mbushi 6 vjet, dhe është ndoshta projekti i dytë më i madh me kod të hapur (pas Linux). Kohët e fundit, ai po stabilizon aktivet e tij pas një iteracioni të shpejtë gjatë viteve të fundit, pasi kjo bëhet kritikisht e rëndësishme për ngarkesat prodhuese në mbarë botën.
Camunda BPM Engine mund të lidhet lehtësisht me aplikacione të tjera që funksionojnë në të njëjtin klasër, dhe Kubernetes ofron shkallëzim të shkëlqyer, duke lejuar rritjen e shpenzimeve për infrastrukturën vetëm kur kjo është me të vërtetë e nevojshme (dhe lehtë të zvogëlohet sipas nevojës).
Cilësia e monitorimit përmirësohet gjithashtu ndjeshëm me ndihmën e mjeteve si Prometheus, Grafana, Loki, Fluentd dhe Elasticsearch, që lejojnë shikimin qendror të të gjitha ngarkesave të klasterit. Sot do të shqyrtojmë se si të implementojmë eksportuesin Prometheus në një makinë virtuale Java (JVM).
Qëllimet
Le të shqyrtojmë disa fusha ku mund të konfigurojmë imazhin Docker të Camunda BPM (), në mënyrë që të funksionojë mirë me Kubernetes.
- Dëshmitë dhe metrikat;
- Lidhjet me bazën e të dhënave;
- Autentifikimi;
- Menaxhimi i sesioneve.
Ne do të shqyrtojmë disa mënyra për të realizuar këto qëllime dhe do ta ilustrojmë të gjithë procesin.
Shënim: Po përdorni versionin Enterprise? Shikoni dhe përditësoni lidhjet me imazhet nëse është e nevojshme.
Zhvillimi i procesit të punës
Në këtë demonstratë, ne do të përdorim Skaffold për të krijuar imazhe Docker me ndihmën e Google Cloud Build. Ai ka mbështetje të mirë 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 cilësime për Google Cloud Build dhe GKE, duke ofruar një mënyrë shumë të thjeshtë për të nisur infrastrukturën e nivelit industrial.
make skaffold do të ngarkojë kontekstin e Dockerfile në Cloud Build, do të krijojë imazhin dhe do ta ruajë atë në GCR, e më pas 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 shabllonet yaml në Kubernetes, ne përdorim kustomize për të menaxhuar përjashtimet yaml pa qenë nevoja të shpërbëjmë 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.
Po ashtu, ne përdorim envsubst për të plotësuar emrin e hostit dhe identifikuesin e projektit GCP në skedarët * .yaml.tmpl. Ju mund ta shihni si funksionon në makefile ose thjesht të vazhdoni përpara.
Kushtet e nevojshme
- Kluster i punës
- për krijimin e imazheve docker të personalizuara dhe për një implementim të lehtë në GKE
- Një kopje e këtij kodi
- Envsubst
Procesi i punës me manifestet
Nëse nuk dëshironi të përdorni kustomize ose skaffold, mund të referoheni te manifestet në generated-manifest.yaml dhe t'i përshtatni ato në procesin e punës sipas zgjedhjes suaj.
Dëshmitë dhe metrikat
Prometheus është standardi për mbledhjen e metrikeve në Kubernetes. Ai zë të njëjtin pozicion si AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics dhe të tjerë. Ka një kod burimi të hapur dhe një gjuhë të fuqishme kërkimesh. Vizualizimin do ta besojmë tek Grafana — ajo vjen me një numër të madh panelesh monitorimi, të disponueshme nga kutia. Ato janë të lidhura me njëra-tjetrën dhe relativisht të lehta për t'u instaluar me .
Sipas parazgjedhjes, Prometheus përdor modelin e nxjerrjes /metrics, dhe shtimi i konteinerëve sidecar për këtë është një praktikë e zakonshme. Fatkeqësisht, metrike JMX regjistrohen më mirë brenda JVM, prandaj konteinerët sidecar nuk janë aq efikasë. Le ta lidhim me kod burimi të hapur nga Prometheus në JVM, duke e shtuar atë në imazhin e konteinerit që do të sigurojë një rrugë /metrics në një port tjetër.
Shtoni Prometheus jmx_exporter në konteiner
-- 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
Eh, kjo ishte e lehtë. Eksportuesi do të monitorojë tomcat dhe do ta shfaqë metriken e tij në formatin Prometheus në adresën :9404/metrics
Konfigurimi i eksportuesit
Lexuesi i kujdesshëm mund të pyesë, nga e 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.
E para, ne shtojmë skedarin e konfigurimit të eksportuesit në drejtori 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
files:
- config/prometheus-jmx.yaml
Kjo do të shtojë çdo element files[] si një element konfigurimi në ConfigMap. ConfigMapGenerators janë të mira sepse hash-në të dhënat në konfigurim dhe iniciatojnë rindërtimin e podit nëse ka ndonjë ndryshim. Ato gjithashtu reduktojnë vëllimin e konfigurimit në Deployment, pasi mund të montoni të gjithë "dosjen" e skedarëve të konfigurimit në një VolumeMount.
Së fundi, na nevojitet të montojmë ConfigMap si një volum 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
[...]
Shkëlqyeshëm. Nëse Prometheus nuk është konfigurues për pastrimin e plotë, mund t'ju duhet të i thoni atij të pastroni podet. Përdoruesit e Prometheus Operator mund të përdorin service-monitor.yaml për të filluar. Shqyrtoni Service-monitor.yaml, dhe para se të nisni.
Shpërndarja e këtij modeli në përdorime të tjera
Të gjitha skedarët që shtojmë në ConfigMapGenerator, do të jenë të disponueshëm në një dosje të re /etc/config. Ju mund ta zgjatni këtë shabllon për të montuar çdo skedar konfiguruese tjetër që ju nevojitet. Madje mund të montoni një skenar të ri fillimi. Mund të përdorni për montimin e skedarëve të veçantë. Për të përditësuar skedarët xml, shqyrtoni përdorimin e në vend të sed. Ai është tashmë i përfshirë në imazh.
Të dhënat
Lajm i shkëlqyer! Të dhënat e aplikacionit janë tashmë të disponueshme në stdout, për shembull, me anë të tani mund të. Fluentd (ai është instaluar si parazgjedhje në GKE) do të redirektojë të dhënat tuaja në Elasticsearch, Loki ose në platformën tuaj të brendshme të të dhënave. Nëse dëshironi të përdorni jsonify për të dhënat, atëherë mund të ndiqni shabllonin e mësipërm për instalim .
Baza e të dhënave
Si parazgjedhje, 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ë nevojitet më vonë për zgjidhjen e detyrave të brendshme. Kjo është një opsion i thjeshtë dhe i besueshëm, 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, nëse kjo nuk është H2, do t'ju nevojitet të vendosni variablat e duhura të mjedisit në platform/deploy.yaml. Kjo duket pak a shumë kështu:
-- platform/deployment.yaml
apiVersion: apps/v1
kind: Deployment
[...]
spec:
template:
spec:
[...]
containers:
- name: camunda-bpm
mjed:
- 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ësit:
emri: cambpm-db-credentials
çelësi: db_username
- emri: DB_PASSWORD
vleraNga:
referencëÇelësit:
emri: cambpm-db-credentials
çelësi: db_password
[...]
Shënim: Mund të përdorni Kustomize për të implementuar në mjedise të ndryshme duke përdorur overlay: .
Shënim: përdorimi valueFrom: secretKeyRef. Ju lutemi, përdorni edhe gjatë zhvillimit për të mbajtur sekretet tuaja në siguri.
Është shumë e mundshme që ju tashmë keni një sistem të preferuar për menaxhimin e sekretëve Kubernetes. Nëse jo, ja disa opsione: t'i enkriptoj ato me KMS të ofruesit tuaj të cloud dhe pastaj t'i integroj ato në K8S si sekrete përmes një kontejneri CD — do të punojë shumë mirë me sekretet Kustomize. Ka edhe mjete të tjera, si dotGPG — ato kryejnë funksione të ngjashme: , .
Ingress
Nëse vetëm nuk vendosni të përdorni redirektimin e portit lokal, do t'ju nevojitet një Ingress Controller i konfiguruar. Nëse nuk po përdorni () atëherë, me siguri tashmë e dini se duhet të vendosni anotimet 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ë i referohet asaj dhe DNS të jashtëm ose një shënim DNS të zëvendësimit, gjithçka është gati. Përndryshe, konfiguroni Ingress Controller dhe DNS, ose kaloni këto hapa dhe lëreni lidhjen direkte me pod-in.
TLS
Nëse po përdorni ose kube-lego dhe letsencrypt — certifikat e reja do të merren automatikisht. Në të kundërt, hapni ingress-patch.yaml.tmpl dhe konfiguroni sipas nevojës tuaj.
Çelësi!
Nëse keni ndjekur gjithçka të shkruar më sipër, ekipi make skaffold HOSTNAME= duhet të niset një instancë të disponueshme në /camunda
Nëse nuk keni kërkuar hyrje përmes një URL-je publike, atëherë mund ta përcillni 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ë marrë disa kohë për të verifikuar emrin e domain-it. Pas kësaj, mund të ndiqni log-et me mjete të disponueshme — 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 ka të bëjë më shumë me konfigurimin e Camunda BPM se sa me Kubernetes, por është e rëndësishme të theksohet se, sipas parazgjedhjes, autentikimi në REST API është i çaktivizuar. Mund ta ose përdorni një metodë tjetër, siç është . Mund të përdorni configmaps dhe volume për të ngarkuar xml, ose xmlstarlet (shih më lart) për të redaktuar skedarët ekzistues në imazh, si dhe ose përdorni wget, ose ngarkoni ato me një enë init dhe një vëllim të përbashkët.
Menaxhimi i sesioneve
Si shumë aplikacione të tjera, Camunda BPM menaxhon sesionet në JVM, kështu që, nëse dëshironi të nidhni disa replika, mund të aktivizoni sesione ngjitëse (), të cilat do të ekzistojnë për sa kohë që replika të mos zhduket, ose të vendosni atributin Max-Age për cookie-t. Si një zgjidhje më të besueshme, mund të implementoni Menaxherin e Sesioneve 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ërdoret xmlstarlet në vend të sed
Kemi përdorur para Google Cloud Memorystore, me (mbështet Redis) për ta drejtuar atë.
Zgjerimi
Nëse tashmë keni kuptuar se si funksionojnë seancat, atëherë pengesa e parë (dhe shpesh e fundit) për të zgjeruar Camunda BPM mund të jetë lidhja me bazën e të dhënave. Konfigurimi i pjesshëm është i disponueshëm "". Gjithashtu do të çaktivizojmë intialSize në skedarin settings.xml. Shtoni dhe do të jeni në gjendje të shkallëzoni lehtësisht numrin e pod-ëve.
Kërkesat dhe kufizimet
Në platform/deployment.yaml do të shihni se ne e kemi koduar ngushtë fushën e burimeve. Kjo funksionon mirë me HPA, por mund të kërkojë konfigurim shtesë. Për këtë, një patch kustomizimi do të ishte i përshtatshëm. Shihni ingress-patch.yaml.tmpl dhe ./kustomization.yaml.tmpl
Përfundimi
Kështu, kemi instaluar Camunda BPM në Kubernetes me metrike Prometheus, regjistra, bazën e të dhënave H2, TLS dhe Ingress. Ne kemi shtuar skedarët jar dhe skedarët e konfigurimit duke përdorur ConfigMaps dhe Dockerfile. Diskutuam mbi shkëmbimin e të dhënave me volumin dhe direkt në variablat ambientale nga sekretet. Për më tepër, ofruam një përmbledhje të konfigurimit të Camunda për disa kopje dhe një API të autentikuar.
Linket
github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes
│
├── generated-manifest.yaml <- manifest për përdorim pa kustomize
├── images
│ └── camunda-bpm
│ └── Dockerfile <- imazhi overlay docker
├── ingress-patch.yaml.tmpl <- konfigurimi specifik i ingress-it
├── kustomization.yaml.tmpl <- Kustomization kryesore
├── Makefile <- objektivat e prodhimit
├── namespace.yaml
├── platform
│ ├── config
│ │ └── prometheus-jmx.yaml <- skedari i konfigurimit të exporter-it prometheus
│ ├── deployment.yaml <- përhapja kryesore
│ ├── ingress.yaml
│ ├── kustomization.yaml <- "baza" e kustomizimit
│ ├── service-monitor.yaml <- konfigurimi shembull për prometheus-operator
│ └── service.yaml
└── skaffold.yaml.tmpl <- direktivat skaffold
05.08.2020, përkthim Alastair Firth, Lars Lange
Burimi: habr.com
