Ertu að nota Kubernetes? Tilbúinn til að færa Camunda BPM tilvikin þín úr sýndarvélum, eða kannski bara prófa að keyra þau á Kubernetes? Við skulum skoða nokkrar algengar stillingar og einstaka hluti sem hægt er að sníða að þínum þörfum.
Það gerir ráð fyrir að þú hafir notað Kubernetes áður. Ef ekki, hvers vegna ekki að kíkja á og byrjaðu ekki fyrsta þyrpinguna þína?
Höfundar
- (Alastair Firth) - Senior Site Reliability Engineer í Camunda Cloud teyminu;
- (Lars Lange) - DevOps verkfræðingur hjá Camunda.
Í stuttu máli:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Allt í lagi, það virkaði líklega ekki vegna þess að þú ert ekki með skaffold og kustomize uppsett. Jæja lestu þá áfram!
Hvað er Camunda BPM
Camunda BPM er opinn uppspretta viðskiptaferlastjórnunar og sjálfvirkni ákvarðanavettvangur sem tengir viðskiptanotendur og hugbúnaðarframleiðendur. Það er tilvalið til að samræma og tengja fólk, (ör)þjónustu eða jafnvel vélmenni! Þú getur lesið meira um mismunandi notkunartilvik á .
Af hverju að nota Kubernetes
Kubernetes er orðinn raunverulegur staðall til að keyra nútíma forrit á Linux. Með því að nota kerfissímtöl í stað vélbúnaðarhermi og getu kjarnans til að stjórna minni og verkefnaskiptum er ræsingartíma og ræsingartíma haldið í lágmarki. Hins vegar gæti stærsti ávinningurinn komið frá venjulegu API sem Kubernetes veitir til að stilla innviðina sem öll forrit þurfa: geymslu, netkerfi og eftirlit. Það varð 2020 ára í júní 6 og er kannski næststærsta opinn uppspretta verkefnið (á eftir Linux). Það hefur nýlega verið virkt stöðugt í virkni sinni eftir hraða endurtekningu á undanförnum árum þar sem það verður mikilvægt fyrir vinnuálag framleiðslu um allan heim.
Camunda BPM Engine getur auðveldlega tengst öðrum forritum sem keyra á sama þyrpingunni og Kubernetes veitir framúrskarandi sveigjanleika, sem gerir þér kleift að auka innviðakostnað aðeins þegar raunverulega er þörf (og minnka hann auðveldlega eftir þörfum).
Gæði vöktunar eru einnig aukin til muna með verkfærum eins og Prometheus, Grafana, Loki, Fluentd og Elasticsearch, sem gerir þér kleift að skoða miðlægt allt vinnuálag í klasa. Í dag munum við skoða hvernig á að innleiða Prometheus útflytjanda í Java Virtual Machine (JVM).
Markmið
Við skulum skoða nokkur svæði þar sem við getum sérsniðið Camunda BPM Docker myndina () þannig að það virkar vel við Kubernetes.
- Logs og mæligildi;
- Gagnagrunnstengingar;
- Auðkenning;
- Þingstjórn.
Við munum skoða nokkrar leiðir til að ná þessum markmiðum og sýna skýrt allt ferlið.
Athugið: Ertu að nota Enterprise útgáfuna? Sjáðu og uppfærðu myndatengla eftir þörfum.
Þróun vinnuflæðis
Í þessari kynningu munum við nota Skaffold til að smíða Docker myndir með Google Cloud Build. Það hefur góðan stuðning fyrir ýmis verkfæri (eins og Kustomize og Helm), CI og smíðaverkfæri og innviðaveitendur. Skrá skaffold.yaml.tmpl inniheldur stillingar fyrir Google Cloud Build og GKE, sem býður upp á mjög einfalda leið til að keyra innviði fyrir framleiðslustig.
make skaffold mun hlaða Dockerfile samhenginu inn í Cloud Build, byggja myndina og geyma hana í GCR og nota síðan birtingarmyndina á þyrpinguna þína. Þetta er það sem það gerir make skaffold, en Skaffold hefur marga aðra eiginleika.
Fyrir yaml sniðmát í Kubernetes notum við kustomize til að hafa umsjón með yaml yfirborði án þess að punga upp alla upplýsingaskrána, sem gerir þér kleift að nota git pull --rebase til frekari úrbóta. Núna er það í kubectl og það virkar frekar vel fyrir svona hluti.
Við notum einnig envsubst til að fylla út hýsilheitið og GCP verkefniskennið í *.yaml.tmpl skránum. Þú getur séð hvernig það virkar í makefile eða bara halda áfram.
Forkröfur
- Vinnuklasi
- - til að búa til þínar eigin bryggjumyndir og auðvelda uppsetningu á GKE
- Afrit af þessum kóða
- Envsubst
Verkflæði með því að nota upplýsingaskrá
Ef þú vilt ekki nota kustomize eða skaffold geturðu vísað til upplýsingaskránna í generated-manifest.yaml og aðlaga þær að því verkflæði sem þú velur.
Logs og mælikvarðar
Prometheus hefur orðið staðallinn til að safna mæligildum í Kubernetes. Það hefur sama sess og AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics og aðrir. Það er opinn uppspretta og hefur öflugt fyrirspurnarmál. Við munum fela Grafana sjónmyndina - henni fylgir fjöldinn allur af mælaborðum sem eru fáanlegir úr kassanum. Þau eru tengd innbyrðis og tiltölulega auðvelt að setja þau upp með .
Sjálfgefið er að Prometheus notar útdráttarlíkanið <service>/metrics, og það er algengt að bæta við hliðarvagnaílátum fyrir þetta. Því miður eru JMX mælingar best skráðar innan JVM, svo hliðarvagnagámar eru ekki eins skilvirkir. Tengjumst opinn uppspretta frá Prometheus í JVM með því að bæta því við gámamyndina sem mun veita slóðina /metrics á annarri höfn.
Bættu Prometheus jmx_exporter við ílátið
-- 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
Jæja, þetta var auðvelt. Útflytjandinn mun fylgjast með tomcat og sýna mælikvarða hans á Prometheus sniði á <svc>:9404/metrics
Uppsetning útflytjanda
Athugull lesandi gæti velt því fyrir sér hvaðan það kom prometheus-jmx.yaml? Það eru margir mismunandi hlutir sem geta keyrt í JVM, og tomcat er bara einn af þeim, svo útflytjandinn þarf nokkrar viðbótarstillingar. Staðlaðar stillingar fyrir tomcat, wildfly, kafka og svo framvegis eru fáanlegar . Við munum bæta við Tomcat sem í Kubernetes og festu það síðan sem bindi.
Fyrst bætum við útflytjanda stillingarskránni við pallinn/config/ möppuna okkar
platform/config
└── prometheus-jmx.yaml
Síðan bætum við við в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Þetta mun bæta við hverjum þætti files[] sem ConfigMap stillingarþáttur. ConfigMapGenerators eru frábærir vegna þess að þeir hassa uppstillingargögnin og þvinga fram endurræsingu pod ef það breytist. Þeir draga einnig úr magni stillinga í Deployment þar sem þú getur tengt heila „möppu“ af stillingarskrám í einu VolumeMount.
Að lokum þurfum við að tengja ConfigMap sem bindi á hólfið:
-- 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
[...]
Dásamlegt. Ef Prometheus er ekki stillt til að gera fulla hreinsun gætirðu þurft að segja honum að þrífa belgina. Notendur Prometheus Operator geta notað service-monitor.yaml að byrja. Kanna Service-monitor.yaml, и áður en þú byrjar.
Útvíkka þetta mynstur til annarra notkunartilvika
Allar skrár sem við bætum við ConfigMapGenerator verða tiltækar í nýju möppunni /etc/config. Þú getur framlengt þetta sniðmát til að tengja allar aðrar stillingarskrár sem þú þarft. Þú getur jafnvel tengt nýtt ræsingarforskrift. Þú getur notað til að tengja einstakar skrár. Til að uppfæra xml skrár skaltu íhuga að nota í stað sed. Það er þegar innifalið í myndinni.
Tímarit
Frábærar fréttir! Forritaskrár eru nú þegar fáanlegar á stdout, til dæmis með kubectl logs. Fluentd (uppsett sjálfgefið í GKE) mun senda annálana þína til Elasticsearch, Loki eða fyrirtækjaskráningarvettvangsins. Ef þú vilt nota jsonify fyrir logs þá geturðu fylgt ofangreindu sniðmátinu til að setja upp .
Gagnagrunnur
Sjálfgefið er að myndin sé með H2 gagnagrunn. Þetta hentar okkur ekki og við munum nota Google Cloud SQL með Cloud SQL Proxy - þetta mun þurfa síðar til að leysa innri vandamál. Þetta er einfaldur og áreiðanlegur valkostur ef þú hefur ekki þínar eigin óskir við uppsetningu gagnagrunnsins. AWS RDS veitir svipaða þjónustu.
Óháð gagnagrunninum sem þú velur, nema það sé H2, þarftu að stilla viðeigandi umhverfisbreytur í platform/deploy.yaml. Það lítur eitthvað svona út:
-- 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
[...]
Athugið: Þú getur notað Kustomize til að dreifa í mismunandi umhverfi með því að nota yfirborð: .
Athugið: notkun valueFrom: secretKeyRef. Vinsamlegast notaðu jafnvel meðan á þróun stendur til að halda leyndarmálum þínum öruggum.
Það er líklegt að þú hafir nú þegar valið kerfi til að stjórna Kubernetes leyndarmálum. Ef ekki, þá eru hér nokkrir valkostir: Dulkóða þá með KMS skýjaveitunnar og sprauta þeim síðan inn í K8S sem leyndarmál í gegnum geisladiskaleiðsluna - - mun virka mjög vel í samsetningu með Kustomize leyndarmálum. Það eru önnur verkfæri, svo sem dotGPG, sem framkvæma svipaðar aðgerðir: , .
Innstreymi
Nema þú veljir að nota staðbundna framsendingu hafna þarftu stilltan Ingress Controller. Ef þú notar ekki () þá veistu líklegast að þú þarft að setja upp nauðsynlegar athugasemdir í ingress-patch.yaml.tmpl eða platform/ingress.yaml. Ef þú ert að nota ingress-nginx og sérð nginx ingress class með álagsjafnara sem bendir á hann og utanaðkomandi DNS eða wildcard DNS færslu, þá ertu góður að fara. Annars skaltu stilla Ingress Controller og DNS, eða sleppa þessum skrefum og halda beinni tengingu við pod.
TLS
Ef þú ert að nota eða kube-lego og letsencrypt - vottorð fyrir nýja innskráningu verða sjálfkrafa fengin. Annars opið ingress-patch.yaml.tmpl og sérsníða það að þínum þörfum.
Ræstu!
Ef þú fylgdir öllu sem skrifað er hér að ofan, þá skipunina make skaffold HOSTNAME=<you.example.com> ætti að ræsa tiltækt tilvik í <hostname>/camunda
Ef þú hefur ekki stillt innskráningu þína á opinbera vefslóð geturðu vísað henni áfram með localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 á localhost:8080/camunda
Bíddu í nokkrar mínútur þar til tomcat er alveg tilbúið. Vottunarstjóri mun taka nokkurn tíma að staðfesta lénið. Þú getur síðan fylgst með annálunum með því að nota tiltæk verkfæri eins og tól eins og kubetail, eða einfaldlega með því að nota kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Næstu skref
Innskráning
Þetta er meira viðeigandi við að stilla Camunda BPM en Kubernetes, en það er mikilvægt að hafa í huga að sjálfgefið er auðkenning óvirk í REST API. Þú getur eða notaðu aðra aðferð eins og . Þú getur notað configmaps og bindi til að hlaða xml, eða xmlstarlet (sjá hér að ofan) til að breyta núverandi skrám í myndinni, og annað hvort notað wget eða hlaða þeim með init íláti og sameiginlegu bindi.
Þingstjórn
Eins og mörg önnur forrit, sér Camunda BPM um lotur í JVM, þannig að ef þú vilt keyra margar eftirlíkingar geturðu virkjað klístraða lotur (), sem verður til þar til eftirmyndin hverfur, eða stilltu Max-Age eigindina fyrir smákökur. Fyrir öflugri lausn geturðu sett upp Session Manager í Tomcat. Lars hefur um þetta efni, en eitthvað eins og:
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
Athugið: þú getur notað xmlstarlet í staðinn fyrir sed
Við notuðum fyrir framan Google Cloud Memorystore, með (styður Redis) til að keyra það.
Skala
Ef þú skilur nú þegar lotur, þá gæti fyrsta (og oft síðasta) takmörkunin á því að skala Camunda BPM verið tengingin við gagnagrunninn. Aðlögun að hluta er þegar í boði "" Slökktum líka á intialSize í settings.xml skránni. Bæta við og þú getur auðveldlega skalað fjölda fræbelgja sjálfkrafa.
Beiðnir og takmarkanir
В platform/deployment.yaml Þú munt sjá að við höfum harðkóða auðlindareitinn. Þetta virkar vel með HPA, en gæti þurft viðbótarstillingar. Kustomize plásturinn er hentugur fyrir þetta. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
Output
Þannig að við settum upp Camunda BPM á Kubernetes með Prometheus mæligildum, logs, H2 gagnagrunni, TLS og Ingress. Við bættum við jar skrám og stillingarskrám með ConfigMaps og Dockerfile. Við ræddum um að skiptast á gögnum í rúmmál og beint í umhverfisbreytur úr leyndarmálum. Að auki veittum við yfirlit yfir uppsetningu Camunda fyrir margar eftirmyndir og auðkennt API.
tilvísanir
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, þýðing Alastair Firth og Lars Lange
Heimild: www.habr.com