: So I've taken a look at the Elastic docker images [1], and they are
: structured much like official images, except for the use of multi-stage
: builds. They have no ARGs, and the docker context is merely the directory
: in which the Dockerfile sits. With this in mind, and wanting to still take
: advantage of the Official Docker Image, we will likely need to do some sort
: of templating, as Hoss suggested. This can be automated using gradle fairly
: easily I would imagine, and we could ensure that the only changes it makes
: is to the part of the image that downloads Solr. That way there is very
: little room for differences to occur between local and release images.

If docker-library is willing to allow _/solr:X.Y images that are just 
simple 'FROM apache/solr:X.Y' wrappers, and the apache/solr iamges can be 
built with multi-stage builds, then i'm not sure we would really need 
templating of the Dockerfile -- or to download a solr.tgz file.

The Dockerfile could have an initial stage that runs "gradle dist" to 
compile the java source files -- using a build AEG to override the 
default X.Y.Z-SNAPSHOT version variables -- while a later stage could 
then take the resulting solr.tgz from the first stage and setup the file 
layout for the final image.

So users wanting to build a "snapshot" docker image from their local 
(possibly patched) checkout could just do...

  docker build -f solr/docker/Dockerfile .

Or from a remote git branch:

  docker build -f solr/docker/Dockerfile 
https://gitbox.apache.org/repos/asf/lucene-solr.git#branch_9x

while the official apache/solr:X.Y.Z image would could be reproducibly 
buildable via...

  docker build --build-arg SOLR_VERSION=X.Y.Z -f solr/docker/Dockerfile 
https://gitbox.apache.org/repos/asf/lucene-solr.git#releases/lucene-solr/X.Y.Z

Same Dockerfile in all use cases, no need for intermediate downloading 
from any remote servers.


-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to