Add multiversion and multiarch support (no more committed binaries) #74
Conversation
|
cc @stevvooe, @dmp42, @RichardScothern, @aaronlehmann, @dmcgowan -- is this still an accurate |
|
You can definitely remove Richard. |
|
Ok, thanks! How about this PR? Is this a sane direction? 🙏 |
|
I guess the concern here would be the size of the resulting image would increase (right?). wdyt? |
|
I did build tests and the image size was identical, but I'll get exact numbers as soon as I'm back at my computer. 👍 |
|
Since we do $ docker images registry
REPOSITORY TAG IMAGE ID CREATED SIZE
registry 2.5-new 67f17c192bbe 2 minutes ago 32.2MB
registry 2.6-new 5a66651566bc 2 minutes ago 32.9MB
registry 2.5 36e3b1f8d3f1 4 months ago 37.8MB
registry 2.6 d1fd7d86a825 4 months ago 33.3MBHere's sizes on $ docker images registry
REPOSITORY TAG IMAGE ID CREATED SIZE
registry 2.5-new 0cc8a98c5044 2 days ago 30.8MB
registry 2.6-new 37885a128820 2 days ago 31.4MB$ docker images registry
REPOSITORY TAG IMAGE ID CREATED SIZE
registry 2.5-new 79ff8fa06c84 10 seconds ago 33MB
registry 2.6-new ae4437e6611e 15 seconds ago 33.6MB |
|
Sweet. That's great. LGTM then. |
|
@dmcgowan can you have a quick look? cc @docker/dtr |
|
Friendly ping ❤️ |
|
Will do the cats herding :-) |
| rm -rf "$GOPATH"; \ | ||
| apk del .build-deps; \ | ||
| # smoke test | ||
| registry --version |
There was a problem hiding this comment.
Wouldn't a multi-stage build be a cleaner way to do this?
There was a problem hiding this comment.
FSVO, see docker-library/official-images#3383 for why we can't ATM
There was a problem hiding this comment.
When do you expect to upgrade the build infrastructure to use buildkit? It seems like that would address most the performance issues and make any arguments for using these hacky one liner RUN commands irrelevant. I don't mind merging this now to get multi-arch support but multi-stage build files would make this much cleaner and easier to maintain.
There was a problem hiding this comment.
The build infrastructure uses docker build directly, but building the Dockerfile is only part of the coordination problem outlined there -- we've got a lot of other tooling and scripts on top that help organize and schedule the builds that need changes to support multi-stage builds (and even getting an accurate accounting of all the places that might need changes is a tall order since it isn't always obvious).
|
My primary concern is there seems to be no control of the Go version used to build these images. For 2.5 I am not sure we have ever tested building and running with go 1.9 or 1.10. And not sure about 2.6 either. It would be preferable to build the images with the |
|
One simple-ish solution would be to publish "official" static binaries upstream -- then this image would be simpler (just downloading the static binary into the right place). |
|
Morning @tianon, how is this PR progressing? It seems as though the desire for ARM64 support is high. Do we know what's blocking? |
|
Yes, the note above from Derek about Go version is blocking AFAIK. I think
Alpine 3.8 can help there, although officially published binaries (as I
noted in the issue you also commented on) would be better, but more work
for the registry maintainers.
|
|
Many of the projects I've encountered use pre-built binaries. Setting up a build, test & publish infra shouldn't be too difficult and would pay dividends with respect to testing and assured functionality. |
|
@tianon, producing pre-built binaries, although better in the long run, seems a long way off. What is stopping us from using Derek's solution of specifying the Go version? Would it then unblock this PR for acceptance and ensure multi-arch on this project? |
|
Works on my ARM64 platform. Tested-by: Lee Jones lee.jones@linaro.org |
|
I've had this PR sitting in CI for a few weeks now. Still working. |
|
Please merge this to provide arm images. |
|
Any update on this commit getting merged? I just tested it out and works. I figure we want this merged since the registry is a fundamental image to the entire Docker ecosystem. |
|
Is there a timeline for this to merge? |
|
Yes please. Lots of requests for this now. 😃 |
|
Still waiting after all these months, despite so much interest. 😞 What's blocking this guys? |
|
Is there anything I can do to help push this along? |
|
Closing this in favor of #81 to support multiversion multiarch |
|
This branch was closed in favor of the #81 regarding arm, but s390x is still not available. Can this be reopened? |
This adapts the main https://github.com/docker/distribution
Dockerfileinto a singleRUNline so that we build theregistrybinary as part of this image build (since we'reFROM alpinenow and can do that), which not only makes it much more trivial to bump the version, but also makes it possible to support more architectures (I personally testeds390xandarm64v8successfully).I also added an explicit
Dockerfilefor 2.5 since it's still supported (https://github.com/docker-library/official-images/blob/87bf0e793eb5e3bf5c3384baaeb54a6c696677a1/library/registry), and updated to Alpine 3.7.Closes #48
Closes #54
Closes #56
Closes #59
Closes #60
Closes #62
Closes #64
Closes #73
Here's an example of how I'd structure
library/registryif this were merged, taking advantage of the newer file format to supportArchitectures: (happy to make that PR too, if you'd like!)