Thanks to Skopeo, we can easily copy container images from one registry to another. In this article, we’ll copy images from docker.io to quay.io, a container registry that has a lot of features that docker.io doesn’t provide. The first feature that I really like is the ability to list and manage image vulnerabilities and other security information. The second is the ability to manage image manifests.
I wrote a small script that one can use to automate image copying. Before running the script, do the following:
- Get an OAuth token from https://quay.io/organization/[your-org]?tab=applications.
- Change the token, namespace, containers, and tag (if needed).
- If your docker.io registry requires authentication, run
podman login docker.io( the–src-credsoption can also be used with Skopeo). - Authenticate against your quay.io registry with
podman login quay.io(the–dest-credsoption can also be used with Skopeo).
Here is the script:
#!/bin/sh
set -ex
# get OAuth token from https://quay.io/organization/[your-org]?tab=applications
token='secrete'
namespace=yourorg
containers='app1 app2'
tag=latest
retry() {
local -r -i max_attempts="$1"; shift
local -r cmd="$@"
local -i attempt_num=1
until $cmd
do
if ((attempt_num==max_attempts))
then
echo "Attempt $attempt_num failed and there are no more attempts left!"
return 1
else
echo "Attempt $attempt_num failed! Trying again in $attempt_num seconds..."
sleep $((attempt_num++))
fi
done
}
for container in $containers; do
# create empty public repo first otherwise skopeo will create the image as private
curl -X POST https://quay.io/api/v1/repository \
-d '{"namespace":"'$namespace'","repository":"'$container'","description":"Container image '$container'","visibility":"public"}' \
-H 'Authorization: Bearer '$token'' -H "Content-Type: application/json"
# workaround if quay.io returns 500 error, likely due to an internal bug when using skopeo against docker.io
copy="skopeo copy docker://docker.io/$namespace/$container:$tag docker://quay.io/$namespace/$container:$tag"
retry 5 $copy
done
As you can see, there are two unusual things in this script. First, the curl command creates an empty public image; otherwise, quay.io would create a private image by default when copying the image with Skopeo. As far as I know, there is no option in quay.io to change the default policy. Of course, you can remove it if you don’t want your image to be public by default.
Second, the retry mechanism works around the 500 error that tells you that the repository already exists when Skopeo provisions a new repository (which sounds specific to how the registry receives authentication from Skopeo vs. Docker CLI).
For more information, check out the quay.io documentation.
Enjoy Skopeo and quay.io!
About the author
Emilien has been contributing to OpenStack since 2011 when it was still a young project. He has helped customers have a better experience when deploying, upgrading and operating OpenStack at large scale. His current focus is the integration between OpenShift and OpenStack. He's maintainer of core components including the Cluster API Provider for OpenStack and Gophercloud. Technical and team leader at Red Hat, he's developing leadership skills with passion for teamwork and technical challenges. He loves sharing his knowledge and often give talks to conferences.
More like this
More than meets the eye: Behind the scenes of Red Hat Enterprise Linux 10 (Part 4)
Red Hat and Sylva unify the future for telco cloud
The Containers_Derby | Command Line Heroes
Can Kubernetes Help People Find Love? | Compiler
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Virtualization
The future of enterprise virtualization for your workloads on-premise or across clouds