Push manifest lists when releasing docker images#248
Push manifest lists when releasing docker images#248luxas wants to merge 1 commit intokubernetes:masterfrom
Conversation
|
So this will set a hard requirement on Docker v1.10+? |
| if [[ -f $(which manifest-tool) ]]; then | ||
| MANIFEST_TOOL=$(which manifest-tool) | ||
| else | ||
| curl -sSL https://github.com/luxas/manifest-tool/releases/download/v0.3.0/manifest-tool > ./manifest-tool |
There was a problem hiding this comment.
this step should probably go in anago's check_prerequisites function.
and probably rather than automatically downloading, it should present instructions on how to download it.
as-is it'll make the git tree dirty.
| fi | ||
|
|
||
| # "docker login" to the gcr.io registry so we can push manifest lists to it | ||
| [[ "$registry" =~ gcr.io/ ]] && docker login -u oauth2accesstoken -p "$(gcloud auth print-access-token)" https://gcr.io |
There was a problem hiding this comment.
would gcloud docker -authorize-only achieve the same thing in a slightly more-readable way?
| [[ "$registry" =~ gcr.io/ ]] && docker login -u oauth2accesstoken -p "$(gcloud auth print-access-token)" https://gcr.io | ||
|
|
||
| # ml_platforms should be in the os1/arch1,os2/arch2,os3/arch3 form | ||
| local ml_platforms= $(echo "${KUBE_SERVER_PLATFORMS[@]}" | sed "s/ /,/g") |
There was a problem hiding this comment.
nits:
- declare var at top of function
local -r
| done | ||
|
|
||
| # This command will push a manifest list: "${registry}/${binary}-ARCH:${version}" that points to each architecture depending on which platform you're pulling from | ||
| $MANIFEST_TOOL push from-args --platforms ${ml_platforms} --template ${registry}/${binary}-ARCH:${version} --target ${registry}/${binary}-ARCH:${version} |
There was a problem hiding this comment.
is ARCH treated as a special value? should both the template and target contain ARCH?
There was a problem hiding this comment.
ARCH is a special value yes, it is replaced by the architectures in the platforms list
ugh, no, shouldn't be in --target
| logrun -r 5 -s ${docker_push_cmd[@]} push "$registry/$docker_target" | ||
|
|
||
| # If we have a amd64 docker image. Tag it without -amd64 also | ||
| # and push it for compatibility with earlier versions |
There was a problem hiding this comment.
What version of docker did we use in k8s 1.3? Does it support v2.2 manifests?
|
Issues go stale after 90d of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or |
|
@ixdy @mkumatag has volunteered to help drive this to completition now that gcr.io supports manifest lists. |
|
/remove-lifecycle stale |
|
The most recent manifest-tool is at https://github.com/estesp/manifest-tool/releases/tag/v0.7.0 and I think it has all of the added functions necessary to support this effort. |
|
Hey, any news on this? we would like to add functionality to kubeadm to deploy multi architecture platforms see: kubeadm should use multi-architecture images when GCR supports Docker distribution API v2 schema 2 which makes use of this additions. |
|
I'm working on getting k8s infra images manifest and its in-progress., kubernetes/kubernetes#57869 |
|
@mkumatag can you make a similar PR (i.e. rebase this PR essentially and submit a new, similar) as this so we can merge it in the v1.10 timeframe please? |
|
created a seperate PR based on this + some additional changes - #516 |
Yes
Nothing, @estesp has merged all the stuff to his repo already a long time ago.
Yes, now it does I'm gonna close this in favor of #516 |
update alpha cadence
Instead of pushing the amd64 image to
${registry}/${binary}:${version}we should push a manifest list: https://integratedcode.us/2016/04/22/a-step-towards-multi-platform-docker-images/More information: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/multi-platform.md
Release for the
manifest-toolbinary: https://github.com/luxas/manifest-tool/releases/tag/v0.3.0So basically, when pulling an
${registry}/${binary}:${version}image, docker will check which platform it is on and redirect and pull layers from the${registry}/${binary}-${arch}:${version}image instead. But the image name will always be${registry}/${binary}:${version}, so this is a true multi-platform image!You have to be logged in to a docker registry with
docker loginso I added that part as well.I can't test this, but I'm quite confident it will work, I've done the same thing for a lot of other images.
Can we merge this and produce an
v1.6.0-alpha.1release?Thanks in advance
@ixdy @david-mcmahon @ethernetdan @spxtr @saad-ali @jessfraz