Kuberneteset használsz? Készen áll arra, hogy a Camunda BPM-példányait kihelyezze a virtuális gépekből, vagy esetleg megpróbálja futtatni őket Kubernetesen? Nézzünk meg néhány gyakori konfigurációt és egyedi elemet, amelyek az Ön egyedi igényeihez szabhatók.
Feltételezi, hogy korábban használta a Kuberneteset. Ha nem, miért ne nézzen meg és nem indítja el az első klasztert?
Szerzők
- (Alastair Firth) - vezető helyszíni megbízhatósági mérnök a Camunda Cloud csapatban;
- (Lars Lange) - DevOps mérnök a Camundánál.
Röviden akkor:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Oké, valószínűleg nem működött, mert nincs telepítve a szkffold és a kustomize. Hát akkor olvass tovább!
Mi az a Camunda BPM
A Camunda BPM egy nyílt forráskódú üzleti folyamatkezelési és döntésautomatizálási platform, amely összeköti az üzleti felhasználókat és a szoftverfejlesztőket. Ideális emberek, (mikro) szolgáltatások vagy akár botok koordinálására, összekapcsolására! A különböző használati esetekről bővebben itt olvashat .
Miért használja a Kuberneteset?
A Kubernetes a modern alkalmazások Linuxon való futtatásának de facto szabványává vált. A hardveres emuláció helyett rendszerhívások használatával, valamint a kernel azon képességével, hogy kezelje a memóriát és a feladatváltást, a rendszerindítási és az indítási idő minimálisra csökken. A legnagyobb előny azonban a Kubernetes által biztosított szabványos API-ból származhat az összes alkalmazáshoz szükséges infrastruktúra konfigurálásához: tárolás, hálózat és felügyelet. 2020 júniusában lett 6 éves, és talán a második legnagyobb nyílt forráskódú projekt (a Linux után). A közelmúltban aktívan stabilizálta funkcionalitását az elmúlt néhány év gyors iterációja után, mivel világszerte kritikussá válik a termelési munkaterhelés szempontjából.
A Camunda BPM Engine könnyen csatlakozhat más, ugyanazon a fürtön futó alkalmazásokhoz, a Kubernetes pedig kiváló skálázhatóságot biztosít, így csak akkor lehet növelni az infrastruktúra költségeit, ha valóban szükség van rá (és szükség szerint egyszerűen csökkenteni).
A megfigyelés minősége is nagymértékben javult az olyan eszközökkel, mint a Prometheus, a Grafana, a Loki, a Fluentd és az Elasticsearch, lehetővé téve az összes munkaterhelés központi megtekintését egy fürtben. Ma megnézzük, hogyan lehet a Prometheus exportőrt a Java virtuális gépbe (JVM) implementálni.
célok
Nézzünk meg néhány területet, ahol testreszabhatjuk a Camunda BPM Docker képet (), hogy jól együttműködjön a Kubernetes-szel.
- Naplók és mérőszámok;
- Adatbázis kapcsolatok;
- Hitelesítés;
- Munkamenet menedzsment.
Megvizsgálunk több módot e célok elérésére, és világosan bemutatjuk a teljes folyamatot.
Megjegyzés: Enterprise verziót használsz? Néz és szükség szerint frissítse a képlinkeket.
Munkafolyamat-fejlesztés
Ebben a demóban a Skaffoldot használjuk Docker-képek létrehozásához a Google Cloud Build segítségével. Jól támogatja a különféle eszközöket (például Kustomize és Helm), CI és build eszközöket, valamint infrastruktúra-szolgáltatókat. Fájl skaffold.yaml.tmpl tartalmazza a Google Cloud Build és a GKE beállításait, amelyek nagyon egyszerű módot biztosítanak az éles szintű infrastruktúra futtatására.
make skaffold betölti a Dockerfile-környezetet a Cloud Buildbe, összeállítja a képet és tárolja a GCR-ben, majd alkalmazza a jegyzékeket a fürtre. Ez az, amit csinál make skaffold, de a Skaffold sok más funkcióval is rendelkezik.
A Kubernetes yaml-sablonjaihoz a kustomize-t használjuk a yaml-fedvények kezelésére anélkül, hogy a teljes jegyzéket elágaznánk, így git pull --rebase további fejlesztésekre. Most a kubectl-ben van, és elég jól működik ilyen dolgokhoz.
Az envsubst-ot is használjuk a gazdagépnév és a GCP-projektazonosító feltöltésére a *.yaml.tmpl fájlokban. Megnézheti, hogyan működik benne makefile vagy csak folytasd tovább.
Előfeltételek
- Munka klaszter
- - saját docker image-ek létrehozásához és a GKE-be való egyszerű telepítéshez
- Ennek a kódnak a másolata
- Envsubst
Munkafolyamat jegyzékek használatával
Ha nem szeretné használni a kustomize-t vagy a skaffold-ot, akkor hivatkozhat a manifesztekre generated-manifest.yaml és igazítsa őket az Ön által választott munkafolyamathoz.
Naplók és mérőszámok
A Prometheus a Kubernetes mérőszámok gyűjtésének szabványává vált. Ugyanazt a rést foglalja el, mint az AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics és mások. Nyílt forráskódú, és erőteljes lekérdezési nyelvvel rendelkezik. A vizualizációt a Grafana-ra bízzuk – számos műszerfallal szállítjuk. Össze vannak kötve egymással, és viszonylag könnyen telepíthetők .
Alapértelmezés szerint a Prometheus a kinyerési modellt használja <service>/metrics, és ehhez gyakori az oldalkocsis konténerek hozzáadása. Sajnos a JMX metrikák a legjobban a JVM-en belül rögzíthetők, így az oldalkocsis konténerek nem olyan hatékonyak. Kapcsolódjunk nyílt forráskódú a Prometheustól a JVM-hez úgy, hogy hozzáadja az elérési utat biztosító tárolóképhez /metrics egy másik porton.
Adja hozzá a Prometheus jmx_exportert a tárolóhoz
-- 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
Hát ez könnyű volt. Az exportőr figyeli a tomcat-ot, és Prometheus formátumban jeleníti meg a mutatóit a címen <svc>:9404/metrics
Exportőr beállítása
A figyelmes olvasó elgondolkodhat, honnan származik prometheus-jmx.yaml? Sok különböző dolog futhat a JVM-ben, és a tomcat csak egy ezek közül, így az exportőrnek további konfigurációra van szüksége. A tomcat, a wildfly, a kafka és így tovább szabványos konfigurációk állnak rendelkezésre . Hozzáadjuk a tomcat as a Kubernetesben, majd rögzítse kötetként.
Először is hozzáadjuk az exportőr konfigurációs fájlját a platform/config/ könyvtárunkhoz
platform/config
└── prometheus-jmx.yaml
Aztán hozzáadjuk в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Ez hozzáad minden elemet files[] ConfigMap konfigurációs elemként. A ConfigMapGenerators nagyszerűek, mert kivonatolja a konfigurációs adatokat, és ha módosulnak, kényszerítik a pod újraindítását. Csökkentik a telepítés mennyiségét is, mivel a konfigurációs fájlok teljes "mappáját" csatlakoztathatja egyetlen VolumeMountba.
Végül fel kell csatolnunk a ConfigMap-et kötetként a podhoz:
-- 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
[...]
Csodálatos. Ha a Prometheus nincs beállítva teljes tisztítás elvégzésére, akkor előfordulhat, hogy szólnia kell neki, hogy tisztítsa meg a hüvelyeket. A Prometheus Operator felhasználói használhatják service-monitor.yaml kezdeni. Fedezd fel Service-monitor.yaml, и mielőtt elkezded.
A minta kiterjesztése más felhasználási esetekre
A ConfigMapGeneratorhoz hozzáadott összes fájl elérhető lesz az új könyvtárban /etc/config. Ezt a sablont kibővítheti bármely más konfigurációs fájl csatlakoztatásához, amelyre szüksége van. Akár új indítószkriptet is csatlakoztathat. Te tudod használni az egyes fájlok csatolásához. Az xml fájlok frissítéséhez fontolja meg a használatát sed helyett. A képen már benne van.
Magazinok
Jó hír! Az alkalmazásnaplók már elérhetőek az stdout-on, például a következővel kubectl logs. A Fluentd (alapértelmezés szerint telepítve van a GKE-ben) továbbítja naplóit az Elasticsearch, a Loki vagy a vállalati naplózási platform felé. Ha a jsonify-t szeretné használni a naplókhoz, kövesse a fenti sablont a telepítéshez .
Adatbázis
Alapértelmezés szerint a képnek H2 adatbázisa lesz. Ez nekünk nem megfelelő, és a Google Cloud SQL-t Cloud SQL Proxyval fogjuk használni – erre később szükség lesz a belső problémák megoldásához. Ez egy egyszerű és megbízható lehetőség, ha nincs saját preferenciája az adatbázis beállításában. Az AWS RDS hasonló szolgáltatást nyújt.
A választott adatbázistól függetlenül, hacsak nem H2, be kell állítania a megfelelő környezeti változókat platform/deploy.yaml. Valahogy így néz ki:
-- 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
[...]
Megjegyzés: A Kustomize segítségével különböző környezetekben is telepíthet fedvényt: .
Megjegyzés: használat valueFrom: secretKeyRef. Kérlek használd még a fejlesztés során is, hogy titkai biztonságban legyenek.
Valószínűleg már rendelkezik egy preferált rendszerrel a Kubernetes-titkok kezelésére. Ha nem, akkor itt van néhány lehetőség: Titkosítsa őket a felhőszolgáltató KMS-ével, majd titkosítsa őket a K8S-be a CD-folyamon keresztül – - nagyon jól fog működni a Kustomize titkokkal kombinálva. Vannak más eszközök, például a dotGPG, amelyek hasonló funkciókat látnak el: , .
Bemenetel
Hacsak nem a helyi porttovábbítást választja, szüksége lesz egy konfigurált belépésvezérlőre. Ha nem használod (), akkor valószínűleg már tudja, hogy telepítenie kell a szükséges megjegyzéseket ingress-patch.yaml.tmpl vagy platform/ingress.yaml. Ha az ingress-nginxet használja, és egy nginx bemeneti osztályt lát, amelyre egy terheléselosztó mutat, és egy külső DNS- vagy helyettesítő karakteres DNS-bejegyzést, akkor készen áll. Ellenkező esetben konfigurálja a Belépés-vezérlőt és a DNS-t, vagy hagyja ki ezeket a lépéseket, és tartsa meg a közvetlen kapcsolatot a podhoz.
TLS
Ha használja vagy kube-lego és letsencrypt - az új bejelentkezéshez tartozó tanúsítványok automatikusan megérkeznek. Ellenkező esetben nyissa ki ingress-patch.yaml.tmpl és testreszabhatja az igényeinek megfelelően.
Dob!
Ha követte a fent leírtakat, akkor a parancsot make skaffold HOSTNAME=<you.example.com> el kell indítania egy elérhető példányt <hostname>/camunda
Ha nem állította be bejelentkezési adatait nyilvános URL-re, átirányíthatja a következővel localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 on localhost:8080/camunda
Várjon néhány percet, amíg a kanca teljesen készen áll. A tanúsítványkezelőnek némi időbe telik a domain név ellenőrzése. Ezután figyelheti a naplókat a rendelkezésre álló eszközökkel, például egy olyan eszközzel, mint a kubetail, vagy egyszerűen a kubectl használatával:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Következő lépések
Meghatalmazás
Ez a Camunda BPM konfigurálása szempontjából relevánsabb, mint a Kubernetes, de fontos megjegyezni, hogy alapértelmezés szerint a hitelesítés le van tiltva a REST API-ban. tudsz vagy használjon más módszert, mint pl . Használhatja a konfigurációs térképeket és a köteteket az xml betöltéséhez, vagy az xmlstarletet (lásd fent) a képben lévő meglévő fájlok szerkesztéséhez, és vagy használja a wget-et, vagy töltse be őket egy indítótároló és egy megosztott kötet segítségével.
Munkamenet menedzsment
Sok más alkalmazáshoz hasonlóan a Camunda BPM is kezeli a munkameneteket a JVM-ben, így ha több replikát szeretne futtatni, engedélyezheti a ragadós munkameneteket (), amely addig létezik, amíg a replika el nem tűnik, vagy állítsa be a Max-Age attribútumot a cookie-khoz. Robusztusabb megoldás érdekében telepítheti a Session Managert a Tomcatban. Larsnak van ebben a témában, de valami ilyesmi:
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
Megjegyzés: használhatja az xmlstarlet-et a sed helyett
Használtuk a Google Cloud Memorystore előtt, azzal (támogatja a Redist), hogy futtassa.
Méretezés
Ha már ismeri a munkameneteket, akkor a Camunda BPM méretezésének első (és gyakran az utolsó) korlátozása az adatbázishoz való csatlakozás lehet. A részleges testreszabás már elérhető"" Kapcsoljuk ki az intialSize-t is a settings.xml fájlban. Hozzáadás és egyszerűen automatikusan skálázhatja a hüvelyek számát.
Kérések és korlátozások
В platform/deployment.yaml Látni fogja, hogy keményen kódoltuk az erőforrások mezőjét. Ez jól működik a HPA-val, de további konfigurációt igényelhet. Erre alkalmas a kustomize tapasz. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
Teljesítmény
Így telepítettük a Camunda BPM-et a Kubernetesre Prometheus metrikákkal, naplókkal, H2 adatbázissal, TLS-sel és Ingressel. Jar fájlokat és konfigurációs fájlokat adtunk hozzá a ConfigMaps és a Dockerfile segítségével. Beszéltünk arról, hogy adatokat cserélünk kötetekre és közvetlenül környezeti változókra a titkokból. Ezenkívül áttekintést adtunk a Camunda beállításáról több replikához és egy hitelesített API-hoz.
referenciák
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., fordítás Alastair Firth, Lars Lange
Forrás: will.com