crane, An Image Built Offline, A Registry Asked

crane

go-containerregistry crane on EL 10 from the vendor's release, checked against the published SHA-256, pinned to a version, installed as root's binary in /usr/local/bin. Original role for EL 10, live-tested with podman on Rocky Linux 10.

No package worth the name. EL 10 carries no crane, and a third-party repository is one more key to trust. This role takes the release from github.com/google/go-containerregistry, has Ansible's get_url refuse the asset unless its SHA-256 is the published one, and the live test checks the asset on disk against the same published value again.

Pinned. crane_version is what gets installed, kept in a directory of its own so the checksum file and the asset it names stay together. A newer release is a variable change and a run; the same version is changed=0.

Proven to run. The live test runs crane append --oci-empty-base -f /tmp/cr-p/layer.tar -t probe:1 -o /tmp/cr-p/probe.tar and expects "base unspecified, using empty image" - the binary ran all the way to the point where it needed something this host does not have.

An image built offline, a registry asked. The live test tars one file into a layer, has crane append --oci-empty-base build an image tarball from it (it says so: "base unspecified, using empty image"), lists the tarball (it holds manifest.json), and has crane ls ask a registry on a port nothing listens on: the connection is refused, which is the first registry call made. Copying, tagging, digesting and mutating images against a real registry are the same binary with credentials from crane auth login or the Docker config. The tarball also holds gcrane and krane, which this role does not install.

License

Commercial - IaC Bazaar EULA. (c) IaC Bazaar.