Elasticsearch fait partie des logiciels open source incontournables. Les cas d’usage sont variés, du fait de sa capacité de stockage, de recherche et d’analyse des données. Il est apprécié par les développeurs pour la richesse de son API RESTful avec une prise en main assez rapide, mais également pour l’implémentation de la bibliothèque client dans plusieurs langages. Coté Ops, Elasticsearch fait partie des systèmes distribués les moins pénibles lors de la gestion de la scalabilité, de la sauvegarde et de la restitution de données.
Mais ce qui fait le succès d'Elasticsearch, c’est son écosystème riche et les outils gravitant tout autour. Kibana et Grafana, utilisés pour la représentation des données et la création des dashboards. Logstash, Filebeat et Fluentd sont performants dans l’ingestion de données, Cerebro (ex Kopf) pour une gestion graphique du cluster, Curator pour l’automatisation des opérations de maintenance.
Alors comment peut-on utiliser Elasticsearch dans un environnement de conteneurs et Cloud Native ?
Elasticsearch et Kubernetes
Dès l'apparition de la problématique de collecte de logs, la stack EFK est choisie comme la solution open source de référence pour la gestion des logs avec l’orchestrateur Kubernetes. La collecte des logs des différents conteneurs se fait par la couche Fluentd, puis acheminés vers Elasticsearch pour le stockage. La lecture et l’analyse s’effectuent grâce à la couche de représentation Kibana. C’est ainsi que la tentation d’exploiter le cluster Elasticsearch sous Kubernetes devient évidente.
Bien que la conteneurisation d’un nœud Elasticsearch avec Docker soit documentée depuis la version 5.0, toute la difficulté se situe dans la gestion du cycle de vie de l'ensemble d'un cluster, et notamment la gestion de données. Si Kubernetes est parfaitement mature sur l’orchestration et l’automatisation de cycle de vie des applications complexes, la persistance de données reste complexe à gérer, car les solutions de gestions de stockage et de persistance de données sur Kubernetes sont encore récentes et en amélioration constante.
Nous allons examiner ci-dessous les plus remarquables tentatives pour maîtriser Elasticsearch dans une infrastructure Cloud Native.
Le labyrinthe des chartes Helm
Pour déployer des applications complexes sous Kubernetes, le processus le plus couramment employé est la mise en place de charte Helm. Sans implémentation ou documentation officielle de la part d’Elastic.io (l’entreprise qui produit Elasticsearch), plusieurs implémentations sont apparues :
- Chartes communautaires
La charte communautaire est passée par plusieurs moments de flous (exemple 1, exemple 2), mais a réussi après quelques efforts à passer du statut «incubateur» à «stable», grâce au travail remarquable des volontaires, notamment en appliquant dans la mesure du possible, les bonnes pratiques de mise en place de charte Helm.
- Charte aboutie
D’autres efforts, ceux du Center For Open Science par exemple, se sont inspirés du travail communautaire et se sont consacrés dès le départ à mieux gérer la persistance des données avec la mise en place de «provisioning» dynamique des volumes persistants et la découverte des Masters. L’utilisation des «Statefulset» était un choix évident pour la gestion des masters du cluster Elasticsearch.
- Chartes officielles
Par charte «officielle» d’une application, l’écosystème Helm désigne la charte stable «résidant» dans le repo officiel de Helm.
Mais peu de temps après la promotion de la charte communautaire en stable, Elastic.io révèle sa propre charte officielle. Cela dit, Elastic prévient que le code n’est pas prêt pour une mise en production (la lecture de l’extrait ci-dessous nous montre un 3ᵉ sens du mot «officiel»: la version d’Elasticsearch utilisée …)
Conclusion
Elasticsearch est utilisé pour différents cas d’usage. Cela se reflète dans la différence des chartes Helm conçues par les différentes communautés. Plus encore, la naissance des opérateurs et l’extension de l’API Kubernetes avec les CRD ne laissent pas ceux qui n’ont pas trouvé leur bonheur avec les chartes Helm les bras croisés. D’autres tentatives pour perfectionner le cycle de vie du cluster Elasticsearch sur Kubernetes ont vu le jour. Nous allons continuer la quête, en découvrant dans la partie 2 comment ces nouvelles techniques ont contribué à l’amélioration du processus.