Utilisez-vous Kubernetes ? Prêt à déplacer vos instances Camunda BPM hors des machines virtuelles, ou peut-être simplement à essayer de les exécuter sur Kubernetes ? Examinons quelques configurations courantes et éléments individuels qui peuvent être adaptés à vos besoins spécifiques.
Cela suppose que vous avez déjà utilisé Kubernetes. Sinon, pourquoi ne pas y jeter un œil et ne pas démarrer votre premier cluster ?
Auteurs
- (Alastair Firth) - Ingénieur senior en fiabilité des sites au sein de l'équipe Camunda Cloud ;
- (Lars Lange) - Ingénieur DevOps chez Camunda.
En bref, alors:
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
D'accord, cela n'a probablement pas fonctionné parce que vous n'avez pas installé skaffold et kustomize. Eh bien, continuez à lire !
Qu'est-ce que le BPM de Camunda
Camunda BPM est une plateforme open source de gestion des processus métier et d'automatisation des décisions qui connecte les utilisateurs professionnels et les développeurs de logiciels. Il est idéal pour coordonner et connecter des personnes, des (micro) services ou même des robots ! Vous pouvez en savoir plus sur les différents cas d'utilisation sur .
Pourquoi utiliser Kubernetes
Kubernetes est devenu le standard de facto pour exécuter des applications modernes sous Linux. En utilisant des appels système au lieu de l'émulation matérielle et la capacité du noyau à gérer la mémoire et le changement de tâche, le temps de démarrage et le temps de démarrage sont réduits au minimum. Cependant, le plus grand avantage pourrait provenir de l’API standard fournie par Kubernetes pour configurer l’infrastructure requise par toutes les applications : stockage, mise en réseau et surveillance. Il a fêté ses 2020 ans en juin 6 et est peut-être le deuxième plus grand projet open source (après Linux). Il a récemment stabilisé activement ses fonctionnalités après des itérations rapides au cours des dernières années, car il devient critique pour les charges de travail de production dans le monde entier.
Camunda BPM Engine peut facilement se connecter à d'autres applications exécutées sur le même cluster, et Kubernetes offre une excellente évolutivité, vous permettant d'augmenter les coûts d'infrastructure uniquement lorsque cela est vraiment nécessaire (et de les réduire facilement si nécessaire).
La qualité de la surveillance est également grandement améliorée avec des outils tels que Prometheus, Grafana, Loki, Fluentd et Elasticsearch, vous permettant de visualiser de manière centralisée toutes les charges de travail d'un cluster. Aujourd'hui, nous verrons comment implémenter l'exportateur Prometheus dans la machine virtuelle Java (JVM).
Objectifs
Examinons quelques domaines dans lesquels nous pouvons personnaliser l'image Camunda BPM Docker () pour qu'il interagisse bien avec Kubernetes.
- Journaux et métriques ;
- Connexions à la base de données ;
- Authentification;
- Gestion des séances.
Nous examinerons plusieurs façons d'atteindre ces objectifs et montrerons clairement l'ensemble du processus.
Noter: Utilisez-vous la version Entreprise ? Regarder et mettez à jour les liens d’images si nécessaire.
Développement de flux de travail
Dans cette démo, nous utiliserons Skaffold pour créer des images Docker à l'aide de Google Cloud Build. Il prend en charge divers outils (tels que Kustomize et Helm), les outils de CI et de build, ainsi que les fournisseurs d'infrastructure. Déposer skaffold.yaml.tmpl inclut des paramètres pour Google Cloud Build et GKE, offrant un moyen très simple d'exécuter une infrastructure de production.
make skaffold chargera le contexte Dockerfile dans Cloud Build, créera l'image et la stockera dans GCR, puis appliquera les manifestes à votre cluster. C'est ce que ça fait make skaffold, mais Skaffold a de nombreuses autres fonctionnalités.
Pour les modèles yaml dans Kubernetes, nous utilisons kustomize pour gérer les superpositions yaml sans bifurquer l'intégralité du manifeste, ce qui vous permet d'utiliser git pull --rebase pour d'autres améliorations. Maintenant, c'est dans Kubectl et cela fonctionne plutôt bien pour de telles choses.
Nous utilisons également envsubst pour renseigner le nom d'hôte et l'ID du projet GCP dans les fichiers *.yaml.tmpl. Vous pouvez voir comment cela fonctionne dans makefile ou continuez simplement plus loin.
Prérequis
- Groupe de travail
- - pour créer vos propres images Docker et un déploiement facile sur GKE
- Copie de ce code
- Envsubst
Workflow utilisant des manifestes
Si vous ne souhaitez pas utiliser kustomize ou skaffold, vous pouvez vous référer aux manifestes dans generated-manifest.yaml et adaptez-les au flux de travail de votre choix.
Journaux et métriques
Prometheus est devenu la norme en matière de collecte de métriques dans Kubernetes. Il occupe le même créneau qu'AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics et autres. Il est open source et dispose d’un langage de requête puissant. Nous confierons la visualisation à Grafana - il est livré avec un grand nombre de tableaux de bord disponibles immédiatement. Ils sont connectés les uns aux autres et sont relativement faciles à installer avec .
Par défaut, Prometheus utilise le modèle d'extraction <service>/metrics, et l'ajout de conteneurs side-car pour cela est courant. Malheureusement, les métriques JMX sont mieux enregistrées dans la JVM, de sorte que les conteneurs side-car ne sont pas aussi efficaces. Connectons-nous open source de Prometheus vers la JVM en l'ajoutant à l'image du conteneur qui fournira le chemin /metrics sur un autre port.
Ajoutez Prometheus jmx_exporter au conteneur
-- 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
Eh bien, c'était facile. L'exportateur surveillera Tomcat et affichera ses métriques au format Prometheus à <svc>:9404/metrics
Configuration de l'exportateur
Le lecteur attentif se demandera peut-être d'où cela vient prometheus-jmx.yaml? De nombreuses choses différentes peuvent s'exécuter dans la JVM, et Tomcat n'est que l'une d'entre elles, l'exportateur a donc besoin d'une configuration supplémentaire. Des configurations standard pour Tomcat, Wildfly, Kafka, etc. sont disponibles . Nous ajouterons Tomcat comme dans Kubernetes, puis montez-le en tant que volume.
Tout d’abord, nous ajoutons le fichier de configuration de l’exportateur à notre répertoire platform/config/
platform/config
└── prometheus-jmx.yaml
Puis on ajoute в kustomization.yaml.tmpl:
-- platform/kustomization.yaml.tmpl
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
[...]
configMapGenerator:
- name: config
files:
- config/prometheus-jmx.yaml
Cela ajoutera chaque élément files[] en tant qu'élément de configuration ConfigMap. Les ConfigMapGenerators sont excellents car ils hachent les données de configuration et forcent le redémarrage du pod si elles changent. Ils réduisent également la quantité de configuration dans le déploiement puisque vous pouvez monter un « dossier » entier de fichiers de configuration dans un seul VolumeMount.
Enfin, nous devons monter le ConfigMap en tant que volume sur le 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
[...]
Merveilleux. Si Prometheus n'est pas configuré pour effectuer un nettoyage complet, vous devrez peut-être lui dire de nettoyer les pods. Les utilisateurs de Prometheus Operator peuvent utiliser service-monitor.yaml pour commencer. Explorer Service-monitor.yaml, и avant de commencer.
Extension de ce modèle à d'autres cas d'utilisation
Tous les fichiers que nous ajoutons à ConfigMapGenerator seront disponibles dans le nouveau répertoire /etc/config. Vous pouvez étendre ce modèle pour monter tous les autres fichiers de configuration dont vous avez besoin. Vous pouvez même monter un nouveau script de démarrage. Vous pouvez utiliser pour monter des fichiers individuels. Pour mettre à jour les fichiers XML, pensez à utiliser au lieu de sed. Il est déjà inclus dans l'image.
Les magazines
Bonne nouvelle! Les journaux d'applications sont déjà disponibles sur la sortie standard, par exemple avec kubectl logs. Fluentd (installé par défaut dans GKE) transmettra vos journaux à Elasticsearch, Loki ou à la plateforme de journalisation de votre entreprise. Si vous souhaitez utiliser jsonify pour les journaux, vous pouvez suivre le modèle ci-dessus pour installer .
База данных
Par défaut, l'image aura une base de données H2. Cela ne nous convient pas et nous utiliserons Google Cloud SQL avec Cloud SQL Proxy - cela sera nécessaire plus tard pour résoudre les problèmes internes. Il s'agit d'une option simple et fiable si vous n'avez pas vos propres préférences lors de la configuration de la base de données. AWS RDS fournit un service similaire.
Quelle que soit la base de données que vous choisissez, sauf s'il s'agit de H2, vous devrez définir les variables d'environnement appropriées dans platform/deploy.yaml. Cela ressemble à ceci :
-- 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
[...]
Noter: Vous pouvez utiliser Kustomize pour déployer dans différents environnements à l'aide d'une superposition : .
Noter: utilisation valueFrom: secretKeyRef. Veuillez utiliser même pendant le développement pour garder vos secrets en sécurité.
Il est probable que vous disposiez déjà d’un système préféré pour gérer les secrets Kubernetes. Sinon, voici quelques options : Les chiffrer avec le KMS de votre fournisseur de cloud, puis les injecter dans K8S en tant que secrets via le pipeline CD - - fonctionnera très bien en combinaison avec les secrets Kustomize. Il existe d'autres outils, tels que dotGPG, qui remplissent des fonctions similaires : , .
Entrée
Sauf si vous choisissez d'utiliser la redirection de port local, vous aurez besoin d'un contrôleur d'entrée configuré. Si vous n'utilisez pas () alors vous savez probablement déjà que vous devez installer les annotations nécessaires dans ingress-patch.yaml.tmpl ou platform/ingress.yaml. Si vous utilisez ingress-nginx et voyez une classe d'entrée nginx avec un équilibreur de charge pointant vers elle et une entrée DNS externe ou DNS générique, vous êtes prêt à partir. Sinon, configurez le contrôleur d'entrée et le DNS, ou ignorez ces étapes et conservez la connexion directe au pod.
TLS
Si vous utilisez ou kube-lego et letencrypt - les certificats pour la nouvelle connexion seront obtenus automatiquement. Sinon, ouvrez ingress-patch.yaml.tmpl et personnalisez-le selon vos besoins.
Lancement!
Si vous avez suivi tout ce qui est écrit ci-dessus, alors la commande make skaffold HOSTNAME=<you.example.com> devrait lancer une instance disponible dans <hostname>/camunda
Si vous n'avez pas défini votre connexion sur une URL publique, vous pouvez la rediriger avec localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 sur localhost:8080/camunda
Attendez quelques minutes jusqu'à ce que Tomcat soit complètement prêt. Le gestionnaire de certificats prendra un certain temps pour vérifier le nom de domaine. Vous pouvez ensuite surveiller les journaux à l'aide des outils disponibles tels qu'un outil comme kubetail, ou simplement en utilisant kubectl :
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Prochaines étapes
AUTORISATION
Ceci est plus pertinent pour la configuration de Camunda BPM que de Kubernetes, mais il est important de noter que par défaut, l'authentification est désactivée dans l'API REST. Tu peux ou utilisez une autre méthode comme . Vous pouvez utiliser des cartes de configuration et des volumes pour charger du XML, ou xmlstarlet (voir ci-dessus) pour modifier les fichiers existants dans l'image, et soit utiliser wget, soit les charger à l'aide d'un conteneur d'initialisation et d'un volume partagé.
Gestion des séances
Comme beaucoup d'autres applications, Camunda BPM gère les sessions dans la JVM, donc si vous souhaitez exécuter plusieurs réplicas, vous pouvez activer les sessions persistantes (), qui existera jusqu'à ce que la réplique disparaisse, ou définissez l'attribut Max-Age pour les cookies. Pour une solution plus robuste, vous pouvez déployer Session Manager dans Tomcat. Lars a sur ce sujet, mais quelque chose comme :
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
Noter: vous pouvez utiliser xmlstarlet au lieu de sed
Nous avons utilisé devant Google Cloud Memorystore, avec (prend en charge Redis) pour l'exécuter.
Mise à l'échelle
Si vous comprenez déjà les sessions, la première (et souvent la dernière) limitation à la mise à l'échelle de Camunda BPM peut être la connexion à la base de données. Une personnalisation partielle est déjà disponible "" Désactivons également initialSize dans le fichier settings.xml. Ajouter et vous pouvez facilement augmenter automatiquement le nombre de pods.
Demandes et restrictions
В platform/deployment.yaml Vous verrez que nous avons codé en dur le champ ressources. Cela fonctionne bien avec HPA, mais peut nécessiter une configuration supplémentaire. Le patch kustomize convient pour cela. Cm. ingress-patch.yaml.tmpl и ./kustomization.yaml.tmpl
conclusion
Nous avons donc installé Camunda BPM sur Kubernetes avec les métriques Prometheus, les logs, la base de données H2, TLS et Ingress. Nous avons ajouté des fichiers jar et des fichiers de configuration à l'aide de ConfigMaps et Dockerfile. Nous avons parlé de l'échange de données vers des volumes et directement vers des variables d'environnement à partir de secrets. De plus, nous avons fourni un aperçu de la configuration de Camunda pour plusieurs réplicas et une API authentifiée.
références
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, traduction Alastair Firth, Lars Lange
Source: habr.com