To build:
go build -o cmd/crane/crane ./cmd/crane/
Copy image into registry (localhost:8080):
cmd/crane/crane copy \
ghcr.io/project-zot/zot-linux-amd64:v1.4.1-rc1 \
localhost:8080/project-zot/zot-linux-amd64:v1.4.1-rc1
Attach a "hello world" text file to the image:
echo "hello world" > hello.txt
cmd/crane/crane attach \
hello.txt \
text/plain \
misc \
localhost:8080/project-zot/zot-linux-amd64:v1.4.1-rc1
Check the manifest of the text file "image":
cmd/crane/crane manifest \
localhost:8080/project-zot/zot-linux-amd64@sha256:81055a87a63833469923e5afb6964cd79e8cff70c30bc6a442ab4d8a613d4068 | jq
Get the references result:
cmd/crane/crane refs \
localhost:8080/project-zot/zot-linux-amd64:v1.4.1-rc1 | jq
This is a golang library for working with container registries. It's largely based on the Python library of the same name.
The following diagram shows the main types that this library handles.
The overarching design philosophy of this library is to define interfaces that present an immutable
view of resources (e.g. Image,
Layer,
ImageIndex),
which can be backed by a variety of medium (e.g. registry,
tarball, daemon, ...).
To complement these immutable views, we support functional mutations that produce new immutable views of the resulting resource (e.g. mutate). The end goal is to provide a set of versatile primitives that can compose to do extraordinarily powerful things efficiently and easily.
Both the resource views and mutations may be lazy, eager, memoizing, etc, and most are optimized for common paths based on the tooling we have seen in the wild (e.g. writing new images from disk to the registry as a compressed tarball).
Over time, we will add new functionality under experimental environment variables listed here.
| Env Var | Value(s) | What is does |
|---|---|---|
GGCR_EXPERIMENT_ESTARGZ |
"1" |
When enabled this experiment will direct tarball.LayerFromOpener to emit estargz compatible layers, which enable them to be lazily loaded by an appropriately configured containerd. |
The simplest use for these libraries is to read from one source and write to another.
For example,
crane pullisremote.Image -> tarball.Write,crane pushistarball.Image -> remote.Write,crane cpisremote.Image -> remote.Write.
However, often you actually want to change something about an image.
This is the purpose of the mutate package, which exposes
some commonly useful things to change about an image.
If you're trying to use this library with a different source or sink than it already supports,
it can be somewhat cumbersome. The Image and Layer interfaces are pretty wide, with a lot
of redundant information. This is somewhat by design, because we want to expose this information
as efficiently as possible where we can, but again it is a pain to implement yourself.
The purpose of the partial package is to make implementing a v1.Image
much easier, by filling in all the derived accessors for you if you implement a minimal
subset of v1.Image.
You might think our abstractions are bad and you just want to authenticate and send requests to a registry.
This is the purpose of the transport and authn packages.
This repo hosts some tools built on top of the library.
crane is a tool for interacting with remote images
and registries.
gcrane is a GCR-specific variant of crane that has
richer output for the ls subcommand and some basic garbage collection support.
krane is a drop-in replacement for crane that supports
common Kubernetes-based workload identity mechanisms using k8schain
as a fallback to traditional authentication mechanisms.
k8schain implements the authentication
semantics used by kubelets in a way that is easily consumable by this library.
k8schain is not a standalone tool, but it is linked here for visibility.
Emeritus: ko
This tool was originally developed in this repo but has since been moved to its own repo.