ARCHIVÉ

Ce projet n'est plus maintenu.

Vous êtes libre de continuer à l'utiliser et à l'adapter à vos besoins, y compris avec Elasticsearch 8.x.

Pour des expériences alternatives de démarrage, vous pouvez essayer l'une de ces options :

• Commencez un essai gratuit sur Elastic Cloud, notre service hébergé.
• Jetez un œil à Elastic Cloud sur Kubernetes (ECK) pour lancer la pile via Kubernetes.
• Lisez notre guide sur L'exécution de l'Elastic Stack sur Docker.
• Consultez le fournisseur Terraform pour Elastic Stack.

ansible-elasticsearch

CE RÔLE EST POUR 7.x ET 6.x, mais devrait également fonctionner avec 8.x (voir note).

Rôle Ansible pour Elasticsearch 7.x/6.x - tests utilisés pour fonctionner sur les plateformes ci-dessous :

• Ubuntu 16.04
• Ubuntu 18.04
• Ubuntu 20.04
• Debian 8
• Debian 9
• Debian 10
• CentOS 7
• Amazon Linux 2

MODIFICATIONS IMPORTANTES

Remarque concernant la prise en charge de plusieurs instances

• Si vous utilisez une seule instance mais souhaitez mettre à jour vers une ancienne version d'ansible-elasticsearch, suivez la procédure de mise à niveau.
• Si vous installez plus d'une instance d'Elasticsearch sur le même hôte (avec des ports, des répertoires et des fichiers de configuration différents), ne mettez pas à jour vers ansible-elasticsearch >= 7.1.1, veuillez suivre ce procédé alternatif à la place.
• Pour les cas d'utilisation à plusieurs instances, nous recommandons désormais l'utilisation de conteneurs Docker avec nos images officielles (https://www.elastic.co/guide/en/elasticsearch/reference/current/docker.html).

Suppression des paramètres MAX_THREAD

Ansible-elasticsearch 7.5.2 supprime l'option de personnaliser le nombre maximum de threads que le processus peut démarrer dans #637. Nous avons découvert que cette option ne fonctionnait plus depuis la suppression de la prise en charge de plusieurs instances dans ansible-elasticsearch 7.1.1. Cette option sera réintroduite dans une version suivante si elle est toujours pertinente par rapport aux évolutions récentes d'Elasticsearch.

Changements concernant les fichiers de configuration

Ansible-elasticsearch 7.5.2 met à jour les fichiers de configuration fournis par ce rôle dans #637 qui contenaient certaines options dépréciées dans 6.x et 7.x :

• /etc/default/elasticsearch|/etc/sysconfig/elasticsearch : le nouveau modèle reflète le fichier de configuration fourni par Elasticsearch >= 6.x, les paramètres que nous avons supprimés n'étaient déjà plus utilisés dans 6.x et 7.x.
• /etc/elasticsearch/jvm.options : le nouveau modèle reflète les fichiers de configuration fournis par Elasticsearch >= 6.x.
• /etc/elasticsearch/log4j2.properties :
  • Nous avons supprimé le modèle log4j2.properties.j2 de ce rôle Ansible car il s'agissait d'un fichier statique n'apportant aucune personnalisation spécifique à certaines variables ansible.
  • Le déploiement de ce rôle Ansible sur de nouveaux serveurs obtiendra le log4j2.properties par défaut fourni par Elasticsearch sans aucune substitution.
  • AVERTISSEMENT : Pour les scénarios de mise à niveau où ce fichier était déjà géré par des versions précédentes d'ansible-elasticsearch, ce fichier deviendra non géré et ne sera pas mis à jour par défaut. Si vous souhaitez le mettre à jour vers la version 7.5, vous pouvez le récupérer ici et utiliser ce fichier avec la variable Ansible es_config_log4j2 (voir ci-dessous).

Suppression de la distribution OSS pour les versions >= 7.11.0

À partir d'Elasticsearch 7.11.0, les distributions OSS ne seront plus fournies suite au récent changement de licence Elasticsearch.

Ce rôle Ansible échouera si oss_version est défini sur true et si es_version est supérieur à 7.11.0.

Consultez le post de blog Doubling down on open, Part II pour plus de détails.

Comment remplacer les fichiers de configuration fournis par ansible-elasticsearch ?

Vous pouvez désormais remplacer les fichiers de configuration par vos propres versions en utilisant les variables Ansible suivantes :

• es_config_default: "elasticsearch.j2" : remplacez elasticsearch.j2 par votre propre modèle pour utiliser un fichier de configuration personnalisé /etc/default/elasticsearch|/etc/sysconfig/elasticsearch.
• es_config_jvm: "jvm.options.j2" : remplacez jvm.options.j2 par votre propre modèle pour utiliser un fichier de configuration personnalisé /etc/elasticsearch/jvm.options.
• es_config_log4j2: "" : définissez cette variable sur le chemin de votre propre modèle pour utiliser un fichier de configuration personnalisé /etc/elasticsearch/log4j2.properties.

Dépendance

Ce rôle utilise le filtre json_query qui requiert jmespath sur la machine locale.

Utilisation

Créez votre playbook Ansible avec vos propres tâches et incluez le rôle elasticsearch. Vous devrez avoir ce référentiel accessible dans le contexte du playbook.

ansible-galaxy install elastic.elasticsearch,v7.17.0

Ensuite, créez votre yaml de playbook en ajoutant le rôle elasticsearch. L'application du rôle elasticsearch entraîne l'installation d'un nœud sur un hôte.

La configuration la plus simple consiste donc en :

- name: Exemple simple
  hosts: localhost
  roles:
    - role: elastic.elasticsearch
  vars:
    es_version: 7.17.0

Ce qui précède installe Elasticsearch 7.17.0 dans un seul nœud 'node1' sur les hôtes 'localhost'.

Remarque : La version par défaut d'Elasticsearch est décrite dans es_version. Vous pouvez remplacer cette variable dans votre playbook pour installer une autre version. Bien que nous testions ce rôle uniquement avec une version 7.x et une version 6.x (respectivement 7.17.0 et 6.8.23 au moment de l'écriture), ce rôle devrait également fonctionner avec d'autres versions dans la plupart des cas.

