🥇 „Camunda BPM“ bėgimas „Kubernetes“

Ar naudojate Kubernetes? Pasiruošę perkelti savo Camunda BPM egzempliorius iš virtualių mašinų, o gal tiesiog pabandykite juos paleisti Kubernetes? Pažvelkime į kai kurias įprastas konfigūracijas ir atskirus elementus, kuriuos galima pritaikyti pagal jūsų konkrečius poreikius.

Daroma prielaida, kad anksčiau naudojote Kubernetes. Jei ne, kodėl gi nepažvelgus vadovas ir nepradėkite savo pirmosios grupės?

Autoriai

Alastairas Firthas (Alastair Firth) – „Camunda Cloud“ komandos vyresnysis svetainių patikimumo inžinierius;
Larsas Lange'as (Lars Lange) – „DevOps“ inžinierius įmonėje „Camunda“.

Trumpai tariant:

git clone https://github.com/camunda-cloud/camunda-examples.git cd camunda-examples/camunda-bpm-demo make skaffold

Gerai, tai tikriausiai neveikė, nes nesate įdiegę scaffold ir kustomize. Na, tada skaitykite toliau!

Kas yra Camunda BPM

Camunda BPM yra atvirojo kodo verslo procesų valdymo ir sprendimų automatizavimo platforma, jungianti verslo vartotojus ir programinės įrangos kūrėjus. Tai idealiai tinka koordinuoti ir sujungti žmones, (mikro) paslaugas ar net robotus! Daugiau apie skirtingus naudojimo atvejus galite perskaityti adresu nuoroda.

Kodėl verta naudoti Kubernetes

„Kubernetes“ tapo faktiniu standartu šiuolaikinių programų veikimui. LinuxNaudojant sisteminius iškvietimus vietoj aparatinės įrangos emuliacijos ir leidžiant branduoliui valdyti atmintį ir užduočių perjungimą, įkrovos ir paleidimo laikas sutrumpėja. Tačiau didžiausias privalumas gali būti standartinė API, kurią „Kubernetes“ teikia visoms programoms reikalingos infrastruktūros – saugyklos, tinklo ir stebėjimo – konfigūravimui. 2020 m. birželį jis atšventė šešerias metines, todėl tai turbūt antras pagal dydį atvirojo kodo projektas (po Linux). Pastaruoju metu jis aktyviai stabilizuoja savo funkcionalumą po greito iteracijos per pastaruosius kelerius metus, nes tampa itin svarbus gamybos darbo krūviams visame pasaulyje.

„Camunda BPM Engine“ gali lengvai prisijungti prie kitų tame pačiame klasteryje veikiančių programų, o „Kubernetes“ suteikia puikų mastelio keitimą, leidžiantį padidinti infrastruktūros sąnaudas tik tada, kai tikrai reikia (ir lengvai jas sumažinti pagal poreikį).

Stebėjimo kokybė taip pat labai pagerinta naudojant tokius įrankius kaip „Prometheus“, „Grafana“, „Loki“, „Fluentd“ ir „Elasticsearch“, todėl galite centralizuotai peržiūrėti visus darbo krūvius grupėje. Šiandien apžvelgsime, kaip įdiegti Prometheus eksportuotoją į Java virtualią mašiną (JVM).

Tikslai

Pažvelkime į keletą sričių, kuriose galime tinkinti „Camunda BPM Docker“ vaizdą (GitHub), kad jis gerai sąveikautų su „Kubernetes“.

Žurnalai ir metrika;
Duomenų bazių jungtys;
Autentifikavimas;
Seanso valdymas.

Išnagrinėsime kelis būdus, kaip pasiekti šiuos tikslus ir aiškiai parodysime visą procesą.

Atkreipti dėmesį: Ar naudojate Enterprise versiją? Žiūrėk čia ir prireikus atnaujinkite vaizdo nuorodas.

Darbo eigos kūrimas

