Stai utilizzando Kubernetes? Pronto a spostare le tue istanze Camunda BPM fuori dalle macchine virtuali o magari provare semplicemente a eseguirle su Kubernetes? Diamo un'occhiata ad alcune configurazioni comuni e ai singoli elementi che possono essere adattati alle vostre esigenze specifiche.
Si presuppone che tu abbia già utilizzato Kubernetes. In caso contrario, perché non dare un'occhiata e non avviare il tuo primo cluster?
Autori
- (Alastair Firth) - Ingegnere senior dell'affidabilità del sito nel team Camunda Cloud;
- (Lars Lange) - Ingegnere DevOps presso Camunda.
In breve, quindi:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Ok, probabilmente non ha funzionato perché non hai installato skaffold e kustomize. Bene, 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 collega utenti aziendali e sviluppatori di software. È ideale per coordinare e connettere persone, (micro)servizi o addirittura bot! Puoi leggere ulteriori informazioni sui diversi casi d'uso su .
Perché utilizzare Kubernetes
Kubernetes è diventato di fatto lo standard per l'esecuzione di applicazioni moderne su Linux. Utilizzando le chiamate di sistema invece dell'emulazione hardware e la capacità del kernel di gestire la memoria e il cambio di attività, i tempi di avvio e di avvio vengono ridotti al minimo. Tuttavia, il vantaggio maggiore potrebbe derivare dall'API standard fornita da Kubernetes per configurare l'infrastruttura richiesta da tutte le applicazioni: archiviazione, rete e monitoraggio. Ha compiuto 2020 anni a giugno 6 ed è forse il secondo progetto open source più grande (dopo Linux). Recentemente ha stabilizzato attivamente le sue funzionalità dopo una rapida iterazione negli ultimi anni poiché è diventato fondamentale per i carichi di lavoro di produzione in tutto il mondo.
Camunda BPM Engine può connettersi facilmente ad altre applicazioni in esecuzione sullo stesso cluster e Kubernetes offre un'eccellente scalabilità, consentendoti di aumentare i costi dell'infrastruttura solo quando realmente necessario (e di ridurli facilmente quando necessario).
Anche la qualità del monitoraggio è notevolmente migliorata con strumenti come Prometheus, Grafana, Loki, Fluentd ed Elasticsearch, che consentono di visualizzare centralmente tutti i carichi di lavoro in un cluster. Oggi vedremo come implementare l'esportatore Prometheus nella Java Virtual Machine (JVM).
Obiettivi
Diamo un'occhiata ad alcune aree in cui possiamo personalizzare l'immagine Docker Camunda BPM () in modo che interagisca bene con Kubernetes.
- Log e metriche;
- Connessioni al database;
- Autenticazione;
- Gestione della sessione.
Esamineremo diversi modi per raggiungere questi obiettivi e mostreremo chiaramente l'intero processo.
Nota: Stai utilizzando la versione Enterprise? Aspetto e aggiornare i collegamenti alle immagini secondo necessità.
Sviluppo del flusso di lavoro
In questa demo utilizzeremo Skaffold per creare immagini Docker utilizzando Google Cloud Build. Ha un buon supporto per vari strumenti (come Kustomize e Helm), strumenti di CI e creazione e fornitori di infrastrutture. File skaffold.yaml.tmpl include le impostazioni per Google Cloud Build e GKE, fornendo un modo molto semplice per eseguire l'infrastruttura di livello produttivo.
make skaffold caricherà il contesto Dockerfile in Cloud Build, creerà l'immagine e la memorizzerà in GCR, quindi applicherà i manifest al tuo cluster. Questo è ciò che fa make skaffold, ma Skaffold ha molte altre caratteristiche.
Per i modelli yaml in Kubernetes, utilizziamo kustomize per gestire gli overlay yaml senza eseguire il fork dell'intero manifest, consentendoti di utilizzare git pull --rebase per ulteriori miglioramenti. Ora è in kubectl e funziona abbastanza bene per queste cose.
Utilizziamo anche envsubst per popolare il nome host e l'ID progetto GCP nei file *.yaml.tmpl. Puoi vedere come funziona makefile o semplicemente continuare oltre.
Prerequisiti
- Gruppo di lavoro
- - per creare le tue immagini docker e semplificarne la distribuzione su GKE
- Copia di questo codice
- Sost
Flusso di lavoro utilizzando i manifest
Se non desideri utilizzare kustomize o skaffold, puoi fare riferimento ai manifest in generated-manifest.yaml e adattarli al flusso di lavoro di tua scelta.
Log e metriche
Prometheus è diventato lo standard per la raccolta dei parametri in Kubernetes. Occupa 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. Affideremo la visualizzazione a Grafana: viene fornito con un gran numero di dashboard disponibili immediatamente. Sono collegati tra loro e sono relativamente facili da installare .
Per impostazione predefinita, Prometheus utilizza il modello di estrazione <service>/metricse l'aggiunta di contenitori sidecar per questo è comune. Sfortunatamente, le metriche JMX vengono registrate meglio all'interno della JVM, quindi i contenitori sidecar non sono altrettanto efficienti. Connettiamoci open source da Prometheus alla JVM aggiungendolo all'immagine del contenitore che fornirà il percorso /metrics su un porto diverso.
Aggiungi Prometheus jmx_exporter 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
Beh, è stato facile. L'esportatore monitorerà Tomcat e visualizzerà le sue metriche in formato Prometheus su <svc>:9404/metrics
Configurazione dell'esportatore
Il lettore attento potrebbe chiedersi da dove provenga prometheus-jmx.yaml? Esistono molte cose diverse che possono essere eseguite nella JVM e Tomcat è solo una di queste, quindi l'esportatore necessita di alcune configurazioni aggiuntive. Sono disponibili configurazioni standard per Tomcat, Wildfly, Kafka e così via . Aggiungeremo Tomcat come in Kubernetes e quindi montarlo come volume.
Per prima cosa aggiungiamo il file di configurazione dell'esportatore alla nostra directory platform/config/
platform/config
└── prometheus-jmx.yaml
Poi aggiungiamo в kustomization.yaml.tmpl:
-- platform/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 ottimi perché eseguono l'hashing dei dati di configurazione e forzano il riavvio del pod se cambia. Riducono inoltre la quantità di configurazione nella distribuzione poiché è possibile montare un'intera "cartella" di file di configurazione in un VolumeMount.
Infine, dobbiamo montare ConfigMap come volume sul 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
[...]
Meraviglioso. Se Prometheus non è configurato per eseguire una pulizia completa, potrebbe essere necessario dirgli di pulire i pod. Gli utenti di Prometheus Operator possono utilizzare service-monitor.yaml per iniziare. Esplorare Service-monitor.yaml, и prima che inizi.
Estendere questo modello ad altri casi d'uso
Tutti i file che aggiungiamo a ConfigMapGenerator saranno disponibili nella nuova directory /etc/config. Puoi estendere 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 singoli file. Per aggiornare i file xml, considera l'utilizzo invece di sed. È già incluso nell'immagine.
riviste
Grandi notizie! I log dell'applicazione sono già disponibili su stdout, ad esempio con kubectl logs. Fluentd (installato per impostazione predefinita in GKE) inoltrerà i tuoi log a Elasticsearch, Loki o alla tua piattaforma di registrazione aziendale. Se desideri utilizzare jsonify per i log, puoi seguire il modello sopra per l'installazione .
База данных
Per impostazione predefinita, l'immagine avrà un database H2. Questo non è adatto a noi e utilizzeremo Google Cloud SQL con Cloud SQL Proxy: questo sarà necessario in seguito per risolvere i problemi interni. Questa è un'opzione semplice e affidabile se non hai le tue preferenze nella configurazione del database. AWS RDS fornisce un servizio simile.
Indipendentemente dal database scelto, a meno che non sia H2, dovrai impostare le variabili di ambiente appropriate platform/deploy.yaml. Sembra qualcosa del genere:
-- 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: puoi utilizzare Kustomize per eseguire la distribuzione in ambienti diversi utilizzando un overlay: .
Nota: utilizzo valueFrom: secretKeyRef. Si prega di utilizzare anche durante lo sviluppo per mantenere i tuoi segreti al sicuro.
È probabile che tu abbia già un sistema preferito per la gestione dei segreti Kubernetes. In caso contrario, ecco alcune opzioni: crittografarli con il KMS del tuo provider cloud e quindi inserirli in K8S come segreti tramite la pipeline CD - - funzionerà molto bene in combinazione con i segreti di Kustomize. Esistono altri strumenti, come dotGPG, che svolgono funzioni simili: , .
Ingresso
A meno che tu non scelga di utilizzare il port forwarding locale, avrai bisogno di un controller di ingresso configurato. Se non usi () allora molto 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 di ingresso nginx con un bilanciatore del carico che punta ad essa e una voce DNS esterna o DNS con caratteri jolly, sei a posto. Altrimenti, configura il controller di ingresso e il DNS oppure salta questi passaggi e mantieni la connessione diretta al pod.
TLS
Se stai usando oppure kube-lego e letsencrypt: i certificati per il nuovo accesso verranno ottenuti automaticamente. Altrimenti apri ingress-patch.yaml.tmpl e personalizzalo in base alle tue esigenze.
Lancio!
Se hai seguito tutto quanto scritto sopra, allora il comando make skaffold HOSTNAME=<you.example.com> dovrebbe avviare un'istanza disponibile in <hostname>/camunda
Se non hai impostato il tuo accesso su un URL pubblico, puoi reindirizzarlo con localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 su localhost:8080/camunda
Attendi qualche minuto finché Tomcat non sarà completamente pronto. Cert-manager impiegherà del tempo per verificare il nome di dominio. Puoi quindi monitorare i log utilizzando gli strumenti disponibili come uno strumento come kubetail o semplicemente utilizzando kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Prossimi passi
Autorizzazione
Ciò è più rilevante per la configurazione di Camunda BPM che per Kubernetes, ma è importante notare che per impostazione predefinita l'autenticazione è disabilitata nell'API REST. Puoi o utilizzare un altro metodo come . Puoi utilizzare mappe di configurazione e volumi per caricare xml o xmlstarlet (vedi sopra) per modificare i file esistenti nell'immagine e utilizzare wget o caricarli utilizzando un contenitore init e un volume condiviso.
Gestione della sessione
Come molte altre applicazioni, Camunda BPM gestisce le sessioni nella JVM, quindi se desideri eseguire più repliche, puoi abilitare sessioni permanenti (), che esisterà fino alla scomparsa della replica o imposterà l'attributo Max-Age per i cookie. Per una soluzione più solida, puoi distribuire Session Manager in Tomcat. Lars sì su questo argomento, ma qualcosa del tipo:
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: puoi usare xmlstarlet invece di sed
Abbiamo usato davanti a Google Cloud Memorystore, con (supporta Redis) per eseguirlo.
scalata
Se conosci già le sessioni, la prima (e spesso l'ultima) limitazione alla scalabilità di Camunda BPM potrebbe essere la connessione al database. La personalizzazione parziale è già disponibile"" Disabilitiamo anche intialSize nel file settings.xml. Aggiungere e puoi facilmente ridimensionare automaticamente il numero di pod.
Richieste e restrizioni
В platform/deployment.yaml Vedrai che abbiamo codificato il campo delle risorse. Funziona bene con HPA, ma potrebbe richiedere una configurazione aggiuntiva. La patch Kustomize è adatta a questo. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
conclusione
Quindi abbiamo installato Camunda BPM su Kubernetes con metriche, log, database H2, TLS e Ingress di Prometheus. Abbiamo aggiunto file jar e file di configurazione utilizzando ConfigMaps e Dockerfile. Abbiamo parlato dello scambio di dati con volumi e direttamente con variabili di ambiente dai segreti. Inoltre, abbiamo fornito una panoramica sulla configurazione di Camunda per più repliche e un'API autenticata.
riferimenti
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/XNUMX/XNUMX, traduzione Alastair Firth, Lars Lange
Fonte: habr.com