Ce rôle utilise également les tags Ansible. Exécutez votre playbook avec le flag --list-tasks pour plus d'informations.

Tests

Ce playbook utilise Kitchen pour l'intégration continue et les tests locaux.

Exigences

• Ruby
• Bundler
• Docker
• Make

Exécution des tests

• Assurez-vous d'avoir cloné ce référentiel sous elasticsearch, et non ansible-elasticsearch.
• Si vous n'avez pas de licence Gold ou Platinum à tester, vous pouvez exécuter les versions d'essai des suites xpack-upgrade en ajoutant -trial à la variable PATTERN.
• Vous devrez peut-être spécifier explicitement VERSION=7.x si certaines suites échouent.

Installez les dépendances ruby avec bundler

make setup

Si vous souhaitez tester les fonctionnalités X-Pack avec une licence, vous devrez d'abord exporter la variable ES_XPACK_LICENSE_FILE.

export ES_XPACK_LICENSE_FILE="$(pwd)/license.json"

Pour converger un hôte Ubuntu 16.04 exécutant X-Pack

$ make converge

Pour exécuter les tests

$ make verify

Pour lister toutes les différentes suites de tests

$ make list

La suite de tests par défaut est Ubuntu 16.04 avec X-Pack. Si vous souhaitez tester une autre suite, vous pouvez la remplacer avec la variable PATTERN

$ make converge PATTERN=security-centos-7

Le PATTERN est un motif de cuisine qui peut correspondre à plusieurs suites. Pour exécuter tous les tests pour CentOS

$ make converge PATTERN=centos-7

La version par défaut est 7.x. Si vous souhaitez tester 6.x, vous pouvez la remplacer avec la variable VERSION, par exemple :

$ make converge VERSION=6.x PATTERN=security-centos-7

Lorsque vous avez terminé les tests, vous pouvez nettoyer tout avec

$ make destroy-all

Configuration de base d'Elasticsearch

Tous les paramètres de configuration d'Elasticsearch sont pris en charge. Cela est réalisé en utilisant un paramètre de carte de configuration 'es_config' qui est sérialisé dans le fichier elasticsearch.yml. L'utilisation d'une carte garantit que le playbook Ansible n'a pas besoin d'être mis à jour pour refléter les nouveaux paramètres de configuration, dépréciés ou liés aux plugins.

En plus de la carte es_config, plusieurs autres paramètres sont pris en charge pour des fonctions supplémentaires, par exemple l'installation de scripts. Cela peut être trouvé dans le fichier defaults/main.yml du rôle.

Ce qui suit illustre l'application des paramètres de configuration à une instance Elasticsearch.

