Run as user "elasticsearch"

[md5]

The elasticsearch package that is being installed for this image creates an "elasticsearch" user that is used by the init.d script:

$ docker run --rm elasticsearch:1.4 id elasticsearch
uid=105(elasticsearch) gid=108(elasticsearch) groups=108(elasticsearch)

This user is not being utilitized in the /usr/share/elasticsearch/bin/elasticsearch script, which means this image is currently running the ES service as root.

The image should be updated so that the service does not run as root. Since ES doesn't appear to have its own way to drop privileges, it seems like that way to go here is with gosu and a custom ENTRYPOINT.

[seschwar]

Apart from having to adapt the permissions of /usr/share/elasticsearch/data Is there any reason to not just use the USER directive in the Dockerfile?

[md5]

It makes it more difficult to create derived Dockerfiles because the user would need to know to add a “USER root" to do any commands that need root before switching back to “USER elasticsearch".

[md5]

Also, because you're relying on the creator of a derived Dockerfile to switch back to USER elasticsearch, it's possible for them to forget to do that and accidentally run the service as USER root.

[yosifkit]

I am +1 on the gosu approach, unless it is not common to derive from this image.

[tianon]

We still have the "having to adapt the permissions of /usr/share/elasticsearch/data", so gosu sounds to me like our only viable approach for now.

[md5]

I was just looking at their run script and it would be nice if it respected a pre-existing setting of JAVA. That way, the Dockerfile could do something like ENV JAVA gosu elasticsearch java instead of having to use an ENTRYPOINT. Still, that's not possible with the current elasticsearch script.

[thomascooper]

I might be one of the users who doesn't know very much about user rights in docker. But 2 days ago I spun up an ES 1.4.4 instance (using Vagrant on OSX), had no problems. Here was my config:
DockerFile:

FROM elasticsearch

VagrantFile:

config.vm.define "es" do |es|
    es.vm.provider "docker" do |d|
      d.build_dir = "./config/es"
      d.create_args = ["-p", "192.168.77.12:9200:9200"]
      d.volumes = [
       "/vagrant_config/es:/usr/share/elasticsearch/config/",
       "/vagrant_data/es:/usr/share/elasticsearch/data/"
      ]
      d.env = {VIRTUAL_HOST: "es.mongoosemetrics.com"}
      d.vagrant_vagrantfile = "./build/dockerbase/VagrantFile"
    end
  end

This set of configuration completely worked with the 1.4.4 image, mounts/volumes worked perfectly. I spun up the exact same setup for 1.5.0 (basically deleted what was in my /vagrant_data/es folder, and updated the dockerfile)

Dockerfile:

FROM elasticsearch:1.5.0

Upon booting the new docker container, I get the following error if the initial volume is mounted NFS (which 1.4.4 was working as)

chown: changing ownership of '/usr/share/elasticsearch/data': Operation not permitted

If I mount using virtualbox folders (default method, just to test), I don't see the OS level error, but I see the follow error when it starts ES

- SettingsException[Failed to open stream for url [file:/usr/share/elasticsearch/config/elasticsearch.yml]]
    FileNotFoundException[/usr/share/elasticsearch/config/elasticsearch.yml (Permission denied)]
org.elasticsearch.common.settings.SettingsException: Failed to open stream for url [file:/usr/share/elasticsearch/config/elasticsearch.yml]

My next step is to create the image locally via your Dockerfile and see if that works any better, but before I do this, if anyone has any advice that would be great.

Thanks

[yosifkit]

@thomascooper, that looks like boot2docker/boot2docker#581.

[thomascooper]

@yosifkit, you are correct for the standard mounted directories, but NFS Solves this issue (which is why 1.4.4 worked), something is different with 1.5.0 which stops the entrypoint script from running chown on the volume

[yosifkit]

The previous image of 1.4.4 didn't have the chown and was running as root; the chown was only added in the last few days and was updated in official images with docker-library/official-images#619.

[thomascooper]

So what would you suggest? For the typical issues with databases and apache/nginx are all solved by mounting with NFS, that solution still does not fix this problem. Should i just copy the dockerfile and remove the entrypoint line the rebuild? Should I try and find a solution to the permission? As it stands now, if you are running off windows or OSX, this image will not work without some manual configuration.

[md5]

The image will work fine under Windows or OS X if you leave the volume on the VM instead of trying to mount it from the host. I'm curious what the use case is for having the ES data live in a host directory.

[yosifkit]

It should work the same way as the database images. Both chown the directory to the user and then step down from root, so I am not sure where the problem is.

[thomascooper]

@md5 there are multiple use cases for leaving it on the host, in the case of boot2docker or vagrant, the underlying VM is supposed to be transparent. As I understand it (and I am newish to docker/vagrant) the VM in either case is just exposing docker to the host OS, I should be able to tear down and rebuild the host VM (which I do often) without losing my persistent data.

[md5]

Thanks @thomascooper. I also use boot2docker and very rarely rebuild the VM, so my persistent data just stays in the Virtualbox data disk. Since that file is backed up regularly to Time Machine along with the rest of my home directory, I don't worry too much about losing any data I might have in a Docker container.