skopeo VS distribution-spec

You can use hashes to verify if a microservice needs to be redeployed—if the code for a specific microservice has not changed, you can skip the deployment for that microservice. Since each image only contains service-specific code after pruning, the resulting image digest will only change when relevant code changes. Compare the new image digest against the one currently in your container registry using skopeo:

That’s why I built an automation script to migrate images quickly and safely. It uses skopeo under the hood to copy images between repositories without pulling and pushing them manually.

I believe skopeo should allow you to: https://github.com/containers/skopeo

I decided to go searching for an alternative means to pull a docker image. In my search I discovered Skopeo, an alternative method to download Docker images that proved to be surprisingly effective. It not only downloaded the image faster, it also allowed me to save my image in a tar file, which means you can pull an image on one system and share that image to another system, loading it easily to docker instance on that system. This can be very beneficial if you have multiple systems and don't want to download an image multiple times.

But I'd suggest looking into if it's solved by other tools already, like regclient/regclient and their regsync features or something like containers/skopeo.

Have a use case where we have a CLI (built with cobra) for our dev teams which can execute common tasks. One of those tasks we want to implement is to copy docker images from the internet to our internal registry. A tool such as skopeo can do this and much more. Instead of essentially re-writing the functionality directly into our CLI we'd like to embed it. This would also negate the need for the dev teams to manage multiple CLI tools.

Self hoisting here, I put this together to make it easier to generate single (extra) layer docker images without needing a docker agent, capabilities, chroot, etc: https://github.com/andrewbaxter/dinker

Caveat: it doesn't work on Fly.io. They seem to be having some issue with OCI manifests: https://github.com/containers/skopeo/issues/1881 . They're also having issues with new docker versions pushing from CI: https://community.fly.io/t/deploying-to-fly-via-github-actio... ... the timing of this post seems weird.

FWIW the article says

> create a Docker image, also known as an OCI image

I don't think this is quite right. From my investigation, Docker and OCI images are basically content addressed trees, starting with a root manifest that points to other files and their hashes (root -> images -> layers -> layer configs + files). The OCI manifests and configs are separate to Docker manifests and configs and basically Docker will support both side by side.

skopeo is another tool worth looking into. we've started deploying amd and arm nodes into our k8s clusters, and this tool was incredibly easy to build around for getting multi-arch images into our container registry.

I would use skopeo, the tool is quite handy for working with remote images. https://github.com/containers/skopeo

Using distroless images not only reduces the size of the container image it also reduces the surface attack. The need for container image signing is because even with the distroless images there is a chance of facing some security threats such as receiving a malicious image. We can use cosign or skopeo for container signing and verifying. You can read more about securing containers with Cosign and Distroless Images in this blog.

As DevOps became more standardised, it brought a necessity of having a standard way to package software applications that allowed them to be used accross different machine configurations. This led to the birth of "containers". However, for a while there where multiple continer technologies such as Docker, rkt, Warden, LXC. To solve this, a bunch of industry leaders decided to come together and decided to draft a standardized specification for containers which resulted into The Open Container Initiative.

RamaLama is an open-source tool built under the containers organization that makes running AI models locally as straightforward as working with containers. The goal is to make AI inference boring and predictable. RamaLama handles host configuration by pulling an OCI (Open Container Initiative) container image tuned to the hardware it detects on your system, so you skip the manual dependency setup entirely.

Both services allow you to run your code in standard Open Container Initiative (OCI) images, completely abstracting away the operational headache of managing permanent clusters. They share critical ecosystem features: both can be triggered for periodic execution using Cloud Scheduler and orchestrated into complex, multi-step data pipelines via Cloud Workflows.

buildah: A command-line tool that lets you build OCI compliant container images. It was created for K8s clusters to eliminate the need to use Docker Daemon for building images in order to deal with the above mentioned security risk.

The Open Container Initiative is an organization aimed at creating industry standards for containers and runtimes.

Modern platforms nearly all build on top of containers as their foundational element to run executable code. This is a logical evolution from Docker's meteoric growth, and the ecosystem that grew around its open standards (such as the OCI - Open Container Initiative). While containers provide a huge step in terms of ease of use, standardization, and security compared to shipping raw artefacts to virtual machines, as was the case before them, they do have some shortcomings.

Behind the scenes, each tool implements the Open Container Initiative (OCI) specifications. These define standard behavior for container images, runtimes, and registries to permit interoperability within the container ecosystem.

You need a containerd on the remote end (Docker and Kubernetes use containerd) and anything that speaks registry API (OCI Distribution spec: https://github.com/opencontainers/distribution-spec) on the client.

You can use skopeo, crane, regclient, BuildKit, anything that speaks OCI-registry on the client. Although you will need to manually run unregistry on the remote host to use them. 'docker pussh' command just automates the workflow.

Just check it out, it's a bash script. You can hack your own way pretty easily.