Add the very useful head plugin

[lrhazi]

Would be nice to add this plugin:

run /usr/share/elasticsearch/bin/plugin -install mobz/elasticsearch-head

[kdekooter]

+1

[reminyborg]

You could use shared directory as shown in README.md:

1. Create ElasticSearch config file at <data-dir>/elasticsearch.yml.

   path:
     plugins: /data/plugins

2. Add plugins to <data-dir>/plugins/
   either manually or by running a temporary docker

   docker run -v <data-dir>:/data dockerfile/elasticsearch /elasticsearch/bin/plugin -i mobz/elasticsearch-head

3. Start a container by mounting data directory and specifying the custom configuration file:

   docker run -d -p 9200:9200 -p 9300:9300 -v <data-dir>:/data dockerfile/elasticsearch /elasticsearch/bin/elasticsearch -Des.config=/data/elasticsearch.yml

For somebody that is already using persistent storage this would also be the best way to do it.

[ramseykhalaf]

I disagree, I like it the way it is.

I think the base image (that's semi-official) should not come with anything that isn't core to elasticsearch. It is so easy to extend, either by configuring as the comment above, or writing a Dockerfile that builds FROM dockerfile/elasticsearch if you don't want to mount volumes yet.

# Pull base image.
FROM dockerfile/elasticsearch

# Install HEAD plugin
RUN \
  cd /elasticsearch && \
  bin/plugin -i mobz/elasticsearch-head

[ppearcy]

@ramseykhalaf
Since the plugins directory lives on the data volume (currently, looks like it changed since you posted ;) ), your example above will not correctly provision things.

I'm currently setting the plugins directory to the default location, so that it is baked into the docker image. Now, I may get hosed if I use a plugin that tries to store local state to plugins location, but am currently using kibana and marvel which persist state to elasticsearch and am probably OK there.

Since I am commenting, don't feel strongly, but a baked in way to specify optional plugins would be nice.

[pilwon]

@ppearcy What change would you suggest?

[lrhazi]

Maybe this:

• User gets to add a file to the data dir, with the list of plugin urls to install, one per line, like:
  mobz/elasticsearch-head.
• Add a startup script to the image, which loops on the list of plugins and installs them.

Customizing Docker images is certainly easy, so maybe this is an overkill.

[dadoonet]

I'm -1 for adding plugins by default.

Still. I'd prefer that this Dockerfile install elasticsearch as a service so it will be easy to restart elasticsearch when needed.

For example, when adding Marvel to my own Dockerfile, it does not work as I am expecting as dockerfile/elasticsearch launched bin/elasticsearch. So this process does not start in background and other commands are not processed (but I might be wrong as I'm starting with Docker :) ).

My Dockerfile:

FROM dockerfile/elasticsearch
RUN /elasticsearch/bin/plugin install elasticsearch/marvel/latest

I would suggest to:

• either launch elasticsearch with -d -p /data/elasticsearch.pid
• or use deb images instead of .tar.gz and then start the service with service elasticsearch start.

Wanna a PR for this?

[Hocdoc]

+1 for using deb images

[neil-rubens]

Having plugins in the \data\plugins has several disadvantages:

• conceptually plugins are not part of the data
• currently, installing plugins have to be done outside of docker (in the to be mounted data volume); and not through the dockerfile (since data volume is mounted at runtime).

Hence my suggestion is to to remove \data\plugins from config file; so that plugins directory will be at its default location \elasticsearch\plugins; this would allow to use /dockerfile/elasticsearch as a base and to install any plugins one wants by simply adding a run command to a dockerfile; e.g.::
RUN ["/elasticsearch/bin/plugin", "--install", "mobz/elasticsearch-head"]

p.s. +1 for using deb images @dadoonet

[mlehner616]

@neil-rubens +1 for removing plugins from the /data directory. Conceptually, this makes much more sense.
deb images also would be okay as long as they don't install into /data of course.

There is definitely confusion on how to properly install a plugin using containers, I believe this is the fundamental reason the question came up in the first place. If it was trivial, which it is obviously not, I don't think there'd be so much discussion/debate. At the very least, This Dockerfile could use better documentation on A) how to install a plugin using the /data/plugins method and B) how to bake one permanently with a Dockerfile.

[fabiosussetto]

@dadoonet I think this way is how docker should be used. I think ideally you should have one service per container. Docker has a --restart flag that can be used to make sure the process is kept running. You shouldn't have two daemon services running in the same container. If for example you have your app server and elasticsearch, they would be in separated (but probably linked) containers. This way you can scale the two components independently. I've just started with Docker so take my words as my current vision of Docker :)

[ghost]

+1 for @neil-rubens, it doesn't make sense to have plugins at /data/plugins.

A workaround for the time being is to have the following dockerfile:

FROM dockerfile/elasticsearch

ADD config/elasticsearch.yml /elasticsearch/config/elasticsearch.yml

RUN /elasticsearch/bin/plugin install elasticsearch/elasticsearch-cloud-aws/2.4.1

where config/elasticsearch.yml is :

path:
  data: /data/data
  logs: /data/log
  plugins: /elasticsearch/plugins
  work: /data/work

[phantomwhale]

Also hit this issue, and agree that moving the plugins out of the data volume would premit easy docker extension to include preferred plugins.

Until then, the workaround's posted above should work for us

[RWOverdijk]

👍

[danpilch]

An easy way to install a plugin into a running elasticsearch instance is:

docker exec -ti container_name ./bin/plugin install mobz/elasticsearch-head