Docker image built with elasticsearch-oss tar and not opendistro rpms


Looking at the opensitro elasticsearch docker images build steps -
opendistro-build/Dockerfile.j2 at main · opendistro-for-elasticsearch/opendistro-build · GitHub,
I notice the dockerfile installs the elasticsearch-oss tar and then the standalone opendistro plugins are installed.
Instead, if the opendistroforelasticsearch rpm was installed directly in the image, then all the plugins would be already part of it. Similar case with kibana docker image.

Wanting to know if there are any potential benefits of building docker images with elasticsearch tar & standalone plugins? Is there a specific reason for going with that approach? Any inputs would be appreciated.

Hi @shivani,

It is a bit more complicated to run rpm distros as a service inside a docker container considering you need to also take care of a service manager such as systemd integration. It is much easier and more lightweight to use standalone tarball/zip version of the distro to create the docker image. Plus, it allows much easier customization going on.

Do you have any specific reason that you want rpm distros in docker? Thanks.

Hi @zhujiaxi,
Many thanks for your response. I now understand why tarball was preferred over rpm in the docker image.
However, opendistro also builds tarballs for elasticsearch & kibana -


I actually intend to understand why opendistro tarballs are not directly used in building the docker images instead of elasticsearch & kibana oss tarballs.
Using opendistro tars would have included all odfe plugins already and would not require install of all standalone plugins as done currently in Dockerfile.

Is there a specific reason for going with that approach and do you see some technical benefits here?

Hi @shivani, the ODFE tarball distro is using “elasticsearch & kibana oss tarballs” under the hood anyway.

The initial decision to “repeat the process and install the plugins again instead of pulling the ODFE tarball in docker image” is with historical reasons, but mainly to allow us to add more customization in the dockerfile so we can provide an image that works on the go. On the contrary, the tarball distro is very barebone, which is more suitable for advanced users, and requires many manual configures.

The initial build methods are created about a little over a year ago, and it is quite simple/small in size and scale at the time. We are in the process of recreating the build process to make sure it is simpler, easier, and more stable on the go.

Until we commit the new process, we will just keep this approach. Thanks for your suggestions.