🥇Esecuzione di Camunda BPM su Kubernetes

Utilizzi Kubernetes? Sei pronto a spostare le tue istanze di Camunda BPM da macchine virtuali, o magari a provare a eseguirle su Kubernetes? Esaminiamo alcune configurazioni comuni e singoli elementi che possono essere adattati alle tue esigenze specifiche.

Si presume che tu abbia già utilizzato Kubernetes in precedenza. Se non è così, perché non dare un'occhiata a guida e avviare il tuo primo cluster?

Autori

Alastair Firth (Alastair Firth) è un ingegnere senior di affidabilità del sito (Site Reliability Engineer) nel team di Camunda Cloud;
Lars Lange (Lars Lange) è 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

Bene, probabilmente non ha funzionato, visto che 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 l'automazione delle decisioni, che unisce gli utenti aziendali e gli sviluppatori di software. È perfetta per coordinare e unire persone, (micro) servizi o addirittura bot! Puoi leggere di più sui vari casi d'uso su link.

Perché usare Kubernetes

Kubernetes è diventato lo standard de facto per l'esecuzione di applicazioni moderne in Linux. Grazie all'uso delle chiamate di sistema invece della simulazione dell'hardware e alle capacità del kernel di gestire la memoria e il commutare i compiti, i tempi di caricamento e di avvio sono ridotti al minimo. Tuttavia, il maggiore vantaggio può derivare dall'API standard che Kubernetes fornisce per configurare l'infrastruttura necessaria per tutte le applicazioni: archiviazione, rete e monitoraggio. Nel giugno 2020 ha compiuto 6 anni ed è probabilmente il secondo progetto open source più grande (dopo Linux). Recentemente ha stabilizzato attivamente le sue funzionalità dopo una rapida iterazione negli ultimi anni, poiché questo diventa critico per i carichi di lavoro di produzione in tutto il mondo.

Il motore Camunda BPM può facilmente connettersi ad altre applicazioni che operano nello stesso cluster, mentre Kubernetes garantisce un'ottima scalabilità, permettendo di aumentare i costi dell'infrastruttura solo quando è veramente necessario (e di ridurli facilmente quando non lo è).

La qualità del monitoraggio migliora significativamente grazie a strumenti come Prometheus, Grafana, Loki, Fluentd ed Elasticsearch, che consentono di visualizzare in modo centralizzato tutti i carichi di lavoro del cluster. Oggi esamineremo come implementare l'esportatore Prometheus su una macchina virtuale Java (JVM).

Obiettivi

Esaminiamo alcune aree in cui possiamo configurare l'immagine Docker di Camunda BPM (github), affinché interagisca bene con Kubernetes.

Log e metriche;
Connessioni al database;
Autenticazione;
Gestione delle sessioni.

Esamineremo diversi modi per raggiungere questi obiettivi e mostreremo chiaramente l'intero processo.

Nota: Utilizzi la versione Enterprise? Controlli qui e aggiorni i collegamenti alle immagini se necessario.

Sviluppo del workflow

In questa dimostrazione utilizzeremo Skaffold per costruire immagini Docker utilizzando Google Cloud Build. Ha un buon supporto per vari strumenti (come Kustomize e Helm), CI e strumenti di build, oltre ai fornitori di infrastruttura. Il file skaffold.yaml.tmpl include le impostazioni per Google Cloud Build e GKE, offrendo un modo molto semplice per avviare un'infrastruttura di livello industriale.

make skaffold caricherà il contesto del Dockerfile in Cloud Build, creerà l'immagine e la salverà in GCR, quindi applicherà i manifesti al tuo cluster. Questo è ciò che fa make skaffold, ma Skaffold ha molte altre funzionalità.

Per i template yaml in Kubernetes usiamo kustomize per gestire le sovrapposizioni yaml senza ramificare l'intero manifesto, permettendoti di usare git pull --rebase per ulteriori miglioramenti. Ora è in kubectl e funziona piuttosto bene per queste cose.

Usiamo anche envsubst per riempire il nome host e l'identificativo del progetto GCP nei file * .yaml.tmpl. Puoi vedere come funziona in makefile o semplicemente continuare oltre.

Requisiti

Cluster operativo Kubernetes
Kustomize
Skaffold — per creare le proprie immagini docker e distribuire facilmente in GKE
Una copia di questo codice
Envsubst