Šioje demonstracijoje naudosime „Skaffold“, kad sukurtume „Docker“ vaizdus naudodami „Google Cloud Build“. Jis puikiai palaiko įvairius įrankius (pvz., Kustomize ir Helm), CI ir kūrimo įrankius bei infrastruktūros teikėjus. Failas skaffold.yaml.tmpl apima „Google Cloud Build“ ir GKE nustatymus, suteikiančius labai paprastą būdą paleisti gamybinio lygio infrastruktūrą.

make skaffold įkels „Dockerfile“ kontekstą į „Cloud Build“, sukurs vaizdą ir išsaugos jį GCR, o tada pritaikys aprašus jūsų klasteriui. Štai ką jis daro make skaffold, bet Skaffold turi daug kitų funkcijų.

„Yaml“ šablonams „Kubernetes“ naudojame „kustomize“, kad tvarkytume „yaml“ perdangas, nesukeldami viso aprašo, todėl galite naudoti git pull --rebase dėl tolesnių patobulinimų. Dabar jis yra kubectl ir gana gerai tinka tokiems dalykams.

Taip pat naudojame envsubst, kad *.yaml.tmpl failuose pateiktume pagrindinio kompiuterio pavadinimą ir GCP projekto ID. Galite pamatyti, kaip tai veikia makefile arba tiesiog tęsk toliau.

Būtinos sąlygos

Darbo klasteris Kubernetes
Pritaikyti
Skarfas - už savo docker vaizdų kūrimą ir lengvą diegimą GKE
Šio kodo kopija
Envsubst

Darbo eiga naudojant manifestus

Jei nenorite naudoti „kustomize“ ar „skaffold“, galite peržiūrėti manifestus generated-manifest.yaml ir pritaikyti juos prie pasirinktos darbo eigos.

Žurnalai ir metrika

„Prometheus“ tapo Kubernetes metrikos rinkimo standartu. Ji užima tą pačią nišą kaip AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics ir kt. Tai atvirojo kodo ir turi galingą užklausų kalbą. Vizualizaciją patikėsime „Grafana“ – ji pateikiama su daugybe prietaisų skydelių, kuriuos galima įsigyti jau iš karto. Jie yra sujungti vienas su kitu ir yra gana lengvai montuojami Prometėjas-operatorius.

Pagal numatytuosius nustatymus „Prometheus“ naudoja ištraukimo modelį <service>/metrics, ir tam įprasta pridėti konteinerių prie šoninių priekabų. Deja, JMX metrika geriausiai registruojama JVM, todėl šoninių priekabų konteineriai nėra tokie veiksmingi. Prisijunkime jmx_exporter atvirojo kodo iš Prometheus į JVM, pridėdami jį prie konteinerio vaizdo, kuriame bus nurodytas kelias /metrics kitame uoste.

Į konteinerį pridėkite Prometheus jmx_exporter

-- images/camunda-bpm/Dockerfile FROM camunda/camunda-bpm-platform:tomcat-7.11.0

## Pridėti „Prometheus“ eksportuotoją
PALEISKITE programėlę „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 yra rezervuotas „prometheus-jmx“ prievadas
ENV CATALINA_OPTS -javaagent:lib/
jmx_prometheus_javaagent-0.11.0.jar=9404:/etc/config/prometheus-jmx.yaml

Na, tai buvo lengva. Eksportuotojas stebės tomcat ir rodys jo metrikas Prometheus formatu adresu <svc>:9404/metrics

Eksportuotojo sąranka

Dėmesingas skaitytojas gali susimąstyti, iš kur jis atsirado prometheus-jmx.yaml? JVM gali veikti daug įvairių dalykų, o tomcat yra tik vienas iš jų, todėl eksportuotojui reikia papildomos konfigūracijos. Galimos standartinės tomcat, wildfly, kafka ir tt konfigūracijos čia. Pridėsime rutulį kaip „ConfigMap“ „Kubernetes“ ir pritvirtinkite jį kaip tomą.

Pirma, mes įtraukiame eksportuotojo konfigūracijos failą į mūsų platformos/config/ katalogą

platform/config └── prometheus-jmx.yaml

Tada pridedame ConfigMapGenerator в kustomization.yaml.tmpl:

-- platform/kustomization.yaml.tmpl apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization [...] configMapGenerator: - name: config files: - config/prometheus-jmx.yaml