- name: Elasticsearch avec configuration personnalisée
  hosts: localhost
  roles:
    - role: elastic.elasticsearch
  vars:
    es_data_dirs:
      - "/opt/elasticsearch/data"
    es_log_dir: "/opt/elasticsearch/logs"
    es_config:
      node.name: "node1"
      cluster.name: "cluster-personnalisé"
      discovery.seed_hosts: "localhost:9301"
      http.port: 9201
      transport.port: 9301
      node.data: false
      node.master: true
      bootstrap.memory_lock: true
    es_heap_size: 1g
    es_api_port: 9201

Bien que le rôle installe Elasticsearch avec les paramètres de configuration par défaut, ce qui suit doit être configuré pour garantir qu'un cluster se forme avec succès :

• es_config['http.port'] - le port http pour le nœud
• es_config['transport.port'] - le port de transport pour le nœud
• es_config['discovery.seed_hosts'] - la liste de découverte unicast, au format séparé par des virgules "<host>:<port>,<host>:<port>" (typiquement les maîtres dédiés du cluster).
• es_config['cluster.initial_master_nodes'] - pour 7.x et au-dessus, la liste des nœuds éligibles au rôle de maître pour initialiser le cluster, au format séparé par des virgules "<node.name>:<port>,<node.name>:<port>" (typiquement les noms des nœuds des maîtres dédiés du cluster).
• es_config['network.host'] - définit à la fois network.bind_host et network.publish_host sur la même valeur d'hôte. Le paramètre network.bind_host permet de contrôler sur quel hôte différents composants réseau se connecteront.

Le paramètre network.publish_host permet de contrôler l'hôte que le nœud publiera dans le cluster, afin que d'autres nœuds puissent se connecter à lui.

Voir https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-network.html pour plus de détails sur le comportement de liaison par défaut et les options disponibles. Le rôle ne tente pas d'imposer le paramètre de ces valeurs et oblige les utilisateurs à les spécifier correctement. Il est recommandé que les nœuds maîtres soient listés et ainsi déployés en premier si possible.

Un exemple plus complexe :

- name: Elasticsearch avec configuration personnalisée
  hosts: localhost
  roles:
    - role: elastic.elasticsearch
  vars:
    es_data_dirs:
      - "/opt/elasticsearch/data"
    es_log_dir: "/opt/elasticsearch/logs"
    es_config:
      node.name: "node1"
      cluster.name: "cluster-personnalisé"
      discovery.seed_hosts: "localhost:9301"
      http.port: 9201
      transport.port: 9301
      node.data: false
      node.master: true
      bootstrap.memory_lock: true
    es_heap_size: 1g
    es_start_service: false
    es_api_port: 9201
    es_plugins:
      - plugin: ingest-attachment

Remarques importantes

Le rôle utilise es_api_host et es_api_port pour communiquer avec le nœud pour des actions uniquement réalisables via http, par exemple, pour installer des modèles et vérifier si le NŒUD EST ACTIF. Ces valeurs par défaut sont "localhost" et 9200 respectivement. Si le nœud doit être lié à un hôte ou à un port différent, ceux-ci doivent être modifiés.

N'utilisez que es_data_dirs et es_log_dir pour personnaliser respectivement les répertoires de données et de journaux. L'utilisation conjointe de es_config['path.data'] et es_config['path.logs'] entraînerait la création de clés de données et de journaux en double dans elasticsearch.yml, ce qui empêcherait le démarrage d'Elasticsearch.

Installations de serveur à plusieurs nœuds

L'application du rôle elasticsearch entraîne l'installation d'un nœud sur un hôte. La spécification du rôle plusieurs fois pour un hôte entraîne donc l'installation de plusieurs nœuds pour cet hôte.

Un exemple de déploiement de trois serveurs est montré ci-dessous. Le premier serveur détient le maître et est donc déclaré en premier. Bien que cela ne soit pas obligatoire, c'est recommandé dans toute configuration de cluster à plusieurs nœuds. Les deux autres serveurs hébergent des nœuds de données.

Notez que nous ne supportons plus l'installation de plus d'un nœud sur le même hôte.

