¿Usas Kubernetes? ¿Listo para mover tus instancias de Camunda BPM de máquinas virtuales, o quizás simplemente probar a ejecutarlas en Kubernetes? Vamos a revisar algunas configuraciones comunes y elementos específicos que se pueden adaptar a tus necesidades particulares.
Se asume que ya has trabajado con Kubernetes anteriormente. Si no, ¿por qué no echar un vistazo a y lanzar tu primer clúster?
Autores
- es ingeniero de confiabilidad del sitio (Site Reliability Engineer) en el equipo de Camunda Cloud;
- es ingeniero DevOps en Camunda.
En resumen:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Bien, probablemente no funcionó, ya que no tienes instalado skaffold ni kustomize. ¡Sigue leyendo!
Qué es Camunda BPM
Camunda BPM es una plataforma de código abierto para la gestión de procesos de negocio y la automatización de la toma de decisiones, que une a los usuarios de negocio y a los desarrolladores de software. Es ideal para coordinar y unir personas, (micro) servicios o incluso bots. Puedes leer más sobre las diversas aplicaciones en .
Por qué usar Kubernetes
Kubernetes se ha convertido en el estándar de facto para ejecutar aplicaciones modernas en Linux. Al utilizar llamadas del sistema en lugar de emulación de nivel de hardware y las capacidades del núcleo para gestionar la memoria y la conmutación de tareas, el tiempo de carga y el tiempo de inicio se minimizan. Sin embargo, la mayor ventaja puede ofrecerla la API estándar que Kubernetes proporciona para configurar la infraestructura necesaria para todas las aplicaciones: almacenamiento, red y monitoreo. En junio de 2020, cumplió 6 años, y es probablemente el segundo proyecto de código abierto más grande (después de Linux). Recientemente, ha estado estabilizando activamente su funcionalidad después de iteraciones rápidas en los últimos años, ya que esto se vuelve crítico para las cargas de trabajo productivas en todo el mundo.
El motor de Camunda BPM se puede conectar fácilmente a otras aplicaciones en el mismo clúster, y Kubernetes proporciona una excelente escalabilidad, permitiendo aumentar los gastos de infraestructura solo cuando es realmente necesario (y disminuirlos fácilmente según sea necesario).
La calidad de la monitorización también mejora significativamente con herramientas como Prometheus, Grafana, Loki, Fluentd y Elasticsearch, que permiten visualizar centralizadamente todas las cargas de trabajo del clúster. Hoy examinaremos cómo implementar el exportador de Prometheus en una máquina virtual Java (JVM).
Objetivos
Analicemos algunas áreas en las que podemos configurar la imagen de Docker de Camunda BPM (), para que interactúe bien con Kubernetes.
- Registros y métricas;
- Conexiones a la base de datos;
- Autenticación;
- Gestión de sesiones.
Examinaremos varias maneras de lograr estos objetivos y mostraremos visualmente todo el proceso.
Nota: ¿Está utilizando la versión Enterprise? Vea y actualice los enlaces a las imágenes si es necesario.
Desarrollo de flujo de trabajo
En esta demostración, utilizaremos Skaffold para crear imágenes de Docker con Google Cloud Build. Tiene un buen soporte para varias herramientas (como Kustomize y Helm), CI y herramientas de construcción, así como proveedores de infraestructura. El archivo skaffold.yaml.tmpl incluye configuraciones para Google Cloud Build y GKE, lo que proporciona una manera muy sencilla de implementar infraestructura de nivel industrial.
make skaffold subirá el contexto de Dockerfile a Cloud Build, creará la imagen y la almacenará en GCR, y luego aplicará los manifiestos a su clúster. Eso es lo que hace make skaffold, pero Skaffold tiene muchas otras capacidades.
Para las plantillas yaml en Kubernetes, usamos kustomize para gestionar superposiciones 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 esas cosas.
También utilizamos envsubst para rellenar el nombre del host y la identificación del proyecto GCP en los archivos * .yaml.tmpl. Puede ver cómo funciona en makefile o simplemente seguir adelante.
Requisitos previos
- Clúster de trabajo
- — para crear imágenes Docker personalizadas y facilitar la implementación en GKE
- Una copia de este código
- Envsubst
Flujo de trabajo con los manifiestos
Si no desea utilizar kustomize o skaffold, puede referirse a los manifiestos en generated-manifest.yaml y adaptarlos al flujo de trabajo que elija.
Registros y métricas
Prometheus se ha convertido en el estándar para la recolección de métricas en Kubernetes. Ocupa el mismo nicho que AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics y otros. Tiene código abierto y un poderoso lenguaje de consulta. Deberíamos dejar la visualización a Grafana, que viene con una gran cantidad de paneles de monitoreo disponibles directamente. Están interconectados y son relativamente fáciles de configurar. .
Por defecto, Prometheus utiliza un modelo de extracción /metrics, y añadir contenedores sidecar para esto es algo común. Desafortunadamente, las métricas JMX se registran mejor dentro de la JVM, por lo que los contenedores sidecar no son tan efectivos. Conectemos el jmx_exporter de código abierto de Prometheus a la JVM, añadiéndolo a la imagen del contenedor que proporcionará la ruta /metrics en otro puerto.
Agregue el jmx_exporter de Prometheus al contenedor
-- images/camunda-bpm/Dockerfile
DE 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 monitorizará tomcat y mostrará sus métricas en formato Prometheus en :9404/metrics
Configuración del exportador
El lector atento puede preguntarse de dónde proviene prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны . Añadiremos tomcat como en Kubernetes y luego lo montaremos como un volumen.
Primero, agregamos el archivo de configuración del exportador a nuestro directorio platform/config/
plataforma/config
└── prometheus-jmx.yaml
Luego añadimos en kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Esto añadirá cada elemento files[] como un elemento de configuración de ConfigMap. Los ConfigMapGenerators son útiles porque hashan los datos en la configuración e inician un reinicio del pod si se modifican. También reducen la cantidad de configuración en el Deployment, ya que puedes montar toda la "carpeta" de archivos de configuración en un solo VolumeMount.
Finalmente, necesitamos montar el ConfigMap como un volumen al pod:
-- plataforma/despliegue.yaml
apiVersion: apps/v1
tipo: Despliegue
[...]
especificación:
plantilla:
especificación:
[...]
volúmenes:
- name: config
configMap:
nombre: config
modoPredeterminado: 0744
contenedores:
- nombre: camunda-bpm
montajesDeVolumen:
- rutaDeMontaje: /etc/config/
nombre: config
[...]
Perfecto. Si Prometheus no está configurado para limpieza completa, puede que necesites indicarle que limpie los pods. Los usuarios de Prometheus Operator pueden usar service-monitor.yaml para comenzar. Revisen Service-monitor.yaml, y antes de proceder.
Expandir esta plantilla a otros casos de uso
Todos los archivos que agreguemos al ConfigMapGenerator estarán disponibles en un nuevo directorio. /etc/config. Puede ampliar esta plantilla para montar cualquier otro archivo de configuración necesario. Incluso puede montar un nuevo script de inicio. Puede usar para montar archivos individuales. Para actualizar archivos xml, considere usar en lugar de sed. Ya está incluido en la imagen.
Registros
¡Grandes noticias! Los registros de aplicaciones ya están disponibles en stdout, por ejemplo, a través de combina. Fluentd (que se instala por defecto en GKE) redirigirá sus registros a Elasticsearch, Loki o a su plataforma de registros corporativa. Si desea usar jsonify para los registros, puede seguir la plantilla anterior para instalar .
Base de datos
Por defecto, la imagen tendrá una base de datos H2. Esto no nos conviene, y usaremos Google Cloud SQL con Cloud SQL Proxy; esto será necesario más adelante para resolver tareas internas. Esta es una opción simple y confiable si no tiene preferencias propias para la configuración de la base de datos. AWS RDS ofrece un servicio similar.
Independientemente de la base de datos que elija, a menos que sea H2, necesitará establecer las variables de entorno correspondientes en platform/deploy.yaml. Esto se ve aproximadamente así:
-- plataforma/despliegue.yaml
apiVersion: apps/v1
tipo: Despliegue
[...]
especificación:
plantilla:
especificación:
[...]
contenedores:
- nombre: camunda-bpm
entorno:
- nombre: DB_DRIVER
valor: org.postgresql.Driver
- nombre: DB_URL
valor: jdbc:postgresql://postgres-proxy.db:5432/process-engine
- nombre: DB_USERNAME
valorDe:
referenciaDeClaveSecreta:
nombre: cambpm-db-credentials
clave: db_username
- nombre: DB_PASSWORD
valorDe:
referenciaDeClaveSecreta:
nombre: cambpm-db-credentials
clave: db_password
[...]
Nota: Puede usar Kustomize para implementar en diferentes entornos utilizando superposiciones: .
Nota: uso valueFrom: secretKeyRef. Por favor, utilice incluso durante el desarrollo, para mantener sus secretos seguros.
Es muy probable que ya tenga un sistema preferido de gestión de secretos de Kubernetes. Si no lo tiene, aquí hay algunas opciones: cifrarlos con KMS de su proveedor de nube y luego inyectarlos en K8S como secretos a través de la tubería de CD — — funcionará muy bien en conjunto con los secretos de Kustomize. Hay otras herramientas, como dotGPG, que realizan funciones similares: , .
Ingress
A menos que decida usar la redirección de puerto local, necesitará un Ingress Controller configurado. Si no está usando () entonces, probablemente ya sepa que necesita establecer las anotaciones necesarias en ingress-patch.yaml.tmpl o platform/ingress.yamlSi estás usando ingress-nginx y ves la clase de ingress de nginx con un balanceador de carga apuntándole y DNS externo o un registro DNS comodín, todo está listo. De lo contrario, configura el Ingress Controller y DNS o salta estos pasos y deja la conexión directa al pod.
TLS
Si estás usando o kube-lego y letsencrypt, los certificados para la nueva entrada se obtendrán automáticamente. De lo contrario, abre ingress-patch.yaml.tmpl y configúralo según tus necesidades.
¡Listo!
Si seguiste todo lo anterior, el comando make skaffold HOSTNAME= debería lanzar una instancia accesible en /camunda
Si no configuraste la entrada a través de una URL pública, puedes redirigirla desde localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 en localhost:8080/camunda
Espera unos minutos mientras tomcat se prepara completamente. Cert-manager necesitará algo de tiempo para verificar el nombre de dominio. Después de esto, puedes monitorear los registros usando herramientas disponibles, como kubetail, o simplemente con kubectl:
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Próximos pasos
Autorización
Esto se refiere más a la configuración de Camunda BPM que a Kubernetes, pero es importante señalar que, por defecto, la autenticación en la API REST está deshabilitada. Puedes o usar otro método, como . Puedes usar configmaps y volúmenes para cargar xml, o xmlstarlet (ver más arriba) para editar archivos existentes en la imagen, así como usar wget o cargarlos con un contenedor init y un volumen compartido.
Gestión de sesiones
Como muchas otras aplicaciones, Camunda BPM maneja sesiones en la JVM, así que si deseas ejecutar múltiples réplicas, puedes habilitar sesiones pegajosas (), que existirán hasta que la réplica desaparezca, o establecer el atributo Max-Age para las cookies. Como solución más confiable, puedes implementar un 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 '/^\/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: se puede usar xmlstarlet en lugar de sed
Usamos antes de Google Cloud Memorystore, con (soporta Redis) para ponerlo en funcionamiento.
Escalado
Si ya ha manejado sesiones, la primera (y a menudo la última) limitación para escalar Camunda BPM puede ser la conexión a la base de datos. La configuración parcial está disponible ya. También desactivaremos intialSize en el archivo settings.xml. Agregue y podrá escalar automáticamente el número de pods sin esfuerzo.
Solicitudes y límites
En platform/deployment.yaml notará que hemos codificado en seco el campo de recursos. Esto funciona bien con HPA, pero puede necesitar ajustes adicionales. Un parche de kustomize sería adecuado. Vea ingress-patch.yaml.tmpl y ./kustomization.yaml.tmpl
Salida
Así que hemos instalado Camunda BPM en Kubernetes con métricas de Prometheus, registros, base de datos H2, TLS e Ingress. Agregamos archivos jar y archivos de configuración utilizando ConfigMaps y Dockerfile. Hablamos sobre el intercambio de datos con volúmenes y directamente en variables de entorno desde secretos. Además, brindamos un resumen sobre la configuración de Camunda para varias réplicas y una API autenticada.
Enlaces
github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes
│
├── generated-manifest.yaml <- manifiesto para uso sin kustomize
├── imágenes
│ └── camunda-bpm
│ └── Dockerfile <- imagen de docker superpuesta
├── ingress-patch.yaml.tmpl <- configuración de ingress específica del sitio
├── kustomization.yaml.tmpl <- Kustomization principal
├── Makefile <- objetivos de construcción
├── namespace.yaml
├── plataforma
│ ├── config
│ │ └── prometheus-jmx.yaml <- archivo de configuración del exportador prometheus
│ ├── deployment.yaml <- implementación principal
│ ├── ingress.yaml
│ ├── kustomization.yaml <- kustomization "base"
│ ├── service-monitor.yaml <- ejemplo de configuración del prometheus-operator
│ └── service.yaml
└── skaffold.yaml.tmpl <- directivas de skaffold
08.05.2020, traducción Alastair Firth, Lars Lange
Fuente: habr.com
