Vous utilisez Kubernetes ? Prêt à déplacer vos instances de Camunda BPM depuis des machines virtuelles, ou peut-être simplement à essayer de les exécuter sur Kubernetes ? Examinons certaines configurations courantes et des éléments individuels que vous pouvez adapter à vos besoins spécifiques.
Il est supposé que vous avez déjà utilisé Kubernetes auparavant. Sinon, pourquoi ne pas jeter un œil à et démarrer votre premier cluster ?
Auteurs
- est un ingénieur senior en fiabilité des sites (Site Reliability Engineer) dans l'équipe de Camunda Cloud ;
- est ingénieur DevOps chez Camunda.
En résumé :
git clone https://github.com/camunda-cloud/camunda-examples.git
cd camunda-examples/camunda-bpm-demo
make skaffold
Eh bien, cela n'a probablement pas fonctionné car vous n'avez pas installé skaffold et kustomize. Alors continuez à lire !
Qu'est-ce que Camunda BPM
Camunda BPM est une plateforme open source pour la gestion des processus métier et l'automatisation de la prise de décision qui relie les utilisateurs métiers et les développeurs de logiciels. Elle est idéale pour coordonner et réunir des personnes, des (micro)services ou même des bots ! Pour en savoir plus sur les différentes utilisations, vous pouvez consulter .
Pourquoi utiliser Kubernetes
Kubernetes est devenu le standard de facto pour exécuter des applications modernes sous Linux. Grâce à des appels système au lieu d'une émulation du matériel et aux capacités du noyau de gérer la mémoire et le multitâche, les temps de chargement et de démarrage sont minimisés. Cependant, le plus grand avantage provient de l'API standard que Kubernetes fournit pour configurer l'infrastructure nécessaire à toutes les applications : stockage, réseau et surveillance. En juin 2020, il a célébré ses 6 ans, et c'est probablement le deuxième plus grand projet open source (après Linux). Récemment, il stabilise activement sa fonctionnalité après des itérations rapides au cours des dernières années, car cela devient crucial pour les charges de production à travers le monde.
Le moteur Camunda BPM peut facilement se connecter à d'autres applications fonctionnant dans le même cluster, et Kubernetes offre une excellente scalabilité, permettant d'augmenter les coûts d'infrastructure uniquement lorsque cela est réellement nécessaire (et de les réduire facilement si nécessaire).
La qualité de la surveillance s'améliore également considérablement grâce à des outils tels que Prometheus, Grafana, Loki, Fluentd et Elasticsearch, permettant de visualiser de manière centralisée toutes les charges de travail du cluster. Aujourd'hui, nous allons voir comment intégrer l'exporteur Prometheus dans une machine virtuelle Java (JVM).
Objectifs
Examinons quelques domaines dans lesquels nous pouvons configurer l'image Docker de Camunda BPM (), afin qu'elle interagisse bien avec Kubernetes.
- Journaux et métriques ;
- Connexions à la base de données ;
- Authentification ;
- Gestion des sessions.
Nous allons explorer plusieurs façons de réaliser ces objectifs et montrer tout le processus en détail.
Remarque: Utilisez-vous la version Enterprise ? Consultez et mettez à jour les liens vers les images si nécessaire.
Développement de flux de travail
Dans cette démonstration, nous allons utiliser Skaffold pour créer des images Docker à l'aide de Google Cloud Build. Il bénéficie d'une bonne prise en charge de divers outils (tels que Kustomize et Helm), d'outils CI et de construction, ainsi que de fournisseurs d'infrastructure. Le fichier skaffold.yaml.tmpl comprend des paramètres pour Google Cloud Build et GKE, offrant un moyen très simple de déployer une infrastructure de niveau industriel.
make skaffold chargera le contexte Dockerfile dans Cloud Build, construira l'image et la stockera dans GCR, puis appliquera les manifestes à votre cluster. C'est ce que fait make skaffold, mais Skaffold a bien d'autres capacités.
Pour les modèles yaml dans Kubernetes, nous utilisons kustomize pour gérer les superpositions yaml sans déployer tout le manifeste, ce qui vous permet d'utiliser git pull --rebase pour des améliorations ultérieures. Il est désormais intégré à kubectl et cela fonctionne plutôt bien pour ce genre de choses.
Nous utilisons également envsubst pour remplir le nom d'hôte et l'identifiant du projet GCP dans les fichiers *.yaml.tmpl. Vous pouvez voir comment cela fonctionne dans makefile ou simplement continuer.
Conditions requises
- Cluster de travail
- — pour créer des images docker personnalisées et déployer facilement dans GKE
- Une copie de ce code
- Envsubst
Flux de travail avec des manifestes
Si vous ne souhaitez pas utiliser kustomize ou skaffold, vous pouvez vous référer aux manifestes dans generated-manifest.yaml et les adapter au flux de travail de votre choix.
Journaux et métriques
Prometheus est devenu le standard pour la collecte de métriques dans Kubernetes. Il occupe le même créneau que AWS Cloudwatch Metrics, Cloudwatch Alerts, Stackdriver Metrics, StatsD, Datadog, Nagios, vSphere Metrics et d'autres. Son code est ouvert et il dispose d'un langage de requête puissant. La visualisation sera assurée par Grafana — celui-ci est livré avec un grand nombre de panneaux de surveillance disponibles immédiatement. Ils sont interconnectés et relativement simples à configurer avec .
Par défaut, Prometheus utilise un modèle d'extraction /metrics, et l'ajout de conteneurs sidecar pour cela est courant. Malheureusement, les métriques JMX sont mieux enregistrées à l'intérieur de la JVM, donc les conteneurs sidecar ne sont pas aussi efficaces. Connectons de code ouvert de Prometheus à la JVM, en l'ajoutant à l'image du conteneur, qui fournira un chemin /metrics sur un autre port.
Ajoutez le jmx_exporter de Prometheus 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'exporteur monitorera tomcat et affichera ses métriques au format Prometheus à l'adresse :9404/metrics
Configuration de l'exporteur
Le lecteur attentif pourrait se demander d'où vient prometheus-jmx.yaml? Существует много разных вещей, которые могут работать в JVM, и tomcat — это только одна из них, поэтому экспортер нуждается в некоторой дополнительной настройке. Стандартные конфигурации для tomcat, wildfly, kafka и так далее доступны . Nous ajouterons tomcat comme dans Kubernetes, puis nous le monterons en tant que volume.
Tout d'abord, nous ajoutons le fichier de configuration de l'exporteur dans notre répertoire platform/config/
plateforme/config
└── prometheus-jmx.yaml
Ensuite, nous ajoutons dans 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 pratiques car ils hachent les données dans la configuration et déclenchent le redémarrage du pod s'il y a des changements. Ils réduisent également la quantité de configuration dans le Deployment, car vous pouvez monter tout le « dossier » des fichiers de configuration dans un seul VolumeMount.
Enfin, nous devons monter le ConfigMap en tant que volume au pod :
-- plateforme/deploiement.yaml
apiVersion: apps/v1
kind: Déploiement
[...]
spécification :
modèle :
spécification :
[...]
volumes :
- name: config
configMap :
nom : config
mode par défaut : 0744
conteneurs :
- nom : camunda-bpm
montages de volumes :
- chemin de montage : /etc/config/
nom : config
[...]
Parfait. Si Prometheus n'est pas configuré pour un nettoyage complet, il se peut que vous deviez lui demander de nettoyer les pods. Les utilisateurs de Prometheus Operator peuvent utiliser service-monitor.yaml pour commencer. Explorez Service-monitor.yaml, et avant de commencer.
La diffusion de ce modèle à d'autres cas d'utilisation
Tous les fichiers que nous ajoutons dans le ConfigMapGenerator seront disponibles dans le nouveau répertoire /etc/config. Vous pouvez étendre ce modèle pour monter d'autres fichiers de configuration nécessaires. 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, envisagez d'utiliser au lieu de sed. Il est déjà inclus dans l'image.
Journaux
Bonne nouvelle ! Les journaux d'application sont déjà disponibles sur stdout, par exemple, en utilisant kubectl logs. Fluentd (déjà installé par défaut dans GKE) redirigera vos journaux vers Elasticsearch, Loki ou votre plateforme de journaux d'entreprise. Si vous souhaitez utiliser jsonify pour les journaux, vous pouvez suivre le modèle ci-dessus pour l'installation .
Base de données
Par défaut, l'image aura une base de données H2. Cela ne nous convient pas, et nous allons utiliser Google Cloud SQL avec Cloud SQL Proxy — cela sera nécessaire plus tard pour résoudre des tâches internes. C'est une option simple et fiable si vous n'avez pas de préférences pour la configuration de la base de données. AWS RDS fournit un service similaire.
Indépendamment de la base de données que vous choisissez, sauf si c'est H2, vous devrez définir les variables d'environnement appropriées dans platform/deploy.yaml. Cela ressemble à ceci :
-- plateforme/deploiement.yaml
apiVersion: apps/v1
kind: Déploiement
[...]
spécification :
modèle :
spécification :
[...]
conteneurs :
- nom : camunda-bpm
env :
- nom : DB_DRIVER
valeur : org.postgresql.Driver
- nom : DB_URL
valeur : jdbc:postgresql://postgres-proxy.db:5432/process-engine
- nom : DB_USERNAME
valeurFrom :
secretKeyRef :
nom : cambpm-db-credentials
clé : db_username
- nom : DB_PASSWORD
valeurFrom :
secretKeyRef :
nom : cambpm-db-credentials
clé : db_password
[...]
Remarque: Vous pouvez utiliser Kustomize pour déployer dans différents environnements en utilisant un overlay : .
Remarque: utilisation valueFrom: secretKeyRef. Veuillez utiliser même pendant le développement pour garder vos secrets en sécurité.
Il est probable que vous ayez déjà un système de gestion des secrets Kubernetes préféré. Sinon, voici quelques options : les chiffrer à l'aide de KMS de votre fournisseur cloud, puis les injecter dans K8S en tant que secrets via un pipeline CI/CD — — fonctionnera très bien avec les secrets de Kustomize. Il existe d'autres outils comme dotGPG — ils remplissent des fonctions similaires : , .
Ingress
Sauf si vous choisissez d'utiliser la redirection de port local, vous aurez besoin d'un Ingress Controller configuré. Si vous n'utilisez pas () alors vous savez probablement déjà qu'il vous faut 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 équilibrage de charge pointant vers elle et un DNS externe ou un enregistrement DNS de substitution, tout est prêt. Sinon, configurez le contrôleur Ingress et le DNS ou passez ces étapes et laissez une connexion directe au pod.
TLS
Si vous utilisez ou kube-lego et letsencrypt, les certificats pour la nouvelle entrée seront obtenus automatiquement. Sinon, ouvrez ingress-patch.yaml.tmpl et configurez-le selon vos besoins.
Lancement!
Si vous avez suivi tout ce qui a été écrit ci-dessus, alors la commande make skaffold HOSTNAME= devrait lancer une instance accessible sur /camunda
Si vous n'avez pas exposé l'entrée via une URL publique, vous pouvez rediriger depuis localhost: kubectl port-forward -n camunda-bpm-demo svc/camunda-bpm 8080:8080 sur localhost:8080/camunda
Attendez quelques minutes, le temps que tomcat soit complètement prêt. Cert-manager prendra un certain temps pour vérifier le nom de domaine. Après cela, vous pouvez surveiller les journaux à l'aide des outils disponibles — par exemple, un outil tel que kubetail, ou simplement avec kubectl :
kubectl logs -n camunda-bpm-demo $(kubectl get pods -o=name -n camunda-bpm-demo) -f
Prochaines étapes
Autorisation
Cela concerne davantage la configuration de Camunda BPM que de Kubernetes, mais il est important de noter qu'authentification est désactivée par défaut dans l'API REST. Vous pouvez ou utiliser une autre méthode, comme . Vous pouvez utiliser des configmaps et des volumes pour charger des xml, ou xmlstarlet (voir ci-dessus) pour modifier des fichiers existants dans l'image, ainsi que soit utiliser wget ou les télécharger via un conteneur init et un volume partagé.
Gestion des sessions
Comme beaucoup d'autres applications, Camunda BPM gère les sessions dans la JVM, donc, si vous souhaitez exécuter plusieurs répliques, vous pouvez activer les sessions persistantes (), qui existeront jusqu'à ce que la réplique disparaisse, ou définir l'attribut Max-Age pour les cookies. Comme solution plus fiable, vous pouvez déployer un gestionnaire de session dans Tomcat. Lars a un à 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 '/^/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
Remarque: vous pouvez utiliser xmlstarlet à la place de sed
Nous avons utilisé avant Google Cloud Memorystore, avec (prend en charge Redis) pour le faire fonctionner.
Mise à l’échelle
Si vous êtes déjà familiarisé avec les sessions, la première (et souvent la dernière) limitation pour la scalabilité de Camunda BPM peut être la connexion à la base de données. Une configuration partielle est déjà disponible. Nous allons également désactiver intialSize dans le fichier settings.xml. Ajoutez et vous pourrez facilement scaler automatiquement le nombre de pods.
Demandes et limites
Dans platform/deployment.yaml vous verrez que nous avons codé en dur le champ des ressources. Cela fonctionne bien avec HPA, mais peut nécessiter une configuration supplémentaire. Un patch kustomize conviendra. Voir ingress-patch.yaml.tmpl et ./kustomization.yaml.tmpl
Sortie
Voilà, nous avons installé Camunda BPM sur Kubernetes avec des métriques Prometheus, des journaux, une base de données H2, TLS et Ingress. Nous avons ajouté des fichiers jar et des fichiers de configuration, en utilisant ConfigMaps et Dockerfile. Nous avons discuté de l'échange de données avec les volumes et directement dans les variables d'environnement à partir des secrets. De plus, nous avons fourni un aperçu de la configuration de Camunda pour plusieurs répliques et une API authentifiée.
Liens
github.com/camunda-cloud/camunda-examples/camunda-bpm-kubernetes
│
├── generated-manifest.yaml <- manifeste à utiliser sans kustomize
├── images
│ └── camunda-bpm
│ └── Dockerfile <- image docker de superposition
├── ingress-patch.yaml.tmpl <- configuration d'Ingress spécifique au site
├── kustomization.yaml.tmpl <- Kustomization principale
├── Makefile <- cibles de création
├── namespace.yaml
├── platform
│ ├── config
│ │ └── prometheus-jmx.yaml <- fichier de configuration de l'exportateur prometheus
│ ├── deployment.yaml <- déploiement principal
│ ├── ingress.yaml
│ ├── kustomization.yaml <- kustomization "de base"
│ ├── service-monitor.yaml <- exemple de configuration prometheus-operator
│ └── service.yaml
└── skaffold.yaml.tmpl <- directives skaffold
05.08.2020, traduction Alastair Firth, Lars Lange
Source : habr.com
