Closed nshou closed 5 years ago
(Original issue 5 last updated on 2019-09-02T17:12:51.132244+00:00)
(Issue automaticaly closed due to status in Bitbucket: resolved)
(Original comment by nshou on 2019-01-12T06:11:56.241144+00:00)
I'm sorry it took so long to get back to you.
I assume that '/home/elasticsearch/elasticsearch/data' in the container is the directory to be persistent so that we can keep the data even after removing the container, and I think there are two ways usually used for binding volumes, 1) bind-mounting and 2) using docker volume.
I think 1) is relatively easy and more intuitive, but a caveat is that the owner and permission of the source mount-point must be 1000:1000 and 755 because the user 'elasticsearch' (uid=gid=1000 inside the container) needs a right to read/write the data directory. So it should look like:
#!shell
$ mkdir -p /path/to/elasticsearch_data
$ chown 1000:1000 /path/to/elasticsearch_data
$ chmod 755 /path/to/elasticsearch_data
$ docker run -d -p 9200:9200 -p 5601:5601 -v /path/to/elasticsearch_data:/home/elasticsearch/elasticsearch/data nshou/elasticsearch-kibana
As for 2), since the original elasticsearch tar.gz does not contain the data directory, its metadata of owner, group, and permission matters. You can attach a volume as follows:
#!shell
$ docker volume create elasticsearch_data
$ docker run -d -p 9200:9200 -p 5601:5601 -v elasticsearch_data:/home/elasticsearch/elasticsearch/data nshou/elasticsearch-kibana
, but the owner and group of the directory is now root:root, which results in the failure in starting up elasticsearch. So I concluded to update Dockerfile to handle it (make the directory in advance,) which would appear in the next commit.
Now both 1) and 2) will work. If it isn't what you meant, please put a message here. I appreciate your great feedback.
(Original comment by nshou on 2019-09-02T17:12:40.829298+00:00)
The persistent volumes are now available in the latest version.
(Original issue 5 created by emilie_rumiano on 2018-08-13T12:38:23.280180+00:00)