FYI: I've implemented a PoC of this idea and opened SOLR-15127...
https://issues.apache.org/jira/browse/SOLR-15127
: Date: Fri, 22 Jan 2021 14:37:19 -0700 (MST)
: From: Chris Hostetter
: To: Solr/Lucene Dev
: Subject: Re: Solr Docker discussion
:
:
: : So I've taken a look at t
: 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
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 m
: 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
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 that it also
becomes solr:x.y.z. That way, you can move all the development/build/test work
into your world (and deal with issues prior to release), and simpl
:- _/solr - docker run solr:9.0 (Official Docker Image)
:- apache/solr - docker run apache/solr:9.0
:
: The benefits of the first are 1) the nice usability of being able to
: plainly specify "solr" and 2) the "Docker Official Images" badge on
: DockerHub. The downsides are that there are
Jan, thanks for clarifying your point on the Dockerfile layers, that makes
a lot of sense.
David, for your point on using the same Solr binary, I think we could
possibly use the same Dockerfile. The difference would be the input Solr
tgz that dockerTar puts into the "releases" sub-directory. Inste
Periodically rebuilding old images seems challenging in this new setup
compared to docker-solr. I suppose it could be done with a script that
loops over release branches to check them out to then execute the
appropriate gradle task to build & push. But the requirement to use an
identical Solr bin
Great summary Houston!
Could also be that docker team is willing to provide a “link” from official
_/solr to apache/solr if we can convince them of solid quality. Think they do
this for elastic images already.
Since Docker images contain Linux and Java, which we would not be allowed to
release
I'm curious about how tags will work when updating the base image for a
released image? The image for a tag should be immutable (IMHO), and I think
people would be surprised if 8.8.0 suddenly changed even if it was for a
good reason such as fixing a CVE in the base image. But based on what Kevin
sa
Thanks for bringing up this issue Kevin.
Periodically re-building docker images is certainly a feature we could
support, and probably should to automatically keep up with security fixes.
We could even automate it pretty easily in Jenkins.
We could also build in support in the gradle commands to i
>
> Currently the solr-docker-image, and a majority of "Docker Official
> Images", the officially released Solr binaries are downloaded from mirrors
> and validated within the Dockerfiles. This makes it easy to ensure to users
> that the 9.0 solr docker image contains the 9.0 solr release. This pro
There's a few decisions that need to be ironed out around the Solr docker
image before 9.0 is released. This is because the community has decided
that Solr should start releasing it's own docker images starting with 9.0.
Below is the current state of the ongoing discussions for the Solr Docker
ima
13 matches
Mail list logo