- hosts: master_node
  roles:
    - role: elastic.elasticsearch
  vars:
    es_heap_size: "1g"
    es_config:
      cluster.name: "test-cluster"
      cluster.initial_master_nodes: "elastic02"
      discovery.seed_hosts: "elastic02:9300"
      http.host: 0.0.0.0
      http.port: 9200
      node.data: false
      node.master: true
      transport.host: 0.0.0.0
      transport.port: 9300
      bootstrap.memory_lock: false
    es_plugins:
     - plugin: ingest-attachment

- hosts: data_node_1
  roles:
    - role: elastic.elasticsearch
  vars:
    es_data_dirs:
      - "/opt/elasticsearch"
    es_config:
      cluster.name: "test-cluster"
      cluster.initial_master_nodes: "elastic02"
      discovery.seed_hosts: "elastic02:9300"
      http.host: 0.0.0.0
      http.port: 9200
      node.data: true
      node.master: false
      transport.host: 0.0.0.0
      transport.port: 9300
      bootstrap.memory_lock: false
    es_plugins:
      - plugin: ingest-attachment

- hosts: data_node_2
  roles:
    - role: elastic.elasticsearch
  vars:
    es_config:
      cluster.name: "test-cluster"
      discovery.seed_hosts: "elastic02:9300"
      http.host: 0.0.0.0
      http.port: 9200
      node.data: true
      node.master: false
      transport.host: 0.0.0.0
      transport.port: 9300
      bootstrap.memory_lock: false
    es_plugins:
      - plugin: ingest-attachment

Les paramètres peuvent également être attribués aux hôtes à l'aide du fichier d'inventaire si souhaité.

Assurez-vous que vos hôtes sont définis dans votre fichier inventory avec les valeurs appropriées ansible_ssh_host, ansible_ssh_user et ansible_ssh_private_key_file.

Puis exécutez-le :

ansible-playbook -i hosts ./your-playbook.yml

Installation des fonctionnalités X-Pack

• es_role_mapping Fichier de mappage des rôles déclaré en yml comme décrit ici

es_role_mapping:
  power_user:
    - "cn=admins,dc=example,dc=com"
  user:
    - "cn=users,dc=example,dc=com"
    - "cn=admins,dc=example,dc=com"

• es_users - Les utilisateurs peuvent être déclarés ici en yml. Deux sous-clés 'native' et 'file' déterminent le royaume sous lequel l'utilisateur est créé. Sous chacune de ces clés, les utilisateurs doivent être déclarés comme des entrées yml. par exemple.

es_users:
  native:
    kibana4_server:
      password: changeMe
      roles:
        - kibana4_server
  file:
    es_admin:
      password: changeMe
      roles:
        - admin
    testUser:
      password: changeMeAlso!
      roles:
        - power_user
        - user

• es_roles - Les rôles Elasticsearch peuvent être déclarés ici en yml. Deux sous-clés 'native' et 'file' déterminent comment le rôle est créé, c'est-à-dire soit par le biais d'un fichier, soit d'un appel http (native). Sous chaque clé, listez les rôles avec les autorisations appropriées, en utilisant le format basé sur le fichier décrit ici par exemple.

es_roles:
  file:
    admin:
      cluster:
        - all
      indices:
        - names: '*'
          privileges:
            - all
    power_user:
      cluster:
        - monitor
      indices:
        - names: '*'
          privileges:
            - all
    user:
      indices:
        - names: '*'
          privileges:
            - read
    kibana4_server:
      cluster:
          - monitor
      indices:
        - names: '.kibana'
          privileges:
            - all
  native:
    logstash:
      cluster:
        - manage_index_templates
      indices:
        - names: 'logstash-*'
          privileges:
            - write
            - delete
            - create_index

• es_xpack_license - Licence X-Pack. La licence est un blob JSON. Définissez la variable directement (possiblement protégée par Ansible vault) ou à partir d'un fichier dans le projet Ansible sur la machine de contrôle via une recherche :

es_xpack_license: "{{ lookup('file', playbook_dir + '/files/' + es_cluster_name + '/license.json') }}"

Si vous n'avez pas de licence, vous pouvez activer l'essai de 30 jours en définissant es_xpack_trial sur true.

Les paramètres de configuration X-Pack peuvent être ajoutés au fichier elasticsearch.yml en utilisant le paramètre normal es_config.

Pour un exemple complet, voir ici.

Remarque importante pour la configuration du royaume natif

Pour que les utilisateurs et les rôles natifs soient configurés, le rôle appelle l'API Elasticsearch. Étant donné que la sécurité est installée, cela nécessite la définition de deux paramètres :

