Ali uporabljate Kubernetes? Ste pripravljeni premakniti svoje primerke Camunda BPM iz virtualnih strojev ali pa jih morda preprosto poskusiti zagnati v Kubernetesu? Oglejmo si nekaj pogostih konfiguracij in posameznih elementov, ki jih je mogoče prilagoditi vašim posebnim potrebam.
Predpostavlja, da ste že uporabljali Kubernetes. Če ne, zakaj si ne ogledate in ne zaženete svoje prve gruče?
Avtorji
- (Alastair Firth) – višji inženir za zanesljivost mesta v ekipi Camunda Cloud;
- (Lars Lange) – DevOps inženir pri Camundi.
V kratkem:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
V redu, verjetno ni delovalo, ker nimate nameščenih programov skaffold in kustomize. No, potem berite naprej!
Kaj je Camunda BPM
Camunda BPM je odprtokodna platforma za upravljanje poslovnih procesov in avtomatizacijo odločanja, ki povezuje poslovne uporabnike in razvijalce programske opreme. Idealen je za koordinacijo in povezovanje ljudi, (mikro) storitev ali celo botov! Več o različnih primerih uporabe lahko preberete na .
Zakaj uporabljati Kubernetes
Kubernetes je postal de facto standard za izvajanje sodobnih aplikacij v sistemu Linux. Z uporabo sistemskih klicev namesto emulacije strojne opreme in zmožnostjo jedra za upravljanje pomnilnika in preklapljanje opravil sta čas zagona in zagona skrajšana na minimum. Največja korist pa lahko izhaja iz standardnega API-ja, ki ga ponuja Kubernetes za konfiguracijo infrastrukture, ki jo potrebujejo vse aplikacije: shranjevanje, mreženje in spremljanje. Junija 2020 je dopolnil 6 let in je morda drugi največji odprtokodni projekt (za Linuxom). Nedavno je aktivno stabiliziral svojo funkcionalnost po hitrem ponavljanju v zadnjih nekaj letih, ko je postalo kritično za proizvodne delovne obremenitve po vsem svetu.
Camunda BPM Engine se lahko preprosto poveže z drugimi aplikacijami, ki se izvajajo v isti gruči, Kubernetes pa zagotavlja odlično razširljivost, ki vam omogoča, da povečate stroške infrastrukture le, ko je to res potrebno (in jih po potrebi preprosto zmanjšate).
Kakovost spremljanja je močno izboljšana tudi z orodji, kot so Prometheus, Grafana, Loki, Fluentd in Elasticsearch, ki vam omogočajo centralni pregled vseh delovnih obremenitev v gruči. Danes si bomo ogledali, kako implementirati izvoznik Prometheus v Java Virtual Machine (JVM).
Cilji
Oglejmo si nekaj področij, kjer lahko prilagodimo sliko Camunda BPM Docker (), tako da dobro sodeluje s Kubernetesom.
- Dnevniki in metrike;
- Povezave z bazo podatkov;
- avtentikacija;
- Upravljanje sej.
Ogledali si bomo več načinov za doseganje teh ciljev in nazorno prikazali celoten postopek.
Obvestilo: Ali uporabljate različico Enterprise? Poglej in po potrebi posodobite povezave do slik.
Razvoj poteka dela
V tej predstavitvi bomo uporabili Skaffold za izdelavo slik Docker z uporabo Google Cloud Build. Ima dobro podporo za različna orodja (kot sta Kustomize in Helm), CI in orodja za gradnjo ter ponudnike infrastrukture. mapa skaffold.yaml.tmpl vključuje nastavitve za Google Cloud Build in GKE, kar zagotavlja zelo preprost način za zagon infrastrukture produkcijske ravni.
make skaffold bo naložil kontekst datoteke Dockerfile v Cloud Build, zgradil sliko in jo shranil v GCR ter nato uporabil manifeste za vašo gručo. To je tisto, kar počne make skaffold, vendar ima Skaffold veliko drugih funkcij.
Za predloge yaml v Kubernetesu uporabljamo kustomize za upravljanje prekrivk yaml brez razcepitve celotnega manifesta, kar vam omogoča uporabo git pull --rebase za nadaljnje izboljšave. Zdaj je v kubectl in deluje precej dobro za take stvari.
Envsubst uporabljamo tudi za zapolnitev imena gostitelja in ID-ja projekta GCP v datotekah *.yaml.tmpl. Kako deluje, si lahko ogledate v makefile ali samo nadaljujte.
Predpogoji
- Delovni grozd
- - za ustvarjanje lastnih slik dockerjev in enostavno uvajanje v GKE
- Kopija te kode
- Envsubst
Potek dela z uporabo manifestov
Če ne želite uporabljati kustomize ali skaffold, si lahko ogledate manifeste v generated-manifest.yaml in jih prilagodite poteku dela po vaši izbiri.
Dnevniki in metrike
Prometheus je postal standard za zbiranje metrik v Kubernetesu. Zaseda isto nišo kot AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics in drugi. Je odprtokoden in ima zmogljiv poizvedovalni jezik. Vizualizacijo bomo zaupali Grafanu, ki ima veliko število nadzornih plošč, ki so na voljo takoj po izdelavi. Med seboj so povezani in jih je relativno enostavno namestiti .
Prometheus privzeto uporablja model ekstrakcije <service>/metrics, in dodajanje zabojnikov s prikolico za to je običajno. Na žalost se metrike JMX najbolje beležijo znotraj JVM, zato kontejnerji s prikolico niso tako učinkoviti. Povežimo se odprtokodno iz Prometheusa v JVM, tako da ga dodate v sliko vsebnika, ki bo zagotovila pot /metrics na druga vrata.
V vsebnik dodajte 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
No, to je bilo enostavno. Izvoznik bo spremljal tomcat in prikazal njegove meritve v formatu Prometheus na <svc>:9404/metrics
Nastavitev izvoznika
Pozoren bralec se lahko vpraša, od kod izvira prometheus-jmx.yaml? Obstaja veliko različnih stvari, ki se lahko izvajajo v JVM, in tomcat je le ena izmed njih, zato izvoznik potrebuje nekaj dodatne konfiguracije. Na voljo so standardne konfiguracije za tomcat, wildfly, kafka in tako naprej . Tomcat bomo dodali kot v Kubernetesu in ga nato namestite kot nosilec.
Najprej dodamo konfiguracijsko datoteko izvoznika v naš imenik platform/config/
platform/config
└── prometheus-jmx.yaml
Nato dodamo в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
To bo dodalo vsak element files[] kot konfiguracijski element ConfigMap. ConfigMapGenerators so odlični, ker zgostijo konfiguracijske podatke in vsilijo ponovni zagon sklopa, če se spremeni. Prav tako zmanjšajo količino konfiguracije v Deploymentu, saj lahko namestite celotno "mapo" konfiguracijskih datotek v en VolumeMount.
Končno moramo namestiti ConfigMap kot nosilec v pod:
-- 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
[...]
čudovito Če Prometheus ni konfiguriran za popolno čiščenje, mu boste morda morali naročiti, naj očisti sklope. Uporabniki Prometheus Operator lahko uporabljajo service-monitor.yaml za začetek. Raziščite Service-monitor.yaml, и preden začnete.
Razširitev tega vzorca na druge primere uporabe
Vse datoteke, ki jih dodamo v ConfigMapGenerator, bodo na voljo v novem imeniku /etc/config. To predlogo lahko razširite za namestitev katere koli druge konfiguracijske datoteke, ki jo potrebujete. Namestite lahko celo nov zagonski skript. Lahko uporabiš za namestitev posameznih datotek. Če želite posodobiti datoteke xml, razmislite o uporabi namesto sed. To je že vključeno v sliko.
Revije
Odlična novica! Dnevniki aplikacij so že na voljo na stdoutu, na primer z kubectl logs. Fluentd (privzeto nameščen v GKE) bo vaše dnevnike posredoval Elasticsearch, Loki ali platformi za beleženje vašega podjetja. Če želite uporabljati jsonify za dnevnike, lahko za namestitev sledite zgornji predlogi .
Baza podatkov
Privzeto bo slika imela bazo podatkov H2. To za nas ni primerno in uporabili bomo Google Cloud SQL s Cloud SQL Proxy – to bo potrebno pozneje za reševanje notranjih težav. To je preprosta in zanesljiva možnost, če nimate lastnih preferenc pri nastavitvi baze podatkov. AWS RDS ponuja podobno storitev.
Ne glede na bazo podatkov, ki jo izberete, razen če je H2, boste morali nastaviti ustrezne spremenljivke okolja v platform/deploy.yaml. Videti je nekako takole:
-- 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
[...]
Obvestilo: Uporabite lahko Kustomize za uvajanje v različna okolja z uporabo prekrivanja: .
Obvestilo: uporaba valueFrom: secretKeyRef. Prosim, uporabite tudi med razvojem, da bodo vaše skrivnosti varne.
Verjetno že imate prednostni sistem za upravljanje skrivnosti Kubernetes. Če ne, je tu nekaj možnosti: šifriranje s KMS vašega ponudnika oblaka in nato vstavljanje v K8S kot skrivnosti prek cevovoda CD − - bo zelo dobro deloval v kombinaciji s skrivnostmi Kustomize. Obstajajo druga orodja, kot je dotGPG, ki izvajajo podobne funkcije: , .
Vstop
Razen če se odločite za posredovanje lokalnih vrat, boste potrebovali konfiguriran vhodni krmilnik. Če ne uporabljate (), potem verjetno že veste, da morate namestiti potrebne opombe ingress-patch.yaml.tmpl ali platform/ingress.yaml. Če uporabljate ingress-nginx in vidite vstopni razred nginx z izravnalnikom obremenitve, ki kaže nanj, in zunanji DNS ali vnos DNS z nadomestnimi znaki, ste pripravljeni. V nasprotnem primeru konfigurirajte vstopni krmilnik in DNS ali preskočite te korake in ohranite neposredno povezavo s podom.
TLS
Če uporabljate ali kube-lego in letsencrypt - potrdila za novo prijavo bodo pridobljena samodejno. Sicer pa odprto ingress-patch.yaml.tmpl in ga prilagodite svojim potrebam.
Kosilo!
Če ste upoštevali vse zgoraj napisano, potem ukaz make skaffold HOSTNAME=<you.example.com> bi moral zagnati razpoložljivo instanco v <hostname>/camunda
Če za prijavo niste nastavili javnega URL-ja, ga lahko preusmerite z localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 o localhost:8080/camunda
Počakajte nekaj minut, dokler tomcat ni popolnoma pripravljen. Upravitelj potrdil si bo vzel nekaj časa, da preveri ime domene. Nato lahko spremljate dnevnike z razpoložljivimi orodji, kot je orodje, kot je kubetail, ali preprosto z uporabo kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Naslednji koraki
Dovoljenje
To je bolj pomembno za konfiguracijo Camunda BPM kot Kubernetes, vendar je pomembno upoštevati, da je privzeto onemogočeno preverjanje pristnosti v API-ju REST. Ti lahko ali uporabite drugo metodo, npr . Za nalaganje xml lahko uporabite konfiguracijske zemljevide in nosilce ali xmlstarlet (glejte zgoraj) za urejanje obstoječih datotek na sliki in uporabite wget ali pa jih naložite z init vsebnikom in skupnim nosilcem.
Upravljanje sej
Tako kot mnoge druge aplikacije tudi Camunda BPM obravnava seje v JVM, tako da, če želite izvajati več replik, lahko omogočite lepljive seje (), ki bo obstajal, dokler replika ne izgine, ali nastavite atribut Max-Age za piškotke. Za bolj robustno rešitev lahko namestite upravitelja sej v Tomcat. Lars ima na to temo, ampak nekaj takega:
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
Obvestilo: namesto sed lahko uporabite xmlstarlet
Smo uporabili pred Google Cloud Memorystore, z (podpira Redis), da ga zaženete.
Skaliranje
Če že razumete seje, potem je lahko prva (in pogosto zadnja) omejitev za skaliranje Camunda BPM povezava z bazo podatkov. Delna prilagoditev je že na voljo "" Onemogočimo tudi intialSize v datoteki settings.xml. Dodaj in preprosto lahko samodejno povečate število strokov.
Zahteve in omejitve
В platform/deployment.yaml Videli boste, da smo polje virov trdo kodirali. To dobro deluje s HPA, vendar bo morda zahtevala dodatno konfiguracijo. Za to je primeren obliž kustomize. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
Izhod
Tako smo na Kubernetes namestili Camunda BPM z metriko Prometheus, dnevniki, bazo podatkov H2, TLS in Ingress. Dodali smo datoteke jar in konfiguracijske datoteke z uporabo ConfigMaps in Dockerfile. Govorili smo o izmenjavi podatkov v količine in neposredno v spremenljivke okolja iz skrivnosti. Poleg tega smo zagotovili pregled nastavitve Camunde za več replik in overjen API.
reference
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, prevod Alastair Firth, Lars Lange
Vir: www.habr.com