Open rur0 opened 4 years ago
Is there any fix for this? I ran into the same issue when trying to create a manifest, on my local machine, as well as on GitHub workflows: https://github.com/MarcusWichelmann/PrometheusSolarExporter/runs/606703836
My script:
docker tag image:amd64 $IMAGE_ID:$BRANCH_OR_TAG-amd64
docker tag image:arm32v7 $IMAGE_ID:$BRANCH_OR_TAG-arm32v7
docker tag image:arm64v8 $IMAGE_ID:$BRANCH_OR_TAG-arm64v8
docker push $IMAGE_ID:$BRANCH_OR_TAG-amd64
docker push $IMAGE_ID:$BRANCH_OR_TAG-arm32v7
docker push $IMAGE_ID:$BRANCH_OR_TAG-arm64v8
docker manifest create $IMAGE_ID:$BRANCH_OR_TAG $IMAGE_ID:$BRANCH_OR_TAG-amd64 $IMAGE_ID:$BRANCH_OR_TAG-arm32v7 $IMAGE_ID:$BRANCH_OR_TAG-arm64v8
--> no such manifest
To help anyone who's having this issue with an 'insecure' registry: adding the --insecure
flag to my create command resolved this for me.
A quick look at the source indicates that the error messages that are actually helpful in this case are hidden behind debug logging.
@adamsteinbok Thanks for the help, it looks like you do need to add --insecure flag when creating manifest on a insecure registry.
I had added
{
"insecure-registries": ["registry_ip:port"]
}
in /etc/docker/daemon.json and ~/.docker/config.json; assuming it would trickle down to all commands.
however, now I am getting this:
$ docker manifest push --insecure 192.168.5.3:31000/authservice
failed to configure transport: error pinging v2 registry: Get "https://192.168.5.3:31000/v2/": http: server gave HTTP response to HTTPS client
As far as I can tell, you need both the 'insecure-registries' entry in the daemon.json AND the --insecure
flag on the client command.
First of all you need to push your docker images which are in manifest list to your remote docker registry ,then pull back those images.After that , you can try 'docker manifest create --insecure xxx/xxx:xx xxx/yyy:yy xxx/zzz:zz ' command .
I've experienced the same issue; needing to push images to a remote registry before being able to create the manifest.
My expectation is that manifest create
would behave in a the same way as a build
or tag
, such that images and manifests can be built locally without needing a remote registry.
This has implications on CI pipelines, since the typical flow is to build and test images and only pushing them on success / release conditions being met.
Will this ever be fixed/improved?
Yes, would be great if this could be addressed (no need to push before creating the manifest), and some documentation is provided with best practices.
Alternatively, if it cannot be addressed just yet, it would be great if the current best practice is documented in a way that it's easy to apply to CI workflows (Azure DevOps, GitLab CI, GitHub Actions, Bitbucket Pipelines, etc.)
Github Enterprise Server does not support manifests for multi-arch containers? Getting multiple failures for GHES
Description docker manifest create returns 'no such manifest'
Steps to reproduce the issue:
Describe the results you received:
Describe the results you expected: As described by the docs, to be able to push this manifest to a docker registry and use the multiarch image
Additional information you deem important (e.g. issue happens only occasionally):
Output of
docker version
:Output of
docker info
:Additional environment details (AWS, VirtualBox, physical, etc.):