[
https://issues.apache.org/jira/browse/SOLR-15127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277542#comment-17277542
]
Chris M. Hostetter commented on SOLR-15127:
-------------------------------------------
bq. David Smiley's suggestion of using the Solr TGZ release as the docker
context itself.
That's pretty close to what i do in one code path of this patch -- except that
(as you mentioned) the Dockerfile and solr/docker/scripts aren't in the
solr.TGZ so i left in the existing build.gradle logic to provide those.
I do however think there is a lot of value in supporting the "build from a
remote git url" approach as well, since it let's people build from arbitrary
branches w/o a local java env. I also think that from a _transparency_
standpoint with the official builds, it would be better to build them from
_source_ ... either the official git tag, or perhaps using the solr-src.tgz
release instead of the (compiled) solr.tgz?
The broader question I have though at this point is how people feel about this
style of "all in one" Dockerfile that uses 'sh' conditional logic in the RUN to
support 2 diff ways to building:
* "docker stage runs gradle to create solr.tgz; then creates & lays out image"
** makes it easy to use git repo or solr-src.tgz as build context for
transparency and portable building of docker images w/o java dev env
* "gradle builds solr.tgz; then invokes docker to create & layout image"
** makes it eas(ier) for people to iteratively develop/patch solr in their java
env & then build docker images from that
It really feels like the best of both worlds to me.
----
bq. I think we can actually add the version as a file inside the release, and
then read it into an env var as a part of RUN. Then we can sym-link from
/opt/solr to /opt/solr-$version, to keep backwards compatibility.
I wasn't sure if there was a *reason* to keep the symlink approach, but yeah,
it would be easy to add back if needed. I don't really have any strong
feelings on where it happens -- just trying to take advantage of the fact that
we can be multi-stage.
bq. Did you move it to the builder so that the final image wouldn't need the
GITHUB_URL arg?
My goal was just to move everything that *could* be in the builder stage into
the builder stage, to "fail fast" and try to keep the final image as small as
possible.
> All-In-One Dockerfile for building local images as well as reproducible
> release builds directly from (remote) git tags
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-15127
> URL: https://issues.apache.org/jira/browse/SOLR-15127
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-15127.patch
>
>
> There was a recent dev@lucene discussion about the future of the
> github/docker-solr repo and (Apache) "official" solr docker images and using
> the "apache/solr" nameing vs (docker-library official) "_/solr" names...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3CCAD4GwrNCPEnAJAjy4tY%3DpMeX5vWvnFyLe9ZDaXmF4J8XchA98Q%40mail.gmail.com%3E
> In that disussion, mak pointed out that docker-library evidently allows for
> some more flexibility in the way "official" docker-library packages can be
> built (compared to the rules that were evidnlty in place when the mak setup
> the current docker-solr image building process/tooling), pointing out how the
> "docker official" elasticsearch images are current built from the "elastic
> official" elasticsearch images...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3C3CED9683-1DD2-4F08-97F9-4FC549EDE47D%40greenhills.co.uk%3E
> Based on this, I proposed that we could probably restructure the Solr
> Dockerfile so that it could be useful for both "local development" -- using
> the current repo checkout -- as well as for "apache official" apache/solr
> images that could be reproducibly built directly from pristine git tags using
> the remote git URL syntax supported by "docker build" (and then -- evidently
> -- extended by trivial one line Dockerfiles for the "docker-library official"
> _/solr images)...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3Calpine.DEB.2.21.2101221423340.16298%40slate%3E
> This jira tracks this idea.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
