Code Monkey home page Code Monkey logo

ansible-elasticsearch's Introduction

ARCHIVED

This project is no longer maintained.

You are welcomed to keep using it and adapting it to work for your own needs, including with Elasticsearch 8.x.

For alternative getting started experiences, you may want to try one of these options:

ansible-elasticsearch

Ansible Galaxy

THIS ROLE IS FOR 7.x & 6.x, but should still work with 8.x (see note).

Ansible role for 7.x/6.x Elasticsearch - tests used to run and pass on the below platforms:

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

BREAKING CHANGES

Notice about multi-instance support

  • If you use only one instance but want to upgrade from an older ansible-elasticsearch version, follow upgrade procedure
  • If you install more than one instance of Elasticsearch on the same host (with different ports, directory and config files), do not update to ansible-elasticsearch >= 7.1.1, please follow this workaround instead.
  • For multi-instances use cases, we are now recommending Docker containers using our official images (https://www.elastic.co/guide/en/elasticsearch/reference/current/docker.html).

Removing the MAX_THREAD settings

Ansible-elasticsearch 7.5.2 is removing the option to customize the maximum number of threads the process can start in #637. We discovered that this option wasn't working anymore since multi-instance support removal in ansible-elasticsearch 7.1.1. This option will be added back in a following release if it's still relevant regarding latest Elasticsearch evolutions.

Changes about configuration files

Ansible-elasticsearch 7.5.2 is updating the configuration files provided by this role in #637 which contained some options deprecated in 6.x and 7.x:

  • /etc/default/elasticsearch|/etc/sysconfig/elasticsearch: the new template reflect the configuration file provided by Elasticsearch >= 6.x, the parameters we removed were already not used in 6.x and 7.x
  • /etc/elasticsearch/jvm.options: the new template reflect the configuration files provided by Elasticsearch >= 6.x
  • /etc/elasticsearch/log4j2.properties:
    • We removed log4j2.properties.j2 template from this Ansible role as it was a static file not bringing any customization specific to some ansible variable.
    • Deployment of this Ansible role on new servers will get the default log4j2.properties provided by Elasticsearch without any override.
    • WARNING: For upgrade scenarios where this file was already managed by previous versions of ansible-elasticsearch, this file will become unmanaged and won't be updated by default. If you wish to update it to 7.5 version, you can retrieve it here and use this file with es_config_log4j2 Ansible variable (see below).

Removing OSS distribution for versions >= 7.11.0

Starting from Elasticsearch 7.11.0, OSS distributions will no longer be provided following the recent Elasticsearch license change.

This Ansible role will fail if oss_version is set to true and es_version is greater than 7.11.0.

See Doubling down on open, Part II blog post for more details.

How to override configuration files provided by ansible-elasticsearch?

You can now override the configuration files with your own versions by using the following Ansible variables:

  • es_config_default: "elasticsearch.j2": replace elasticsearch.j2 by your own template to use a custom /etc/default/elasticsearch|/etc/sysconfig/elasticsearch configuration file
  • es_config_jvm: "jvm.options.j2": replace jvm.options.j2 by your own template to use a custom /etc/elasticsearch/jvm.options configuration file
  • es_config_log4j2: "": set this variable to the path of your own template to use a custom /etc/elasticsearch/log4j2.properties configuration file

Dependency

This role uses the json_query filter which requires jmespath on the local machine.

Usage

Create your Ansible playbook with your own tasks, and include the role elasticsearch. You will have to have this repository accessible within the context of playbook.

ansible-galaxy install elastic.elasticsearch,v7.17.0

Then create your playbook yaml adding the role elasticsearch. The application of the elasticsearch role results in the installation of a node on a host.

The simplest configuration therefore consists of:

- name: Simple Example
  hosts: localhost
  roles:
    - role: elastic.elasticsearch
  vars:
    es_version: 7.17.0

The above installs Elasticsearch 7.17.0 in a single node 'node1' on the hosts 'localhost'.

Note: Elasticsearch default version is described in es_version. You can override this variable in your playbook to install another version. While we are testing this role only with one 7.x and one 6.x version (respectively 7.17.0 and 6.8.23 at the time of writing), this role should work with other versions also in most cases.

This role also uses Ansible tags. Run your playbook with the --list-tasks flag for more information.

Testing

This playbook uses Kitchen for CI and local testing.

Requirements

  • Ruby
  • Bundler
  • Docker
  • Make

Running the tests

  • Ensure you have checked out this repository to elasticsearch, not ansible-elasticsearch.
  • If you don't have a Gold or Platinum license to test with you can run the trial versions of the xpack-upgrade suites by appending -trial to the PATTERN variable.
  • You may need to explicitly specify VERSION=7.x if some suites are failing.

Install the ruby dependencies with bundler

make setup

If you want to test X-Pack features with a license you will first need to export the ES_XPACK_LICENSE_FILE variable.

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

To converge an Ubuntu 16.04 host running X-Pack

$ make converge

To run the tests

$ make verify

To list all of the different test suits

$ make list

The default test suite is Ubuntu 16.04 with X-Pack. If you want to test another suite you can override this with the PATTERN variable

$ make converge PATTERN=security-centos-7

The PATTERN is a kitchen pattern which can match multiple suites. To run all tests for CentOS

$ make converge PATTERN=centos-7

The default version is 7.x. If you want to test 6.x you can override it with the VERSION variable, for example:

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

When you are finished testing you can clean up everything with

$ make destroy-all

Basic Elasticsearch Configuration

All Elasticsearch configuration parameters are supported. This is achieved using a configuration map parameter 'es_config' which is serialized into the elasticsearch.yml file. The use of a map ensures the Ansible playbook does not need to be updated to reflect new/deprecated/plugin configuration parameters.

In addition to the es_config map, several other parameters are supported for additional functions e.g. script installation. These can be found in the role's defaults/main.yml file.

The following illustrates applying configuration parameters to an Elasticsearch instance.

- name: Elasticsearch with custom configuration
  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: "custom-cluster"
      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

Whilst the role installs Elasticsearch with the default configuration parameters, the following should be configured to ensure a cluster successfully forms:

  • es_config['http.port'] - the http port for the node
  • es_config['transport.port'] - the transport port for the node
  • es_config['discovery.seed_hosts'] - the unicast discovery list, in the comma separated format "<host>:<port>,<host>:<port>" (typically the clusters dedicated masters)
  • es_config['cluster.initial_master_nodes'] - for 7.x and above the list of master-eligible nodes to boostrap the cluster, in the comma separated format "<node.name>:<port>,<node.name>:<port>" (typically the node names of the clusters dedicated masters)
  • es_config['network.host'] - sets both network.bind_host and network.publish_host to the same host value. The network.bind_host setting allows to control the host different network components will bind on.

The network.publish_host setting allows to control the host the node will publish itself within the cluster so other nodes will be able to connect to it.

See https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-network.html for further details on default binding behavior and available options. The role makes no attempt to enforce the setting of these are requires users to specify them appropriately. It is recommended master nodes are listed and thus deployed first where possible.

A more complex example:

- name: Elasticsearch with custom configuration
  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: "custom-cluster"
      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

Important Notes

The role uses es_api_host and es_api_port to communicate with the node for actions only achievable via http e.g. to install templates and to check the NODE IS ACTIVE. These default to "localhost" and 9200 respectively. If the node is deployed to bind on either a different host or port, these must be changed.

Only use es_data_dirs and es_log_dir for customizing the data and log dirs respectively. When using together with es_config['path.data'] and es_config['path.logs'] it would result in generating duplicate data- and logs-keys in elasticsearch.yml and thus let fail to start elasticsearch.

Multi Node Server Installations

The application of the elasticsearch role results in the installation of a node on a host. Specifying the role multiple times for a host therefore results in the installation of multiple nodes for the host.

An example of a three server deployment is shown below. The first server holds the master and is thus declared first. Whilst not mandatory, this is recommended in any multi node cluster configuration. The two others servers hosts data nodes.

Note that we do not support anymore installation of more than one node in the same host

- 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

Parameters can additionally be assigned to hosts using the inventory file if desired.

Make sure your hosts are defined in your inventory file with the appropriate ansible_ssh_host, ansible_ssh_user and ansible_ssh_private_key_file values.

Then run it:

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

Installing X-Pack Features

  • es_role_mapping Role mappings file declared as yml as described here
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 - Users can be declared here as yml. Two sub keys 'native' and 'file' determine the realm under which the user is created. Beneath each of these keys users should be declared as yml entries. e.g.
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 - Elasticsearch roles can be declared here as yml. Two sub keys 'native' and 'file' determine how the role is created i.e. either through a file or http(native) call. Beneath each key list the roles with appropriate permissions, using the file based format described here e.g.
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 - X-Pack license. The license is a json blob. Set the variable directly (possibly protected by Ansible vault) or from a file in the Ansible project on the control machine via a lookup:
es_xpack_license: "{{ lookup('file', playbook_dir + '/files/' + es_cluster_name + '/license.json') }}"

If you don't have a license you can enable the 30-day trial by setting es_xpack_trial to true.

X-Pack configuration parameters can be added to the elasticsearch.yml file using the normal es_config parameter.

For a full example see here

Important Note for Native Realm Configuration

In order for native users and roles to be configured, the role calls the Elasticsearch API. Given security is installed this requires definition of two parameters:

  • es_api_basic_auth_username - admin username
  • es_api_basic_auth_password - admin password

These can either be set to a user declared in the file based realm, with admin permissions, or the default "elastic" superuser (default password is changeme).

X-Pack Security SSL/TLS

  • To configure your cluster with SSL/TLS for HTTP and/or transport communications follow the SSL/TLS setup procedure

Additional Configuration

In addition to es_config, the following parameters allow the customization of the Java and Elasticsearch versions as well as the role behavior. Options include:

  • oss_version Default false. Setting this to true will install the oss release of Elasticsearch (for version <7.11.0 only).

  • es_xpack_trial Default false. Setting this to true will start the 30-day trail once the cluster starts.

  • es_version (e.g. "7.17.0").

  • es_api_host The host name used for actions requiring HTTP e.g. installing templates. Defaults to "localhost".

  • es_api_port The port used for actions requiring HTTP e.g. installing templates. Defaults to 9200. CHANGE IF THE HTTP PORT IS NOT 9200

  • es_api_basic_auth_username The Elasticsearch username for making admin changing actions. Used if Security is enabled. Ensure this user is admin.

  • es_api_basic_auth_password The password associated with the user declared in es_api_basic_auth_username

  • es_delete_unmanaged_file Default true. Set to false to keep file realm users that have been added outside of ansible.

  • es_delete_unmanaged_native Default true. Set to false to keep native realm users that have been added outside of ansible.

  • es_start_service (true (default) or false)

  • es_plugins_reinstall (true or false (default) )

  • es_plugins an array of plugin definitions e.g.:

      es_plugins:
        - plugin: ingest-attachment
  • es_path_repo Sets the whitelist for allowing local back-up repositories

  • es_action_auto_create_index Sets the value for auto index creation, use the syntax below for specifying indexes (else true/false): es_action_auto_create_index: '[".watches", ".triggered_watches", ".watcher-history-*"]'

  • es_allow_downgrades For development purposes only. (true or false (default) )

  • es_java_install If set to true, Java will be installed. (false (default for 7.x) or true (default for 6.x))

  • update_java Updates Java to the latest version. (true or false (default))

  • es_max_map_count maximum number of VMA (Virtual Memory Areas) a process can own. Defaults to 262144.

  • es_max_open_files the maximum file descriptor number that can be opened by this process. Defaults to 65536.

  • es_debian_startup_timeout how long Debian-family SysV init scripts wait for the service to start, in seconds. Defaults to 10 seconds.

  • es_use_repository Setting this to false will stop Ansible from using the official Elastic package from any repository configured on the system.

  • es_add_repository Setting this to false will stop Ansible to add the official Elastic package repositories (if es_use_repository is true) if you want to use a repo already present.

  • es_custom_package_url the URL to the rpm or deb package for Ansible to install. When using this you will also need to set es_use_repository: false and make sure that the es_version matches the version being installed from your custom URL. E.g. es_custom_package_url: https://downloads.example.com/elasticsearch.rpm

Earlier examples illustrate the installation of plugins using es_plugins. For officially supported plugins no version or source delimiter is required. The plugin script will determine the appropriate plugin version based on the target Elasticsearch version. For community based plugins include the full url. This approach should NOT be used for the X-Pack plugin. See X-Pack below for details here.

If installing Monitoring or Alerting, ensure the license plugin is also specified. Security configuration currently has limited support, but more support is planned for later versions.

To configure X-pack to send mail, the following configuration can be added to the role. When require_auth is true, you will also need to provide the user and password. If not these can be removed:

    es_mail_config:
        account: <functional name>
        profile: standard
        from: <from address>
        require_auth: <true or false>
        host: <mail domain>
        port: <port number>
        user: <e-mail address> --optional
        pass: <password> --optional
  • es_user - defaults to elasticsearch.
  • es_group - defaults to elasticsearch.
  • es_user_id - default is undefined.
  • es_group_id - default is undefined.

Both es_user_id and es_group_id must be set for the user and group ids to be set.

  • es_restart_on_change - defaults to true. If false, changes will not result in Elasticsearch being restarted.
  • es_plugins_reinstall - defaults to false. If true, all currently installed plugins will be removed from a node. Listed plugins will then be re-installed.

To add, update or remove elasticsearch.keystore entries, use the following variable:

# state is optional and defaults to present
es_keystore_entries:
- key: someKeyToAdd
  value: someValue
  state: present

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

- key: someKeyToDelete
  state: absent

This role ships with sample templates located in the test/integration/files/templates-7.x directory. es_templates_fileglob variable is used with the Ansible with_fileglob loop. When setting the globs, be sure to use an absolute path.

Proxy

To define proxy globally, set the following variables:

  • es_proxy_host - global proxy host
  • es_proxy_port - global proxy port

Notes

  • The role assumes the user/group exists on the server. The elasticsearch packages create the default elasticsearch user. If this needs to be changed, ensure the user exists.
  • The playbook relies on the inventory_name of each host to ensure its directories are unique
  • KitchenCI has been used for testing. This is used to confirm images reach the correct state after a play is first applied. We currently test the latest version of 7.x and 6.x on all supported platforms.
  • The role aims to be idempotent. Running the role multiple times, with no changes, should result in no state change on the server. If the configuration is changed, these will be applied and Elasticsearch restarted where required.
  • In order to run x-pack tests a license file with security enabled is required. Set the environment variable ES_XPACK_LICENSE_FILE to the full path of the license file prior to running tests. A trial license is appropriate and can be used by setting es_xpack_trial to true

IMPORTANT NOTES RE PLUGIN MANAGEMENT

  • If the ES version is changed, all plugins will be removed. Those listed in the playbook will be re-installed. This is behavior is required in ES 6.x.
  • If no plugins are listed in the playbook for a node, all currently installed plugins will be removed.
  • The role supports automatic detection of differences between installed and listed plugins - installing those listed but not installed, and removing those installed but not listed. Should users wish to re-install plugins they should set es_plugins_reinstall to true. This will cause all currently installed plugins to be removed and those listed to be installed.

Questions on Usage

We welcome questions on how to use the role. However, in order to keep the GitHub issues list focused on "issues" we ask the community to raise questions at https://discuss.elastic.co/c/elasticsearch. This is monitored by the maintainers.

ansible-elasticsearch's People

Contributors

aevaonline avatar barryib avatar brad avatar branen avatar broferek avatar crazybus avatar cyrilleverrier avatar dcleric avatar dekhtyarev avatar elasticmachine avatar electrical avatar eradical avatar itsmed avatar jakommo avatar janderson2 avatar jeffrey-e avatar jmlrt avatar konasp avatar lde avatar meersjo avatar mgreau avatar nduytg avatar nkammah avatar nullkarma avatar pemontto avatar pixelrebel avatar qk4l avatar robin13 avatar slothofanarchy avatar veger avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ansible-elasticsearch's Issues

Skip Java package install if java already installed

Hello

Could it be possible to check whether Java is already present before to install it through package manager?

In my case, Oracle JDK is installed through an ansible role that download the tgz directly from Oracle.
I would like to avoid openjdk installation if not required.

For example, changing java.yml to:

---
- name: Check Java
  shell: command -v java
    register: check_java
    ignore_errors: True
    changed_when: False

- name: RedHat - Ensure Java is installed
  yum: name={{ java }} state=latest
  when: ansible_os_family == 'RedHat' and check_java.rc > 0

- name: Debian - Ensure Java is installed
  apt: name={{ java }} state=present update_cache=yes force=yes
  when: ansible_os_family == 'Debian' and check_java.rc > 0

Best regards.

Geoff.

Remove Plugins that re installed but not listed in the playbook.

Currently if the user does the following:

  1. Installs ES with plugins
  2. Changes the plugins listed - adds and removed
  3. Re-runs the playbook

The plugins are not changed to those in step (2) - they are required to specify es_plugins_reinstall:true. My current proposal is to remove all plugins and re-install them in the event of ANY delta.

@jakommo thoughts?

data_dirs environment wrongly expanded

Somehow this showed up after running the playbook in the /etc/system/multi-user.target.wants/node1_elasticsearch.service file

Environment=DATA_DIR=[,',/,v,a,r,/,l,i,b,/,e,l,a,s,t,i,c,s,e,a,r,c,h,/,e,s,-,0,1,-,n,o,d,e,1,',]

Also shows in /etc/elasticsearch/node1/elasticsearch.yml
path.data: [,',/,v,a,r,/,l,i,b,/,e,l,a,s,t,i,c,s,e,a,r,c,h,/,e,s,-,0,1,-,n,o,d,e,1,',]

Expect :

Template

[Service]
Environment=ES_HOME={{es_home}}
Environment=CONF_DIR={{conf_dir}}
Environment=DATA_DIR={{ data_dirs | array_to_str }}
Environment=LOG_DIR={{log_dir}}
Environment=PID_DIR={{pid_dir}}
EnvironmentFile=-{{instance_default_file}}

Test Idempotent behaviour of Role

All current tests install to a clean docker image. The image is destroyed on completion of the test run. No tests currently confirm the behaviour if a role is applied multiple times to an image.

Whilst this is difficult to achieve with Kitchen tests, we could test the behaviour is correct when the role is applied to a docker image which already has nodes installed. This could be used to confirm:

  1. No changes are applied and the nodes are NOT restarted i.e. the role is Idempotent
  2. Changes are correctly applied and result in node restarts.

@electrical I propose choosing one platform on which to test this - in Kitchen it will require another platform/docker image preloaded with Elasticsearch. To avoid test explosion we might just limit to one platform therefore.

Test run levels

Test run levels are correctly applied per OS. Given the challenge with testing (using Kitchen) that ES is restarted on machine reboot, this gives us a confidence this is behaving correctly.

Create user if it doesn't exist

Currently the default user "elasticsearch" is used - this is installed by the package manager.
If installed through a manual URL this might not be the case. User may also wish to use another user.
Proposal is to create the user if it doesn't exist.

udpate-rc.d fails on Ubuntu with multiple nodes on the same machine

/usr/sbin/update-rc.d fails on Ubuntu (15.04):

fatal: [hostname]: FAILED! => {"changed": false, "failed": true, "msg": "Error when trying to enable node2_elasticsearch: rc=1 Synchronizing state for node2_elasticsearch.service with sysvinit using update-rc.d...\nExecuting /usr/sbin/update-rc.d node2_elasticsearch defaults\ninsserv: script node2_elasticsearch: service elasticsearch already provided!\ninsserv: exiting now!\nupdate-rc.d: error: insserv rejected the script header\n"}

node2 is the es_instance_name.

I believe the issue is related to the following line in the debian init script:

# Provides:          elasticsearch

Should that be something like this?

# Provides:          {{es_instance_name}}_{{default_file | basename}}

My playbook looks like this:

- hosts: elasticsearch
  vars:
    es_major_version: "2.x"
    es_version: "2.2.0"
    es_heap_size: "31g"
    es_max_open_files: 262140
    es_data_dir: "/elasticsearch/data"
    es_log_dir: "/elasticsearch/log"
  roles:
    - { role: elasticsearch, es_instance_name: "node1", es_config: { node.name: "node1", http.port: 9200, transport.tcp.port: 9300, cluster.name: "cluster", bootstrap.mlockall: true, discovery.zen.ping.multicast.enabled: false } }
    - { role: elasticsearch, es_instance_name: "node2", es_config: { node.name: "node2", http.port: 9201, transport.tcp.port: 9301, discovery.zen.ping.unicast.hosts: "localhost:9300", cluster.name: "cluster", bootstrap.mlockall: true, discovery.zen.ping.multicast.enabled: false } }
    - { role: elasticsearch, es_instance_name: "node3", es_config: { node.name: "node3", http.port: 9202, transport.tcp.port: 9302, discovery.zen.ping.unicast.hosts: "localhost:9300", cluster.name: "cluster", bootstrap.mlockall: true, discovery.zen.ping.multicast.enabled: false } }

(I assume this is also an issue on redhat, but dont have a system to test.)

Check plugin directory before plugin install

Avoid automatic upgrades by checking directory before trying to install a plugin: if directory exists, then don't try to install again unless the reinstall variable is set.

Remember - the directory name is not necessarily the same as the plugin name

Add shield support

I would like to add shield support, and I was wondering how we can structure things like variables and templates.

Here are my proposals:

Dicts structure:

es_license: my_vaulted_private_and_secret_license
es_users:
  - user: bob
    password: my_vaulted_secret_password
    role: user

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

or this structure (I personally prefer this one):

es_license: my_vaulted_private_and_secret_license
es_shield:
  - users:
      - user: bob
        password: my_vaulted_secret_password
        role: user
  - role_mapping:
      - admin:
        - "cn=admins,dc=example,dc=com"
      - user:
        - "cn=users,dc=example,dc=com"
        - "cn=other-users,dc=example,dc=com"

Templates structure:

Add these following templates to configure shield's roles and role mappings. For the main configuration, we'll use the es_config object.

+-- templates
|   +-- ...
|   +-- shield
|   |  +-- role_mapping.yml.j2
|   |  +-- roles.yml.j2

Do you have any suggestion or preference on how we should add this feature?

plugin binary can't find elasticsearch defaults file on Ubuntu 14.04

I am using Ubuntu 14.04.

I am configuring Elasticsearch in a role like so:-

    - { role: elasticsearch,
              es_instance_name: "es01",
              es_heap_size: "3g",
              es_data_dirs: "/opt/app/elasticsearch/data",
              es_log_dir: "/opt/app/elasticsearch/logs",
              es_work_dir: "/opt/app/elasticsearch/temp",
              es_config: { network.host: '[ "_local_", "_docker0_" ]',
                           transport.host: '_eth0_',
                           http.port: 9200,
                           transport.tcp.port: 9300,
                           max-open-files: true,
                           bootstrap.mlockall: true,
                           script.inline: true,
                           script.indexed: true,
                           index.translog.durability: async,
                           index.queries.cache.everything: true } }

This leaves me with a defaults file at /etc/default/es01_elasticsearch.

This happens when I try to run the plugin command:-

root@my-es-host:/usr/share/elasticsearch# bin/plugin                                               โ”‚~
bin/plugin: 49: .: Can't open //etc/default/elasticsearch

I can fix it up manually by editing bin/plugin like so:-

ES_ENV_FILE="/etc/default/es01_elasticsearch"

Am I missing some configuration or is this a bug? Thanks for your help.

Ubuntu 14.04 - elastic service cannot be stopped or restarted

On Ubuntu 14.04 you cannot restart (or stop) the elastic service with this command:

service <es_instance_name_elasticsearch> restart

Currently you have to restart the service, you have to kill the process and then use:

service <es_instance_name_elasticsearch> start

es_config usage fails to start elasticsearch

Every time I use the es_config parameter elasticsearch fails to start:

$ cat playbooks/elasticsearch.yml

---
- name: One Node Elasticsearch
  hosts: search
  become: True
  roles:
    - { role: ansiblebit.oracle-java, oracle_java_set_as_default: yes }
    - { role: elasticsearch, es_instance_name: "node1" , es_config: { network.host: "_global_" } }
  vars:

If I do NOT use es_config everything works fine.

Custom Repos for Elasticsearch install

Currently installs can be only installed from the official Elastic repos. We commonly encounter users who have systems with no external internet access, instead hosting their own yum/apt-get repos. This feature would allow users to specify the repo as a parameter - if specified this would be used for the install.

Unable to set java version

I've been testing the role with a few plugins that require java 8 (openjdk-8-jre-headless). Attempting to set the java: variable directly in the playbook, or in a separate vars file does not override the default. As a workaround, I can set it using the --extra-vars flag on runtime.

The use of include_vars: in tasks/main.yml is the culprit. According to https://github.com/ansible/ansible/issues/11807 , this is 'expected behaviour'.

Multiple data_dir definitions does not work

Defining multiple data directories:

 es_data_dir: "/mnt/xvdb,/mnt/xvdc"

Results in

DATA_DIR=/mnt/xvdb,/mnt/xvdc/ec2_marvel-rclarke_marvel

The node name is pasted after the last directory.

I don't think it is necessary to have a separate directory for each node running on a single machine, same as it is not necessary to have a separate directory for logs or work I think...

Make Java Repo Configurable

Given the situation with default java versions on Centos and Debian based systems, users are likely to want to specify an external repo to supply Java e.g. for Oracle. Currently the role limits them to IcedTea distribution and the latest version available through the default repos.

Cleanup unused init, env configs and yml files

The rpm and deb packages install an elasticsearch.yml, env default file (e.g. /etc/sysconfig/elasticsearch) init script and systemd file. These are not used as the role creates its own copy for each node instance - delimiting them with the mandatory instance name.
This ticket proposes cleaning these files up on completion of install.

Advanced Cluster Management Features

Proposal to support:

  1. Full Cluster Stop cluster
  2. Stop/Start/Restart Specific Node
  3. Full Cluster Restart
  4. Rolling Restart

Some of the above could already be achieved. It may not be appropriate to include this functionality in the default role - we may wish to create a separate management role.

To be discussed.

Plugins fail due to deleted /etc/default/elasticsearch

When using the role to manage plugins, it fails in consecutive runs due to deleted /etc/default/elasticsearch

The elasticsearch plugin command used in elasticsearch-plugins.yml to detect already installed plugins fails with

# ./plugin list
./plugin: 49: .: Can't open //etc/default/elasticsearch

The playbook fails with

"ERROR: plugin directory /usr/share/elasticsearch/plugins/sams/kopf already exists. To update the plugin, uninstall it first using 'remove kopf' command"

You delete /etc/default/elasticsearchin elasticsearch-config.yml.

Running Debian Jessie and elasticsearch 2.2.0

Better Support for Plugin removal

Ansible role currently only adds plugins and does not support plugin removal.

First improvement will:

  1. Remove and re-install all plugins if ES is upgraded - as required in 2.x
  2. Provide aa flag to re-install all plugins
  3. Remove all plugins if none are specified and some are installed
  4. Install plugins listed and not installed - currently supported

More tricky, and separate ticket:

  1. Removal of plugins that are installed but not listed in the playbook. Requires additional logic as ES lists names differently than install names

cloud-aws plugin configuration

How do I add additional properties to:

es_plugins:
- plugin: elasticsearch-cloud-aws
version: 2.5.0

to match:

cloud:
aws:
access_key: *********
secret_key: **********
discovery:
type: ec2

Thanks,
Per

Install plugin by URI

Provide a path from which to install a plugin.
Add a uri parameter to each plugin definition like this

Package version pinning

When a specific version of Elasticsearch is defined, this will be pinned in the package manager so that an inadvertent apt-get upgrade will not upgrade to the latest elasticsearch.

How do you add custom scripts/templates?

The copy commands in the tasks/elasticsearch-scripts.yml and tasks/elasticsearch-templates.yml are pretty clear in their intent.

So, is the expectation that I should clone this repo, and add any custom scripts/templates to the appropriate directory in files/?

Is there a way to configure a playbook to reference a different directory to load scripts/templates from?

Allow for any plugin to be installed

Currently we are forcing people to be only able to install Elasticsearch plugins with --install elasticsearch/{{ item.plugin }}/{{ item.version }}
Could we please make this more open?
the item.plugin could be something like elasticsearch/marvel or an other author/pluginname combo.

Logrotate as part of ES Ansible setup

I just started using the ES Ansible playbook, and noticed that there aren't any logrotate entries.

Would be nice to see a logrotate file added for ES automatically as part of the playbook as I can't seem to find any reference to one.

Clearly Determine when Systemd is used vs Init

This is currently left to which ever takes precedence as to what the user configures post install i.e. both scripts are installed.
The proposal is we clearly delimitate which is used, why and when.
@electrical maybe we should replicate the puppet modules behaviour here?

ERROR: plugin directory already exists (idempotence)

Issue: The plugin management is not idempotent (using current master, commit e14ebe0).

A plugin gets installed on first ansible-playbook run and causes "ERROR: plugin directory already exists" on the second run.

To be able to run a playbook multiple time, one has to workaround it by setting es_plugins_reinstall to true (default is false), but then the playbook reports changes on each run (not idempotent either).

Expected behaviour: second run finishes without error, with zero changes.

Environment: Fresh Ubuntu 14.04 64bit in Vagrant

Playbook (idemp.yml):

---
- name: Provision the ES node or cluster
  hosts: es
  remote_user: vagrant
  become: yes
  become_user: root
  gather_facts: true

  vars:
    es_plugins:
      - plugin: cloud-aws

  roles:
    - { role: elasticsearch, es_instance_name: "node1" }

First run:

marji@anna:~/projects/ansible-project-logstash$ ansible-playbook -i hosts idemp.yml 

--- cut ---

PLAY RECAP *********************************************************************
10.8.8.2                   : ok=47   changed=18   unreachable=0    failed=0   

Second run:

marji@anna:~/projects/ansible-project-logstash$ ansible-playbook -i hosts idemp.yml 

--- cut ---

TASK [elasticsearch : Remove elasticsearch plugins] ****************************
skipping: [10.8.8.2] => (item= cloud-aws) 

TASK [elasticsearch : Install elasticsearch plugins] ***************************
failed: [10.8.8.2] => (item={u'plugin': u'cloud-aws'}) => {"changed": false, "cmd": ["/usr/share/elasticsearch/bin/plugin", "install", "cloud-aws", "--silent"], "delta": "0:00:10.256230", "end": "2016-06-05 03:27:35.476620", "failed": true, "failed_when_result": true, "item": {"plugin": "cloud-aws"}, "rc": 74, "start": "2016-06-05 03:27:25.220390", "stderr": "", "stdout": "ERROR: plugin directory /usr/share/elasticsearch/plugins/node1/cloud-aws already exists. To update the plugin, uninstall it first using 'remove cloud-aws' command", "stdout_lines": ["ERROR: plugin directory /usr/share/elasticsearch/plugins/node1/cloud-aws already exists. To update the plugin, uninstall it first using 'remove cloud-aws' command"], "warnings": []}

PLAY RECAP *********************************************************************
10.8.8.2                   : ok=43   changed=0    unreachable=0    failed=1   

The error above is: "ERROR: plugin directory /usr/share/elasticsearch/plugins/node1/cloud-aws already exists. To update the plugin, uninstall it first using 'remove cloud-aws' command"

Validate configuration

Using a map for configuring elasticsearch.yml is super flexible and nice, but it makes it very easy to miscreate configurations that will not start. It would be very nice if there was some sort of validation that checks syntax.

Debian 8 - Issue with Systemd

Currently Systemd results in an error and fails to work when tested in Docker. Further investigation required. Error to be added here.

Allow specification of own user name

Allow the specification of a different username under which elasticsearch should be run. Currently we only support "elasticsearch".

I propose we do not create this user if it doesn't exist i.e. we assume its existence.

Switch to apt / yum repo's

At the moment the code uses a download link.
Would be nice if we can use our official repositories instead.

After installing, elasticsearch will not start due to no logging configuration?

I just did an initial test install with this role. I configured three nodes and ran the play. When I tried checking the health of the cluster, it became apparent that elasticsearch was not started.

So I tried starting it manually, and I got this:

root@node1:~# /usr/share/elasticsearch/bin/elasticsearch
Failed to configure logging...
ElasticsearchException[Failed to load logging configuration]; nested: NoSuchFileException[/usr/share/elasticsearch/config];
    at org.elasticsearch.common.logging.log4j.LogConfigurator.resolveConfig(LogConfigurator.java:158)
    at org.elasticsearch.common.logging.log4j.LogConfigurator.configure(LogConfigurator.java:103)
    at org.elasticsearch.bootstrap.Bootstrap.setupLogging(Bootstrap.java:204)
    at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:258)
    at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:35)
