skopeo
Work with remote images registries - retrieving information, images, signing content
Top Related Projects
A tool that facilitates building OCI images.
Build Container Images In Kubernetes
Standalone, daemon-less, unprivileged Dockerfile and OCI compatible container image builder.
concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit
Podman: A tool for managing OCI containers and pods.
Quick Overview
Skopeo is a command-line utility for working with remote image registries. It allows users to inspect, copy, delete, and sign container images across various storage mechanisms, including container registries, local directories, and container daemon storage.
Pros
- Supports multiple image formats and storage types
- Enables image operations without a full container runtime
- Provides image signing and verification capabilities
- Integrates well with other container tools and workflows
Cons
- Limited graphical user interface options
- May require additional setup for certain operations (e.g., authentication)
- Learning curve for users new to container image management
- Some advanced features may not be as well-documented as core functionality
Getting Started
To install Skopeo on a Linux system, you can use your package manager. For example, on Fedora:
sudo dnf install skopeo
On Ubuntu or Debian:
sudo apt-get install skopeo
Once installed, you can use Skopeo to inspect an image:
skopeo inspect docker://docker.io/library/alpine:latest
To copy an image from one registry to another:
skopeo copy docker://docker.io/library/alpine:latest docker://quay.io/myuser/alpine:latest
For more detailed instructions and advanced usage, refer to the official Skopeo documentation.
Competitor Comparisons
A tool that facilitates building OCI images.
Pros of Buildah
- Allows building container images without a daemon, providing more flexibility and control
- Supports creating images from scratch, enabling highly customized and minimal containers
- Integrates well with other OCI-compliant tools and can produce OCI-compliant images
Cons of Buildah
- Primarily focused on image building, lacking Skopeo's extensive image inspection and manipulation capabilities
- May have a steeper learning curve for users familiar with Dockerfile-based workflows
Code Comparison
Buildah example:
buildah from alpine
buildah run alpine-working-container apk add --no-cache python3
buildah commit alpine-working-container my-python-image
buildah push my-python-image docker://registry.example.com/my-python-image:latest
Skopeo example:
skopeo inspect docker://registry.example.com/my-image:latest
skopeo copy docker://registry.example.com/my-image:latest docker://registry2.example.com/my-image:latest
Key Differences
- Buildah focuses on building and manipulating container images, while Skopeo specializes in inspecting, copying, and signing container images
- Skopeo is better suited for image management tasks across registries, while Buildah excels in creating custom images
- Buildah provides a more granular approach to image creation, whereas Skopeo offers streamlined operations for existing images
Build Container Images In Kubernetes
Pros of kaniko
- Designed specifically for building container images within containers, making it ideal for CI/CD pipelines
- Supports building images without root privileges, enhancing security
- Integrates well with Kubernetes environments
Cons of kaniko
- Limited to building container images, while skopeo offers broader image management capabilities
- May have slower build times compared to traditional Docker builds
- Requires more setup and configuration for non-Kubernetes environments
Code comparison
skopeo:
skopeo copy docker://source-registry.com/image:tag docker://destination-registry.com/image:tag
kaniko:
/kaniko/executor --context=dir:///workspace --destination=gcr.io/my-repo/image:tag
Key differences
- skopeo focuses on image management tasks like copying, inspecting, and signing
- kaniko specializes in building container images within containerized environments
- skopeo offers more versatility for general image operations, while kaniko excels in CI/CD pipelines for image building
Use cases
- Use skopeo for general container image management tasks across registries
- Choose kaniko for building images within containers, especially in Kubernetes-based CI/CD pipelines
Standalone, daemon-less, unprivileged Dockerfile and OCI compatible container image builder.
Pros of img
- Supports building container images without root privileges
- Offers a more user-friendly CLI interface
- Includes additional features like pruning and listing images
Cons of img
- Less mature and less widely adopted compared to Skopeo
- May have fewer integrations with other container tools
- Limited to OCI image format support
Code Comparison
img:
img build -t myimage:latest .
img push myimage:latest
img pull myimage:latest
Skopeo:
skopeo copy docker-archive:myimage.tar docker://registry.example.com/myimage:latest
skopeo inspect docker://registry.example.com/myimage:latest
skopeo delete docker://registry.example.com/myimage:latest
Key Differences
- img focuses on building and managing container images, while Skopeo specializes in image inspection and transfer between different storage mechanisms.
- Skopeo supports a wider range of image formats and registries, making it more versatile for complex container ecosystems.
- img provides a more streamlined experience for developers working with container images, especially those familiar with Docker commands.
Use Cases
- Choose img for local development and simple image management tasks, particularly when working without root privileges.
- Opt for Skopeo when dealing with multiple registries, formats, or when advanced image inspection and manipulation are required.
Both tools have their strengths, and the choice between them depends on specific project requirements and the existing container infrastructure.
concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit
Pros of buildkit
- More comprehensive build system with advanced caching and parallelization
- Supports multi-stage builds and complex Dockerfile instructions
- Integrates well with Docker and other container ecosystems
Cons of buildkit
- Steeper learning curve due to more complex features
- Primarily focused on building images, not inspecting or transferring them
- Requires more setup and configuration for standalone use
Code comparison
buildkit:
# syntax=docker/dockerfile:1.4
FROM alpine
RUN --mount=type=cache,target=/var/cache/apk \
apk add --update gcc
COPY . /src
RUN --mount=type=cache,target=/root/.cache/go-build \
go build -o /bin/myapp /src
skopeo:
skopeo copy docker://alpine:latest oci:alpine:latest
skopeo inspect docker://alpine:latest
Key differences
- buildkit is a comprehensive build system, while skopeo focuses on image operations
- skopeo excels at inspecting and transferring images across different storage types
- buildkit offers more advanced caching and optimization features for builds
- skopeo is simpler to use for basic image management tasks
- buildkit integrates more deeply with Docker and container runtimes
Podman: A tool for managing OCI containers and pods.
Pros of Podman
- Provides a full container management solution, including running containers
- Supports rootless containers, enhancing security
- Offers a Docker-compatible CLI, making migration easier
Cons of Podman
- Larger footprint and more complex than Skopeo
- May have a steeper learning curve for users new to container management
Code Comparison
Skopeo (image copying):
skopeo copy docker://registry.example.com/image:tag \
docker://registry.example.com/image:newtag
Podman (image copying):
podman pull registry.example.com/image:tag
podman tag registry.example.com/image:tag registry.example.com/image:newtag
podman push registry.example.com/image:newtag
Key Differences
Skopeo is focused on image operations and inspection, while Podman offers a complete container management solution. Skopeo is lighter and more specialized, making it ideal for CI/CD pipelines and automated image handling. Podman, on the other hand, provides a broader range of features, including running containers, which makes it suitable for development and production environments.
Both tools are part of the containers ecosystem and can be used complementarily. Skopeo excels at image operations, while Podman offers a more comprehensive container management experience.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
skopeo
is a command line utility that performs various operations on container images and image repositories.
skopeo
does not require the user to be running as root to do most of its operations.
skopeo
does not require a daemon to be running to perform its operations.
skopeo
can work with OCI images as well as the original Docker v2 images.
Skopeo works with API V2 container image registries such as docker.io and quay.io registries, private registries, local directories and local OCI-layout directories. Skopeo can perform operations which consist of:
- Copying an image from and to various storage mechanisms. For example you can copy images from one registry to another, without requiring privilege.
- Inspecting a remote image showing its properties including its layers, without requiring you to pull the image to the host.
- Deleting an image from an image repository.
- Syncing an external image repository to an internal registry for air-gapped deployments.
- When required by the repository, skopeo can pass the appropriate credentials and certificates for authentication.
Skopeo operates on the following image and repository types:
-
containers-storage:docker-reference An image located in a local containers/storage image store. Both the location and image store are specified in /etc/containers/storage.conf. (This is the backend for Podman, CRI-O, Buildah and friends)
-
dir:path An existing local directory path storing the manifest, layer tarballs and signatures as individual files. This is a non-standardized format, primarily useful for debugging or noninvasive container inspection.
-
docker://docker-reference An image in a registry implementing the "Docker Registry HTTP API V2". By default, uses the authorization state in
$XDG_RUNTIME_DIR/containers/auth.json
, which is set usingskopeo login
. -
docker-archive:path[:docker-reference] An image is stored in a
docker save
-formatted file. docker-reference is only used when creating such a file, and it must not contain a digest. -
docker-daemon:docker-reference An image docker-reference stored in the docker daemon internal storage. docker-reference must contain either a tag or a digest. Alternatively, when reading images, the format can also be docker-daemon:algo:digest (an image ID).
-
oci:path:tag An image tag in a directory compliant with "Open Container Image Layout Specification" at path.
Obtaining skopeo
For a detailed description how to install or build skopeo, see install.md.
Skopeo is also available as a Container Image on quay.io. For more information, see the Skopeo Image page.
Inspecting a repository
skopeo
is able to inspect a repository on a container registry and fetch images layers.
The inspect command fetches the repository's manifest and it is able to show you a docker inspect
-like
json output about a whole repository or a tag. This tool, in contrast to docker inspect
, helps you gather useful information about
a repository or a tag before pulling it (using disk space). The inspect command can show you which tags are available for the given
repository, the labels the image has, the creation date and operating system of the image and more.
Examples:
Show properties of fedora:latest
$ skopeo inspect docker://registry.fedoraproject.org/fedora:latest
{
"Name": "registry.fedoraproject.org/fedora",
"Digest": "sha256:0f65bee641e821f8118acafb44c2f8fe30c2fc6b9a2b3729c0660376391aa117",
"RepoTags": [
"34-aarch64",
"34",
"latest",
...
],
"Created": "2022-11-24T13:54:18Z",
"DockerVersion": "1.10.1",
"Labels": {
"license": "MIT",
"name": "fedora",
"vendor": "Fedora Project",
"version": "37"
},
"Architecture": "amd64",
"Os": "linux",
"Layers": [
"sha256:2a0fc6bf62e155737f0ace6142ee686f3c471c1aab4241dc3128904db46288f0"
],
"LayersData": [
{
"MIMEType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"Digest": "sha256:2a0fc6bf62e155737f0ace6142ee686f3c471c1aab4241dc3128904db46288f0",
"Size": 71355009,
"Annotations": null
}
],
"Env": [
"DISTTAG=f37container",
"FGC=f37",
"container=oci"
]
}
Show container configuration from fedora:latest
$ skopeo inspect --config docker://registry.fedoraproject.org/fedora:latest | jq
{
"created": "2020-04-29T06:48:16Z",
"architecture": "amd64",
"os": "linux",
"config": {
"Env": [
"DISTTAG=f32container",
"FGC=f32",
"container=oci"
],
"Cmd": [
"/bin/bash"
],
"Labels": {
"license": "MIT",
"name": "fedora",
"vendor": "Fedora Project",
"version": "32"
}
},
"rootfs": {
"type": "layers",
"diff_ids": [
"sha256:a4c0fa2b217d3fd63d51e55a6fd59432e543d499c0df2b1acd48fbe424f2ddd1"
]
},
"history": [
{
"created": "2020-04-29T06:48:16Z",
"comment": "Created by Image Factory"
}
]
}
Show unverified image's digest
$ skopeo inspect docker://registry.fedoraproject.org/fedora:latest | jq '.Digest'
"sha256:655721ff613ee766a4126cb5e0d5ae81598e1b0c3bcf7017c36c4d72cb092fe9"
Copying images
skopeo
can copy container images between various storage mechanisms, including:
-
Container registries
- The Quay, Docker Hub, OpenShift, GCR, Artifactory ...
-
Container Storage backends
-
github.com/containers/storage (Backend for Podman, CRI-O, Buildah and friends)
-
Docker daemon storage
-
-
Local directories
-
Local OCI-layout directories
$ skopeo copy docker://quay.io/buildah/stable docker://registry.internal.company.com/buildah
$ skopeo copy oci:busybox_ocilayout:latest dir:existingemptydirectory
Deleting images
$ skopeo delete docker://localhost:5000/imagename:latest
Syncing registries
$ skopeo sync --src docker --dest dir registry.example.com/busybox /media/usb
Authenticating to a registry
Private registries with authentication
skopeo uses credentials from the --creds (for skopeo inspect|delete) or --src-creds|--dest-creds (for skopeo copy) flags, if set; otherwise it uses configuration set by skopeo login, podman login, buildah login, or docker login.
$ skopeo login --username USER myregistrydomain.com:5000
Password:
$ skopeo inspect docker://myregistrydomain.com:5000/busybox
{"Tag":"latest","Digest":"sha256:473bb2189d7b913ed7187a33d11e743fdc2f88931122a44d91a301b64419f092","RepoTags":["latest"],"Comment":"","Created":"2016-01-15T18:06:41.282540103Z","ContainerConfig":{"Hostname":"aded96b43f48","Domainname":"","User":"","AttachStdin":false,"AttachStdout":false,"AttachStderr":false,"Tty":false,"OpenStdin":false,"StdinOnce":false,"Env":null,"Cmd":["/bin/sh","-c","#(nop) CMD [\"sh\"]"],"Image":"9e77fef7a1c9f989988c06620dabc4020c607885b959a2cbd7c2283c91da3e33","Volumes":null,"WorkingDir":"","Entrypoint":null,"OnBuild":null,"Labels":null},"DockerVersion":"1.8.3","Author":"","Config":{"Hostname":"aded96b43f48","Domainname":"","User":"","AttachStdin":false,"AttachStdout":false,"AttachStderr":false,"Tty":false,"OpenStdin":false,"StdinOnce":false,"Env":null,"Cmd":["sh"],"Image":"9e77fef7a1c9f989988c06620dabc4020c607885b959a2cbd7c2283c91da3e33","Volumes":null,"WorkingDir":"","Entrypoint":null,"OnBuild":null,"Labels":null},"Architecture":"amd64","Os":"linux"}
$ skopeo logout myregistrydomain.com:5000
Using --creds directly
$ skopeo inspect --creds=testuser:testpassword docker://myregistrydomain.com:5000/busybox
{"Tag":"latest","Digest":"sha256:473bb2189d7b913ed7187a33d11e743fdc2f88931122a44d91a301b64419f092","RepoTags":["latest"],"Comment":"","Created":"2016-01-15T18:06:41.282540103Z","ContainerConfig":{"Hostname":"aded96b43f48","Domainname":"","User":"","AttachStdin":false,"AttachStdout":false,"AttachStderr":false,"Tty":false,"OpenStdin":false,"StdinOnce":false,"Env":null,"Cmd":["/bin/sh","-c","#(nop) CMD [\"sh\"]"],"Image":"9e77fef7a1c9f989988c06620dabc4020c607885b959a2cbd7c2283c91da3e33","Volumes":null,"WorkingDir":"","Entrypoint":null,"OnBuild":null,"Labels":null},"DockerVersion":"1.8.3","Author":"","Config":{"Hostname":"aded96b43f48","Domainname":"","User":"","AttachStdin":false,"AttachStdout":false,"AttachStderr":false,"Tty":false,"OpenStdin":false,"StdinOnce":false,"Env":null,"Cmd":["sh"],"Image":"9e77fef7a1c9f989988c06620dabc4020c607885b959a2cbd7c2283c91da3e33","Volumes":null,"WorkingDir":"","Entrypoint":null,"OnBuild":null,"Labels":null},"Architecture":"amd64","Os":"linux"}
$ skopeo copy --src-creds=testuser:testpassword docker://myregistrydomain.com:5000/private oci:local_oci_image
Contributing
Please read the contribution guide if you want to collaborate in the project.
Commands
Command | Description |
---|---|
skopeo-copy(1) | Copy an image (manifest, filesystem layers, signatures) from one location to another. |
skopeo-delete(1) | Mark the image-name for later deletion by the registry's garbage collector. |
skopeo-generate-sigstore-key(1) | Generate a sigstore public/private key pair. |
skopeo-inspect(1) | Return low-level information about image-name in a registry. |
skopeo-list-tags(1) | Return a list of tags for the transport-specific image repository. |
skopeo-login(1) | Login to a container registry. |
skopeo-logout(1) | Logout of a container registry. |
skopeo-manifest-digest(1) | Compute a manifest digest for a manifest-file and write it to standard output. |
skopeo-standalone-sign(1) | Debugging tool - Sign an image locally without uploading. |
skopeo-standalone-verify(1) | Debugging tool - Verify an image signature from local files. |
skopeo-sync(1) | Synchronize images between registry repositories and local directories. |
License
skopeo is licensed under the Apache License, Version 2.0. See LICENSE for the full license text.
Top Related Projects
A tool that facilitates building OCI images.
Build Container Images In Kubernetes
Standalone, daemon-less, unprivileged Dockerfile and OCI compatible container image builder.
concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit
Podman: A tool for managing OCI containers and pods.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot