Installer Elasticsearch avec Docker

Pour supprimer les conteneurs et leur réseau, exécutez :

Vous disposez désormais d’un environnement de test Elasticsearch configuré. Avant de vous lancer dans un développement sérieux ou de passer en production avec Elasticsearch, passez en revue les exigences et les recommandations à appliquer lors de l’exécution d’Elasticsearch dans Docker en production.

Pour arrêter le cluster, exécutez docker-compose down. Les données des volumes Docker sont conservées et chargées lorsque vous redémarrez le cluster avec docker-compose up.

docker-compose down

Pour supprimer le réseau, les conteneurs et les volumes lorsque vous arrêtez le cluster, spécifiez l’ -voption :

docker-compose down -v

Vous disposez désormais d’un environnement de test Elasticsearch configuré. Avant de vous lancer dans un développement sérieux ou de passer en production avec Elasticsearch, passez en revue les exigences et les recommandations à appliquer lors de l’exécution d’Elasticsearch dans Docker en production.

Le vm.max_map_countparamètre du noyau doit être défini au moins 262144pour une utilisation en production.

La manière dont vous définissez vm.max_map_countdépend de votre plate-forme.

grep vm.max_map_count /etc/sysctl.conf
vm.max_map_count=262144

sysctl -w vm.max_map_count=262144

docker-machine ssh
sudo sysctl -w vm.max_map_count=262144

wsl -d docker-desktop -u root
sysctl -w vm.max_map_count=262144

[wsl2]
kernelCommandLine = "sysctl.vm.max_map_count=262144"

wsl -d docker-desktop -u root
vi /etc/sysctl.conf

vm.max_map_count = 262144

Par défaut, Elasticsearch s’exécute dans le conteneur en tant qu’utilisateur elasticsearchutilisant uid:gid 1000:0.

Si vous montez en liaison un répertoire ou un fichier local, il doit être lisible par l’ elasticsearchutilisateur. De plus, cet utilisateur doit avoir un accès en écriture aux répertoires de configuration, de données et de journal (Elasticsearch a besoin d’un accès en écriture au configrépertoire pour pouvoir générer un magasin de clés). Une bonne stratégie consiste à accorder un accès de groupe au gid 0pour le répertoire local.

Par exemple, pour préparer un répertoire local pour stocker des données via un montage lié :

mkdir esdatadir
chmod g+rwx esdatadir
chgrp 0 esdatadir

Vous pouvez également exécuter un conteneur Elasticsearch en utilisant à la fois un UID et un GID personnalisés. Vous devez vous assurer que les autorisations de fichiers n’empêcheront pas l’exécution d’Elasticsearch. Vous pouvez utiliser l’une des deux options suivantes :

Des ulimits augmentés pour nofile et nproc doivent être disponibles pour les conteneurs Elasticsearch. Vérifiez que le système d’initialisation du démon Docker les définit sur des valeurs acceptables.

Pour vérifier les valeurs par défaut du démon Docker pour ulimits, exécutez :

docker run --rm docker.elastic.co/elasticsearch/elasticsearch:8.13.4 /bin/bash -c 'ulimit -Hn && ulimit -Sn && ulimit -Hu && ulimit -Su'

Si nécessaire, ajustez-les dans le démon ou remplacez-les par conteneur. Par exemple, lorsque vous utilisez docker run, définissez :

--ulimit nofile=65535:65535

L’échange doit être désactivé pour des raisons de performances et de stabilité des nœuds. Pour plus d’informations sur les façons de procéder, voir Désactiver l’échange .

Si vous optez pour cette bootstrap.memory_lock: trueapproche, vous devez également définir le memlock: trueulimit dans le Docker Daemon , ou le définir explicitement pour le conteneur, comme indiqué dans l’ exemple de fichier de composition . Lorsque vous utilisez docker run, vous pouvez spécifier :

-e "bootstrap.memory_lock=true" --ulimit memlock=-1:-1

L’image expose les ports TCP 9200 et 9300. Pour les clusters de production, --publish-allil est recommandé de randomiser les ports publiés, sauf si vous épinglez un conteneur par hôte.

Par défaut, Elasticsearch dimensionne automatiquement le tas JVM en fonction des rôles des nœuds et de la mémoire totale disponible pour le conteneur du nœud. Nous recommandons ce dimensionnement par défaut pour la plupart des environnements de production. Si nécessaire, vous pouvez remplacer le dimensionnement par défaut en définissant manuellement la taille du segment JVM.

Pour définir manuellement la taille du tas en production, montez sous une liaison un fichier d’options JVM qui inclut les paramètres de taille de tas/usr/share/elasticsearch/config/jvm.options.d souhaités .

Pour les tests, vous pouvez également définir manuellement la taille du tas à l’aide de la ES_JAVA_OPTS variable d’environnement. Par exemple, pour utiliser 1 Go, utilisez la commande suivante.

docker run -e ES_JAVA_OPTS="-Xms1g -Xmx1g" -e ENROLLMENT_TOKEN="<token>" --name es01 -p 9200:9200 --net elastic -it docker.elastic.co/elasticsearch/elasticsearch:8.13.4

La ES_JAVA_OPTSvariable remplace toutes les autres options JVM. Nous déconseillons son utilisation ES_JAVA_OPTSen production.

Épinglez vos déploiements à une version spécifique de l’image Docker d’Elasticsearch. Par exemple docker.elastic.co/elasticsearch/elasticsearch:8.13.4.

Vous devez utiliser un volume relié /usr/share/elasticsearch/datapour les raisons suivantes :

Si vous utilisez le pilote de stockage Devicemapper, n’utilisez pas le loop-lvmmode par défaut. Configurez docker-engine pour utiliser direct-lvm .

Pensez à centraliser vos journaux en utilisant un autre pilote de journalisation . Notez également que le pilote de journalisation de fichiers JSON par défaut n’est pas idéal pour une utilisation en production.

Créez des fichiers de configuration personnalisés et montez-les en liaison sur les fichiers correspondants dans l’image Docker. Par exemple, pour effectuer un montage en liaison custom_elasticsearch.ymlavec docker run, spécifiez :

-v full_path_to/custom_elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml

Si vous montez en liaison un elasticsearch.ymlfichier personnalisé, assurez-vous qu’il inclut le network.host: 0.0.0.0paramètre. Ce paramètre garantit que le nœud est accessible pour le trafic HTTP et de transport, à condition que ses ports soient exposés. Le fichier intégré de l’image Docker elasticsearch.ymlinclut ce paramètre par défaut.

Par défaut, Elasticsearch générera automatiquement un fichier de clés pour les paramètres sécurisés . Ce fichier est masqué mais non chiffré.

Pour chiffrer vos paramètres sécurisés avec un mot de passe et les conserver en dehors du conteneur, utilisez docker runplutôt une commande pour créer manuellement le magasin de clés. La commande doit :

Par exemple:

docker run -it --rm \
-v full_path_to/config:/usr/share/elasticsearch/config \
docker.elastic.co/elasticsearch/elasticsearch:8.13.4 \
bin/elasticsearch-keystore create -p

Vous pouvez également utiliser une docker runcommande pour ajouter ou mettre à jour des paramètres sécurisés dans le magasin de clés. Vous serez invité à saisir les valeurs de réglage. Si le magasin de clés est chiffré, vous serez également invité à saisir le mot de passe du magasin de clés.

docker run -it --rm \
-v full_path_to/config:/usr/share/elasticsearch/config \
docker.elastic.co/elasticsearch/elasticsearch:8.13.4 \
bin/elasticsearch-keystore \
add my.secure.setting \
my.other.secure.setting

Si vous avez déjà créé le magasin de clés et que vous n’avez pas besoin de le mettre à jour, vous pouvez directement monter le elasticsearch.keystorefichier en liaison. Vous pouvez utiliser la KEYSTORE_PASSWORDvariable d’environnement pour fournir le mot de passe du magasin de clés au conteneur au démarrage. Par exemple, une docker runcommande peut avoir les options suivantes :

-v full_path_to/config/elasticsearch.keystore:/usr/share/elasticsearch/config/elasticsearch.keystore
-e KEYSTORE_PASSWORD=mypassword

Dans certains environnements, il peut être plus judicieux de préparer une image personnalisée contenant votre configuration. Pour Dockerfiley parvenir, cela pourrait être aussi simple que :

FROM docker.elastic.co/elasticsearch/elasticsearch:8.13.4
COPY --chown=elasticsearch:elasticsearch elasticsearch.yml /usr/share/elasticsearch/config/

Vous pouvez ensuite créer et exécuter l’image avec :

docker build -- tag = elasticsearch - custom . 
docker run - ti - v / usr / share / elasticsearch / data elasticsearch - personnalisé

Certains plugins nécessitent des autorisations de sécurité supplémentaires. Vous devez les accepter explicitement soit en :

Résoudre les erreurs Docker pour Elasticsearch

Voici comment résoudre les erreurs courantes lors de l’exécution d’Elasticsearch avec Docker.

Exception in thread "main" org.elasticsearch.bootstrap.BootstrapException: java.io.IOException: Is a directory: SimpleFSIndexInput(path="/usr/share/elasticsearch/config/elasticsearch.keystore") Likely root cause: java.io.IOException: Is a directory

Une commande liée au magasin de clés docker run a tenté de monter directement en liaison un elasticsearch.keystorefichier qui n’existe pas. Si vous utilisez l’ indicateur -vou --volumepour monter un fichier qui n’existe pas, Docker crée à la place un répertoire avec le même nom.

Pour résoudre cette erreur :

Exception in thread "main" java.nio.file.FileSystemException: /usr/share/elasticsearch/config/elasticsearch.keystore.tmp -> /usr/share/elasticsearch/config/elasticsearch.keystore: Device or resource busy

Une docker runcommande a tenté de mettre à jour le magasin de clés tout en montant directement le elasticsearch.keystorefichier en liaison. Pour mettre à jour le magasin de clés, le conteneur doit accéder à d’autres fichiers du configrépertoire, tels que keystore.tmp.

Pour résoudre cette erreur :