• es_api_basic_auth_username - nom d'utilisateur admin
• es_api_basic_auth_password - mot de passe admin

Ceci peut être défini soit sur un utilisateur déclaré dans le domaine basé sur le fichier, avec des autorisations administratives, soit sur le superutilisateur par défaut "elastic" (mot de passe par défaut est changeme).

SSL/TLS de sécurité X-Pack

• Pour configurer votre cluster avec SSL/TLS pour les communications HTTP et/ou de transport, suivez la procédure de configuration SSL/TLS.

Configuration supplémentaire

En plus de es_config, les paramètres suivants permettent de personnaliser les versions de Java et d'Elasticsearch ainsi que le comportement du rôle. Les options incluent :

• oss_version Par défaut false. En le définissant sur true, vous installerez la version oss d'Elasticsearch (pour les versions <7.11.0 uniquement).

• es_xpack_trial Par défaut false. En le définissant sur true, vous démarrerez l'essai de 30 jours une fois le cluster démarré.

• es_version (par exemple, "7.17.0").

• es_api_host Le nom d'hôte utilisé pour les actions nécessitant HTTP, par exemple, l'installation de modèles. Par défaut, "localhost".

• es_api_port Le port utilisé pour les actions nécessitant HTTP, par exemple, l'installation de modèles. Par défaut, 9200. CHANGEZ S'il LE PORT HTTP N'EST PAS 9200

• es_api_basic_auth_username Le nom d'utilisateur Elasticsearch pour effectuer des actions administratives. Utilisé si la sécurité est activée. Assurez-vous que cet utilisateur est administrateur.

• es_api_basic_auth_password Le mot de passe associé à l'utilisateur déclaré dans es_api_basic_auth_username.

• es_delete_unmanaged_file Par défaut true. Défini sur false pour garder les utilisateurs du domaine de fichiers ajoutés en dehors d'ansible.

• es_delete_unmanaged_native Par défaut true. Défini sur false pour garder les utilisateurs du royaume natif ajoutés en dehors d'ansible.

• es_start_service (true (par défaut) ou false)

• es_plugins_reinstall (true ou false (par défaut))

• es_plugins un tableau de définitions de plugins, par exemple :

    es_plugins:
      - plugin: ingest-attachment
  

• es_path_repo Définit la liste blanche pour permettre des dépôts de sauvegarde locaux.

• es_action_auto_create_index Définit la valeur pour la création automatique d'index, utilisez la syntaxe ci-dessous pour spécifier des index (sinon vrai/faux) : es_action_auto_create_index: '[".watches", ".triggered_watches", ".watcher-history-*"]'

• es_allow_downgrades Pour des fins de développement uniquement. (true ou false (par défaut))

• es_java_install Si défini sur true, Java sera installé. (false (par défaut pour 7.x) ou true (par défaut pour 6.x))

• update_java Met à jour Java vers la dernière version. (true ou false (par défaut))

• es_max_map_count nombre maximum d'AMV (zones de mémoire virtuelle) qu'un processus peut posséder. Par défaut, 262144.

• es_max_open_files le nombre maximum de descripteurs de fichiers pouvant être ouverts par ce processus. Par défaut, 65536.

• es_debian_startup_timeout combien de temps les scripts SysV init de la famille Debian attendent que le service démarre, en secondes. Par défaut, 10 secondes.

• es_use_repository En définissant cela sur false, vous empêchez Ansible d'utiliser le package officiel Elastic de tout dépôt configuré sur le système.

• es_add_repository En définissant cela sur false, vous empêchez Ansible d'ajouter les dépôts de packages Elastic officiels (si es_use_repository est vrai) si vous souhaitez utiliser un dépôt déjà présent.

• es_custom_package_url l'URL du package rpm ou deb à installer par Ansible. Lorsque vous utilisez ceci, vous devrez également définir es_use_repository: false et vous assurer que es_version correspond à la version installée depuis votre URL personnalisée. Exemple : es_custom_package_url: https://downloads.example.com/elasticsearch.rpm.

Les exemples antérieurs illustrent l'installation de plugins à l'aide de es_plugins. Pour les plugins officiellement pris en charge, aucune version ou délimiteur de source n'est requis. Le script du plugin déterminera la version appropriée du plugin en fonction de la version cible d'Elasticsearch. Pour les plugins communautaires, incluez l'URL complète. Cette approche ne doit PAS être utilisée pour le plugin X-Pack. Voir ci-dessous pour des détails ici.

