Thanks for your input Hoss and Martijn. 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.
I do think that the current PR can be merged, regardless of our intent for the release build, because the current way of building isn't going to be acceptable for an official docker image release. I have made a ticket to determine a release process for Solr docker images (9.0+) [2], this way we can continue on with other parts of the Solr docker improvements while being able to work on that in parallel. To respond to the point about different architectures or operating system images, I agree with you Martijn. I think we should support one operating system by default, which would hopefully work with multiple architectures. Dockerhub seems to support this for official images [3]. However if users would want different operating system images, we will have given them the ability to specify a custom base image and the dockerfile instructions should be clear enough to migrate to other operating systems. That way they can easily build their own. - Houston [1] https://github.com/elastic/dockerfiles/tree/v7.10.1/elasticsearch [2] https://issues.apache.org/jira/browse/SOLR-15102 [3] https://github.com/docker-library/official-images#multiple-architectures On Wed, Jan 20, 2021 at 11:55 AM Chris Hostetter <hossman_luc...@fucit.org> wrote: > > : I'd recommend building apache/solr:x.y.z as part of the normal solr > : release, then import those images into the official images library so > ... > : I don't know exactly what it takes for this to happen on the > : official-image library side, but it seems that Elastisearch does this > > Oh wow ... ok, yeah: I had no idea that was allowed by docker-library > based on the things I'd read about "official" docker images. (per the > links in the comments, the Dockerfile for the ES base image even uses > multi-stage builds which would help seriously simplify the our 'official' > image build process) > > Yeah, if this is something docker-library will allow us to do as well -- > define _/solr images directly 'FROM' apache/solr images -- and that > those are/can be reproducibly built from a (multistage) Dockerfile in our > git source repo identified by our release tag -- then by all means that > seems like the best way to go. > > (I suspect the one finicky bit may be ensuring that docker-library is > ok with us using '--build-arg' to set the version when building our base > apache/solr images so that by building docker images from source checkout > defaults to building a snapshot) > > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
