[docs] Should we document that the docker container expects the "elasticsearch" user to uid=1000

[joshuar]

Do we need to document that the Docker image by default has the elasticsearch user mapped to uid 1000? This can cause issues in certain situations where the host OS has a different user with uid 1000. Mainly, this causes permission issues with the volumes. I can see that using a container orchestration tool could mitigate this problem and could be considered a best practice when using these images?

If needed, this could be documented in Notes for production use?

[nik9000]

It feels weird that the elasticsearch-docker docs are in the Elasticsearch project. We should probably fix that at some point. I don't really have an opinion on the question at hand though.

[jasontedor]

It feels weird that the elasticsearch-docker docs are in the Elasticsearch project.

I think that having the installing from Docker docs alongside the installing from other distributions docs makes sense.

[nik9000]

Yeah, it does. We could get them to look like that even if the source of the document is in the docker project but maybe it just isn't worth it. I'm certainly not going to block docker docs changes because I want them in another place. That'd be silly.

If you think we should document this the user name then I'm fine with it.

[jasontedor]

We could get them to look like that even if the source of the document is in the docker project but maybe it just isn't worth it.

In my mind it is indeed not worth it. Let's consider the situation last year when we changed command-line parsing to change -D to -E. If the Docker docs had existed here at this time, they would need to be updated along with this change. By being in this repository, that kind of maintenance is easier (command-line tools will find the necessary places).

If you think we should document this the user name then I'm fine with it.

I'm still pondering this one.

[packet-rat]

re: Do we need to document that the Docker image by default has the elasticsearch user mapped to uid 1000? This can cause issues in certain situations where the host OS has a different user with uid 1000. Mainly, this causes permission issues with the volumes. I can see that using a container orchestration tool could mitigate this problem and could be considered a best practice when using these images? Absolutely! Managing permissions for directories on external volumes is a must. So those who are looking for a "quick" deployment for learning Elastic Stack and blindly following the deployment guides will need to know that they need to chmod/chown the volumes and how to do so. Not everyone understands the underlying details around Docker, many are looking for the "Easy Button", I know I was back in the beginning! Some notes on system sizing and expectations in terms of Docker Elastic Stack Deployment would be very useful as well. Either intertwined with the Docker Deployment section or in the overall Elastic Stack System sizing guides (I'd vote for the latter)

[dliappis]

This has been on my radar for a bit. We do document it, albeit not so directly, in an important note in the bind mounts section (-v stuff) as well as in the customized image section.

Nevertheless, judging by the amount of issues in the elasticsearch-docker repo, it is obviously not clear enough esp. when people use bind mounts for the data dir /usr/share/elasticsearch as opposed to Docker volumes. So I think it makes sense to make a more generalized and prominent (=in bold) note in the Bind Mounted section about the default user and need to match the uid/gid for bind mounted dirs and perhaps even, duplicate it in the Notes section.

[jasontedor]

So I think it makes sense to make a more generalized and prominent (=in bold) note in the Bind Mounted section about the default user and need to match the uid/gid for bind mounted dirs and perhaps even, duplicate it in the Notes section.

I'm good with this. Do you want to open a PR @dliappis?

[dliappis]

I'm good with this. Do you want to open a PR @dliappis?

Thanks @jasontedor I will do that.

[dliappis]

I created #24092