Estàs utilitzant Kubernetes? Esteu preparat per moure les vostres instàncies BPM de Camunda fora de les màquines virtuals, o potser només proveu d'executar-les a Kubernetes? Vegem algunes configuracions habituals i elements individuals que es poden adaptar a les vostres necessitats específiques.
Se suposa que heu utilitzat Kubernetes abans. Si no, per què no fer-hi una ullada i no inicieu el vostre primer clúster?
Autors
- (Alastair Firth) - Enginyer sènior de fiabilitat del lloc a l'equip de Camunda Cloud;
- (Lars Lange) - Enginyer DevOps a Camunda.
En resum:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
D'acord, probablement no va funcionar perquè no teniu instal·lats skaffold i kustomize. Bé, doncs segueix llegint!
Què és Camunda BPM
Camunda BPM és una plataforma d'automatització de decisions i gestió de processos empresarials de codi obert que connecta usuaris empresarials i desenvolupadors de programari. És ideal per coordinar i connectar persones, (micro) serveis o fins i tot bots! Podeu llegir més sobre els diferents casos d'ús a .
Per què utilitzar Kubernetes
Kubernetes s'ha convertit en l'estàndard de facto per executar aplicacions modernes a Linux. Mitjançant l'ús de trucades al sistema en lloc de l'emulació de maquinari i la capacitat del nucli per gestionar la memòria i el canvi de tasques, el temps d'arrencada i el temps d'inici es redueixen al mínim. Tanmateix, el major benefici pot provenir de l'API estàndard que proporciona Kubernetes per configurar la infraestructura requerida per totes les aplicacions: emmagatzematge, xarxes i monitorització. Va complir 2020 anys el juny de 6 i és potser el segon projecte de codi obert més gran (després de Linux). Recentment, ha estat estabilitzant activament la seva funcionalitat després d'una ràpida iteració durant els últims anys, ja que esdevé fonamental per a les càrregues de treball de producció a tot el món.
Camunda BPM Engine es pot connectar fàcilment a altres aplicacions que s'executen al mateix clúster, i Kubernetes ofereix una escalabilitat excel·lent, que us permet augmentar els costos d'infraestructura només quan realment ho necessiteu (i reduir-los fàcilment segons sigui necessari).
La qualitat de la supervisió també es millora molt amb eines com Prometheus, Grafana, Loki, Fluentd i Elasticsearch, que us permeten visualitzar de manera centralitzada totes les càrregues de treball d'un clúster. Avui veurem com implementar l'exportador Prometheus a la màquina virtual Java (JVM).
Objectius
Vegem algunes àrees on podem personalitzar la imatge Docker de Camunda BPM () perquè interactuï bé amb Kubernetes.
- Registres i mètriques;
- Connexions de bases de dades;
- Autenticació;
- Gestió de sessions.
Veurem diverses maneres d'aconseguir aquests objectius i mostrarem clarament tot el procés.
Nota: feu servir la versió Enterprise? Mira i actualitzeu els enllaços d'imatges segons sigui necessari.
Desenvolupament del flux de treball
En aquesta demostració, utilitzarem Skaffold per crear imatges de Docker amb Google Cloud Build. Té un bon suport per a diverses eines (com ara Kustomize i Helm), eines de CI i compilació i proveïdors d'infraestructura. Dossier skaffold.yaml.tmpl inclou la configuració per a Google Cloud Build i GKE, que ofereix una manera molt senzilla d'executar una infraestructura de producció.
make skaffold carregarà el context Dockerfile a Cloud Build, crearà la imatge i l'emmagatzemarà a GCR i, a continuació, aplicarà els manifests al vostre clúster. Això és el que fa make skaffold, però Skaffold té moltes altres característiques.
Per a les plantilles de yaml a Kubernetes, fem servir kustomize per gestionar les superposicions de yaml sense bifurcar tot el manifest, cosa que us permet utilitzar git pull --rebase per a més millores. Ara està a kubectl i funciona bastant bé per a aquestes coses.
També fem servir envsubst per emplenar el nom d'amfitrió i l'identificador del projecte GCP als fitxers *.yaml.tmpl. Podeu veure com funciona makefile o simplement continuar més enllà.
Requisits previs
- Clúster de treball
- - per crear les vostres pròpies imatges de Docker i desplegar-les fàcilment a GKE
- Còpia d'aquest codi
- Envsubst
Flux de treball mitjançant manifests
Si no voleu utilitzar kustomize o skaffold, podeu consultar els manifestos a generated-manifest.yaml i adaptar-los al flux de treball que escolliu.
Registres i mètriques
Prometheus s'ha convertit en l'estàndard per recopilar mètriques a Kubernetes. Ocupa el mateix nínxol que AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics i altres. És de codi obert i té un llenguatge de consulta potent. Confiarem la visualització a Grafana: inclou un gran nombre de taulers de comandament disponibles de manera immediata. Estan connectats entre si i són relativament fàcils d'instal·lar .
Per defecte, Prometheus utilitza el model d'extracció <service>/metrics, i afegir contenidors sidecar per a això és habitual. Malauradament, les mètriques JMX es registren millor a la JVM, de manera que els contenidors sidecar no són tan eficients. Connectem-nos codi obert de Prometheus a la JVM afegint-lo a la imatge del contenidor que proporcionarà el camí /metrics en un port diferent.
Afegiu Prometheus jmx_exporter al contenidor
-- 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
Bé, això va ser fàcil. L'exportador supervisarà Tomcat i mostrarà les seves mètriques en format Prometheus a <svc>:9404/metrics
Configuració de l'exportador
El lector atent es preguntarà d'on prové prometheus-jmx.yaml? Hi ha moltes coses diferents que es poden executar a la JVM, i tomcat és només una d'elles, de manera que l'exportador necessita una configuració addicional. Hi ha disponibles configuracions estàndard per a tomcat, wildfly, kafka, etc . Afegirem tomcat com a Kubernetes i després muntar-lo com a volum.
Primer, afegim el fitxer de configuració de l'exportador al nostre directori platform/config/
platform/config
└── prometheus-jmx.yaml
Després afegim в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Això afegirà cada element files[] com a element de configuració de ConfigMap. Els ConfigMapGenerators són excel·lents perquè fan un hash de les dades de configuració i obliguen a reiniciar el pod si canvia. També redueixen la quantitat de configuració a Deployment, ja que podeu muntar una "carpeta" sencera de fitxers de configuració en un volum VolumeMount.
Finalment, hem de muntar el ConfigMap com a volum al 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
[...]
Meravellós. Si Prometheus no està configurat per fer una neteja completa, potser haureu de dir-li que netegi les beines. Els usuaris de Prometheus Operator poden utilitzar service-monitor.yaml per començar. Explora Service-monitor.yaml, и abans de començar.
Estenent aquest patró a altres casos d'ús
Tots els fitxers que afegim a ConfigMapGenerator estaran disponibles al nou directori /etc/config. Podeu ampliar aquesta plantilla per muntar qualsevol altre fitxer de configuració que necessiteu. Fins i tot podeu muntar un nou script d'inici. Pots fer servir per muntar fitxers individuals. Per actualitzar fitxers xml, considereu l'ús en lloc de sed. Ja està inclòs a la imatge.
Revistes
Una gran notícia! Els registres d'aplicacions ja estan disponibles a stdout, per exemple amb kubectl logs. Fluentd (instal·lat per defecte a GKE) reenviarà els vostres registres a Elasticsearch, Loki o la vostra plataforma de registre empresarial. Si voleu utilitzar jsonify per als registres, podeu seguir la plantilla anterior per instal·lar-la .
Base de dades
Per defecte, la imatge tindrà una base de dades H2. Això no és adequat per a nosaltres i utilitzarem Google Cloud SQL amb Cloud SQL Proxy; això serà necessari més endavant per resoldre problemes interns. Aquesta és una opció senzilla i fiable si no teniu les vostres preferències per configurar la base de dades. AWS RDS ofereix un servei similar.
Independentment de la base de dades que trieu, tret que sigui H2, haureu d'establir les variables d'entorn adequades a platform/deploy.yaml. Sembla una cosa així:
-- 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: podeu utilitzar Kustomize per implementar-lo en diferents entorns mitjançant una superposició: .
Nota: ús valueFrom: secretKeyRef. Si us plau, utilitza fins i tot durant el desenvolupament per protegir els vostres secrets.
És probable que ja tingueu un sistema preferit per gestionar els secrets de Kubernetes. Si no, aquí hi ha algunes opcions: xifrar-los amb el KMS del vostre proveïdor de núvol i després injectar-los al K8S com a secrets mitjançant el pipeline de CD − - funcionarà molt bé en combinació amb Kustomize secrets. Hi ha altres eines, com ara dotGPG, que fan funcions similars: , .
Ingrés
A menys que trieu utilitzar el reenviament de ports locals, necessitareu un controlador d'entrada configurat. Si no feu servir () llavors probablement ja sabeu que heu d'instal·lar les anotacions necessàries ingress-patch.yaml.tmpl o platform/ingress.yaml. Si utilitzeu ingress-nginx i veieu una classe d'entrada nginx amb un equilibrador de càrrega que hi apunta i una entrada DNS externa o DNS comodí, ja esteu a punt. En cas contrari, configureu el controlador d'entrada i el DNS, o ometeu aquests passos i mantingueu la connexió directa al pod.
TLS
Si utilitzeu o kube-lego i letsencrypt: els certificats per al nou inici de sessió s'obtindran automàticament. En cas contrari, obert ingress-patch.yaml.tmpl i personalitzeu-lo segons les vostres necessitats.
Llançament!
Si heu seguit tot el que s'ha escrit anteriorment, aleshores l'ordre make skaffold HOSTNAME=<you.example.com> hauria de llançar una instància disponible a <hostname>/camunda
Si no heu establert el vostre inici de sessió a un URL públic, podeu redirigir-lo amb localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 en localhost:8080/camunda
Espereu uns minuts fins que el tomcat estigui completament a punt. Cert-Manager trigarà un temps a verificar el nom de domini. A continuació, podeu supervisar els registres mitjançant eines disponibles, com ara kubetail, o simplement utilitzant kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Següents passos
Autorització
Això és més rellevant per configurar Camunda BPM que Kubernetes, però és important tenir en compte que, per defecte, l'autenticació està desactivada a l'API REST. Tu pots o utilitzar un altre mètode com . Podeu utilitzar configuracions i volums per carregar xml, o xmlstarlet (vegeu més amunt) per editar fitxers existents a la imatge, i utilitzar wget o carregar-los amb un contenidor d'inici i un volum compartit.
Gestió de sessions
Com moltes altres aplicacions, Camunda BPM gestiona sessions a la JVM, de manera que si voleu executar diverses rèpliques, podeu habilitar sessions enganxades (), que existirà fins que la rèplica desaparegui, o estableixi l'atribut Max-Age per a les galetes. Per obtenir una solució més robusta, podeu implementar Session Manager a Tomcat. Lars ho té sobre aquest tema, però alguna cosa com:
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: podeu utilitzar xmlstarlet en comptes de sed
Hem utilitzat davant de Google Cloud Memorystore, amb (admet Redis) per executar-lo.
Escalat
Si ja enteneu les sessions, la primera (i sovint l'última) limitació per escalar Camunda BPM pot ser la connexió a la base de dades. La personalització parcial ja està disponible "" També desactivem intialSize al fitxer settings.xml. Afegeix i podeu escalar fàcilment automàticament el nombre de beines.
Peticions i restriccions
В platform/deployment.yaml Veureu que hem codificat el camp de recursos. Això funciona bé amb HPA, però pot requerir una configuració addicional. El pegat kustomize és adequat per a això. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
Sortida
Així que vam instal·lar Camunda BPM a Kubernetes amb mètriques, registres, base de dades H2, TLS i Ingress de Prometheus. Hem afegit fitxers jar i fitxers de configuració mitjançant ConfigMaps i Dockerfile. Hem parlat de l'intercanvi de dades a volums i directament a variables d'entorn des de secrets. A més, vam oferir una visió general de la configuració de Camunda per a diverses rèpliques i una API autenticada.
Referències
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, traducció Alastair Firth, Lars Lange
Font: www.habr.com