Packaging
Components and interfaces are packaged as OCI artifacts.
The wasmCloud ecosystem uses the Open Container Initiative (OCI) image specification to package components and interfaces as OCI artifacts.
While we sometimes refer to them as "images," these artifacts are not container images—nonetheless, they conform to OCI standards and may be stored on any OCI-compatible registry. You can think of the OCI artifact layer as a thin shell of metadata wrapped around the component or interface.
Using the OCI specification for packaging means:
- wasmCloud can integrate with organizations' existing cloud native tooling such as registries.
- Components and interfaces are portable across the WebAssembly (Wasm) ecosystem, which uses OCI as a common packaging standard.
WebAssembly and OCI artifacts
The OCI specification enables users to create "artifacts," providing a standard set of guidelines for packaging objects other than container images.
WebAssembly components are a compelling use-case for OCI artifacts because, unlike containers, the same WebAssembly binary can run on any architecture or operating system. WebAssembly components can leverage the existing base of OCI tooling, enabling organizations to easily start packaging, distributing, and running components with OCI artifacts across environments.
wasmCloud and OCI artifacts
In the wasmCloud ecosystem, we use OCI images in two primary contexts:
- Packaging components
- WIT interface dependency management
Both of these use-cases are aligned with the wider WebAssembly ecosystem's implementation of OCI for component packaging and WIT interface dependency management, making both components and interfaces portable across platforms adopting open standards.
Publishing components as OCI artifacts
You can publish components as OCI artifacts using the wasmCloud Shell (wash) CLI.
You can learn more about publishing component artifacts to registries (and pulling them for local use) in the Wasm Shell Developer Guide. This page outlines how to authenticate to a registry and push and pull components.
Running components from OCI artifacts
Once a component or provider is published to a registry, you can include it in a CRD manifest, like so:
...
components:
- name: http-component
image: ghcr.io/wasmcloud/components/http-hello-world-rust:0.1.0
...In the manifest excerpt above, the http-component is included in a WorkloadDeployment manifest via an artifact (or "image") stored on a GitHub Packages registry. You can learn more about CRD manifests on the Custom Resource Definitions (CRDs) page.
WIT interface dependency management
The wasmCloud (and wider WebAssembly) ecosystem uses OCI artifacts to package and distribute WebAssembly Interface Type (WIT) interfaces that define the contracts between entities and typically serve as dependencies for a WebAssembly component.
wash builds on a set of open source tooling called Wasm Package Tools to handle the following jobs:
- Checking for WIT package dependencies
- Fetching WIT packages from known registries
- Pushing packages to your own registry
If you set a well-known interface as an import or export in your specified world file (usually world.wit), wash will ensure that you have the proper packages in your project directory when you build. The tooling reads the world and downloads the appropriate dependencies automatically into the wit/deps directory. With no further configuration, wash can download dependencies from the following well-known namespaces:
wasi: Interfaces proposed for the common WebAssembly System Interface (WASI) standardwasmcloud: Interfaces maintained as part of the wasmCloud projectba: Interfaces maintained by the Bytecode Alliance