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 ir nepradėkite savo pirmosios grupės?
Autoriai
- (Alastair Firth) – „Camunda Cloud“ komandos vyresnysis svetainių patikimumo inžinierius;
- (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 .
Kodėl verta naudoti Kubernetes
„Kubernetes“ tapo de facto standartu, leidžiančiu paleisti šiuolaikines programas „Linux“. Naudojant sistemos iškvietimus, o ne aparatinės įrangos emuliaciją ir branduolio gebėjimą valdyti atmintį ir užduočių perjungimą, įkrovos ir paleidimo laikas sumažinamas iki minimumo. Tačiau didžiausią naudą gali gauti standartinė API, kurią teikia Kubernetes, kad sukonfigūruotų infrastruktūrą, reikalingą visoms programoms: saugyklai, tinklui ir stebėjimui. 2020 m. birželį jam sukako 6 metai ir tai bene antras pagal dydį atvirojo kodo projektas (po Linux). Pastaruoju metu ji aktyviai stabilizavo savo funkcionalumą po greito kartojimosi per pastaruosius kelerius metus, nes tampa labai svarbia gamybos apkrovai 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ą (), 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 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
- - 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 .
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 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
## 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
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 . Pridėsime rutulį kaip „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 в 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, и 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 atskiriems failams prijungti. Norėdami atnaujinti xml failus, apsvarstykite galimybę naudoti 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 .
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ą: .
Atkreipti dėmesį: naudojimas valueFrom: secretKeyRef. Prašau, naudokis 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į. - labai gerai veiks kartu su Kustomize paslaptimis. Yra ir kitų įrankių, tokių kaip dotGPG, kurie atlieka panašias funkcijas: , .
Įėjimas
Jei nepasirinksite naudoti vietinio prievado persiuntimo, jums reikės sukonfigūruoto įėjimo valdiklio. Jei nenaudojate (), 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 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 arba naudokite kitą metodą, pvz . 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 (), 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 š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 '/^</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
Atkreipti dėmesį: vietoj sed galite naudoti xmlstarlet
Mes naudojom priešais „Google Cloud Memorystore“, su (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 "“ Taip pat išjunkite intialSize faile settings.xml. Papildyti 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
05.08.2020-XNUMX-XNUMX, vertimas Alastairas Firthas, Larsas Lange'as
Šaltinis: www.habr.com