Folosești Kubernetes? Sunteți gata să mutați instanțele dvs. Camunda BPM din mașinile virtuale sau poate încercați pur și simplu să le rulați pe Kubernetes? Să ne uităm la câteva configurații comune și elemente individuale care pot fi adaptate nevoilor dumneavoastră specifice.
Se presupune că ați folosit Kubernetes înainte. Dacă nu, de ce să nu aruncați o privire la și nu porniți primul dvs. cluster?
Autori
- (Alastair Firth) - Senior Site Reliability Engineer în echipa Camunda Cloud;
- (Lars Lange) - inginer DevOps la Camunda.
Pe scurt, atunci:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Bine, probabil că nu a funcționat pentru că nu ai instalat scaffold și kustomize. Ei bine, atunci citește mai departe!
Ce este Camunda BPM
Camunda BPM este o platformă open source de gestionare a proceselor de afaceri și de automatizare a deciziilor care conectează utilizatorii de afaceri și dezvoltatorii de software. Este ideal pentru coordonarea și conectarea persoanelor, (micro)servicii sau chiar a botilor! Puteți citi mai multe despre diferitele cazuri de utilizare la .
De ce să folosiți Kubernetes
Kubernetes a devenit standardul de facto pentru rularea aplicațiilor moderne pe Linux. Prin utilizarea apelurilor de sistem în locul emulării hardware și a capacității nucleului de a gestiona memoria și comutarea sarcinilor, timpul de pornire și timpul de pornire sunt reduse la minimum. Cu toate acestea, cel mai mare beneficiu poate veni din API-ul standard pe care Kubernetes îl oferă pentru a configura infrastructura necesară tuturor aplicațiilor: stocare, rețea și monitorizare. A împlinit 2020 ani în iunie 6 și este poate al doilea cel mai mare proiect open source (după Linux). Recent și-a stabilizat în mod activ funcționalitatea după o repetare rapidă în ultimii câțiva ani, deoarece devine critică pentru sarcinile de producție din întreaga lume.
Camunda BPM Engine se poate conecta cu ușurință la alte aplicații care rulează pe același cluster, iar Kubernetes oferă o scalabilitate excelentă, permițându-vă să creșteți costurile de infrastructură doar atunci când este cu adevărat necesar (și să le reduceți cu ușurință după cum este necesar).
Calitatea monitorizării este, de asemenea, îmbunătățită considerabil cu instrumente precum Prometheus, Grafana, Loki, Fluentd și Elasticsearch, permițându-vă să vizualizați central toate sarcinile de lucru dintr-un cluster. Astăzi vom analiza cum să implementăm exportatorul Prometheus în Java Virtual Machine (JVM).
goluri
Să ne uităm la câteva zone în care putem personaliza imaginea Camunda BPM Docker () astfel încât să interacționeze bine cu Kubernetes.
- Jurnalele și valorile;
- Conexiuni la baze de date;
- Autentificare;
- Managementul sesiunii.
Vom analiza mai multe moduri de a atinge aceste obiective și vom arăta în mod clar întregul proces.
Nota: Folosiți versiunea Enterprise? Uite și actualizați linkurile de imagini după cum este necesar.
Dezvoltarea fluxului de lucru
În această demonstrație, vom folosi Skaffold pentru a construi imagini Docker folosind Google Cloud Build. Are suport bun pentru diverse instrumente (cum ar fi Kustomize și Helm), instrumente CI și build și furnizori de infrastructură. Fişier skaffold.yaml.tmpl include setări pentru Google Cloud Build și GKE, oferind o modalitate foarte simplă de a rula infrastructura de nivel de producție.
make skaffold va încărca contextul Dockerfile în Cloud Build, va construi imaginea și o va stoca în GCR, apoi va aplica manifestele clusterului dvs. Aceasta este ceea ce face make skaffold, dar Skaffold are multe alte caracteristici.
Pentru șabloanele yaml din Kubernetes, folosim kustomize pentru a gestiona suprapunerile yaml fără a bifurca întregul manifest, permițându-vă să utilizați git pull --rebase pentru îmbunătățiri ulterioare. Acum este în kubectl și funcționează destul de bine pentru astfel de lucruri.
De asemenea, folosim envsubst pentru a completa numele de gazdă și ID-ul proiectului GCP în fișierele *.yaml.tmpl. Puteți vedea cum funcționează makefile sau pur și simplu continuați mai departe.
Cerințe preliminare
- Cluster de lucru
- - pentru crearea propriilor imagini Docker și implementarea ușoară în GKE
- Copie a acestui cod
- Envsubst
Flux de lucru folosind manifeste
Dacă nu doriți să utilizați kustomize sau scaffold, vă puteți referi la manifestele din generated-manifest.yaml și adaptați-le la fluxul de lucru pe care îl alegeți.
Jurnalele și valorile
Prometheus a devenit standardul pentru colectarea de valori în Kubernetes. Ocupă aceeași nișă ca și AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics și altele. Este open source și are un limbaj de interogare puternic. Vom încredința vizualizarea lui Grafana - vine cu un număr mare de tablouri de bord disponibile imediat. Sunt conectate între ele și sunt relativ ușor de instalat .
În mod implicit, Prometheus folosește modelul de extracție <service>/metrics, iar adăugarea de containere sidecar pentru aceasta este obișnuită. Din păcate, valorile JMX sunt cel mai bine înregistrate în JVM, astfel încât containerele sidecar nu sunt la fel de eficiente. Să ne conectăm sursă deschisă de la Prometheus la JVM prin adăugarea acesteia la imaginea containerului care va furniza calea /metrics pe alt port.
Adăugați Prometheus jmx_exporter în container
-- 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
Ei bine, a fost ușor. Exportatorul va monitoriza tomcat și își va afișa valorile în format Prometheus la <svc>:9404/metrics
Configurarea exportatorului
Cititorul atent se poate întreba de unde provine prometheus-jmx.yaml? Există multe lucruri diferite care pot rula în JVM, iar tomcat este doar unul dintre ele, așa că exportatorul are nevoie de o configurație suplimentară. Sunt disponibile configurații standard pentru tomcat, wildfly, kafka și așa mai departe . Vom adăuga tomcat ca în Kubernetes și apoi montați-l ca volum.
Mai întâi, adăugăm fișierul de configurare a exportatorului în directorul nostru platform/config/
platform/config
└── prometheus-jmx.yaml
Apoi adaugam в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Acest lucru va adăuga fiecare element files[] ca element de configurare ConfigMap. ConfigMapGenerators sunt grozavi pentru că trimit datele de configurare și forțează repornirea podului dacă se modifică. De asemenea, reduc cantitatea de configurare în Deployment, deoarece puteți monta un întreg „dosar” de fișiere de configurare într-un singur VolumeMount.
În cele din urmă, trebuie să instalăm ConfigMap ca volum pe 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
[...]
Minunat. Dacă Prometheus nu este configurat să facă o curățare completă, poate fi necesar să îi spuneți să curețe podurile. Utilizatorii Prometheus Operator pot folosi service-monitor.yaml pentru a incepe. Explora Service-monitor.yaml, и inainte sa incepi.
Extinderea acestui model la alte cazuri de utilizare
Toate fișierele pe care le adăugăm la ConfigMapGenerator vor fi disponibile în noul director /etc/config. Puteți extinde acest șablon pentru a monta orice alte fișiere de configurare de care aveți nevoie. Puteți chiar să montați un nou script de pornire. Poți să folosești pentru a monta fișiere individuale. Pentru a actualiza fișierele xml, luați în considerare utilizarea în loc de sed. Este deja inclusă în imagine.
Reviste
Vesti bune! Jurnalele de aplicații sunt deja disponibile pe stdout, de exemplu cu kubectl logs. Fluentd (instalat implicit în GKE) vă va redirecționa jurnalele către Elasticsearch, Loki sau platforma dvs. de înregistrare a întreprinderii. Dacă doriți să utilizați jsonify pentru jurnal, puteți urma șablonul de mai sus pentru a instala .
bază de date
În mod implicit, imaginea va avea o bază de date H2. Acest lucru nu este potrivit pentru noi și vom folosi Google Cloud SQL cu Cloud SQL Proxy - acesta va fi necesar mai târziu pentru a rezolva problemele interne. Aceasta este o opțiune simplă și de încredere dacă nu aveți propriile preferințe în configurarea bazei de date. AWS RDS oferă un serviciu similar.
Indiferent de baza de date pe care o alegeți, cu excepția cazului în care este H2, va trebui să setați variabilele de mediu corespunzătoare în platform/deploy.yaml. Arata cam asa:
-- 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
[...]
Nota: Puteți folosi Kustomize pentru a implementa în diferite medii folosind o suprapunere: .
Nota: utilizare valueFrom: secretKeyRef. Te rog, folosește chiar și în timpul dezvoltării pentru a vă păstra secretele în siguranță.
Este probabil să aveți deja un sistem preferat pentru gestionarea secretelor Kubernetes. Dacă nu, iată câteva opțiuni: criptați-le cu KMS-ul furnizorului dvs. de cloud și apoi injectați-le în K8S ca secrete prin conducta CD-ului − - va funcționa foarte bine în combinație cu Kustomize secrets. Există și alte instrumente, cum ar fi dotGPG, care îndeplinesc funcții similare: , .
Pătrundere
Dacă nu alegeți să utilizați redirecționarea portului local, veți avea nevoie de un controler de intrare configurat. Daca nu folosesti () atunci cel mai probabil știți deja că trebuie să instalați adnotările necesare în ingress-patch.yaml.tmpl sau platform/ingress.yaml. Dacă utilizați ingress-nginx și vedeți o clasă de intrare nginx cu un echilibrator de încărcare care indică spre ea și o intrare DNS externă sau DNS wildcard, sunteți gata. În caz contrar, configurați controlerul de intrare și DNS sau omiteți acești pași și păstrați conexiunea directă la pod.
TLS
Dacă utilizați sau kube-lego și letsencrypt - certificatele pentru noua autentificare vor fi obținute automat. Altfel, deschide ingress-patch.yaml.tmpl și personalizați-l în funcție de nevoile dvs.
Lansa!
Dacă ai urmat tot ce este scris mai sus, atunci comanda make skaffold HOSTNAME=<you.example.com> ar trebui să lanseze o instanță disponibilă în <hostname>/camunda
Dacă nu v-ați setat autentificarea la o adresă URL publică, o puteți redirecționa cu localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 pe localhost:8080/camunda
Așteptați câteva minute până când pisica este complet gata. Cert-manager va dura ceva timp pentru a verifica numele domeniului. Apoi puteți monitoriza jurnalele folosind instrumente disponibile, cum ar fi un instrument precum kubetail sau pur și simplu folosind kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Pașii următori
autorizare
Acest lucru este mai relevant pentru configurarea Camunda BPM decât Kubernetes, dar este important de reținut că în mod implicit, autentificarea este dezactivată în API-ul REST. Puteți sau folosiți o altă metodă, cum ar fi . Puteți folosi configmaps și volume pentru a încărca xml sau xmlstarlet (vezi mai sus) pentru a edita fișierele existente în imagine și fie să utilizați wget, fie să le încărcați folosind un container de inițializare și un volum partajat.
Managementul sesiunii
Ca multe alte aplicații, Camunda BPM gestionează sesiunile în JVM, așa că dacă doriți să rulați mai multe replici, puteți activa sesiunile sticky (), care va exista până când replica dispare sau setează atributul Max-Age pentru cookie-uri. Pentru o soluție mai robustă, puteți implementa Session Manager în Tomcat. Lars are pe acest subiect, dar ceva de genul:
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
Nota: puteți folosi xmlstarlet în loc de sed
Noi am folosit în fața Google Cloud Memorystore, cu (suportă Redis) să-l ruleze.
Scalare
Dacă înțelegeți deja sesiunile, atunci prima (și adesea ultima) limitare pentru scalarea Camunda BPM poate fi conexiunea la baza de date. Personalizarea parțială este deja disponibilă "" Să dezactivăm și intialSize în fișierul settings.xml. Adăuga și puteți scala cu ușurință automat numărul de poduri.
Cereri și restricții
В platform/deployment.yaml Veți vedea că am codificat câmpul de resurse. Acest lucru funcționează bine cu HPA, dar poate necesita o configurare suplimentară. Plasturele kustomize este potrivit pentru asta. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
Producție
Așa că am instalat Camunda BPM pe Kubernetes cu valorile Prometheus, jurnalele, baza de date H2, TLS și Ingress. Am adăugat fișiere jar și fișiere de configurare folosind ConfigMaps și Dockerfile. Am vorbit despre schimbul de date la volume și direct la variabilele de mediu din secrete. În plus, am oferit o imagine de ansamblu despre configurarea Camunda pentru mai multe replici și un API autentificat.
referințe
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, traducere Alastair Firth, Lars Lange
Sursa: www.habr.com