| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for creating multi-layer OCI images with explicit layer
definitions via OCI_LAYERS variable. This enables fine-grained control
over container layer composition.
New variables:
- OCI_LAYER_MODE: Set to "multi" for explicit layer definitions
- OCI_LAYERS: Define layers as "name:type:content" entries
- packages: Install specific packages in a layer
- directories: Copy directories from IMAGE_ROOTFS
- files: Copy specific files from IMAGE_ROOTFS
Package installation uses Yocto's package manager classes (RpmPM,
OpkgPM) for consistency with do_rootfs, rather than calling dnf/opkg
directly.
Example usage:
OCI_LAYER_MODE = "multi"
OCI_LAYERS = "\
base:packages:base-files+base-passwd+netbase \
shell:packages:busybox \
app:packages:curl \
"
This creates a 3-layer OCI image with discrete base, shell, and app
layers that can be shared and cached independently.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add example recipes demonstrating multi-layer OCI image building:
alpine-oci-base_3.19.bb:
- Fetches Alpine 3.19 from Docker Hub using container-bundle
- Uses CONTAINER_BUNDLE_DEPLOY for use as OCI_BASE_IMAGE source
- Pinned digest for reproducible builds
app-container-alpine.bb:
- Demonstrates external base image usage
- Layers Yocto packages (busybox) on top of Alpine
- Uses OCI_IMAGE_CMD for Docker-like behavior
app-container-layered.bb:
- Demonstrates local base image usage
- Layers Yocto packages on top of container-base
- Uses OCI_IMAGE_CMD for Docker-like behavior
Both app containers produce 2-layer OCI images where the base layer
is shared, reducing storage and transfer costs.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This class creates installable packages that bundle pre-processed
container images. When installed via IMAGE_INSTALL, containers are
automatically merged into the target image's container storage.
Component relationships for bundling a local container:
1. Application Recipe (builds the software)
recipes-demo/myapp/myapp_1.0.bb
- Compiles application binaries
- Creates installable package (myapp)
2. Container Image Recipe (creates OCI image containing the app)
recipes-demo/images/myapp-container.bb
- inherit image image-oci
- IMAGE_INSTALL = "myapp"
- Produces: ${DEPLOY_DIR_IMAGE}/myapp-container-latest-oci/
3. Bundle Recipe (packages container images for deployment)
recipes-demo/bundles/my-bundle_1.0.bb
- inherit container-bundle
- CONTAINER_BUNDLES = "myapp-container:autostart"
- Creates installable package with OCI data
Flow: application recipe -> container image recipe -> bundle recipe
-> IMAGE_INSTALL in host image -> container deployed on target
Usage:
inherit container-bundle
CONTAINER_BUNDLES = "myapp-container:autostart redis-container"
CONTAINER_BUNDLES format: source[:autostart-policy]
- source: Container IMAGE recipe name or remote registry URL
- autostart-policy: Optional (autostart, always, unless-stopped, on-failure)
Features:
- Auto-generates dependencies on container image recipes (do_image_complete)
- Supports remote containers via skopeo (requires CONTAINER_DIGESTS)
- Runtime auto-detected from CONTAINER_PROFILE (docker/podman)
- Produces OCI directories and metadata for container-cross-install
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
| |
|
|
|
| |
Signed-off-by: Chris Laplante <chris.laplante@agilent.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
| |
|
|
|
| |
Signed-off-by: Chris Laplante <chris.laplante@agilent.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
| |
|
|
|
|
|
|
| |
Variable overrides have stopped working when this specific .inc
file are used. To keep the demo working, we temporarily copy the
exact contents of the .inc file into the recipe .. and all is well.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
| |
|
|
|
|
|
| |
This is useful for demonstrating how entry points and functionality
can be delivered in containers
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
|
To enable demonstrations of application container builds, and deployment
to k*s clusters, we introduce a simple recipes-demo/ structure with a
sample flask application and deployment yaml.
i.e. ensure that "helloworld-flask-deploy" is installed on your image,
and then:
% kubectl apply -f /etc/flask-app.yaml
% kubectl label pods zeddii-pod new-label=yoctorule
% kubectl expose pod zeddii-pod --port=9000 --target-port=9000 --type=LoadBalancer --name=my-service
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