Tai pridės kiekvieną elementą files[] kaip ConfigMap konfigūracijos elementą. „ConfigMapGenerators“ yra puikūs, nes jie sumaišo konfigūracijos duomenis ir priverčia paleisti bloką iš naujo, jei jie pasikeičia. Jie taip pat sumažina diegimo konfigūracijos kiekį, nes galite prijungti visą konfigūracijos failų „aplanką“ viename „VolumeMount“.

Galiausiai turime prijungti „ConfigMap“ kaip tomą prie lizdo:

-- 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 [...]

Nuostabu. Jei „Prometheus“ nesukonfigūruotas atlikti visišką valymą, gali tekti jam nurodyti, kad išvalytų ankštis. Prometheus Operator vartotojai gali naudotis service-monitor.yaml pradėti. Naršyti Service-monitor.yaml, operatoriaus dizainas и ServiceMonitorSpec prieš tau pradedant.

Šio modelio išplėtimas kitais naudojimo atvejais

Visi failai, kuriuos pridedame prie ConfigMapGenerator, bus pasiekiami naujajame kataloge /etc/config. Galite išplėsti šį šabloną, kad prijungtumėte kitus reikalingus konfigūracijos failus. Jūs netgi galite įdiegti naują paleisties scenarijų. Tu gali naudoti antrinis kelias atskiriems failams prijungti. Norėdami atnaujinti xml failus, apsvarstykite galimybę naudoti xmlstarlet vietoj sed. Jis jau įtrauktas į paveikslėlį.

Žurnalai

Puiki naujiena! Programų žurnalai jau yra stdout, pavyzdžiui, su kubectl logs. „Fluentd“ (pagal numatytuosius nustatymus įdiegta GKE) perduos jūsų žurnalus „Elasticsearch“, „Loki“ arba jūsų įmonės registravimo platformai. Jei žurnalams norite naudoti jsonify, diegdami galite vadovautis aukščiau pateiktu šablonu atsijungimas.

Duomenų bazė

Pagal numatytuosius nustatymus vaizdas turės H2 duomenų bazę. Tai mums netinka, o Google Cloud SQL naudosime su Cloud SQL Proxy – to prireiks vėliau sprendžiant vidines problemas. Tai paprastas ir patikimas pasirinkimas, jei neturite savo pasirinkimų nustatydami duomenų bazę. AWS RDS teikia panašią paslaugą.

Nepriklausomai nuo pasirinktos duomenų bazės, jei tai nėra H2, turėsite nustatyti atitinkamus aplinkos kintamuosius platform/deploy.yaml. Tai atrodo maždaug taip:

-- 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 [...]

Atkreipti dėmesį: Galite naudoti Kustomize, kad diegtumėte įvairiose aplinkose naudodami perdangą: pavyzdys.

Atkreipti dėmesį: naudojimas valueFrom: secretKeyRef. Prašau, naudokis šią „Kubernetes“ funkciją net kūrimo metu, kad jūsų paslaptys būtų saugios.

Tikėtina, kad jau turite pageidaujamą „Kubernetes“ paslapčių tvarkymo sistemą. Jei ne, čia yra keletas variantų: užšifruoti juos naudojant debesijos paslaugų teikėjo KMS ir įterpti juos į K8S kaip paslaptis per kompaktinio disko dujotiekį. Mozilla SOPS - labai gerai veiks kartu su Kustomize paslaptimis. Yra ir kitų įrankių, tokių kaip dotGPG, kurie atlieka panašias funkcijas: „HashiCorp Vault“, Tinkinkite slaptos vertės papildinius.

Įėjimas

Jei nepasirinksite naudoti vietinio prievado persiuntimo, jums reikės sukonfigūruoto įėjimo valdiklio. Jei nenaudojate ingress-nginx (Vairo diagrama), tada greičiausiai jau žinote, kad turite įdiegti reikiamus komentarus ingress-patch.yaml.tmpl arba platform/ingress.yaml. Jei naudojate ingress-nginx ir matote nginx įėjimo klasę su į ją nukreiptu apkrovos balansavimo įtaisu ir išoriniu DNS arba pakaitos simbolių DNS įrašu, galite pradėti. Kitu atveju sukonfigūruokite įėjimo valdiklį ir DNS arba praleiskite šiuos veiksmus ir palaikykite tiesioginį ryšį su priedu.

