[
https://issues.apache.org/jira/browse/SOLR-15250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315119#comment-17315119
]
Houston Putman commented on SOLR-15250:
---------------------------------------
Sorry for the very late reply [~hossman], but now I have time to help out with
this.
I'll list out my thoughts:
* Perfectly happy to move the docker-scripts to a different directory in the
TGZ, but I would prefer for them to not live under {{server/}}
* I’m not sure it’s necessary to have all of that logic in the Dockerfile that
isn’t used until release time. When we were talking about templating, I was
imagining that the Keys/Download/Verification logic would be injected, along
with all of those ARGs. It certainly works in the patch that you have, but it’s
hard to tell what’s used for each build style.
* So the way that this works with the Docker official images, we will probably
want to create a directory with just the official image Dockerfile in it, so
{{build/official-image-src/}} or something like that.
Actually we probably
want to create a folder (not in the build directory) that stores it, so that we
can commit it when we cut the official release in Git. Therefore we have
somewhere to point to here:
[https://github.com/docker-library/official-images/blob/master/library/solr]
We
would need to remove the folder after upping the branch version (8.8.0 ->
8.8.1-SNAPSHOT). But we do need it in the git history
* I’m +1 to downloading the keys, but it wouldn’t be hard to add the key in
the release logic. It’s something the release wizard already knows about. Not
sure if the docker people would be ok with it though, they seem to suggest
putting the key in the Dockerfile
[https://github.com/docker-library/official-images#security]
=
* We need to change FROM $BASE_IMAGE to FROM <BASE_IMAGE>. The Docker team has
scripts that go and check the FROMs to make sure that they are approved images.
* All of the other args should go after the FROM, I believe
If we are decided on using the official Docker image, then I think this is a
good start!
> Dockerfile for local builds that can also serve as template for 'official'
> docker images
> ----------------------------------------------------------------------------------------
>
> Key: SOLR-15250
> URL: https://issues.apache.org/jira/browse/SOLR-15250
> Project: Solr
> Issue Type: Sub-task
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-15250.patch
>
>
> This issue tracks PoC work experimenting with the idea of the following
> workflow:
> For Users:
> * a {{Dockerfile}} (or {{Dockerfile.local}}) in our git repo that can be
> used (directly or via gradle) to build docker images directly from a local
> solr.tgz (in the docker build context)
> For Release Manager:
> * The exact same {{Dockerfile}} serves as a "template" that gradle tasks use
> to generate a {{build/Dockerfile.official}} via some very simple
> substitutions to fill in ARG defaults based on the "official"
> solr-VERSION.tgz for this release
> * This {{Dockerfile.official}} can then be committed to the docker-solr
> github repo (or some similar new 9.x+ repo) and can be build with a a
> completely empty build context – in which it downloads (and validates) the
> official solr-VERSION.tgz (based on the ARG values that were filled in during
> the release)
> * Automated tests can help us "validate" that the generated
> {{Dockerfile.official}} will work _prior_ to officially publishing release
> artifacts, by using a "mock" download server to host the local
> solr-VERSION.tgz file
> The driving goal being that the Dockerfile used for official {{_/solr}}
> builds should be as close as possible to identical to the Dockerfile used for
> "local" builds by users – given the constraints put on us by the
> docker-library team.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
