¿Estás usando Kubernetes? ¿Está listo para sacar sus instancias de Camunda BPM de las máquinas virtuales, o tal vez simplemente intentar ejecutarlas en Kubernetes? Veamos algunas configuraciones comunes y elementos individuales que pueden adaptarse a sus necesidades específicas.
Se supone que ha utilizado Kubernetes antes. Si no, ¿por qué no echas un vistazo? ¿Y no iniciar tu primer clúster?
Autores
- (Alastair Firth): ingeniero sénior de confiabilidad del sitio en el equipo de Camunda Cloud;
- (Lars Lange) - Ingeniero de DevOps en Camunda.
En resumen, entonces:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Bien, probablemente no funcionó porque no tienes skaffold y kustomize instalados. ¡Pues entonces sigue leyendo!
¿Qué es Camunda BPM?
Camunda BPM es una plataforma de automatización de decisiones y gestión de procesos empresariales de código abierto que conecta a usuarios empresariales y desarrolladores de software. ¡Es ideal para coordinar y conectar personas, (micro)servicios o incluso bots! Puede leer más sobre los diferentes casos de uso en .
¿Por qué utilizar Kubernetes?
Kubernetes se ha convertido en el estándar de facto para ejecutar aplicaciones modernas en Linux. Al utilizar llamadas al sistema en lugar de emulación de hardware y la capacidad del kernel para administrar la memoria y el cambio de tareas, el tiempo de arranque y el tiempo de inicio se mantienen al mínimo. Sin embargo, el mayor beneficio puede provenir de la API estándar que proporciona Kubernetes para configurar la infraestructura requerida por todas las aplicaciones: almacenamiento, redes y monitoreo. Cumplió 2020 años en junio de 6 y es quizás el segundo proyecto de código abierto más grande (después de Linux). Recientemente, ha estado estabilizando activamente su funcionalidad después de una rápida iteración en los últimos años, a medida que se vuelve fundamental para las cargas de trabajo de producción en todo el mundo.
Camunda BPM Engine puede conectarse fácilmente a otras aplicaciones que se ejecutan en el mismo clúster y Kubernetes proporciona una excelente escalabilidad, lo que le permite aumentar los costos de infraestructura solo cuando realmente sea necesario (y reducirlos fácilmente según sea necesario).
La calidad del monitoreo también mejora enormemente con herramientas como Prometheus, Grafana, Loki, Fluentd y Elasticsearch, que le permiten ver de forma centralizada todas las cargas de trabajo en un clúster. Hoy veremos cómo implementar el exportador Prometheus en la máquina virtual Java (JVM).
Objetivos
Veamos algunas áreas donde podemos personalizar la imagen Docker de Camunda BPM () para que interactúe bien con Kubernetes.
- Registros y métricas;
- Conexiones de bases de datos;
- Autenticación;
- Gestión de sesiones.
Consideraremos varias formas de lograr estos objetivos y mostraremos claramente todo el proceso.
Nota: ¿Estás utilizando la versión Enterprise? Mirar y actualice los enlaces de imágenes según sea necesario.
Desarrollo del flujo de trabajo
En esta demostración, usaremos Skaffold para crear imágenes de Docker usando Google Cloud Build. Tiene buen soporte para varias herramientas (como Kustomize y Helm), herramientas de compilación y CI y proveedores de infraestructura. Archivo skaffold.yaml.tmpl incluye configuraciones para Google Cloud Build y GKE, lo que proporciona una forma muy sencilla de ejecutar una infraestructura de nivel de producción.
make skaffold cargará el contexto de Dockerfile en Cloud Build, creará la imagen y la almacenará en GCR, y luego aplicará los manifiestos a su clúster. Esto es lo que hace make skaffold, pero Skaffold tiene muchas otras características.
Para las plantillas de yaml en Kubernetes, usamos kustomize para administrar las superposiciones de yaml sin bifurcar todo el manifiesto, lo que le permite usar git pull --rebase para futuras mejoras. Ahora está en kubectl y funciona bastante bien para ese tipo de cosas.
También usamos envsubst para completar el nombre de host y el ID del proyecto GCP en los archivos *.yaml.tmpl. Puedes ver cómo funciona en makefile o simplemente continuar más.
Requisitos previos
- Clúster de trabajo
- - para crear tus propias imágenes de Docker y facilitar la implementación en GKE
- Copia de este código
- Envsubst
Flujo de trabajo mediante manifiestos
Si no desea utilizar kustomize o skaffold, puede consultar los manifiestos en generated-manifest.yaml y adáptalos al flujo de trabajo de tu elección.
Registros y métricas
Prometheus se ha convertido en el estándar para recopilar métricas en Kubernetes. Ocupa el mismo nicho que AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics y otros. Es de código abierto y tiene un potente lenguaje de consulta. Confiaremos la visualización a Grafana: viene con una gran cantidad de paneles disponibles listos para usar. Están conectados entre sí y son relativamente fáciles de instalar con .
Por defecto, Prometheus usa el modelo de extracción. <service>/metrics, y es común agregar contenedores sidecar para esto. Desafortunadamente, las métricas de JMX se registran mejor dentro de la JVM, por lo que los contenedores sidecar no son tan eficientes. conectemos abra el código fuente de Prometheus a la JVM agregándolo a la imagen del contenedor que proporcionará la ruta /metrics en un puerto diferente.
Agregue Prometheus jmx_exporter al contenedor
-- 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
Bueno, eso fue fácil. El exportador monitoreará Tomcat y mostrará sus métricas en formato Prometheus en <svc>:9404/metrics
Configuración del exportador
El lector atento puede preguntarse de dónde vino prometheus-jmx.yaml? Hay muchas cosas diferentes que se pueden ejecutar en la JVM y Tomcat es solo una de ellas, por lo que el exportador necesita alguna configuración adicional. Están disponibles configuraciones estándar para Tomcat, Wildfly, Kafka, etc. . Agregaremos tomcat como en Kubernetes y luego montarlo como un volumen.
Primero, agregamos el archivo de configuración del exportador a nuestro directorio plataforma/config/
platform/config
└── prometheus-jmx.yaml
Luego agregamos в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Esto agregará cada elemento. files[] como elemento de configuración de ConfigMap. Los ConfigMapGenerators son excelentes porque codifican los datos de configuración y fuerzan un reinicio del pod si cambia. También reducen la cantidad de configuración en la implementación, ya que puede montar una "carpeta" completa de archivos de configuración en un VolumeMount.
Finalmente, necesitamos montar ConfigMap como un volumen en el 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
[...]
Maravilloso. Si Prometheus no está configurado para realizar una limpieza completa, es posible que deba indicarle que limpie los pods. Los usuarios del operador Prometheus pueden utilizar service-monitor.yaml Para empezar. Explorar Service-monitor.yaml, и antes de que empieces.
Ampliar este patrón a otros casos de uso
Todos los archivos que agreguemos a ConfigMapGenerator estarán disponibles en el nuevo directorio /etc/config. Puede ampliar esta plantilla para montar cualquier otro archivo de configuración que necesite. Incluso puedes montar un nuevo script de inicio. Puedes usar para montar archivos individuales. Para actualizar archivos xml, considere usar en lugar de sed. Ya está incluido en la imagen.
Revistas
¡Una gran noticia! Los registros de aplicaciones ya están disponibles en stdout, por ejemplo con kubectl logs. Fluentd (instalado de forma predeterminada en GKE) reenviará sus registros a Elasticsearch, Loki o la plataforma de registro de su empresa. Si desea utilizar jsonify para registros, puede seguir la plantilla anterior para instalar .
База данных
Por defecto, la imagen tendrá una base de datos H2. Esto no es adecuado para nosotros y usaremos Google Cloud SQL con Cloud SQL Proxy; esto será necesario más adelante para resolver problemas internos. Esta es una opción simple y confiable si no tiene sus propias preferencias al configurar la base de datos. AWS RDS proporciona un servicio similar.
Independientemente de la base de datos que elija, a menos que sea H2, deberá configurar las variables de entorno adecuadas en platform/deploy.yaml. Se parece a esto:
-- 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: Puedes usar Kustomize para implementar en diferentes entornos usando una superposición: .
Nota: uso valueFrom: secretKeyRef. Por favor use incluso durante el desarrollo para mantener tus secretos seguros.
Es probable que ya tenga un sistema preferido para administrar los secretos de Kubernetes. De lo contrario, aquí hay algunas opciones: Cifrarlos con el KMS de su proveedor de nube y luego inyectarlos en K8S como secretos a través de la canalización de CD. - funcionará muy bien en combinación con los secretos de Kustomize. Existen otras herramientas, como dotGPG, que realizan funciones similares: , .
Ingreso
A menos que elija utilizar el reenvío de puertos local, necesitará un controlador de ingreso configurado. Si no usas () entonces lo más probable es que ya sepas que necesitas instalar las anotaciones necesarias en ingress-patch.yaml.tmpl o platform/ingress.yaml. Si está utilizando ingress-nginx y ve una clase de ingreso nginx con un equilibrador de carga apuntando a ella y una entrada DNS externa o DNS comodín, está listo. De lo contrario, configure el controlador de ingreso y el DNS, u omita estos pasos y mantenga la conexión directa al pod.
TLS
Si esta usando o kube-lego y letsencrypt: los certificados para el nuevo inicio de sesión se obtendrán automáticamente. De lo contrario, abra ingress-patch.yaml.tmpl y personalízalo según tus necesidades.
¡Lanzamiento!
Si siguió todo lo escrito anteriormente, entonces el comando make skaffold HOSTNAME=<you.example.com> debería lanzar una instancia disponible en <hostname>/camunda
Si no ha configurado su inicio de sesión en una URL pública, puede redirigirlo con localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 en localhost:8080/camunda
Espere unos minutos hasta que Tomcat esté completamente listo. Cert-manager tardará algún tiempo en verificar el nombre de dominio. Luego puede monitorear los registros usando herramientas disponibles, como kubetail, o simplemente usando kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Próximos pasos
Autorización
Esto es más relevante para configurar Camunda BPM que Kubernetes, pero es importante tener en cuenta que, de forma predeterminada, la autenticación está deshabilitada en la API REST. Puede o usar otro método como . Puede usar configmaps y volúmenes para cargar xml, o xmlstarlet (ver arriba) para editar archivos existentes en la imagen, y usar wget o cargarlos usando un contenedor de inicio y un volumen compartido.
Gestión de sesiones
Como muchas otras aplicaciones, Camunda BPM maneja sesiones en JVM, por lo que si desea ejecutar múltiples réplicas, puede habilitar sesiones fijas (), que existirá hasta que la réplica desaparezca, o establezca el atributo Max-Age para las cookies. Para obtener una solución más sólida, puede implementar Session Manager en Tomcat. Lars tiene sobre este tema, pero algo 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: puedes usar xmlstarlet en lugar de sed
Nosotros usamos frente a Google Cloud Memorystore, con (compatible con Redis) para ejecutarlo.
Escalado
Si ya comprende las sesiones, entonces la primera (y a menudo la última) limitación para escalar Camunda BPM puede ser la conexión a la base de datos. La personalización parcial ya está disponible "" También deshabilitemos el tamaño inicial en el archivo settings.xml. Agregar y puede escalar fácilmente y automáticamente la cantidad de pods.
Solicitudes y restricciones
В platform/deployment.yaml Verás que hemos codificado el campo de recursos. Esto funciona bien con HPA, pero puede requerir configuración adicional. El parche kustomize es adecuado para esto. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
conclusión
Entonces instalamos Camunda BPM en Kubernetes con métricas, registros, base de datos H2, TLS e Ingress de Prometheus. Agregamos archivos jar y archivos de configuración usando ConfigMaps y Dockerfile. Hablamos de intercambiar datos a volúmenes y directamente a variables de entorno desde secretos. Además, proporcionamos una descripción general de la configuración de Camunda para múltiples réplicas y una 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, traducción Alastair Firth, Lars Lange
Fuente: habr.com