Caused by: java.nio.file.NoSuchFileException: /usr/share/elasticsearch/config
    at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
    at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
    at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
    at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
    at sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
    at sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:97)
    at java.nio.file.Files.readAttributes(Files.java:1686)
    at java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:109)
    at java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:69)
    at java.nio.file.Files.walkFileTree(Files.java:2602)
    at org.elasticsearch.common.logging.log4j.LogConfigurator.resolveConfig(LogConfigurator.java:142)
    ... 4 more
log4j:WARN No appenders could be found for logger (bootstrap).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
Exception in thread "main" java.lang.RuntimeException: don't run elasticsearch as root.
    at org.elasticsearch.bootstrap.Bootstrap.initializeNatives(Bootstrap.java:93)
    at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:144)
    at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:285)
    at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:35)
Refer to the log for complete error details.
root@node1:~# ls /etc/elasticsearch/
elasticsearch.yml  node1  logging.yml  scripts

Here are the ansible vars, just replace node1 with node2 or node3 to get the other nodes config:

es_version: 2.1.1
es_log_dir: "/opt/elasticsearch/logs"
es_work_dir: "/opt/elasticsearch/temp"
es_heap_size: "3072m"
es_config: 
  cluster.name: "asdfqwerty"
  discovery.zen.ping.unicast.hosts: "http://node1:9301"
  http.port: 9200
  transport.tcp.port: 9301
  bootstrap.mlockall: True
  discovery.zen.ping.multicast.enabled: False
  path.repo: "/path/to/repo/path"
  discovery.zen.minimum_master_nodes: 2
  action.destructive_requires_name: True