Si vous installez le Monitoring ou l'Alerte, assurez-vous que le plugin de licence est également spécifié. La configuration de la sécurité a actuellement un support limité, mais un support supplémentaire est prévu pour les versions ultérieures.

Pour configurer X-pack pour envoyer des mails, la configuration suivante peut être ajoutée au rôle. Lorsque require_auth est vrai, vous devrez également fournir l'utilisateur et le mot de passe. Sinon, ces informations peuvent être supprimées :

    es_mail_config:
        account: <nom fonctionnel>
        profile: standard
        from: <adresse d'envoi>
        require_auth: <true ou false>
        host: <domaine de messagerie>
        port: <numéro de port>
        user: <adresse e-mail> --optionnel
        pass: <mot de passe> --optionnel

• es_user - par défaut à elasticsearch.
• es_group - par défaut à elasticsearch.
• es_user_id - par défaut indéfini.
• es_group_id - par défaut indéfini.

Les deux es_user_id et es_group_id doivent être définis pour que les identifiants des utilisateurs et des groupes soient définis.

• es_restart_on_change - par défaut à true. Si false, les changements n'entraîneront pas le redémarrage d'Elasticsearch.
• es_plugins_reinstall - par défaut à false. Si true, tous les plugins actuellement installés seront retirés d'un nœud. Les plugins listés seront alors réinstallés.

Pour ajouter, mettre à jour ou supprimer des entrées dans elasticsearch.keystore, utilisez la variable suivante :

# l'état est optionnel et par défaut à présent
es_keystore_entries:
- key: someKeyToAdd
  value: someValue
  state: present

- key: someKeyToUpdate
  value: newValue
  # state: present
  force: Yes

- key: someKeyToDelete
  state: absent

Ce rôle est livré avec des modèles d'exemple situés dans le test/integration/files/templates-7.x. La variable es_templates_fileglob est utilisée avec la boucle with_fileglob d'Ansible. Lors de la définition des globes, assurez-vous d'utiliser un chemin absolu.

Proxy

Pour définir un proxy globalement, définissez les variables suivantes :

• es_proxy_host - hôte proxy global
• es_proxy_port - port proxy global

Remarques

• Le rôle suppose que l'utilisateur/groupe existe sur le serveur. Les paquets elasticsearch créent l'utilisateur elasticsearch par défaut. Si cela doit être changé, assurez-vous que l'utilisateur existe.
• Le playbook repose sur le nom d'inventaire de chaque hôte pour garantir que ses répertoires sont uniques.
• KitchenCI a été utilisé pour les tests. Cela permet de confirmer que les images atteignent le bon état après qu'un play a été appliqué pour la première fois. Nous testons actuellement la dernière version de 7.x et 6.x sur toutes les plateformes supportées.
• Le rôle vise à être idempotent. Exécuter le rôle plusieurs fois, sans modifications, ne devrait pas entraîner de changement d'état sur le serveur. Si la configuration est modifiée, celles-ci seront appliquées et Elasticsearch sera redémarré si nécessaire.
• Pour exécuter des tests x-pack, un fichier de licence avec la sécurité activée est requis. Définissez la variable d'environnement ES_XPACK_LICENSE_FILE sur le chemin complet du fichier de licence avant d'exécuter les tests. Une licence d'essai est appropriée et peut être utilisée en définissant es_xpack_trial sur true.

NOTES IMPORTANTES ÉCONOMISANT GESTION DE PLUGIN

• Si la version ES est modifiée, tous les plugins seront supprimés. Ceux listés dans le playbook seront réinstallés. Ce comportement est requis dans ES 6.x.
• Si aucun plugin n'est listé dans le playbook pour un nœud, tous les plugins actuellement installés seront supprimés.
• Le rôle prend en charge la détection automatique des différences entre les plugins installés et listés - installant ceux listés mais non installés, et supprimant ceux installés mais non listés. Si les utilisateurs souhaitent réinstaller des plugins, ils doivent définir es_plugins_reinstall sur true. Cela entraînera la suppression de tous les plugins actuellement installés et l'installation de ceux listés.

Questions sur l'utilisation

Nous accueillons les questions sur la façon d'utiliser le rôle. Cependant, afin de garder la liste des problèmes GitHub axée sur les "problèmes", nous demandons à la communauté de poser des questions sur https://discuss.elastic.co/c/elasticsearch. Cela est surveillé par les mainteneurs.