Workflow tramite manifesti

Se non vuoi usare 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 uno standard per la raccolta di metriche in Kubernetes. Occupa lo stesso spazio di mercato di AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics e altri. Ha un codice sorgente aperto e un linguaggio di query potente. La visualizzazione è affidata a Grafana, che viene fornito con un gran numero di pannelli di monitoraggio disponibili out-of-the-box. Sono interconnessi tra loro e relativamente facili da installare con prometheus-operator.

Per impostazione predefinita, Prometheus utilizza un modello di estrazione /metrics, e aggiungere contenitori sidecar per questo è prassi comune. Sfortunatamente, le metriche JMX si registrano meglio all'interno della JVM, quindi i contenitori sidecar non sono così efficaci. Connettiamo jmx_exporter con codice sorgente aperto da Prometheus alla JVM, aggiungendolo all'immagine del contenitore, che fornirà un percorso /metrics su una porta diversa.

Aggiungi il Prometheus jmx_exporter al contenitore

-- immagini/camunda-bpm/Dockerfile DA 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

Beh, è stato facile. L'esportatore monitorerà tomcat e mostrerà le sue metriche nel formato Prometheus all'indirizzo :9404/metrics

Configurazione dell'esportatore

Il lettore attento potrebbe chiedersi da dove provenga prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны qui. Aggiungeremo tomcat come ConfigMap in Kubernetes e poi lo monteremo come volume.

Per prima cosa, aggiungiamo il file di configurazione dell'esportatore nella nostra directory platform/config/

piattaforma/config └── prometheus-jmx.yaml

Poi aggiungiamo ConfigMapGenerator in kustomization.yaml.tmpl:

-- piattaforma/kustomization.yaml.tmpl apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization [...] configMapGenerator: - name: config files: - config/prometheus-jmx.yaml

Questo aggiungerà ogni elemento files[] come elemento di configurazione ConfigMap. I ConfigMapGenerator sono utili in quanto eseguono l'hashing dei dati nella configurazione e innescano il riavvio del pod se vengono modificati. Riduce anche l'ingombro della 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 mountsVolume: - mountPath: /etc/config/ nome: config [...]

Ottimo. Se Prometheus non è configurato per una pulizia completa, potrebbe essere necessario dirgli di pulire i pod. Gli utenti del Prometheus Operator possono utilizzare service-monitor.yaml per iniziare. Esamina Service-monitor.yaml, operatore design e ServiceMonitorSpec prima di procedere.

Diffondere questo modello in 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 utilizzare subPath per montare file singoli. Per aggiornare file xml, considera di utilizzare xmlstarlet invece di sed. È già incluso nell'immagine.

Log

Ottime notizie! I log delle applicazioni sono già disponibili su stdout, ad esempio usando kubectl logs. Fluentd (installato di default in GKE) reindirizzerà i tuoi log in Elasticsearch, Loki o sulla tua piattaforma di logging aziendale. Se desideri utilizzare jsonify per i log, puoi seguire il modello sopra per l'installazione logback.

Qui la scelta è stata molto più semplice, Simple SCADA offre due prodotti da utilizzare: MS SQL Server e MySQL. Il secondo mi è sembrato più vicino, poiché avevo già lavorato con esso, quindi mi sono fermato lì.

Per impostazione predefinita, l'immagine avrà un database H2. Questo non ci soddisfa, e utilizzeremo Google Cloud SQL con Cloud SQL Proxy — questo sarà necessario in seguito per gestire compiti interni. È una soluzione semplice e affidabile se non hai preferenze specifiche nella configurazione del database. AWS RDS offre un servizio simile.

Indipendentemente dal database scelto, a meno che non sia H2, dovrai impostare le relative variabili d'ambiente in platform/deploy.yaml. Si presenta più o meno così:

-- piattaforma/deployment.yaml apiVersion: apps/v1 tipo: Deployment [...] spec: template: spec: [...] contenitori: - nome: camunda-bpm env: - nome: DB_DRIVER valore: org.postgresql.Driver - nome: DB_URL valore: jdbc:postgresql://postgres-proxy.db:5432/process-engine - nome: DB_USERNAME valoreDa: riferimentoChiaveSegreta: nome: cambpm-db-credentials chiave: db_username - nome: DB_PASSWORD valoreDa: riferimentoChiaveSegreta: nome: cambpm-db-credentials chiave: db_password [...]

