Kas kasutate Kubernetest? Kas olete valmis oma Camunda BPM-i eksemplare virtuaalmasinatest välja viima või proovige neid lihtsalt Kubernetesis käivitada? Vaatame mõningaid levinumaid konfiguratsioone ja üksikuid üksusi, mida saab kohandada vastavalt teie konkreetsetele vajadustele.
See eeldab, et olete Kubernetest varem kasutanud. Kui ei, siis miks mitte visata pilk peale ja mitte alustada oma esimest klastrit?
Autorid
- (Alastair Firth) – Camunda Cloudi meeskonna töökindluse vaneminsener;
- (Lars Lange) – Camunda DevOpsi insener.
Lühidalt:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Olgu, see ilmselt ei töötanud, kuna teil pole skaffoldi ja kustomize'i installitud. No siis loe edasi!
Mis on Camunda BPM
Camunda BPM on avatud lähtekoodiga äriprotsesside juhtimise ja otsuste automatiseerimise platvorm, mis ühendab ärikasutajaid ja tarkvaraarendajaid. See on ideaalne inimeste, (mikro)teenuste või isegi robotite koordineerimiseks ja ühendamiseks! Lisateavet erinevate kasutusjuhtude kohta saate lugeda aadressilt .
Miks kasutada Kubernetest?
Kubernetesest on saanud Linuxis kaasaegsete rakenduste käitamise de facto standard. Kasutades riistvara emulatsiooni asemel süsteemikutseid ja kerneli võimet hallata mälu ja ülesannete vahetamist, hoitakse alglaadimis- ja käivitusaeg minimaalsena. Suurim kasu võib aga tulla standardsest API-st, mida Kubernetes pakub kõigi rakenduste jaoks vajaliku infrastruktuuri konfigureerimiseks: salvestus, võrgundus ja jälgimine. See sai 2020. aasta juunis 6-aastaseks ja on võib-olla suuruselt teine avatud lähtekoodiga projekt (pärast Linuxi). See on hiljuti aktiivselt stabiliseerinud oma funktsionaalsust pärast viimaste aastate kiiret iteratsiooni, kuna see muutub kogu maailmas tootmise töökoormuse jaoks kriitiliseks.
Camunda BPM Engine saab hõlpsasti ühenduda teiste samas klastris töötavate rakendustega ja Kubernetes pakub suurepärast mastaapsust, võimaldades teil infrastruktuurikulusid suurendada ainult siis, kui see on tõesti vajalik (ja vajadusel neid hõlpsalt vähendada).
Seirekvaliteeti parandavad oluliselt ka sellised tööriistad nagu Prometheus, Grafana, Loki, Fluentd ja Elasticsearch, võimaldades teil tsentraalselt vaadata kõiki töökoormusi klastris. Täna vaatame, kuidas rakendada Prometheuse eksportijat Java virtuaalmasinasse (JVM).
Eesmärgid
Vaatame mõnda piirkonda, kus saame Camunda BPM Dockeri pilti kohandada (), et see Kubernetesega hästi suhtleks.
- Logid ja mõõdikud;
- Andmebaasi ühendused;
- Autentimine;
- Seansi juhtimine.
Vaatleme mitmeid viise nende eesmärkide saavutamiseks ja näitame selgelt kogu protsessi.
Märkus: Kas kasutate Enterprise'i versiooni? Vaata ja vajadusel värskendage pildilinke.
Töövoo arendamine
Selles demos kasutame Skaffoldi Dockeri piltide loomiseks Google Cloud Buildi abil. Sellel on hea tugi erinevatele tööriistadele (nagu Kustomize ja Helm), CI- ja ehitustööriistadele ning infrastruktuuri pakkujatele. Fail skaffold.yaml.tmpl sisaldab Google Cloud Buildi ja GKE seadeid, pakkudes väga lihtsat viisi tootmistaseme infrastruktuuri käitamiseks.
make skaffold laadib Dockerfile'i konteksti Cloud Buildi, loob pildi ja salvestab selle GCR-is ning rakendab seejärel manifestid teie klastris. Seda see teeb make skaffold, kuid Skaffoldil on palju muid funktsioone.
Kubernetese yamli mallide puhul kasutame kustomize'i yamli ülekatete haldamiseks ilma kogu manifesti kahandamata, võimaldades teil kasutada git pull --rebase edasiste paranduste jaoks. Nüüd on see kubectlis ja töötab selliste asjade puhul päris hästi.
Samuti kasutame faili envsubst hostinime ja GCP projekti ID sisestamiseks *.yaml.tmpl-failidesse. Näete, kuidas see sees töötab makefile või lihtsalt jätkake.
Eeltingimused
- Tööklaster
- - oma dokipiltide loomiseks ja hõlpsaks juurutamiseks GKE-sse
- Selle koodi koopia
- Envsubst
Töövoog manifestide abil
Kui te ei soovi kustomize'i või skaffoldi kasutada, võite vaadata manifeste generated-manifest.yaml ja kohandage need vastavalt teie valitud töövoogudele.
Logid ja mõõdikud
Prometheusest on saanud Kubernetes mõõdikute kogumise standard. Sellel on sama nišš nagu AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics ja teised. See on avatud lähtekoodiga ja sellel on võimas päringukeel. Usaldame visualiseerimise Grafanale – sellega on kaasas suur hulk karbist väljas saadaolevaid armatuurlaudu. Need on omavahel ühendatud ja neid on suhteliselt lihtne paigaldada .
Vaikimisi kasutab Prometheus ekstraheerimismudelit <service>/metricsja külgkorvi konteinerite lisamine selleks on tavaline. Kahjuks on JMX-i mõõdikud kõige paremini logitud JVM-is, seega pole külgkorvi konteinerid nii tõhusad. Ühendame avatud lähtekoodiga Prometheusest JVM-i, lisades selle konteineri kujutisele, mis annab tee /metrics teises sadamas.
Lisage konteinerisse 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
Noh, see oli lihtne. Eksportija jälgib tomcati ja kuvab selle mõõdikuid Prometheuse formaadis aadressil <svc>:9404/metrics
Eksportija seadistamine
Tähelepanelik lugeja võib küsida, kust see tuli prometheus-jmx.yaml? JVM-is saab töötada palju erinevaid asju ja tomcat on vaid üks neist, seega vajab eksportija lisakonfiguratsiooni. Saadaval on standardkonfiguratsioonid tomcat, wildfly, kafka ja nii edasi jaoks . Lisame totcat as Kubernetes ja seejärel paigaldage see köitena.
Esiteks lisame eksportija konfiguratsioonifaili oma platvormi/config/ kataloogi
platform/config
└── prometheus-jmx.yaml
Siis lisame в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
See lisab iga elemendi files[] ConfigMapi konfiguratsioonielemendina. ConfigMapGenerators on suurepärane, kuna räsib konfiguratsiooniandmeid ja sunnib podi taaskäivitama, kui need muutuvad. Need vähendavad ka juurutamise konfiguratsiooni hulka, kuna saate ühendada terve konfiguratsioonifailide "kausta" ühte VolumeMounti.
Lõpuks peame installima ConfigMapi mahuna podi:
-- 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
[...]
Imeline. Kui Prometheus ei ole konfigureeritud täielikku puhastamist tegema, peate võib-olla käskima tal kaunad puhastada. Prometheus Operatori kasutajad saavad kasutada service-monitor.yaml alustamiseks. Uurige Service-monitor.yaml, и enne kui alustad.
Selle mustri laiendamine teistele kasutusjuhtudele
Kõik failid, mille me lisame ConfigMapGeneratorisse, on saadaval uues kataloogis /etc/config. Saate seda malli laiendada muude vajalike konfiguratsioonifailide paigaldamiseks. Saate isegi paigaldada uue käivitusskripti. Sa võid kasutada üksikute failide ühendamiseks. Xml-failide värskendamiseks kaaluge selle kasutamist sed asemel. See on juba pildile lisatud.
Ajakirjad
Hea uudis! Rakenduste logid on stdoutis juba saadaval, näiteks koos kubectl logs. Fluentd (vaikimisi installitud GKE-sse) saadab teie logid edasi Elasticsearchile, Lokile või teie ettevõtte logimisplatvormile. Kui soovite logide jaoks kasutada jsonifyt, saate installimiseks järgida ülaltoodud malli .
Andmebaas
Vaikimisi on pildil H2 andmebaas. See meile ei sobi ja me kasutame Google Cloud SQL-i koos Cloud SQL Proxyga – seda läheb hiljem sisemiste probleemide lahendamiseks vaja. See on lihtne ja usaldusväärne valik, kui teil pole andmebaasi seadistamisel oma eelistusi. AWS RDS pakub sarnast teenust.
Olenemata valitud andmebaasist, kui see pole H2, peate määrama sobivad keskkonnamuutujad platform/deploy.yaml. See näeb välja umbes selline:
-- 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
[...]
Märkus: Kustomize'i abil saate ülekatte abil juurutada erinevatesse keskkondadesse: .
Märkus: kasutamine valueFrom: secretKeyRef. Palun kasutage isegi arenduse ajal, et hoida oma saladusi turvaliselt.
Tõenäoliselt on teil juba eelistatud süsteem Kubernetese saladuste haldamiseks. Kui ei, siis siin on mõned võimalused: krüpteerige need oma pilveteenuse pakkuja KMS-iga ja seejärel sisestage need K8S-i saladustena CD-konveieri kaudu – - töötab väga hästi koos Kustomize saladustega. On ka teisi tööriistu, nagu dotGPG, mis täidavad sarnaseid funktsioone: , .
Ingress
Kui te ei vali kohalikku pordi suunamist, vajate konfigureeritud sisendkontrollerit. Kui te ei kasuta (), siis tõenäoliselt teate juba, et peate installima vajalikud märkused ingress-patch.yaml.tmpl või platform/ingress.yaml. Kui kasutate ingress-nginxi ja näete nginxi sisestusklassi, millele osutab koormuse tasakaalustaja ja välise DNS-i või metamärgiga DNS-i kirje, siis on kõik korras. Muul juhul konfigureerige sissepääsukontroller ja DNS või jätke need sammud vahele ja säilitage otseühendus podiga.
TLS
Kui kasutate või kube-lego ja letsencrypt – uue sisselogimise sertifikaadid hangitakse automaatselt. Vastasel juhul avage ingress-patch.yaml.tmpl ja kohandage seda vastavalt oma vajadustele.
Käivitage!
Kui järgisite kõike ülalkirjeldatud, siis käsku make skaffold HOSTNAME=<you.example.com> peaks käivitama saadaoleva eksemplari <hostname>/camunda
Kui te pole oma sisselogimiseks avalikku URL-i määranud, saate selle ümber suunata localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 edasi localhost:8080/camunda
Oodake mõni minut, kuni kõuts on täielikult valmis. Serdihalduril kulub domeeninime kinnitamiseks veidi aega. Seejärel saate logisid jälgida saadaolevate tööriistade (nt kubetail) või lihtsalt kubectli abil.
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Järgmised sammud
luba
See on Camunda BPM-i konfigureerimisel asjakohasem kui Kubernetes, kuid on oluline märkida, et vaikimisi on autentimine REST API-s keelatud. Sa saad või kasutage mõnda muud meetodit nagu . Saate kasutada xml-i laadimiseks konfiguratsioonikaarte ja köiteid või pildil olemasolevate failide redigeerimiseks xmlstarleti (vt ülal) ning kasutada wget-i või laadida need algkonteineri ja jagatud köite abil.
Seansi juhtimine
Nagu paljud teised rakendused, haldab Camunda BPM seansse JVM-is, nii et kui soovite käitada mitut koopiat, saate lubada kleepuvad seansid (), mis eksisteerib seni, kuni replika kaob, või määrake küpsiste jaoks atribuut Max-Age. Tugevama lahenduse saamiseks saate Tomcatis juurutada Session Manageri. Larsil on sellel teemal, aga midagi sellist:
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
Märkus: saate sed asemel kasutada xmlstarlet
Me kasutasime Google Cloud Memorystore'i ees koos (toetab Redist), et seda käivitada.
Skaleerimine
Kui te juba mõistate seansse, võib Camunda BPM-i skaleerimise esimene (ja sageli ka viimane) piirang olla ühendus andmebaasiga. Osaline kohandamine on juba saadaval "" Keelame failis settings.xml ka intialSize. Lisama ja saate kaunade arvu hõlpsalt automaatselt skaleerida.
Taotlused ja piirangud
В platform/deployment.yaml Näete, et oleme ressursside välja kõvasti kodeerinud. See töötab HPA-ga hästi, kuid võib vajada täiendavat konfigureerimist. Selleks sobib kustomize plaaster. cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
Väljund
Seega installisime Camunda BPM-i Kubernetesesse koos Prometheuse mõõdikute, logide, H2 andmebaasi, TLS-i ja Ingressiga. Lisasime ConfigMapsi ja Dockerfile'i abil jar-failid ja konfiguratsioonifailid. Rääkisime andmete vahetamisest mahtudele ja otse keskkonnamuutujatele saladustest. Lisaks andsime ülevaate Camunda seadistamisest mitme koopia ja autentitud API jaoks.
Viited
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, tõlge Alastair Firth, Lars Lange
Allikas: www.habr.com