Stai usando Kubernetes? Sei pronto a spostare le tue istanze di Camunda BPM dalle macchine virtuali, o magari vuoi semplicemente provare a eseguirle su Kubernetes? Esaminiamo alcune configurazioni comuni e singoli elementi che puoi adattare alle tue esigenze specifiche.
Si presuppone che tu abbia già utilizzato Kubernetes in passato. In caso contrario, perché non dare un'occhiata a e avviare il tuo primo cluster?
Autori
- è un ingegnere senior per l'affidabilità del sito (Site Reliability Engineer) nel team di Camunda Cloud;
- è un ingegnere DevOps in Camunda.
In breve:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Va bene, probabilmente non ha funzionato perché non hai installato skaffold e kustomize. Allora continua a leggere!
Cos'è Camunda BPM
Camunda BPM è una piattaforma open source per la gestione dei processi aziendali e per l'automazione delle decisioni, che connette utenti aziendali e sviluppatori software. È perfetta per coordinare e integrare persone, servizi (micro) o anche bot! Puoi leggere di più sulle varie applicazioni visitando .
Perché usare Kubernetes
Kubernetes è diventato lo standard de facto per eseguire applicazioni moderne su Linux. Grazie all'uso delle chiamate di sistema invece dell'emulazione a livello hardware e alle capacità del kernel di gestire la memoria e il switching dei task, i tempi di avvio e i tempi di esecuzione sono ridotti al minimo. Tuttavia, il principale vantaggio può derivare dall'API standard che Kubernetes fornisce per configurare l'infrastruttura necessaria per tutte le applicazioni: archiviazione, rete e monitoraggio. A giugno 2020 ha compiuto 6 anni ed è, probabilmente, il secondo progetto open source più grande (dopo Linux). Negli ultimi tempi ha stabilizzato attivamente le proprie funzionalità dopo una rapida iterazione degli ultimi anni, poiché questo diventa critico per i carichi produttivi in tutto il mondo.
Il motore Camunda BPM può facilmente connettersi ad altre applicazioni in esecuzione nello stesso cluster, e Kubernetes fornisce una scalabilità eccellente, permettendo di incrementare i costi dell'infrastruttura solo quando è realmente necessario (e di ridurli facilmente se necessario).
La qualità del monitoraggio migliora notevolmente con strumenti come Prometheus, Grafana, Loki, Fluentd ed Elasticsearch, che consentono di visualizzare centralmente tutti i carichi di lavoro del cluster. Oggi vedremo come implementare un esportatore Prometheus su una macchina virtuale Java (JVM).
Obiettivi
Esaminiamo alcune aree in cui possiamo configurare l'immagine Docker di Camunda BPM (), affinché funzioni bene con Kubernetes.
- Log e metriche;
- Connessioni al database;
- Autenticazione;
- Gestione delle sessioni.
Esamineremo alcuni modi per realizzare questi obiettivi e illustreremo l'intero processo.
Nota: Stai utilizzando la versione Enterprise? Controlla e aggiorna i collegamenti alle immagini se necessario.
Sviluppo del flusso di lavoro
In questa dimostrazione utilizzeremo Skaffold per creare immagini Docker usando Google Cloud Build. Ha un buon supporto per vari strumenti (come Kustomize e Helm), CI e strumenti di compilazione, così come fornitori di infrastruttura. Il file skaffold.yaml.tmpl include impostazioni per Google Cloud Build e GKE, fornendo un modo molto semplice per avviare infrastrutture di livello enterprise.
make skaffold caricherà il contesto del Dockerfile in Cloud Build, creerà l'immagine e la salverà in GCR, per poi applicare i manifesti al tuo cluster. Questo è ciò che fa make skaffold, ma Skaffold offre molte altre funzionalità.
Per i modelli yaml in Kubernetes utilizziamo kustomize per gestire gli overlay yaml senza ramificare l'intero manifesto, permettendoti di usare git pull --rebase per miglioramenti ulteriori. Ora è in kubectl e funziona abbastanza bene per tali attività.
Utilizziamo anche envsubst per riempire il nome host e l'ID del progetto GCP nei file * .yaml.tmpl. Puoi vedere come funziona in makefile o semplicemente continuare.
Requisiti
- Cluster funzionante
- per creare immagini docker personalizzate e un semplice deployment in GKE
- Una copia di questo codice
- Envsubst
Flusso di lavoro con manifesti
Se non vuoi utilizzare kustomize o skaffold, puoi fare riferimento ai manifesti in generated-manifest.yaml e adattarli al flusso di lavoro di tua scelta.
Log e metriche
Prometheus è diventato lo standard per la raccolta delle metriche in Kubernetes. Occupando la stessa nicchia di AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics e altri. È open source e dispone di un potente linguaggio di query. La visualizzazione sarà gestita da Grafana, che offre un ampio numero di dashboard pronte all'uso. Queste sono collegate tra loro e relativamente facili da installare. .
Per impostazione predefinita, Prometheus utilizza un modello di estrazione /metrics, e l'aggiunta di contenitori sidecar per questo è pratica comune. Sfortunatamente, le metriche JMX sono meglio registrate all'interno della JVM, quindi i contenitori sidecar non sono così efficaci. Colleghiamo l'exporter open source di Prometheus alla JVM, aggiungendolo all'immagine del contenitore, che fornirà un percorso /metrics su un'altra porta.
Aggiungi il jmx_exporter di Prometheus al contenitore
-- 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
Bene, è stato facile. L'exporter monitorerà tomcat e mostrerà le sue metriche in formato Prometheus all'indirizzo :9404/metrics
Configurazione dell'exporter
Il lettore attento potrebbe chiedersi da dove provenga prometheus-jmx.yaml.? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны Aggiungeremo tomcat come in Kubernetes e poi lo monteremo come volume.
Per prima cosa, aggiungiamo il file di configurazione dell'exporter nella nostra directory platform/config/
piattaforma/config
└── prometheus-jmx.yaml
Poi aggiungiamo in kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
file:
- config/prometheus-jmx.yaml
Questo aggiungerà ogni elemento files[] come elemento di configurazione ConfigMap. I ConfigMapGenerator sono utili poiché hashano i dati nella configurazione e innescano il riavvio del pod se viene modificato. Inoltre, riducono la quantità di configurazione nel Deployment, poiché puoi montare l'intera "cartella" di file di configurazione in un'unica VolumeMount.
Infine, dobbiamo montare il ConfigMap come volume nel pod:
-- piattaforma/deployment.yaml
apiVersion: apps/v1
tipo: Deployment
[...]
spec:
template:
spec:
[...]
volumi:
- name: config
configMap:
nome: config
modalitàPredefinita: 0744
contenitori:
- nome: camunda-bpm
montaggiVolume:
- percorsoDiMontaggio: /etc/config/
nome: config
[...]
Ottimo. Se Prometheus non è configurato per una pulizia completa, potrebbe essere necessario dirgli di pulire i pod. Gli utenti di Prometheus Operator possono utilizzare service-monitor.yaml per iniziare. Esplora Service-monitor.yaml, e prima di procedere.
L'estensione di questo modello ad altri casi d'uso
Tutti i file che aggiungiamo al ConfigMapGenerator saranno disponibili nella nuova directory /etc/config. Puoi espandere questo modello per montare qualsiasi altro file di configurazione di cui hai bisogno. Puoi anche montare un nuovo script di avvio. Puoi usare per montare file singoli. Per l'aggiornamento dei file xml, considera di utilizzare invece di sed. È già incluso nell'immagine.
Log
Ottime notizie! I log delle applicazioni sono già disponibili su stdout, ad esempio, tramite kubectl logs. Fluentd (incluso per impostazione predefinita in GKE) reindirizzerà i tuoi log in Elasticsearch, Loki o sulla tua piattaforma di logging aziendale. Se desideri usare jsonify per i log, puoi seguire il modello sopra per installare .
Database
Per impostazione predefinita, l'immagine avrà un database H2. Questo non va bene per noi e utilizzeremo Google Cloud SQL con Cloud SQL Proxy — questo sarà necessario in seguito per affrontare le attività interne. È un'opzione semplice e sicura, se non hai preferenze proprie per la configurazione del database. AWS RDS offre un servizio simile.
Indipendentemente dal database scelto, a meno che non sia H2, dovrai impostare le variabili ambientali appropriate in platform/deploy.yaml.Questo appare circa così:
-- piattaforma/deployment.yaml
apiVersion: apps/v1
tipo: Deployment
[...]
spec:
template:
spec:
[...]
contenitori:
- nome: 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: Puoi utilizzare Kustomize per il deployment in ambienti diversi usando un overlay: .
Nota: utilizzo valueFrom: secretKeyRef. Ti prego di usare anche durante lo sviluppo, per mantenere al sicuro i tuoi segreti.
È probabile che tu abbia già un sistema di gestione dei segreti Kubernetes preferito. Se non ce l'hai, ecco alcune opzioni: criptarli utilizzando la KMS del tuo provider cloud e poi iniettarli in K8S come segreti tramite un pipeline CI/CD — funzionerà molto bene con i segreti di Kustomize. Ci sono altri strumenti come dotGPG — che eseguono funzioni simili: , .
Ingress
A meno che tu non decida di utilizzare il port forwarding locale, avrai bisogno di un Ingress Controller configurato. Se non stai usando () probabilmente già sai che devi impostare le annotazioni necessarie in ingress-patch.yaml.tmpl o platform/ingress.yaml.Se utilizzi ingress-nginx e vedi la classe ingress nginx con un bilanciatore di carico che punta a essa e DNS esterno o record DNS wildcard — sei a posto. Altrimenti, configura l'Ingress Controller e DNS o salta questi passaggi e lascia una connessione diretta al pod.
TLS
Se stai utilizzando o kube-lego e letsencrypt — i certificati per il nuovo accesso verranno ottenuti automaticamente. In caso contrario, apri ingress-patch.yaml.tmpl e configuralo secondo le tue esigenze.
Avvio!
Se hai seguito tutto quanto scritto sopra, il comando make skaffold HOSTNAME= dovrebbe avviare un'istanza accessibile in /camunda
Se non hai esposto l'accesso tramite un URL pubblico, puoi reindirizzarlo con localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 con localhost:8080/camunda
Aspetta qualche minuto affinché tomcat sia completamente pronto. Cert-manager avrà bisogno di un po' di tempo per verificare il nome di dominio. Dopo di che, puoi monitorare i log usando gli strumenti disponibili — ad esempio, uno strumento come kubetail, oppure semplicemente usando kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Prossimi passi
Autenticazione
Questo si riferisce più alla configurazione di Camunda BPM che a Kubernetes, ma è importante notare che per impostazione predefinita, l'autenticazione nell'API REST è disabilitata. Puoi o usare un altro metodo, come . Puoi usare configmaps e volumi per caricare xml, oppure xmlstarlet (vedi sopra) per modificare i file esistenti nell'immagine, e anche usare wget o caricarli tramite un contenitore init e un volume condiviso.
Gestione delle sessioni
Come molte altre applicazioni, Camunda BPM gestisce le sessioni nella JVM, quindi se vuoi avviare più repliche, puoi abilitare le sticky sessions (), che rimarranno fino a quando la replica non scomparirà, oppure impostare l'attributo Max-Age per i cookie. Come soluzione più affidabile, puoi distribuire il Session Manager in Tomcat. Lars ha un articolo su questo argomento, ma qualcosa del genere:
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 '/^/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: puoi usare xmlstarlet invece di sed
Abbiamo usato prima di Google Cloud Memorystore, con (supporta Redis) per gestirlo.
Scalabilità
Se hai già gestito le sessioni, il primo (e spesso ultimo) limite per la scalabilità di Camunda BPM può essere la connessione al database. Una configurazione parziale è già "". Disabilitiamo anche intialSize nel file settings.xml. Aggiungi e potrai facilmente scalare automaticamente il numero di pod.
Richieste e limiti
In platform/deployment.yaml vedrai che abbiamo codificato rigidamente il campo delle risorse. Funziona bene con HPA, ma potrebbe essere necessaria una configurazione aggiuntiva. Un patch di kustomize sarà utile. Vedi. ingress-patch.yaml.tmpl e ./kustomization.yaml.tmpl
Risultato
Ecco, abbiamo installato Camunda BPM su Kubernetes con metriche Prometheus, log, database H2, TLS e Ingress. Abbiamo aggiunto file jar e file di configurazione usando ConfigMaps e Dockerfile. Abbiamo parlato dello scambio di dati con volumi e direttamente nelle variabili d'ambiente dai segreti. Inoltre, abbiamo fornito una panoramica della configurazione di Camunda per più repliche e API autentificate.
Link
github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes
│
├── generated-manifest.yaml <- manifesto da utilizzare senza kustomize
├── immagini
│ └── camunda-bpm
│ └── Dockerfile <- immagine docker di overlay
├── ingress-patch.yaml.tmpl <- configurazione ingress specifica per il sito
├── kustomization.yaml.tmpl <- Kustomization principale
├── Makefile <- obiettivi di make
├── namespace.yaml
├── piattaforma
│ ├── configurazione
│ │ └── prometheus-jmx.yaml <- file di configurazione dell'esportatore prometheus
│ ├── deployment.yaml <- deployment principale
│ ├── ingress.yaml
│ ├── kustomization.yaml <- Kustomization "base"
│ ├── service-monitor.yaml <- configurazione esempio del prometheus-operator
│ └── service.yaml
└── skaffold.yaml.tmpl <- direttive skaffold
08.05.2020, traduzione Alastair Firth, Lars Lange
Fonte: habr.com