Nota: Puoi utilizzare Kustomize per il deployment in vari ambienti con overlay: un esempio.

Nota: uso valueFrom: secretKeyRef. Ti preghiamo di usare questa funzione di Kubernetes anche durante lo sviluppo, per mantenere i tuoi segreti al sicuro.

È probabile che tu abbia già un sistema di gestione dei segreti Kubernetes preferito. Se no, ecco alcune opzioni: criptarli con KMS del tuo fornitore di cloud e poi iniettarli in K8S come segreti tramite il pipeline CD — MozillaSOPS funzionerà molto bene con i segreti di Kustomize. Ci sono anche altri strumenti, come dotGPG — svolgono funzioni simili: HashiCorp Vault, Kustomize Secret Value Plugins.

Ingress

A meno che tu non decida di utilizzare il port forwarding locale, avrai bisogno di un Ingress Controller configurato. Se non usi ingress-nginx (Helm chart) allora probabilmente sai già che devi installare le annotazioni necessarie in ingress-patch.yaml.tmpl o platform/ingress.yaml. Se stai utilizzando ingress-nginx e vedi una classe nginx ingress con un bilanciatore di carico che punta ad esso e un DNS esterno o un record DNS di sostituzione, tutto è pronto. In caso contrario, configura l'Ingress Controller e il DNS, oppure salta questi passaggi e mantieni una connessione diretta al pod.

TLS

Se stai usando cert-manager o kube-lego e letsencrypt, i certificati per il nuovo ingresso saranno ottenuti automaticamente. In caso contrario, apri ingress-patch.yaml.tmpl e configurarlo secondo le tue esigenze.

Avvio!

Se hai seguito quanto descritto sopra, il comando make skaffold HOSTNAME= dovrebbe avviare un'istanza accessibile in /camunda

Se non hai esposto l'ingresso tramite un URL pubblico, puoi inoltrarlo da localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 in localhost:8080/camunda

Aspetta qualche minuto affinché tomcat sia completamente pronto. Il 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, come 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

Passaggi successivi

Autenticazione

Questo si riferisce più alla configurazione di Camunda BPM che a Kubernetes, ma è importante notare che per impostazione predefinita l'autenticazione API REST è disabilitata. Puoi abilitare l'autenticazione di base o utilizzare un altro metodo, come ad esempio JWT. Puoi utilizzare configmaps e volumi per caricare xml, oppure xmlstarlet (vedi sopra) per modificare file esistenti nell'immagine, e inoltre puoi usare wget oppure 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 desideri avviare più repliche, puoi abilitare le sticky sessions (ad esempio, per ingress-nginx), che esisteranno finché la replica non scomparirà, oppure impostare l'attributo Max-Age per i cookie. Come soluzione più consistente, puoi implementare un Session Manager in Tomcat. Lars ha un post separato su questo argomento, ma qualcosa di simile a:

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 twemproxy prima di Google Cloud Memorystore, con memcached-session-manager (supporta Redis) per eseguirlo.

Scalabilità

Se hai già compreso le sessioni, la prima (e spesso ultima) limitazione per scalare Camunda BPM può essere la connessione al database. Una configurazione parziale è già disponibile "fuori dalla scatola". Disattiviamo anche intialSize nel file settings.xml. Aggiungi HorizontalPodAutoscaler (HPA) 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. Questo funziona bene con HPA, ma potrebbe essere necessaria una configurazione aggiuntiva. Un patch kustomize sarà utile. Vedi. ingress-patch.yaml.tmpl e ./kustomization.yaml.tmpl

Conclusione

Ecco che abbiamo installato Camunda BPM su Kubernetes con metriche Prometheus, registri, database H2, TLS e Ingress. Abbiamo aggiunto file jar e file di configurazione utilizzando ConfigMaps e Dockerfile. Abbiamo discusso lo scambio di dati con i volumi e direttamente nelle variabili d'ambiente dai segreti. Inoltre, abbiamo fornito una panoramica della configurazione di Camunda per più repliche e API autenticate.

Link

github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes │ ├── generated-manifest.yaml < - manifesto per uso 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 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 per prometheus-operator │ └── service.yaml └── skaffold.yaml.tmpl < - direttive skaffold