Package Usage: go: github.com/containerd/platforms
Package platforms provides a toolkit for normalizing, matching and
specifying container platforms.
Centered around OCI platform specifications, we define a string-based
specifier syntax that can be used for user input. With a specifier, users
only need to specify the parts of the platform that are relevant to their
context, providing an operating system or architecture or both.
How do I use this package?
The vast majority of use cases should simply use the match function with
user input. The first step is to parse a specifier into a matcher:
Once you have a matcher, use it to match against the platform declared by a
component, typically from an image or runtime. Since extracting an images
platform is a little more involved, we'll use an example against the
platform default:
This can be composed in loops for resolving runtimes or used as a filter for
fetch and select images.
More details of the specifier syntax and platform spec follow.
Components that have strict platform requirements should use the OCI
platform specification to declare their support. Typically, this will be
images and runtimes that should make these declaring which platform they
support specifically. This looks roughly as follows:
Most images and runtimes should at least set Architecture and OS, according
to their GOARCH and GOOS values, respectively (follow the OCI image
specification when in doubt). ARM should set variant under certain
discussions, which are outlined below.
While the OCI platform specifications provide a tool for components to
specify structured information, user input typically doesn't need the full
context and much can be inferred. To solve this problem, we introduced
"specifiers". A specifier has the format
`<os>|<arch>|<os>/<arch>[/<variant>]`. The user can provide either the
operating system or the architecture or both.
An example of a common specifier is `linux/amd64`. If the host has a default
of runtime that matches this, the user can simply provide the component that
matters. For example, if a image provides amd64 and arm64 support, the
operating system, `linux` can be inferred, so they only have to provide
`arm64` or `amd64`. Similar behavior is implemented for operating systems,
where the architecture may be known but a runtime may support images from
different operating systems.
Because not all users are familiar with the way the Go runtime represents
platforms, several normalizations have been provided to make this package
easier to user.
The following are performed for architectures:
We also normalize the operating system `macos` to `darwin`.
To qualify ARM architecture, the Variant field is used to qualify the arm
version. The most common arm version, v7, is represented without the variant
unless it is explicitly provided. This is treated as equivalent to armhf. A
previous architecture, armel, will be normalized to arm/v6.
Similarly, the most common arm64 version v8, and most common amd64 version v1
are represented without the variant.
While these normalizations are provided, their support on arm platforms has
not yet been fully implemented and tested.
4 versions
Latest release: over 1 year ago
2 dependent packages
View more package details: https://packages.ecosystem.code.gouv.fr/registries/proxy.golang.org/packages/github.com/containerd/platforms