Estás a usar Kubernetes? ¿Estás preparado para sacar as túas instancias de Camunda BPM das máquinas virtuais, ou quizais simplemente intentas executalas en Kubernetes? Vexamos algunhas configuracións comúns e elementos individuais que se poden adaptar ás súas necesidades específicas.
Asume que xa usaches Kubernetes antes. Se non, por que non botarlle unha ollada e non inicias o teu primeiro clúster?
Autores
- (Alastair Firth) - Enxeñeiro sénior de fiabilidade do sitio no equipo de Camunda Cloud;
- (Lars Lange) - Enxeñeiro de DevOps en Camunda.
En resumo:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Está ben, probablemente non funcionou porque non tes skaffold e kustomize instalados. Pois siga lendo!
Que é Camunda BPM
Camunda BPM é unha plataforma de xestión de procesos empresariais e de automatización de decisións de código aberto que conecta usuarios empresariais e desenvolvedores de software. É ideal para coordinar e conectar persoas, (micro) servizos ou incluso bots! Podes ler máis sobre os diferentes casos de uso en .
Por que usar Kubernetes
Kubernetes converteuse no estándar de facto para executar aplicacións modernas en Linux. Ao usar chamadas ao sistema en lugar da emulación de hardware e a capacidade do núcleo para xestionar a memoria e a conmutación de tarefas, o tempo de arranque e o tempo de inicio redúcense ao mínimo. Non obstante, o maior beneficio pode vir da API estándar que proporciona Kubernetes para configurar a infraestrutura requirida por todas as aplicacións: almacenamento, redes e monitorización. Cumpriu 2020 anos en xuño de 6 e quizais sexa o segundo proxecto de código aberto máis grande (despois de Linux). Recentemente estivo a estabilizar activamente a súa funcionalidade despois dunha rápida iteración nos últimos anos, xa que se fai fundamental para as cargas de traballo de produción en todo o mundo.
Camunda BPM Engine pode conectarse facilmente a outras aplicacións que se executan no mesmo clúster e Kubernetes ofrece unha excelente escalabilidade, o que lle permite aumentar os custos de infraestrutura só cando realmente sexa necesario (e reducilos facilmente segundo sexa necesario).
A calidade do seguimento tamén se mellora moito con ferramentas como Prometheus, Grafana, Loki, Fluentd e Elasticsearch, o que lle permite ver de forma centralizada todas as cargas de traballo nun clúster. Hoxe veremos como implementar o exportador Prometheus na máquina virtual Java (JVM).
Obxectivos
Vexamos algunhas áreas onde podemos personalizar a imaxe Docker de Camunda BPM () para que interactúe ben con Kubernetes.
- Rexistros e métricas;
- conexións de bases de datos;
- Autenticación;
- Xestión de sesións.
Observaremos varias formas de acadar estes obxectivos e mostraremos claramente todo o proceso.
Nota: Estás a usar a versión Enterprise? Mirar e actualiza as ligazóns de imaxes segundo sexa necesario.
Desenvolvemento do fluxo de traballo
Nesta demostración, usaremos Skaffold para crear imaxes de Docker usando Google Cloud Build. Ten un bo soporte para varias ferramentas (como Kustomize e Helm), ferramentas de CI e de compilación e provedores de infraestrutura. Arquivo skaffold.yaml.tmpl inclúe configuracións para Google Cloud Build e GKE, que ofrecen un xeito moi sinxelo de executar infraestruturas de produción.
make skaffold cargará o contexto Dockerfile en Cloud Build, creará a imaxe e almacenará en GCR e, a continuación, aplicará os manifestos ao seu clúster. Isto é o que fai make skaffold, pero Skaffold ten moitas outras características.
Para os modelos de yaml en Kubernetes, usamos kustomize para xestionar as superposicións de yaml sen bifurcar todo o manifesto, o que che permite usar git pull --rebase para melloras posteriores. Agora está en kubectl e funciona bastante ben para tales cousas.
Tamén usamos envsubst para encher o nome de host e o ID do proxecto GCP nos ficheiros *.yaml.tmpl. Podes ver como funciona makefile ou simplemente continúa máis.
Requisitos previos
- Clúster de traballo
- - para crear as túas propias imaxes de acoplador e unha fácil implementación en GKE
- Copia deste código
- Envsubst
Fluxo de traballo mediante manifestos
Se non queres usar kustomize ou skaffold, podes consultar os manifestos en generated-manifest.yaml e adáptaos ao fluxo de traballo que elixas.
Rexistros e métricas
Prometheus converteuse no estándar para recoller métricas en Kubernetes. Ocupa o mesmo nicho que AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics e outros. É de código aberto e ten unha potente linguaxe de consulta. Encargarémoslle a visualización a Grafana, que inclúe un gran número de paneis dispoñibles. Están conectados entre si e son relativamente fáciles de instalar .
Por defecto, Prometheus utiliza o modelo de extracción <service>/metrics, e engadir contedores sidecar para iso é habitual. Desafortunadamente, as métricas JMX son mellor rexistradas na JVM, polo que os contedores sidecar non son tan eficientes. Imos conectar código aberto de Prometheus á JVM engadíndoo á imaxe do contenedor que proporcionará o camiño /metrics nun porto diferente.
Engade Prometheus jmx_exporter ao contedor
-- 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
Ben, iso foi doado. O exportador supervisará Tomcat e mostrará as súas métricas en formato Prometheus en <svc>:9404/metrics
Configuración do exportador
O lector atento pode preguntarse de onde veu prometheus-jmx.yaml? Hai moitas cousas diferentes que se poden executar na JVM, e tomcat é só unha delas, polo que o exportador necesita algunha configuración adicional. Están dispoñibles configuracións estándar para tomcat, wildfly, kafka, etc . Engadiremos tomcat como en Kubernetes e, a continuación, montalo como un volume.
En primeiro lugar, engadimos o ficheiro de configuración do exportador ao noso directorio platform/config/
platform/config
└── prometheus-jmx.yaml
Despois engadimos в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Isto engadirá cada elemento files[] como elemento de configuración de ConfigMap. Os ConfigMapGenerators son xeniais porque modifican os datos de configuración e forzan o reinicio do pod se cambia. Tamén reducen a cantidade de configuración en Deployment xa que pode montar un "cartafol" completo de ficheiros de configuración nun VolumeMount.
Finalmente, necesitamos montar o ConfigMap como un volume no 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
[...]
Marabilloso. Se Prometheus non está configurado para facer unha limpeza completa, é posible que teñas que indicarlle que limpe as vainas. Os usuarios de Prometheus Operator poden usar service-monitor.yaml para comezar. Explora Service-monitor.yaml, и antes de comezar.
Estendendo este patrón a outros casos de uso
Todos os ficheiros que engadimos a ConfigMapGenerator estarán dispoñibles no novo directorio /etc/config. Podes ampliar este modelo para montar calquera outro ficheiro de configuración que necesites. Incluso pode montar un novo script de inicio. Podes usar para montar ficheiros individuais. Para actualizar ficheiros xml, considere usar en vez de sed. Xa está incluído na imaxe.
Revistas
Gran noticia! Os rexistros de aplicacións xa están dispoñibles en stdout, por exemplo con kubectl logs. Fluentd (instalado de forma predeterminada en GKE) reenviará os teus rexistros a Elasticsearch, Loki ou á túa plataforma de rexistro empresarial. Se queres usar jsonify para os rexistros, podes seguir o modelo anterior para instalar .
Base de datos
Por defecto, a imaxe terá unha base de datos H2. Isto non é axeitado para nós, e usaremos Google Cloud SQL con Cloud SQL Proxy; isto será necesario máis tarde para resolver problemas internos. Esta é unha opción sinxela e fiable se non tes as túas propias preferencias para configurar a base de datos. AWS RDS ofrece un servizo similar.
Independentemente da base de datos que elixas, a non ser que sexa H2, terás que establecer as variables de ambiente adecuadas en platform/deploy.yaml. Parece algo así:
-- 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: Podes usar Kustomize para implementar en diferentes ambientes usando unha superposición: .
Nota: uso valueFrom: secretKeyRef. Por favor, usa mesmo durante o desenvolvemento para manter os teus segredos a salvo.
É probable que xa teñas un sistema preferido para xestionar os segredos de Kubernetes. Se non, aquí tes algunhas opcións: encriptándoas co KMS do teu provedor de nube e inxectándoas no K8S como segredos a través da canalización de CD − - funcionará moi ben en combinación con Kustomize secrets. Hai outras ferramentas, como dotGPG, que realizan funcións similares: , .
Ingreso
A menos que elixas usar o reenvío de portos locais, necesitarás un controlador de entrada configurado. Se non usas () entón probablemente xa saiba que necesita instalar as anotacións necesarias ingress-patch.yaml.tmpl ou platform/ingress.yaml. Se estás a usar ingress-nginx e ves unha clase de entrada nginx cun equilibrador de carga apuntando a ela e unha entrada de DNS externo ou comodín, xa estás listo. En caso contrario, configure o controlador de entrada e o DNS ou omita estes pasos e manteña a conexión directa co pod.
TLS
Se está a usar ou kube-lego e letsencrypt - os certificados para o novo inicio de sesión obteranse automaticamente. En caso contrario, abre ingress-patch.yaml.tmpl e personalizalo segundo as túas necesidades.
¡Lanzamento!
Se seguiu todo o escrito anteriormente, entón o comando make skaffold HOSTNAME=<you.example.com> debería iniciar unha instancia dispoñible en <hostname>/camunda
Se non configuraches o teu inicio de sesión nun URL público, podes redirixilo con localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 en localhost:8080/camunda
Agarde uns minutos ata que tomcat estea completamente listo. Cert-xestor tardará algún tempo en verificar o nome de dominio. Despois podes supervisar os rexistros usando ferramentas dispoñibles, como unha ferramenta como kubetail, ou simplemente usando kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Próximos pasos
Autorización
Isto é máis relevante para configurar Camunda BPM que Kubernetes, pero é importante ter en conta que, por defecto, a autenticación está desactivada na API REST. Podes ou use outro método como . Podes usar configmaps e volumes para cargar xml, ou xmlstarlet (ver arriba) para editar ficheiros existentes na imaxe, e usar wget ou cargalos mediante un contenedor de inicio e un volume compartido.
Xestión de sesións
Como moitas outras aplicacións, Camunda BPM xestiona sesións na JVM, polo que se queres executar varias réplicas, podes activar sesións adhesivas (), que existirá ata que desapareza a réplica ou estableza o atributo Max-Age para as cookies. Para obter unha solución máis robusta, pode implementar Session Manager en Tomcat. Lars ten sobre este tema, pero algo así como:
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: pode usar xmlstarlet en lugar de sed
Usamos diante de Google Cloud Memorystore, con (soporta Redis) para executalo.
Escalado
Se xa entendes sesións, entón a primeira (e moitas veces a última) limitación para escalar Camunda BPM pode ser a conexión á base de datos. A personalización parcial xa está dispoñible "" Tamén desactivemos intialSize no ficheiro settings.xml. Engadir e pode escalar facilmente automaticamente o número de vainas.
Solicitudes e restricións
В platform/deployment.yaml Verás que codificamos o campo de recursos. Isto funciona ben con HPA, pero pode requirir unha configuración adicional. O parche kustomize é axeitado para iso. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
Saída
Así que instalamos Camunda BPM en Kubernetes con métricas de Prometheus, rexistros, base de datos H2, TLS e Ingress. Engadimos ficheiros jar e ficheiros de configuración mediante ConfigMaps e Dockerfile. Falamos de intercambiar datos a volumes e directamente a variables de ambiente desde segredos. Ademais, ofrecemos unha visión xeral da configuración de Camunda para varias réplicas e unha API autenticada.
referencias
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, tradución Alastair Firth, Lars Lange
Fonte: www.habr.com