Go to file
Bruce Ashfield 29c60173e2 containers: introduce image-oci
This image class creates an oci image spec directory from a generated
rootfs. The contents of the rootfs do not matter (i.e. they need not be
container optimized), but by using the container image type and small
footprint images, we can create directly executable container images.

Once the tarball (or oci image directory) has been created of the OCI
image, it can be manipulated by standard tools. For example, to create a
runtime bundle from the oci image, the following can be done:

Assuming the image name is "container-base":

  If the oci image was a tarball, extract it (skip, if a directory is being directly used)
    % tar xvf container-base-<arch>-<stamp>.rootfs-oci-latest-x86_64-linux.oci-image.tar

  And then create the bundle:
    % oci-image-tool create --ref name=latest container-base-<arch>-<stamp>.rootfs-oci container-base-oci-bundle

  Or to copy (push) the oci image to a docker registry, skopeo can be used (vary the
  tag based on the created oci image:

    % skopeo copy --dest-creds <username>:<password> oci:container-base-<arch>-<stamp>:latest docker://zeddii/container-base

The following image variables are available to customize the details
of the constructed image (defaults as shown):

   OCI_IMAGE_AUTHOR ?= "${PATCH_GIT_USER_NAME}"
   OCI_IMAGE_AUTHOR_EMAIL ?= "${PATCH_GIT_USER_EMAIL}"

   OCI_IMAGE_TAG ?= "latest"
   OCI_IMAGE_RUNTIME_UID ?= ""

   OCI_IMAGE_ARCH ?= "${TARGET_ARCH}"
   OCI_IMAGE_SUBARCH ?= "${@oci_map_subarch(d.getVar('TARGET_ARCH'), d.getVar('TUNE_FEATURES'), d)}"

   OCI_IMAGE_ENTRYPOINT ?= "sh"
   OCI_IMAGE_ENTRYPOINT_ARGS ?= ""
   OCI_IMAGE_WORKINGDIR ?= ""

   //List of ports to expose from a container running this image:
   //PORT[/PROT]
   //  format: <port>/tcp, <port>/udp, or <port> (same as <port>/tcp).
   OICI_IMAGE_PORTS ?= ""

   // key=value list of labels
   OCI_IMAGE_LABELS ?= ""
   // key=value list of environment variables
   OCI_IMAGE_ENV_VARS ?= ""

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
2019-02-27 11:46:25 -05:00
classes containers: introduce image-oci 2019-02-27 11:46:25 -05:00
conf layer: add thud to compatible releases 2018-09-30 21:27:54 -04:00
docs openvswitch: uprev to 1.10 and documentation update. 2013-06-03 18:07:39 -04:00
files fs-perms-nagios.txt: add perms conf file 2018-09-06 12:45:17 -04:00
recipes-containers containers: introduce sloci for generating OCI image directories 2019-02-27 11:46:25 -05:00
recipes-core kata: WIP 2018-11-05 10:22:54 -05:00
recipes-devtools python-webob:upgrade to 1.8.5 2019-02-03 03:42:29 +00:00
recipes-extended ipxe: Uprev and fix host compiler and linker flags. 2019-02-21 03:15:23 +00:00
recipes-graphics/xorg-xserver xen-guest-image-minimal: Fix non-x86. Select x11 via IMAGE_FEATURES. 2017-09-19 09:22:55 -04:00
recipes-kernel/linux kernel: Add bbappend for linux-yocto-dev 2019-01-25 08:31:06 -05:00
recipes-networking openvswitch: uprev from v2.10.1 to v2.11 2019-02-03 03:49:55 +00:00
.gitignore Added .gitignore file 2012-12-07 15:32:31 +01:00
COPYING.MIT Initial meta-xen layer documentation. 2012-06-21 15:51:11 -06:00
README README: add optional dependency on meta-cloud-services 2018-12-04 18:15:20 -05:00

meta-virtualization

This layer provides support for building Xen, KVM, Libvirt, and associated packages necessary for constructing OE-based virtualized solutions.

The bbappend files for some recipes (e.g. linux-yocto) in this layer need to have 'virtualization' in DISTRO_FEATURES to have effect. To enable them, add in configuration file the following line.

DISTRO_FEATURES_append = " virtualization"

If meta-virtualization is included, but virtualization is not enabled as a distro feature a warning is printed at parse time:

You have included the meta-virtualization layer, but
'virtualization' has not been enabled in your DISTRO_FEATURES. Some bbappend files
may not take effect. See the meta-virtualization README for details on enabling
virtualization support.

If you know what you are doing, this warning can be disabled by setting the following variable in your configuration:

SKIP_META_VIRT_SANITY_CHECK = 1

Depending on your use case, there are other distro features in meta-virtualization that may also be enabled:

  • xen: enables xen functionality in various packages (kernel, libvirt, etc)
  • kvm: enables KVM configurations in the kernel and autoloads modules
  • aufs: enables aufs support in docker and linux-yocto
  • x11: enable xen and libvirt functionality related to x11
  • selinux: enables functionality in libvirt and lxc
  • systemd: enable systemd services and unit files (for recipes for support)
  • sysvinit: enable sysvinit scripts (for recipes with support)

Dependencies

This layer depends on:

URI: git://github.com/openembedded/openembedded-core.git branch: master revision: HEAD prio: default

URI: git://github.com/openembedded/meta-openembedded.git branch: master revision: HEAD layers: meta-oe meta-networking meta-filesystems meta-python

BBFILE_PRIORITY_openembedded-layer = "4"

Required for Xen XSM policy: URI: git://git.yoctoproject.org/meta-selinux branch: master revision: HEAD prio: default

Required for Ceph: URI: git://git.yoctoproject.org/meta-cloud-services branch: master revision: HEAD prio: default

Maintenance

Send pull requests, patches, comments or questions to meta-virtualization@yoctoproject.org

Maintainer: Bruce Ashfield bruce.ashfield@gmail.com

When sending single patches, please using something like: $ git send-email -1 -M --to meta-virtualization@yoctoproject.org --subject-prefix='meta-virtualization][PATCH'

License

All metadata is MIT licensed unless otherwise stated. Source code included in tree for individual recipes is under the LICENSE stated in each recipe (.bb file) unless otherwise stated.