init service name and dir names

[jogaco]

Maybe I'm missing something, but I've looked at the README and issues but have found no response.
Tried against an Ubuntu 16.04
The playbook installs elasticsearch but I cannot find the init script.

I reboot the machine and elasticsearch is being started up, but alas, I cannot find the init or init.d script.

I need that to manually restart or check the service.

There is also something nasty: elaticsearch dirs are named like this: my-server-ip-node1
Replaced with xx:

path.data: /opt/elasticsearch/data/138.68.xx.xxx-node1

path.work: /opt/elasticsearch/temp/138.68.xx.xxx-node1

path.logs: /opt/elasticsearch/logs/138.68.xx.xxx-node1

How can I avoid that? I would prefer no prefix or localhost prefix, as the IP is not even fixed!
The playbook is not run locally.

My playbook:

---
- name: Configure servers with Elastic Search
  hosts: newservers
  become: yes
  roles:
    #expand to all available parameters
    - { role: elasticsearch, es_instance_name: "node1", es_heap_size: "200m", es_data_dirs: "/opt/elasticsearch/data", es_log_dir: "/opt/elasticsearch/logs", es_work_dir: "/opt/elasticsearch/temp",
          es_config: {
            bootstrap.mlockall: true, index.merge.scheduler.max_thread_count: 1,
          }
      }
  vars:
    es_scripts: true
    es_heap_size: 256m
    es_start_service: true
    es_plugins_reinstall: false
    es_plugins:
        - plugin: cloud-aws

[jogaco]

I've used this hosts file as workaround to avoid ip in dir names:

[newservers]
# localchost ansible_host => required by elasticsearch install otherwise it fills config files with actual ip
localhost ansible_host=46.101.xxx.xx

Regarding service, I noticed it's installed as systemd and as node1_elasticsearch

[tomekit]

Is there an option to use default names for the service, default config dir etc.?

In my opinion that naming convention is ridiculously complex and useless.
If I provision a host with the ES setup, I am not going to run more than 1 ES, so there is no need to provide any kind of structure. If anyone is going to look after the server whilst I am away, I am sure this person would fall into same troubles, trying to find init.d script, config, etc.

[jakommo]

Is there an option to use default names for the service, default config dir etc.?

No, this is needed to support multiple nodes per machine and you can not easily switch to default names.

If I provision a host with the ES setup, I am not going to run more than 1 ES, so there is no need to provide any kind of structure

This might be true for you, but there are a lot of people running multiple nodes per host. Mostly because they have bar metal with 128/256GB RAM and lots of cores, but a single instance of ES can not really use more than 30GB HEAP so multiple nodes per host are the way to go.

If anyone is going to look after the server whilst I am away, I am sure this person would fall into same troubles, trying to find init.d script, config, etc.

That's a case of documenting/handover the environment IMHO.

[tomekit]

Ok true, I understand that everyone has their own use cases. In environments I've worked on even if there is 256GB RAM node there was a virtualization in place anyway. For the smaller projects I could see the ES nodes wrapped around containers.

I would say running cluster of n nodes on just one host must be really specific use case. You would rather want to distribute your ES nodes in case your host dies.

Anyway, I've patched the code, so it fits my use case, for anyone who has the same problem:
tomekit@16df06c

E.g configuration:

- hosts: v2-es-us
  become: yes
  roles:
    #- common
    - { role: elasticsearch,
        es_instance_name: "v2-es-us",
        es_heap_size: "1g",
        es_major_version: "1.4",
        es_version: "1.4.2",
        es_data_dirs: ["/mnt/elasticsearch/data"],
        es_log_dir: "/mnt/elasticsearch/logs",
        es_service_name: "elasticsearch",
        es_config: {
            cluster.name: "v2",
            discovery.zen.ping.unicast.hosts: "10.24.0.249:9300",
            http.port: 9200,
            transport.tcp.port: 9300,
            node.data: true,
            node.master: true,
            bootstrap.mlockall: false,
            discovery.zen.ping.multicast.enabled: false }
        }
  vars:
    es_scripts: false
    es_templates: false
    es_version_lock: false
    es_plugins:
     - plugin: elasticsearch/license
       version: latest
     - plugin: mobz/elasticsearch-head
       version: latest
     - plugin: lmenezes/elasticsearch-kopf
       version: latest

[jakommo]

Yes, Virtualization is often used in this case as well, but some users do not want that extra layer.

I would say running cluster of n nodes on just one host must be really specific use case. You would rather want to distribute your ES nodes in case your host dies.

In the cases I was referring to It's multiple big hosts running multiple nodes each and then using allocation awareness to have replicas distributed to different hosts. On a single host I would not recommend doing this for the reasons you stated.

Thanks for posting your solution, I'm sure it's useful for others.

I'm closing this now, as I don't want change the current functionality and you provided a workaround for users that want to do this.

[jogaco]

IMO multiple nodes per host would be a minority of cases.
I will try @tomekit patch

[jogaco]

Thanks @tomekit for your patch. Works well, except I had to define es_data_dirs: ["/home/elasticsearch"] otherwise it was defined as /h,o,m,e...

Funny that the ansible role prioritizes the non-recommended elasticsearch setup over the recommended one: recommended hardware

[tomekit]

Hi @jogaco , I am glad it's working for you.

If you check my suggested config (#205 (comment)) there is `es_data_dirs defined:

es_data_dirs: ["/mnt/elasticsearch/data"],

[jogaco]

@tomekit and anyone interested in a simple setup of ES easy to admin:

An updated fork for 5.x is here: https://github.com/jogaco/ansible-elasticsearch

[hatdropper1977]

@jakommo I agree with @jogaco - Deploying n services to one server seems like an obscure use case. It should not be the default. In the spirit of "convention over configuration" the default should be one elastic per server. Those who want the obscure use case of deploying n services to one server should be the ones Googling stack exchange for the configuration.