es_instance_name: "node1"

es_config: 
  node.name: "node1"
  node.data: True
  node.master: True

es_data_dir: "/mounts/node1"

Did I miss some required var?

I did try /etc/init.d/node1_elasticsearch start and it did not work, nor did it output any errors. Just Starting ... [OK]. /var/logs/elasticsearch is empty so I can't figure anything out from there.

So, what obvious step am I missing?

Should this kind of question be posted on discuss.elastic.co somewhere instead of here? If so, what forum?

Debian-8 fails java package

   TASK: [elasticsearch | Debian - Add java repos] *******************************
   failed: [localhost] => (item=ppa:webupd8team/java) => {"failed": true, "item": "ppa:webupd8team/java"}
   msg: Invalid repository string: ppa:webupd8team/java

Centos-7 fails with service

Not sure where the fault lays but should be found out :-)

       TASK: [elasticsearch | Start elasticsearch service] ***************************
       failed: [localhost] => {"failed": true}
       msg: failed determining service state, possible typo of service name?

       FATAL: all hosts have already failed -- aborting

Support plugin management for ES 1.x

Between ES 1.x and 2.x plugins management verbs changed.

  • ES 1.x: bin/plugin --install [plugin_name]
  • ES 2.x: bin/plugin install [plugin_name]

We should catch this change during the plugin installation and removal. At least, as long we support ES 1.x

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.