: - _/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 very strict requirements with
: creating Official Docker Images, which would complicate and require
: separating the way that we build release docker images and local docker
: images.
I don't know that this is strictly true? I think it would be possible to
support "local" images and "release" images fairly easily w/ a small
amount of tooling, but more on this idea farther below...
: *I think there is some consensus that choosing the "apache/solr" location
: is fine, and worth the added flexibility we get in the build process.*
...
: *The current opinion in the community is to abandon the "Docker Official
: Images" style process of downloading and validating official binaries, and
: instead having the release manager use the local-build image creation with
: the final release source.* This should result in the same docker image in
: the end, however there is no trust built into the docker image itself.
: Instead we are likely going to document a way for users to verify the
: docker-image contents themselves.
"Citation Needed" :)
Seriously though ... can you point me to when/where there has been
discussion/concensus about this?
And which community exactly are you refering to? -- Because I suspect that
on the subject of where/how to build the Docker images and if/how-much it
matters wether they live in _/solr vs apache/solr you may find a
discrepency between the "community of solr comitters" and the "docker user
community". Keep in mind: Mak didn't jump through the neccessary hoops
all those years ago to create _/solr just because he thought it would be
fun -- it would have been a lot easier to just create & publish
makuk66/solr images, but there was a (docker) community desire to have
"Docker official" _/solr images.
I think it would be presumptuous to assume that (docker) community desire
is going to go away just because the (apache solr) community is now
willing to publish apache/solr images.
With that in mind, I *think* there is a relatively straight forward way we
can have a "best of both worlds" type situation....
DISCLAIMER: I am not a docker expect, nor am i an expert on the docker-hub
rules for "official" images -- the idea below is just based on how the
current docker-solr/docker-solr github repo works. (I should also mention
I'm not up to speed on the docker related bits in lucene-solr master for
building "local" images, for now I'm just ignoring that and assuming it's
fair game to start over from scratch with how building docker images from
a source release/checkout work)
The crux of my suggestion is that we keep a Dockerfile.template in
the lucene-solr repo, on master (and any future branches) which has
templated values for the SOLR_VERSION and SHA512 of the
"solr-SOLR_VERSION.tgz" file names.
as part of the "gradle assemble" process, right after gradle creates
./packaging/build/distributions/solr-FOO.tgz and
./packaging/build/distributions/solr-FOO.tgz.sha512, the
Dockerfile.template should be used to create Dockerfile with the
corisponding file names and SHA512 values hardcoded into it.
the Dockerfile(.template) should have COPY directive that looks something
like...
COPY ./solr-FOO.tgz* /opt/solr/dist-archive
...followed by a RUN command invoking bash conditionals to download
solr-FOO.tgz from SOLR_DOWNLOAD_URL into /opt/solr/dist-archive if and
only if /opt/solr/dist-archive/solr-FOO.tgz doesn't already exist -- and
if it does exist to touch some file
/opt/solr/dist-archive/this.is.a.local.build.txt
RUN script logic after this should attempt GPG validation (via KEYS & asc
files fetched from dist.apache.org) if and only if
/opt/solr/dist-archive/this.is.a.local.build.txt does not exist. (Either
way the hardcoded SHA512 value should be used to validate the tgz file
matches expectations)
This should allow us to have "Local" docker builds that don't require
any network access or downloading special files either by putting the
(post-templating) Dockerfile directly in ./packaging/build/distributions/
and telling people to use that as the context for "docker build" or by
some other gradle helper logic for constructing a special "docker context
dir" for people to build from where gradle copies the solr-FOO.tgz file.
"Official" docker-solr builds could use the exact same Dockerfile --
committed to the docker-solr/docker-solr (or some future
apache/docker-solr) repo by the RM via some release publishing scripts
(Any other "files" in the lucene-solr git repo that we want to be part
of docker images could likewise be copied to the "local" docker context
dir by gradle and/or to the apache/docker-solr repo by the release
publishing scripts -- but I would argue that as much as possible those
files should "live" inside the solr-FOO.tgz binary release)
Does anyone see any holes in this idea that i've missed? ... the need for
a "pre-processing" step to convert Dockerfile.template -> Dockerfile may
seem like a disadvantage of this process compared to other "simpler" ways
to build a "local" docker image (w/o needing any hard coded values) but no
matter what type of local docker image build process we'd like to have,
users will have to run *some* gradle command to compile the source code,
etc... so it doesn't seem like that much of a headache to add this if it
means the resulting Dockerfiles are also "viable" for use as official
_/solr Dockerfiles
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
