Kasutate Kubernetes't? Kas olete valmis oma Camunda BPM eksemplarid virtuaalmasinatelt üle viima või lihtsalt proovima neid Kuberneteses käivitada? Vaatame mõningaid levinud konfigureeringuid ja eraldi komponente, mida saab kohandada teie spetsiifiliste vajadustega.
Eeldatakse, et olete Kubernetes't juba varem kasutanud. Kui ei, miks mitte vaadata ja käivitada oma esimene klaster?
Autorid
- (Alastair Firth) — Camunda Cloudi saidi usaldusväärsuse vaneminsener;
- (Lars Lange) — DevOps-insener Camundas.
Lühidalt öeldes:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Noh, tõenäoliselt ei töötanud see, kuna teil pole installitud skaffoldi ja kustomize'i. Kui nii, siis lugege edasi!
Mis on Camunda BPM
Camunda BPM on avatud lähtekoodiga platvorm äriprotsesside haldamiseks ja otsuste automatiseerimiseks, mis ühendab ärihaldureid ja tarkvaraarendajaid. See sobib ideaalselt inimestega, (mikro) teenuste või isegi botidega koordineerimiseks ja ühendamiseks! Lisateavet erinevate kasutusvõimaluste kohta leiate .
Miks kasutada Kubernetes't
Kubernetes on saanud de facto standardiks kaasaegsete rakenduste käitamiseks Linuxis. Süsteemikutsed asendavad riistvaratasemel emulatsiooni ning südamiku suutlikkus hallata mälu ja ülesande vahetust vähendab käivitusaega ja laadimisaega. Suurim kasu tuleb aga Kubernetes'i pakkumisest standardse API kaudu, mis kohandab kõigi rakenduste jaoks vajaliku infrastruktuuri: salvestus, võrk ja jälgimine. Juunis 2020 täitus tal 6 aastat ning see on ilmselt teine suurima avatud koodiga projekt (Linuxi järel). Viimasel ajal on see aktiivselt stabiliseerinud oma funktsioone pärast kiireid iteratsioone viimastel aastatel, kuna see muutub tootmiskoormuste jaoks kogu maailmas järjest kriitilisemaks.
Camunda BPM Engine saab hõlpsasti ühenduda teiste rakendustega, mis töötavad samas klastris, samas kui Kubernetes tagab suurepärase skaleeritavuse, võimaldades infrastruktuuri kulusid suurendada ainult siis, kui see on tõeliselt vajalik (ja hõlpsasti vähendada vastavalt vajadusele).
Järelevalve kvaliteet paraneb oluliselt ka selliste tööriistade nagu Prometheus, Grafana, Loki, Fluentd ja Elasticsearch abil, mis võimaldavad keskeltvaates kõiki klastritöökoormusi. Täna vaatame, kuidas rakendada Prometheuse eksportijat Java virtuaalmasinas (JVM).
Eesmärgid
Vaadake mõned valdkonnad, kus saame konfigureerida Camunda BPM Docker-pilti (), et see toimiks hästi Kubernetesega.
- Logid ja mõõdikud;
- Andmebaasiühendused;
- Autentimine;
- Seansihaldus.
Vaatame mitmeid viise nende eesmärkide saavutamiseks ja illustreerime kogu protsessi.
Märkus: Kas kasutate Enterprise versiooni? Vaadake ja värskendage pilte vastavalt vajadusele.
Tööprotsessi arendamine
Selles demonstreerimises kasutame Skaffoldi Docker-piltide loomiseks Google Cloud Buildiga. Sellel on hea tugi erinevatele tööriistadele (nagu Kustomize ja Helm), CI ja ehitusriistadele ning infrastruktuuri pakkujatele. Fail skaffold.yaml.tmpl sisaldab Seadeid Google Cloud Buildi ja GKE jaoks, mis võimaldab väga lihtsat tööstusliku tasemega infrastruktuuri käivitamist.
make skaffold laeb konteksti Dockerfile Cloud Buildi, loob pildi ja salvestab selle GCR-i ning seejärel rakendab manifestid teie klastrisse. See on see, mida ta teeb make skaffold, kuid Skaffoldil on palju muid võimalusi.
Kubernetes'i yaml-mallide jaoks kasutame kustomize'i yaml-i overlay'de haldamiseks ilma kogu manifesti harudeta, mis võimaldab teil kasutada git pull --rebase edasiarendamiseks. Praegu on see kubectl-is ja see töötab hästi sarnaste asjade jaoks.
Kasutame ka envsubst'i hostinime ja GCP projekti identifikaatori täitmiseks failides * .yaml.tmpl. Saate vaadata, kuidas see töötab makefile või lihtsalt jätkake edasi.
Nõuded
- Töörühm
- — oma Docker-piltide loomise ja GKE-s lihtsa juurutamise jaoks
- Koopia sellest koodist
- Envsubst
Tööpõhimõtted manifestidega
Kui te ei soovi kasutada kustomize'i või skaffoldi, võite viidata manifestidele generated-manifest.yaml ja kohandada neid oma valitud tööprotsessi jaoks.
Logid ja mõõdikud
Prometheus on saanud standardiks metrikate kogumiseks Kuberneteses. Ta asendab AWS Cloudwatch Metrit, Cloudwatch Alerts'i, Stackdriver Metrit, StatsD, Datadogi, Nagios'e, vSphere Metrit ja teisi. Sellel on avatud lähtekood ja võimas päringute keel. Visualiseerimise jaoks kasutame Grafanat — see tuleb koos suure hulga valmisseadetega armatuurlaudadega. Need on omavahel seotud ja suhteliselt lihtsad seadistada. .
Vaikimisi kasutab Prometheus väljavõtte mudelit /metrics, ja sidecar konteinerite lisamine on tavaline praktika. Kahjuks registreeritakse JMX-metrikad kõige paremini JVM-i sees, mistõttu sidecar konteinerid ei ole nii tõhusad. Ühendame avatud lähtekoodiga Prometheuse JVM-iga, lisades selle konteineri kujutisse, mis annab tee /metrics teisel pordil.
Lisage Prometheus jmx_exporter konteinerisse
-- 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
No, see oli lihtne. Eksporter jälgib tomcat'i ja kuvab selle metrikad Prometheuse formaadis aadressil :9404/metrics
Eksporteri seadistamine
Karmus lugeja võib küsida, kust see tuli prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны . Lisame tomcat'i nagu Kuberneteses ja seejärel monteerime selle mahuna.
Esiteks lisame eksoporterite konfiguratsioonifaili meie katalooge platform/config/
platvorm/config
└── prometheus-jmx.yaml
Seejärel lisame ühes 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[] ConfigMap'i konfiguratsiooni elemendina. ConfigMapGenerators on head, sest need hashivad konfiguratsioonis andmed ning algatavad poodi taaskäivitamise, kui see muutub. Need vähendavad ka konfiguratsiooni mahtu Rikkuse osas, kuna saate monteerida kogu konfiguratsioonifailide 'kausta' ühte VolumeMount'i.
Lõpuks peame monteerima ConfigMap'i kui mahuna poodi:
-- platform/deployment.yaml
apiVersion: apps/v1
tüüp: Deployment
[...]
spetsifikatsioon:
mall:
spetsifikatsioon:
[...]
mahtude:
- name: config
configMap:
nimi: config
vaikeRežiim: 0744
anumad:
- nimi: camunda-bpm
mahuMäged:
- mountPath: /etc/config/
nimi: config
[...]
Suurepärane. Kui Prometheus ei ole seadistatud täielikuks puhastamiseks, peate võib-olla talle ütlema, et ta puhastaks poode. Prometheus Operatori kasutajad saavad kasutada service-monitor.yaml et alustada. Uurige Service-monitor.yaml, ja enne alustamist.
Selle malli levitamine teiste kasutusjuhtude jaoks
Kõik failid, mille lisame ConfigMapGenerator'isse, saavad olema kättesaadavad uues kataloogis /etc/config. Saate seda mallis laiendada, et mountida kõiki teisi vajalikke konfiguratsiooni faile. Saate isegi mountida uue käivitusskripti. Võite kasutada üksikute failide mountimiseks. XML-failide värskendamiseks kaaluge asemel sed. See on pildis juba kaasas.
Logid
Suured uudised! Rakenduse logid on juba stdout-s saadaval, näiteks kubectl logs. Fluentd (mis on GKE-s vaikimisi installitud) suunab teie logid Elasticsearchi, Lokisse või teie ettevõtte logimisplatvormile. Kui soovite kasutada jsonify logide jaoks, võite järgida ülaltoodud malli installimiseks .
Andmebaas
Vaikimisi sisaldab pilt H2 andmebaasi. See ei sobi meile, ja me kasutame Google Cloud SQL-i koos Cloud SQL Proxy'ga — see on hiljem vajalik sisemiste ülesannete lahendamiseks. See on lihtne ja usaldusväärne valik, kui teil pole oma eelistusi andmebaasi seadistamise osas. AWS RDS pakub sarnast teenust.
Olenemata valitud andmebaasist, välja arvatud kui see on H2, peate seadistama vastavad keskkonnamuutujad faili platform/deploy.yaml. See umbes nii:
-- platform/deployment.yaml
apiVersion: apps/v1
tüüp: Deployment
[...]
spetsifikatsioon:
mall:
spetsifikatsioon:
[...]
anumad:
- nimi: camunda-bpm
keskkond:
- nimi: DB_DRIVER
väärtus: org.postgresql.Driver
- nimi: DB_URL
väärtus: jdbc:postgresql://postgres-proxy.db:5432/process-engine
- nimi: DB_USERNAME
väärtusAllikas:
salajaneVõtmeViide:
nimi: cambpm-db-credentials
võti: db_username
- nimi: DB_PASSWORD
väärtusAllikas:
salajaneVõtmeViide:
nimi: cambpm-db-credentials
võti: db_password
[...]
Märkus: Saate kasutada Kustomize'i erinevates keskkondades juurdepääsu süsteemide ülekatte kasutamiseks: .
Märkus: kasutamine valueFrom: secretKeyRef. Palun kasutage isegi arendamise ajal, et hoida oma saladusi turvaliselt.
On tõenäoline, et teil on juba eelistatud Kubernetes'i saladuste haldamise süsteem. Kui ei, siis siin on mõned variandid: nende krüpteerimine teie pilveteenuse pakkuja KMS-i abil ja seejärel nende sissetoomine K8S-ina saladustena CD-voogude kaudu — — töötab väga hästi Kustomize'i saladustega. On ka teisi tööriistu, nagu dotGPG — need täidavad sarnaseid funktsioone: , .
Ingress
Kui te ei otsusta kasutada kohalikku sadama edastamist, vajate seadistatud Ingress Controllerit. Kui te ei kasuta () siis te tõenäoliselt juba teate, et peate määrama vajalikud annotatsioonid ingress-patch.yaml.tmpl või platform/ingress.yaml. Kui kasutate ingress-nginx-i ja näete nginx ingress klassi koos sellele suunatud koormuse tasakaalustajaga ja välise DNS-i või asenduse DNS-i kirje, on kõik valmis. Vastupidisel juhul seadistage Ingress Controller ja DNS või jätke need sammud vahele ning jätke otseühendus pod-i juurde.
TLS
Kui kasutate või kube-lego ja letsencrypt — sertifikaadid uue sisenemise jaoks saadakse automaatselt. Vastupidisel juhul avage ingress-patch.yaml.tmpl ja seadistage see oma vajadustele vastavaks.
Käivitamine!
Kui olete järgnenud kõigile ülaltoodud juhistele, peaks käsk make skaffold HOSTNAME= käivitama saadaval oleva eksemplari aadressil /camunda
Kui te ei ole sisenemist määranud avaliku URL-aadressiga, saate selle suunata localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 järgnevaga localhost:8080/camunda
Oodake mõned minutid, kuni tomcat täies mahus käivitub. Cert-manager vajab domeeninime kontrollimiseks aega. Pärast seda saate jälgida logisid olemasolevate vahendite abil — näiteks sellise tööriista nagu kubetail abil või lihtsalt kubectl-i kaudu:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Järgmised sammud
Autoriseerimine
See puudutab rohkem Camunda BPM seadistamist kui Kubernetes, kuid on oluline märkida, et vaikimisi on REST API autentimine keelatud. Saate või kasuta mõnda muud meetodit, näiteks . Sa saad kasutada configmaps'i ja mahtu xml-i üleslaadimiseks või xmlstarlet'i (vaata üle) olemasolevate failide redigeerimiseks pildis, samuti kasutada kas wget'i või laadida neid init konteineri ja ühise mahu kaudu.
Seansihaldus
Nagu paljude teiste rakenduste puhul, töötleb Camunda BPM seansse JVM-is, seega, kui soovid käivitada mitu koopiat, saad sisse lülitada sticky seansid (), mis püsivad seni, kuni koopiad kaovad, või määrata küpsiste Max-Age atribuut. Usaldusväärsema lahendusena saad kasutada Session Managerit Tomcat'is. Lars'il on selle kohta teave, aga midagi sarnast:
wget http://repo1.maven.org/maven2/ee/javakaffee/msm/memcached-session-manager/
2.3.2/memcached-session-manager-2.3.2.jar -P lib/ &&
wget http://repo1.maven.org/maven2/ee/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
Märkus: xmlstarlet'i saab kasutada sed'i asemel
Me kasutasime enne Google Cloud Memorystore’i, koos (toetab Redis) selle tööks.
Mastaapimine
Kui olete juba sessioonidega tutvust teinud, võib Camunda BPM-i skaleeritavuse esimene (ja sageli viimane) piirang olla andmebaasi ühendus. Osaline seadistamine on juba "". Lülitame ka settings.xml failis välja intialSize. Lisage ja saate hõlpsasti automaatselt skaaleerida podide arvu.
Päringud ja piirangud
V platform/deployment.yaml näete, et oleme ressursside välja rangelt kodeerinud. See töötab HPA-ga hästi, kuid võib vajada täiendavat seadistamist. Selleks sobib kustomize patch. Vaadake, ingress-patch.yaml.tmpl ja ./kustomization.yaml.tmpl
Kokkuvõte
Nii oleme me Camunda BPM-i Kuberneteses installinud koos Prometheuse mõõturitega, logidega, H2 andmebaasiga, TLS-i ja Ingressiga. Oleme lisanud jar-failid ja konfiguratsioonifailid, kasutades ConfigMaps ja Dockerfile'i. Rääkisime andmevahetusest mahutites ja vahetult keskkonnamuutujatesse saladustest. Lisaks andsime ülevaate Camunda seadistamisest mitme replika ja autentitud API jaoks.
Lingid
github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes
│
├── generated-manifest.yaml <- manifest, mida saab kasutada ilma kustomize'ita
├── images
│ └── camunda-bpm
│ └── Dockerfile <- overlay docker pilt
├── ingress-patch.yaml.tmpl <- saidispetsiifiline ingress konfiguratsioon
├── kustomization.yaml.tmpl <- peamine Kustomization
├── Makefile <- make sihtmärgid
├── namespace.yaml
├── platform
│ ├── config
│ │ └── prometheus-jmx.yaml <- prometheus eksportija konfiguratsioonifail
│ ├── deployment.yaml <- peamine juurdepääs
│ ├── ingress.yaml
│ ├── kustomization.yaml <- "põhi" kustomization
│ ├── service-monitor.yaml <- näidis prometheus-operatori konfiguratsioon
│ └── service.yaml
└── skaffold.yaml.tmpl <- skaffold direktiivid
05.08.2020, tõlge Alastair Firth, Lars Lange
Allikas: habr.com
