[
https://issues.apache.org/jira/browse/SOLR-15127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277530#comment-17277530
]
Houston Putman edited comment on SOLR-15127 at 2/2/21, 11:49 PM:
-----------------------------------------------------------------
I think there are two possible ways of going forward with something that the
official Docker image people might be ok with.
# Using the git tags, as with your example. Doing the gradle build in the
multi-stage build.
# [~dsmiley]'s suggestion of using the Solr TGZ release as the docker context
itself.
** In order to have the Solr TGZ become the docker context, we would merely
need to add the Dockerfile and solr/docker/scripts to the release.
I'll put up a PR that would use the Solr TGZ as the docker context, allowing us
to use docker build directly with the released artifacts. That way we can
compare pros/cons of each approach. (Can be found at SOLR-15129)
Besides this bigger question. There are some things I really like in your patch:
* Trying to remove the SOLR_VERSION argument (Big improvement, as there would
be no required ARGs)
** 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.
* Consolidating the last two RUN layers
I am split on the jattach thing. It will be great when it can be moved to the
{{apt-get install}} section. Until then, I don't mind if it's fetched in the
actual image or the builder image. Did you move it to the builder so that the
final image wouldn't need the GITHUB_URL arg?
was (Author: houston):
I think there are two possible ways of going forward with something that the
official Docker image people might be ok with.
# Using the git tags, as with your example. Doing the gradle build in the
multi-stage build.
# [~dsmiley]'s suggestion of using the Solr TGZ release as the docker context
itself.
** In order to have the Solr TGZ become the docker context, we would merely
need to add the Dockerfile and solr/docker/scripts to the release.
I'll put up a PR that would use the Solr TGZ as the docker context, allowing us
to use docker build directly with the released artifacts. That way we can
compare pros/cons of each approach.
Besides this bigger question. There are some things I really like in your patch:
* Trying to remove the SOLR_VERSION argument (Big improvement, as there would
be no required ARGs)
** 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.
* Consolidating the last two RUN layers
I am split on the jattach thing. It will be great when it can be moved to the
{{apt-get install}} section. Until then, I don't mind if it's fetched in the
actual image or the builder image. Did you move it to the builder so that the
final image wouldn't need the GITHUB_URL arg?
> 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
