For convenience, we will define the following environment variables:
If you specify values for your setup, you can directly use the commands shown in the next steps.
The variable OCM_REPO is set to a location of an OCI registry where artifacts and component
descriptors are stored (omitting the https:// prefix). For example,
GitHub Packages can be used as an OCI registry. Many other
options exist.
Let’s assume that we are creating a component based on a GitHub source repository.
The first step when creating a new component version is to create a component archive. A component archive contains references, resources, and sources. The ocm CLI tool can help with this.
The next step is ocm add resources.
In this example, we want to add the Helm Chart podinfo to the component archive.
If you do not have a Helm Chart available locally, you can follow these steps:
What happened?
The generated file structure is:
The added blob contains the packaged Helm Chart. The blob is referenced in the component descriptor
in component.resources.access.localreference:
Because we use content from the local environment, it is directly packaged into the component archive
using the access method of type
localBlob.
Alternatively, you can add an image as a resource built locally using Docker before. It will be picked up from the local Docker file system and added to the component archive.
What happened?
The Docker image is downloaded from the Docker daemon, converted to an OCI artifact,
and added as local artifact to the component version.
The component descriptor now has the content:
You could simplify the previous two steps (adding helm chart and image as resources) by using a text file as input. For that, you could create a file resources.yaml, which looks like this:
A resource is described either by its access information to a remote repository or by locally
provided resources. For remote access, the field access is used to describe the
access method. The type field is used to specify the kind of access.
If the resource content should be taken from local resources, the field input is used to specify
the access to local resources. In this case, the resource content is directly put into the component
archive. Similarly to the access attribute, the kind of the input source is described by the field type.
The input types are not part of the input specification but are provided locally by the OCM command
line client. For available input types, see ocm add resources.
For more complex scenarios, the description files might use variable substitution (templating), see Best Practices.
Add the resources using the following command:
For a local image built with Docker use this file:
(Note: If this file is used, the output of the following instructions will differ since another local resource was added.)
If you have created multiple components according to the instructions above, you can bundle
them into a single archive entity. This can be done by creating a transport archive using the common transfer format (CTF).
The transport archive is the entity that does the transfer between
component repositories. It is used to transfer entire deployments between
locations.
A transport archive may contain any number of component versions. It may also be pushed to an OCM repository.
Note that a transport archive is also an OCM repository, so it can also be used as source or as a target
for transport operations.
What happened?
The resulting transport archive has the following file structure:
The transport archive’s contents can be found in artifact-index.json. This file
contains the list of component version artifacts to be transported.
The content of the transport archive is stored as OCI artifacts. Notice that the repository names of Component Version artifacts (found at artifacts.respository) are prefixed by component-descriptors/.
The component version is described as an OCI manifest:
Notice that the output of the component version above contains the component descriptor as one of the layers. It can be identified by its content type, which is application/vnd.ocm.software.component-descriptor.v2+yaml+tar. In this case, the component descriptor can be displayed with the following command:
The other elements listed as layers describe the blobs for the local resources stored along with the component version. The digests can be seen in the localReference attributes of the component descriptor.
The previous steps can be combined into a single operation working on a single description file that can contain multiple components:
Creating a Common Transport Archive
Adding one or more components
With resources, sources, and references
The command ocm add componentversions
directly creates or extends a common transport archive without the need for creating dedicated component archives.
Create a yaml configuration file component-constructor.yaml, which contains information about the components
to create and the elements added to those components. You can use our public configuration schema to validate the configuration. The schema is available at https://ocm.software/schemas/configuration-schema.yaml and can be used in your editor to validate the configuration (e.g., in Visual Studio Code).
What happened?
The command creates the common-transport-archive (option --create) and adds the listed components
with the described resources.