TLS

Jei naudojate sertifikatas-vadybininkas arba kube-lego ir letsencrypt – naujo prisijungimo sertifikatai bus gauti automatiškai. Priešingu atveju atidarykite ingress-patch.yaml.tmpl ir pritaikykite jį pagal savo poreikius.

Paleisti!

Jei vykdėte viską, kas parašyta aukščiau, tada komanda make skaffold HOSTNAME=<you.example.com> turėtų paleisti galimą egzempliorių <hostname>/camunda

Jei nenustatėte savo prisijungimo prie viešo URL, galite jį peradresuoti naudodami localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 apie localhost:8080/camunda

Palaukite kelias minutes, kol kačiukas bus visiškai paruoštas. Sertifikatų valdytojui prireiks šiek tiek laiko, kol patvirtins domeno pavadinimą. Tada galite stebėti žurnalus naudodami turimus įrankius, tokius kaip „kubetail“, arba tiesiog naudodami „kubectl“:

kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f

Kitas žingsnis

Leidimas

Tai labiau tinka konfigūruojant „Camunda BPM“ nei „Kubernetes“, tačiau svarbu pažymėti, kad pagal numatytuosius nustatymus autentifikavimas REST API yra išjungtas. Tu gali įgalinti pagrindinį autentifikavimą arba naudokite kitą metodą, pvz J.W.T.. Galite naudoti konfigūracijos žemėlapius ir tomus, norėdami įkelti xml, arba xmlstarlet (žr. aukščiau), norėdami redaguoti esamus vaizdo failus, ir naudoti wget arba įkelti juos naudodami pradinį konteinerį ir bendrinamą tomą.

Seanso valdymas

Kaip ir daugelis kitų programų, „Camunda BPM“ tvarko seansus JVM, todėl, jei norite paleisti kelias kopijas, galite įjungti lipnias seansus (pavyzdžiui, ingress-nginx), kuris egzistuos tol, kol išnyks kopija, arba nustatykite slapukų atributą Max-Age. Norėdami gauti patikimesnį sprendimą, galite įdiegti „Session Manager“ Tomcat. Larsas turi atskiras postas šia tema, bet kažkas panašaus:

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"
lipnus="klaidingas"
sessionBackupAsync="false"
storageKeyPrefix="kontekstas"
užrakinimo režimas = „automatinis“
/>' conf/kontekstas.xml

Atkreipti dėmesį: vietoj sed galite naudoti xmlstarlet

Mes naudojom tvemproxy priešais „Google Cloud Memorystore“, su atmintinės seanso tvarkyklė (palaiko Redis), kad jį paleistumėte.

Mastelio keitimas

Jei jau suprantate seansus, pirmasis (ir dažnai paskutinis) Camunda BPM mastelio keitimo apribojimas gali būti ryšys su duomenų baze. Jau galimas dalinis tinkinimas "iš dėžės“ Taip pat išjunkite intialSize faile settings.xml. Papildyti Horizontaliosios talpyklos automatinis skaleris (HPA) ir jūs galite lengvai automatiškai pakeisti ankščių skaičių.

Prašymai ir apribojimai

В platform/deployment.yaml Pamatysite, kad išteklių lauką užkodavome. Tai gerai veikia su HPA, tačiau gali prireikti papildomos konfigūracijos. Tam tinka „kustomize“ pleistras. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl

Produkcija

Taigi mes įdiegėme „Camunda BPM“ „Kubernetes“ su „Prometheus“ metrika, žurnalais, H2 duomenų baze, TLS ir „Ingress“. Pridėjome jar failus ir konfigūracijos failus naudodami ConfigMaps ir Dockerfile. Mes kalbėjome apie keitimąsi duomenimis į tomus ir tiesiai į aplinkos kintamuosius iš paslapčių. Be to, pateikėme „Camunda“ nustatymo kelioms kopijoms ir autentifikuotai API apžvalgą.

Nuorodos

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