Käytätkö Kubernetesia? Oletko valmis siirtämään Camunda BPM -esiintymäsi pois virtuaalikoneen tai ehkä vain kokeilemaan niiden suorittamista Kubernetesissa? Katsotaanpa joitain yleisiä kokoonpanoja ja yksittäisiä kohteita, jotka voidaan räätälöidä sinun tarpeidesi mukaan.
Se olettaa, että olet käyttänyt Kubernetesia aiemmin. Jos ei, miksi et katsoisi etkä aloita ensimmäistä klusteriasi?
Tekijät
- (Alastair Firth) - vanhempi työmaan luotettavuusinsinööri Camunda Cloud -tiimissä;
- (Lars Lange) - Camundan DevOps-insinööri.
Lyhyesti sanottuna:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Okei, se ei luultavasti toiminut, koska sinulla ei ole skaffoldia ja kustomizea asennettuna. No lue sitten!
Mikä on Camunda BPM
Camunda BPM on avoimen lähdekoodin liiketoimintaprosessien hallinta- ja päätösautomaatioalusta, joka yhdistää yrityskäyttäjät ja ohjelmistokehittäjät. Se on ihanteellinen ihmisten, (mikro)palvelujen tai jopa robottien koordinointiin ja yhdistämiseen! Voit lukea lisää eri käyttötapauksista osoitteessa .
Miksi käyttää Kubernetesia
Kubernetesista on tullut de facto standardi nykyaikaisten sovellusten käyttämiselle Linuxissa. Käyttämällä järjestelmäkutsuja laitteistoemuloinnin sijaan ja ytimen kykyä hallita muistia ja tehtävien vaihtoa, käynnistysaika ja käynnistysaika pidetään minimissä. Suurin hyöty voi kuitenkin tulla Kubernetesin tarjoamasta vakiosovellusliittymästä kaikkien sovellusten edellyttämän infrastruktuurin määrittämiseen: tallennus, verkko ja valvonta. Se täytti 2020 vuotta kesäkuussa 6 ja on ehkä toiseksi suurin avoimen lähdekoodin projekti (Linuxin jälkeen). Se on viime aikoina aktiivisesti vakauttanut toiminnallisuuttaan viime vuosien nopean iteroinnin jälkeen, kun siitä tulee kriittistä tuotantotyökuormitukselle ympäri maailmaa.
Camunda BPM Engine voi helposti muodostaa yhteyden muihin samassa klusterissa toimiviin sovelluksiin, ja Kubernetes tarjoaa erinomaisen skaalautuvuuden, jolloin voit lisätä infrastruktuurikustannuksia vain silloin, kun sitä todella tarvitaan (ja vähentää niitä helposti tarpeen mukaan).
Seurannan laatua parannetaan myös huomattavasti työkaluilla, kuten Prometheus, Grafana, Loki, Fluentd ja Elasticsearch, jolloin voit tarkastella kaikkia työkuormia keskitetysti klusterissa. Tänään tarkastellaan, kuinka Prometheus-vienti voidaan ottaa käyttöön Java Virtual Machine (JVM) -koneeseen.
tavoitteet
Katsotaanpa muutamia alueita, joilla voimme mukauttaa Camunda BPM Docker -kuvaa (), jotta se toimii hyvin vuorovaikutuksessa Kubernetesin kanssa.
- Lokit ja mittarit;
- Tietokantayhteydet;
- Todennus;
- Istunnon hallinta.
Tarkastelemme useita tapoja saavuttaa nämä tavoitteet ja näytämme selkeästi koko prosessin.
Huomata: Käytätkö Enterprise-versiota? Katso ja päivitä kuvalinkkejä tarpeen mukaan.
Työnkulun kehittäminen
Tässä esittelyssä käytämme Skaffoldia Docker-kuvien rakentamiseen Google Cloud Buildin avulla. Siinä on hyvä tuki erilaisille työkaluille (kuten Kustomize ja Helm), CI- ja build-työkaluille sekä infrastruktuurin tarjoajille. Tiedosto skaffold.yaml.tmpl sisältää asetukset Google Cloud Buildille ja GKE:lle, mikä tarjoaa erittäin yksinkertaisen tavan käyttää tuotantotason infrastruktuuria.
make skaffold lataa Dockerfile-kontekstin Cloud Buildiin, rakentaa kuvan ja tallentaa sen GCR:ään ja käyttää sitten luetteloita klusteriisi. Tämä on mitä se tekee make skaffold, mutta Skaffoldissa on monia muita ominaisuuksia.
Kubernetesin yaml-malleissa käytämme kustomizea yaml-peittokuvien hallintaan ilman koko luetteloa haaroittamatta, jolloin voit käyttää git pull --rebase lisäparannuksia varten. Nyt se on kubectlissä ja toimii melko hyvin sellaisiin asioihin.
Käytämme envsubst-komentoa myös isäntänimen ja GCP-projektin tunnuksen lisäämiseen *.yaml.tmpl-tiedostoihin. Voit nähdä kuinka se toimii makefile tai jatka vain eteenpäin.
edellytykset
- Työklusteri
- - omien telakointikuvien luomiseen ja helppokäyttöisyyteen GKE:hen
- Kopio tästä koodista
- Envsubst
Työnkulku luetteloiden avulla
Jos et halua käyttää kustomizea tai skaffoldia, voit viitata manifesteihin generated-manifest.yaml ja mukauta ne valitsemaasi työnkulkuun.
Lokit ja mittarit
Prometheuksesta on tullut standardi mittareiden keräämiseen Kubernetesissa. Sillä on sama markkinarako kuin AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics ja muut. Se on avoimen lähdekoodin ja siinä on tehokas kyselykieli. Annamme visualisoinnin Grafanalle – sen mukana tulee suuri määrä kojelaudat, joita on saatavana heti valmiina. Ne on kytketty toisiinsa ja niiden kanssa on suhteellisen helppo asentaa .
Oletuksena Prometheus käyttää poimintamallia <service>/metrics, ja sivuvaunukonttien lisääminen tätä varten on yleistä. Valitettavasti JMX-mittarit kirjataan parhaiten JVM:ssä, joten sivuvaunujen säiliöt eivät ole yhtä tehokkaita. Otetaan yhteyttä avoimen lähdekoodin Prometheuksesta JVM:ään lisäämällä se säiliökuvaan, joka tarjoaa polun /metrics eri satamassa.
Lisää Prometheus jmx_exporter säiliöön
-- 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 se oli helppoa. Viejä seuraa tomcatia ja näyttää sen mittareita Prometheus-muodossa osoitteessa <svc>:9404/metrics
Viejän asetukset
Huomaavainen lukija saattaa ihmetellä, mistä se on peräisin prometheus-jmx.yaml? JVM:ssä voi toimia monia eri asioita, ja tomcat on vain yksi niistä, joten viejä tarvitsee lisämäärityksiä. Saatavilla on vakiokokoonpanot tomcat-, wildfly-, kafka- ja niin edelleen . Lisäämme tomcatin nimellä Kubernetesissa ja asenna se sitten taltioksi.
Ensin lisäämme viejän määritystiedoston alusta/config/-hakemistoomme
platform/config
└── prometheus-jmx.yaml
Sitten lisäämme в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Tämä lisää jokaisen elementin files[] ConfigMap-määrityselementtinä. ConfigMapGenerators ovat mahtavia, koska ne tiivistävät määritystiedot ja pakottavat podin uudelleenkäynnistyksen, jos ne muuttuvat. Ne myös vähentävät määritysten määrää Deploymentissa, koska voit liittää kokonaisen "kansion" määritystiedostoja yhteen VolumeMountiin.
Lopuksi meidän on liitettävä ConfigMap-taltio podiin:
-- 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
[...]
Ihana. Jos Prometheusta ei ole määritetty suorittamaan täydellistä puhdistusta, saatat joutua kehottamaan sitä puhdistamaan kotelot. Prometheus Operatorin käyttäjät voivat käyttää service-monitor.yaml aloittaaksesi. Tutkia Service-monitor.yaml, и ennen kuin aloitat.
Tämän mallin laajentaminen muihin käyttötapauksiin
Kaikki ConfigMapGeneratoriin lisäämämme tiedostot ovat saatavilla uudessa hakemistossa /etc/config. Voit laajentaa tätä mallia asentaaksesi kaikki muut tarvitsemasi määritystiedostot. Voit jopa asentaa uuden käynnistysohjelman. Voit käyttää yksittäisten tiedostojen liittämiseen. Voit päivittää xml-tiedostoja harkitsemalla sed:n sijaan. Se on jo mukana kuvassa.
Lehdet
Hyviä uutisia! Sovelluslokit ovat jo saatavilla stdoutissa, esimerkiksi kubectl logs. Fluentd (asennettu oletuksena GKE:hen) välittää lokisi Elasticsearchille, Lokille tai yrityksesi lokialustaan. Jos haluat käyttää jsonifyta lokeille, voit asentaa yllä olevan mallin .
tietokanta
Oletusarvoisesti kuvassa on H2-tietokanta. Tämä ei sovellu meille, ja käytämme Google Cloud SQL:ää Cloud SQL Proxyn kanssa - tätä tarvitaan myöhemmin sisäisten ongelmien ratkaisemiseen. Tämä on yksinkertainen ja luotettava vaihtoehto, jos sinulla ei ole omia mieltymyksiäsi tietokannan perustamisessa. AWS RDS tarjoaa samanlaisen palvelun.
Riippumatta valitsemastasi tietokannasta, ellei se ole H2, sinun on asetettava asianmukaiset ympäristömuuttujat platform/deploy.yaml. Se näyttää jotakuinkin tältä:
-- 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
[...]
Huomata: Voit käyttää Kustomizea ottaaksesi käyttöön eri ympäristöissä peittokuvan avulla: .
Huomata: käyttö valueFrom: secretKeyRef. Käytä, kiitos jopa kehityksen aikana pitääksesi salaisuutesi turvassa.
On todennäköistä, että sinulla on jo ensisijainen järjestelmä Kubernetes-salaisuuksien hallintaan. Jos ei, tässä on joitain vaihtoehtoja: Salaa ne pilvipalveluntarjoajan KMS:llä ja lisää ne sitten K8S:ään salaisuuksina CD-putken kautta − - toimii erittäin hyvin yhdessä Kustomizen salaisuuksien kanssa. On muita työkaluja, kuten dotGPG, jotka suorittavat samanlaisia toimintoja: , .
Sisääntulo
Jos et valitse paikallista portin edelleenohjausta, tarvitset konfiguroidun sisääntuloohjaimen. Jos et käytä (), tiedät todennäköisesti jo, että sinun on asennettava tarvittavat merkinnät ingress-patch.yaml.tmpl tai platform/ingress.yaml. Jos käytät ingress-nginxiä ja näet nginx-sisääntuloluokan, johon on osoittanut kuormituksen tasapainottaja ja ulkoinen DNS- tai jokerimerkki-DNS-merkintä, olet valmis. Muussa tapauksessa määritä Ingress Controller ja DNS tai ohita nämä vaiheet ja säilytä suora yhteys podiin.
TLS
Jos käytät tai kube-lego ja letsencrypt - uuden kirjautumisen varmenteet hankitaan automaattisesti. Muuten auki ingress-patch.yaml.tmpl ja mukauta se tarpeidesi mukaan.
Tuoda markkinoille!
Jos noudatit kaikkea yllä kirjoitettua, niin komento make skaffold HOSTNAME=<you.example.com> pitäisi käynnistää käytettävissä oleva esiintymä <hostname>/camunda
Jos et ole määrittänyt kirjautumistunnukseksi julkista URL-osoitetta, voit ohjata sen uudelleen localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 päälle localhost:8080/camunda
Odota muutama minuutti, kunnes tomcat on täysin valmis. Cert-manager kestää jonkin aikaa varmistaakseen verkkotunnuksen. Voit sitten valvoa lokeja käyttämällä käytettävissä olevia työkaluja, kuten työkalua, kuten kubetail, tai yksinkertaisesti käyttämällä kubectl-komentoa:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
РЎР »РµРґСѓСЋС ‰ РёРµ С € Р ° РіРё
Lupa
Tämä on merkityksellisempää Camunda BPM:n määrittämisessä kuin Kubernetes, mutta on tärkeää huomata, että oletusarvoisesti todennus on poistettu käytöstä REST API:ssa. Sinä pystyt tai käytä jotain muuta menetelmää, kuten . Voit käyttää configmapsia ja taltioita ladataksesi xml:n tai xmlstarletilla (katso yllä) muokataksesi olemassa olevia tiedostoja kuvassa ja joko käyttää wgetiä tai ladata ne käyttämällä init-säilöä ja jaettua taltiota.
Istunnon hallinta
Kuten monet muutkin sovellukset, Camunda BPM käsittelee istuntoja JVM:ssä, joten jos haluat suorittaa useita replikoita, voit ottaa käyttöön tarttuvat istunnot (), joka on olemassa, kunnes replika katoaa, tai aseta evästeille Max-Age-attribuutti. Saat tehokkaamman ratkaisun ottamalla käyttöön Session Managerin Tomcatissa. Larsilla on tästä aiheesta, mutta jotain tällaista:
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
Huomata: voit käyttää xmlstarletiä sed:n sijaan
Me käytimme Google Cloud Memorystoren edessä (tukee Redistä) suorittaaksesi sen.
Skaalaus
Jos ymmärrät jo istunnot, ensimmäinen (ja usein viimeinen) Camunda BPM:n skaalauksen rajoitus voi olla yhteys tietokantaan. Osittainen räätälöinti on jo saatavilla"" Poistetaan myös intialSize asetus.xml-tiedostosta. Lisätä ja voit helposti skaalata palojen lukumäärää automaattisesti.
Pyynnöt ja rajoitukset
В platform/deployment.yaml Näet, että olemme koodannut resurssikentän. Tämä toimii hyvin HPA:n kanssa, mutta saattaa vaatia lisämäärityksiä. Kustomize patch sopii tähän. cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
johtopäätös
Joten asensimme Camunda BPM:n Kubernetesiin Prometheus-mittareiden, lokien, H2-tietokannan, TLS:n ja Ingressin avulla. Lisäsimme jar- ja määritystiedostot ConfigMaps- ja Dockerfile-työkaluilla. Puhuimme tietojen vaihtamisesta volyymeihin ja suoraan ympäristömuuttujiin salaisuuksista. Lisäksi annoimme yleiskatsauksen Camundan määrittämisestä useille replikoille ja todennettuun sovellusliittymään.
viittaukset
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, käännös Alastair Firth, Lars Lange
Lähde: will.com