* [PATCH v3 0/2] Add support for containerized root filesystems @ 2021-02-12 8:51 Silvano Cirujano Cuesta 2021-02-12 8:51 ` [PATCH v3 1/2] images: add support for container images Silvano Cirujano Cuesta 2021-02-12 8:51 ` [PATCH v3 2/2] docs: document creation of " Silvano Cirujano Cuesta 0 siblings, 2 replies; 10+ messages in thread From: Silvano Cirujano Cuesta @ 2021-02-12 8:51 UTC (permalink / raw) To: isar-users This patch series provides support for containerized root filesystems, for both target images and SDKs. For containerized target images the new image type `container-img` has been added. For containerized SDKs the task `populate_sdk` has been extended. Containerized root filesystems are easy to distribute and run, enabling this way following scenarios: - Use ISAR to build container images meant to be run only in containers. - Use the same ISAR configuration to build images for containers, VMs and bare-metal. - Easy SDK distribution and "installation". - Quickly testing certain applications in the workstation using the target root filesystem. In order to build containerized target root filesystems `IMAGE_TYPE` has to be `container-img`, additionally the container image format can be selected with the variable `CONTAINER_FORMATS`. The default format is `docker-archive`. In order to build containerized SDKs the variable `SDK_FORMAT` has to provide any of the supported container formats (e.g. `docker-archive`). The default format is the legacy non-containerized: `tar_xz`. More information about its usage is documented in the file docs/user_manual.md. A PoC/demo of this functionality (only the SDK part) has been created based on the project https://github.com/siemens/meta-iot2050. Jan Kiszka already tested and liked it! => https://github.com/siemens/meta-iot2050/issues/86#issuecomment-768907845 Successful builds of both containerized target and SDK are available on the same PoC project: - https://github.com/Silvanoc/meta-iot2050/actions/runs/558311580 - https://github.com/Silvanoc/meta-iot2050/actions/runs/558311581 and also the resulting images: - https://github.com/users/Silvanoc/packages/container/package/meta-iot2050%2Fiot2050-debian-arm64 - https://github.com/users/Silvanoc/packages/container/package/meta-iot2050%2Fiot2050-debian-sdk-arm64 In order to get a feeling about its usage (you need Docker or Podman), follow these simple copy&paste instructions: https://github.com/Silvanoc/meta-iot2050/blob/master/kas/BUILDING-SDK-CONTAINER.md#running-the-sdk Build instructions are available in the upper part of that document. Two new dependencies are required to create containerized root filesystems (as specified in the documentation). Typical container image management actions (e.g. push an image to a container image regitry) are out of scope. Available tools (Docker, Skopeo, Buildah, Podman,...) should be used for these actions. A patch will follow this one to get the dependencies into the container images being provided by the project https://github.com/siemens/kas (for `kas-container`, for example). Silvano Cirujano Cuesta (2): images: add support for container images docs: document creation of container images doc/user_manual.md | 127 +++++++++++++++++++++++ meta/classes/container-img.bbclass | 88 ++++++++++++++++ meta/classes/image-sdk-extension.bbclass | 51 +++++++-- meta/classes/image.bbclass | 1 + 4 files changed, 260 insertions(+), 7 deletions(-) create mode 100644 meta/classes/container-img.bbclass -- 2.30.0 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v3 1/2] images: add support for container images 2021-02-12 8:51 [PATCH v3 0/2] Add support for containerized root filesystems Silvano Cirujano Cuesta @ 2021-02-12 8:51 ` Silvano Cirujano Cuesta 2021-02-12 17:10 ` Jan Kiszka 2021-02-12 8:51 ` [PATCH v3 2/2] docs: document creation of " Silvano Cirujano Cuesta 1 sibling, 1 reply; 10+ messages in thread From: Silvano Cirujano Cuesta @ 2021-02-12 8:51 UTC (permalink / raw) To: isar-users Add support for creation of container images with the build root filesystems. Extend also task "populate_sdk" to support the creation of a container image containing the SDK. Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com> --- meta/classes/container-img.bbclass | 88 ++++++++++++++++++++++++ meta/classes/image-sdk-extension.bbclass | 51 ++++++++++++-- meta/classes/image.bbclass | 1 + 3 files changed, 133 insertions(+), 7 deletions(-) create mode 100644 meta/classes/container-img.bbclass diff --git a/meta/classes/container-img.bbclass b/meta/classes/container-img.bbclass new file mode 100644 index 0000000..35c7bbc --- /dev/null +++ b/meta/classes/container-img.bbclass @@ -0,0 +1,88 @@ +# This software is a part of ISAR. +# Copyright (C) Siemens AG, 2021 +# +# SPDX-License-Identifier: MIT +# +# This class provides the tasks 'containerize_rootfs' and 'containerize_sdk' +# to create container images containing the target rootfs and the SDK +# respectively. + +CONTAINER_FORMATS ?= "docker-archive" + +containerize_rootfs() { + local cmd="/bin/dash" + local empty_tag="empty" + local full_tag="latest" + local oci_img_dir="${WORKDIR}/oci-image" + local rootfs="$1" + local rootfs_id="$2" + local container_formats="$3" + + # prepare OCI container image skeleton + bbdebug 1 "prepare OCI container image skeleton" + rm -rf "${oci_img_dir}" + sudo umoci init --layout "${oci_img_dir}" + sudo umoci new --image "${oci_img_dir}:${empty_tag}" + sudo umoci config --image "${oci_img_dir}:${empty_tag}" \ + --config.cmd="${cmd}" + sudo umoci unpack --image "${oci_img_dir}:${empty_tag}" \ + "${oci_img_dir}_unpacked" + + # add root filesystem as the flesh of the skeleton + sudo cp -a "${rootfs}"/* "${oci_img_dir}_unpacked/rootfs/" + + # pack container image + bbdebug 1 "pack container image" + sudo umoci repack --image "${oci_img_dir}:${full_tag}" \ + "${oci_img_dir}_unpacked" + sudo umoci remove --image "${oci_img_dir}:${empty_tag}" + sudo rm -rf "${oci_img_dir}_unpacked" + + # no root needed anymore + sudo chown --recursive $(id -u):$(id -g) "${oci_img_dir}" + + # convert the OCI container image to the desired format + image_name="isar-${rootfs_id}" + for image_type in ${CONTAINER_FORMATS} ; do + image_archive="${DEPLOY_DIR_IMAGE}/${rootfs_id}-${image_type}.tar" + bbdebug 1 "Creating container image type: ${image_type}" + case "${image_type}" in + "docker-archive" | "oci-archive") + if [ "${image_type}" = "oci-archive" ] ; then + target="${image_type}:${image_archive}:latest" + else + target="${image_type}:${image_archive}:${image_name}:latest" + fi + rm -f "${image_archive}" "${image_archive}.xz" + bbdebug 2 "Converting OCI image to ${image_type}" + skopeo --insecure-policy copy \ + "oci:${oci_img_dir}:${full_tag}" "${target}" + bbdebug 2 "Compressing image" + xz -T0 "${image_archive}" + ;; + "oci") + tar --create --xz --directory "${oci_img_dir}" \ + --file "${image_archive}.xz" . + ;; + "docker-daemon" | "containers-storage") + skopeo --insecure-policy copy \ + "oci:${oci_img_dir}:${full_tag}" \ + "${image_type}:${image_name}:latest" + ;; + *) + die "Unsupported format for containerize_rootfs: ${image_type}" + ;; + esac + done +} + +do_container_image[stamp-extra-info] = "${DISTRO}-${MACHINE}" +do_container_image[vardeps] += "CONTAINER_FORMATS" +do_container_image(){ + rootfs_id="${DISTRO}-${DISTRO_ARCH}" + + bbnote "Generate container image in these formats: ${CONTAINER_FORMATS}" + containerize_rootfs "${IMAGE_ROOTFS}" "${rootfs_id}" "${CONTAINER_FORMATS}" +} + +addtask container_image before do_image after do_image_tools diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass index a8c708a..63138da 100644 --- a/meta/classes/image-sdk-extension.bbclass +++ b/meta/classes/image-sdk-extension.bbclass @@ -6,11 +6,25 @@ # This class extends the image.bbclass to supply the creation of a sdk SDK_INCLUDE_ISAR_APT ?= "0" +SDK_FORMATS ?= "tar-xz" + +sdk_tar_xz() { + # Copy mount_chroot.sh for convenience + sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} + + # Create SDK archive + cd -P ${SDKCHROOT_DIR}/.. + sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ + -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz + bbnote "SDK rootfs available in ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz" +} do_populate_sdk[stamp-extra-info] = "${DISTRO}-${MACHINE}" do_populate_sdk[depends] = "sdkchroot:do_build" -do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT" +do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT SDK_FORMATS" do_populate_sdk() { + local sdk_container_formats="" + if [ "${SDK_INCLUDE_ISAR_APT}" = "1" ]; then # Copy isar-apt with deployed Isar packages sudo cp -Trpfx ${REPO_ISAR_DIR}/${DISTRO} ${SDKCHROOT_DIR}/isar-apt @@ -48,12 +62,35 @@ do_populate_sdk() { done done - # Copy mount_chroot.sh for convenience - sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} + # separate SDK formats: TAR and container formats + for sdk_format in ${SDK_FORMATS} ; do + case ${sdk_format} in + "tar-xz") + sdk_tar_xz + ;; + "docker-archive" | "oci" | "oci-archive") + if [ -z "${sdk_container_formats}" ] ; then + sdk_container_formats="${sdk_format}" + else + sdk_container_formats="${sdk_container_formats} ${sdk_format}" + fi + ;; + "docker-daemon" | "containers-storage") + if [ -f /.dockerenv ] || [ -f /run/.containerenv ] ; then + die "Adding the SDK container image to a container runtime (${sdk_format}) not supported if running from a container (e.g. 'kas-container')" + fi + ;; + *) + die "unsupported SDK format specified: ${sdk_format}" + ;; + esac + done - # Create SDK archive - cd -P ${SDKCHROOT_DIR}/.. - sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ - -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz + # generate the SDK in all the desired container formats + if [ -n "${sdk_container_formats}" ] ; then + bbnote "Generating SDK container in ${sdk_container_formats} format" + containerize_rootfs "${SDKCHROOT_DIR}" "sdk-${DISTRO}-${DISTRO_ARCH}" "${sdk_container_formats}" + fi } + addtask populate_sdk after do_rootfs diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass index eddc444..7fb7b7e 100644 --- a/meta/classes/image.bbclass +++ b/meta/classes/image.bbclass @@ -76,6 +76,7 @@ inherit image-tools-extension inherit image-postproc-extension inherit image-locales-extension inherit image-account-extension +inherit container-img # Extra space for rootfs in MB ROOTFS_EXTRA ?= "64" -- 2.30.0 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v3 1/2] images: add support for container images 2021-02-12 8:51 ` [PATCH v3 1/2] images: add support for container images Silvano Cirujano Cuesta @ 2021-02-12 17:10 ` Jan Kiszka 2021-02-12 17:46 ` Silvano Cirujano Cuesta 0 siblings, 1 reply; 10+ messages in thread From: Jan Kiszka @ 2021-02-12 17:10 UTC (permalink / raw) To: [ext] Silvano Cirujano Cuesta, isar-users On 12.02.21 09:51, [ext] Silvano Cirujano Cuesta wrote: > Add support for creation of container images with the build root > filesystems. > > Extend also task "populate_sdk" to support the creation of a container image > containing the SDK. Should be done in to steps: container-img.bbclass frirst, and then a patch to use it for the SDK as well. > > Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com> > --- > meta/classes/container-img.bbclass | 88 ++++++++++++++++++++++++ > meta/classes/image-sdk-extension.bbclass | 51 ++++++++++++-- > meta/classes/image.bbclass | 1 + > 3 files changed, 133 insertions(+), 7 deletions(-) > create mode 100644 meta/classes/container-img.bbclass > > diff --git a/meta/classes/container-img.bbclass b/meta/classes/container-img.bbclass > new file mode 100644 > index 0000000..35c7bbc > --- /dev/null > +++ b/meta/classes/container-img.bbclass > @@ -0,0 +1,88 @@ > +# This software is a part of ISAR. > +# Copyright (C) Siemens AG, 2021 > +# > +# SPDX-License-Identifier: MIT > +# > +# This class provides the tasks 'containerize_rootfs' and 'containerize_sdk' Nope, it now only provides the former. > +# to create container images containing the target rootfs and the SDK > +# respectively. > + > +CONTAINER_FORMATS ?= "docker-archive" > + > +containerize_rootfs() { > + local cmd="/bin/dash" > + local empty_tag="empty" > + local full_tag="latest" > + local oci_img_dir="${WORKDIR}/oci-image" > + local rootfs="$1" > + local rootfs_id="$2" > + local container_formats="$3" > + > + # prepare OCI container image skeleton > + bbdebug 1 "prepare OCI container image skeleton" > + rm -rf "${oci_img_dir}" > + sudo umoci init --layout "${oci_img_dir}" > + sudo umoci new --image "${oci_img_dir}:${empty_tag}" > + sudo umoci config --image "${oci_img_dir}:${empty_tag}" \ > + --config.cmd="${cmd}" > + sudo umoci unpack --image "${oci_img_dir}:${empty_tag}" \ > + "${oci_img_dir}_unpacked" > + > + # add root filesystem as the flesh of the skeleton > + sudo cp -a "${rootfs}"/* "${oci_img_dir}_unpacked/rootfs/" > + > + # pack container image > + bbdebug 1 "pack container image" > + sudo umoci repack --image "${oci_img_dir}:${full_tag}" \ > + "${oci_img_dir}_unpacked" > + sudo umoci remove --image "${oci_img_dir}:${empty_tag}" > + sudo rm -rf "${oci_img_dir}_unpacked" > + > + # no root needed anymore > + sudo chown --recursive $(id -u):$(id -g) "${oci_img_dir}" > + > + # convert the OCI container image to the desired format > + image_name="isar-${rootfs_id}" > + for image_type in ${CONTAINER_FORMATS} ; do > + image_archive="${DEPLOY_DIR_IMAGE}/${rootfs_id}-${image_type}.tar" > + bbdebug 1 "Creating container image type: ${image_type}" > + case "${image_type}" in > + "docker-archive" | "oci-archive") > + if [ "${image_type}" = "oci-archive" ] ; then > + target="${image_type}:${image_archive}:latest" > + else > + target="${image_type}:${image_archive}:${image_name}:latest" > + fi > + rm -f "${image_archive}" "${image_archive}.xz" > + bbdebug 2 "Converting OCI image to ${image_type}" > + skopeo --insecure-policy copy \ > + "oci:${oci_img_dir}:${full_tag}" "${target}" > + bbdebug 2 "Compressing image" > + xz -T0 "${image_archive}" > + ;; > + "oci") > + tar --create --xz --directory "${oci_img_dir}" \ > + --file "${image_archive}.xz" . > + ;; > + "docker-daemon" | "containers-storage") > + skopeo --insecure-policy copy \ > + "oci:${oci_img_dir}:${full_tag}" \ > + "${image_type}:${image_name}:latest" > + ;; Missing check for "Am I in a container?", like in the SDK. Maybe move that test here and share. > + *) > + die "Unsupported format for containerize_rootfs: ${image_type}" > + ;; > + esac > + done > +} > + > +do_container_image[stamp-extra-info] = "${DISTRO}-${MACHINE}" > +do_container_image[vardeps] += "CONTAINER_FORMATS" > +do_container_image(){ > + rootfs_id="${DISTRO}-${DISTRO_ARCH}" > + > + bbnote "Generate container image in these formats: ${CONTAINER_FORMATS}" Probabably more "bbdebug"? Unsure. But we aren't using bbnote in the core so far. Nor bbdebug, though. > + containerize_rootfs "${IMAGE_ROOTFS}" "${rootfs_id}" "${CONTAINER_FORMATS}" > +} > + > +addtask container_image before do_image after do_image_tools > diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass > index a8c708a..63138da 100644 > --- a/meta/classes/image-sdk-extension.bbclass > +++ b/meta/classes/image-sdk-extension.bbclass > @@ -6,11 +6,25 @@ > # This class extends the image.bbclass to supply the creation of a sdk > > SDK_INCLUDE_ISAR_APT ?= "0" > +SDK_FORMATS ?= "tar-xz" > + > +sdk_tar_xz() { > + # Copy mount_chroot.sh for convenience > + sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} > + > + # Create SDK archive > + cd -P ${SDKCHROOT_DIR}/.. > + sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ > + -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz > + bbnote "SDK rootfs available in ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz" > +} > > do_populate_sdk[stamp-extra-info] = "${DISTRO}-${MACHINE}" > do_populate_sdk[depends] = "sdkchroot:do_build" > -do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT" > +do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT SDK_FORMATS" > do_populate_sdk() { > + local sdk_container_formats="" > + > if [ "${SDK_INCLUDE_ISAR_APT}" = "1" ]; then > # Copy isar-apt with deployed Isar packages > sudo cp -Trpfx ${REPO_ISAR_DIR}/${DISTRO} ${SDKCHROOT_DIR}/isar-apt > @@ -48,12 +62,35 @@ do_populate_sdk() { > done > done > > - # Copy mount_chroot.sh for convenience > - sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} > + # separate SDK formats: TAR and container formats > + for sdk_format in ${SDK_FORMATS} ; do > + case ${sdk_format} in > + "tar-xz") > + sdk_tar_xz > + ;; > + "docker-archive" | "oci" | "oci-archive") > + if [ -z "${sdk_container_formats}" ] ; then Unneeded, just use the else part unconditionally. > + sdk_container_formats="${sdk_format}" > + else > + sdk_container_formats="${sdk_container_formats} ${sdk_format}" > + fi > + ;; > + "docker-daemon" | "containers-storage") > + if [ -f /.dockerenv ] || [ -f /run/.containerenv ] ; then > + die "Adding the SDK container image to a container runtime (${sdk_format}) not supported if running from a container (e.g. 'kas-container')" > + fi See above, should likely go into containerize_rootfs(). > + ;; > + *) > + die "unsupported SDK format specified: ${sdk_format}" > + ;; > + esac > + done > > - # Create SDK archive > - cd -P ${SDKCHROOT_DIR}/.. > - sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ > - -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz > + # generate the SDK in all the desired container formats > + if [ -n "${sdk_container_formats}" ] ; then > + bbnote "Generating SDK container in ${sdk_container_formats} format" > + containerize_rootfs "${SDKCHROOT_DIR}" "sdk-${DISTRO}-${DISTRO_ARCH}" "${sdk_container_formats}" > + fi > } > + > addtask populate_sdk after do_rootfs > diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass > index eddc444..7fb7b7e 100644 > --- a/meta/classes/image.bbclass > +++ b/meta/classes/image.bbclass > @@ -76,6 +76,7 @@ inherit image-tools-extension > inherit image-postproc-extension > inherit image-locales-extension > inherit image-account-extension > +inherit container-img > > # Extra space for rootfs in MB > ROOTFS_EXTRA ?= "64" > Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v3 1/2] images: add support for container images 2021-02-12 17:10 ` Jan Kiszka @ 2021-02-12 17:46 ` Silvano Cirujano Cuesta 2021-02-12 18:04 ` Silvano Cirujano Cuesta 2021-02-12 18:06 ` Jan Kiszka 0 siblings, 2 replies; 10+ messages in thread From: Silvano Cirujano Cuesta @ 2021-02-12 17:46 UTC (permalink / raw) To: Jan Kiszka, isar-users On 12/02/2021 18:10, Jan Kiszka wrote: > On 12.02.21 09:51, [ext] Silvano Cirujano Cuesta wrote: >> Add support for creation of container images with the build root >> filesystems. >> >> Extend also task "populate_sdk" to support the creation of a container image >> containing the SDK. > Should be done in to steps: container-img.bbclass frirst, and then a > patch to use it for the SDK as well. Ok. There are some many different tastes WRT to big vs small commits :-) > >> Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com> >> --- >> meta/classes/container-img.bbclass | 88 ++++++++++++++++++++++++ >> meta/classes/image-sdk-extension.bbclass | 51 ++++++++++++-- >> meta/classes/image.bbclass | 1 + >> 3 files changed, 133 insertions(+), 7 deletions(-) >> create mode 100644 meta/classes/container-img.bbclass >> >> diff --git a/meta/classes/container-img.bbclass b/meta/classes/container-img.bbclass >> new file mode 100644 >> index 0000000..35c7bbc >> --- /dev/null >> +++ b/meta/classes/container-img.bbclass >> @@ -0,0 +1,88 @@ >> +# This software is a part of ISAR. >> +# Copyright (C) Siemens AG, 2021 >> +# >> +# SPDX-License-Identifier: MIT >> +# >> +# This class provides the tasks 'containerize_rootfs' and 'containerize_sdk' > Nope, it now only provides the former. Yes, you're right, will fix it. > >> +# to create container images containing the target rootfs and the SDK >> +# respectively. >> + >> +CONTAINER_FORMATS ?= "docker-archive" >> + >> +containerize_rootfs() { >> + local cmd="/bin/dash" >> + local empty_tag="empty" >> + local full_tag="latest" >> + local oci_img_dir="${WORKDIR}/oci-image" >> + local rootfs="$1" >> + local rootfs_id="$2" >> + local container_formats="$3" >> + >> + # prepare OCI container image skeleton >> + bbdebug 1 "prepare OCI container image skeleton" >> + rm -rf "${oci_img_dir}" >> + sudo umoci init --layout "${oci_img_dir}" >> + sudo umoci new --image "${oci_img_dir}:${empty_tag}" >> + sudo umoci config --image "${oci_img_dir}:${empty_tag}" \ >> + --config.cmd="${cmd}" >> + sudo umoci unpack --image "${oci_img_dir}:${empty_tag}" \ >> + "${oci_img_dir}_unpacked" >> + >> + # add root filesystem as the flesh of the skeleton >> + sudo cp -a "${rootfs}"/* "${oci_img_dir}_unpacked/rootfs/" >> + >> + # pack container image >> + bbdebug 1 "pack container image" >> + sudo umoci repack --image "${oci_img_dir}:${full_tag}" \ >> + "${oci_img_dir}_unpacked" >> + sudo umoci remove --image "${oci_img_dir}:${empty_tag}" >> + sudo rm -rf "${oci_img_dir}_unpacked" >> + >> + # no root needed anymore >> + sudo chown --recursive $(id -u):$(id -g) "${oci_img_dir}" >> + >> + # convert the OCI container image to the desired format >> + image_name="isar-${rootfs_id}" >> + for image_type in ${CONTAINER_FORMATS} ; do >> + image_archive="${DEPLOY_DIR_IMAGE}/${rootfs_id}-${image_type}.tar" >> + bbdebug 1 "Creating container image type: ${image_type}" >> + case "${image_type}" in >> + "docker-archive" | "oci-archive") >> + if [ "${image_type}" = "oci-archive" ] ; then >> + target="${image_type}:${image_archive}:latest" >> + else >> + target="${image_type}:${image_archive}:${image_name}:latest" >> + fi >> + rm -f "${image_archive}" "${image_archive}.xz" >> + bbdebug 2 "Converting OCI image to ${image_type}" >> + skopeo --insecure-policy copy \ >> + "oci:${oci_img_dir}:${full_tag}" "${target}" >> + bbdebug 2 "Compressing image" >> + xz -T0 "${image_archive}" >> + ;; >> + "oci") >> + tar --create --xz --directory "${oci_img_dir}" \ >> + --file "${image_archive}.xz" . >> + ;; >> + "docker-daemon" | "containers-storage") >> + skopeo --insecure-policy copy \ >> + "oci:${oci_img_dir}:${full_tag}" \ >> + "${image_type}:${image_name}:latest" >> + ;; > Missing check for "Am I in a container?", like in the SDK. Maybe move > that test here and share. Not needed, since the usage of IMAGE_TYPE is fixing already to container type. In the case of the SDK the same task is provides the non-containerized format tar-xz. > >> + *) >> + die "Unsupported format for containerize_rootfs: ${image_type}" >> + ;; >> + esac >> + done >> +} >> + >> +do_container_image[stamp-extra-info] = "${DISTRO}-${MACHINE}" >> +do_container_image[vardeps] += "CONTAINER_FORMATS" >> +do_container_image(){ >> + rootfs_id="${DISTRO}-${DISTRO_ARCH}" >> + >> + bbnote "Generate container image in these formats: ${CONTAINER_FORMATS}" > Probabably more "bbdebug"? Unsure. But we aren't using bbnote in the > core so far. Nor bbdebug, though. At least bbdebug is IMO needed for debbuging if goes wrong. BTW I'm using bbdebug a lot in the containerize_rootfs section because I've missed those kind of traces much too often when trying to debug some issues on ISAR recipes. Perhaps we should have more debug verbosity in the logs to ease debugging... > >> + containerize_rootfs "${IMAGE_ROOTFS}" "${rootfs_id}" "${CONTAINER_FORMATS}" >> +} >> + >> +addtask container_image before do_image after do_image_tools >> diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass >> index a8c708a..63138da 100644 >> --- a/meta/classes/image-sdk-extension.bbclass >> +++ b/meta/classes/image-sdk-extension.bbclass >> @@ -6,11 +6,25 @@ >> # This class extends the image.bbclass to supply the creation of a sdk >> >> SDK_INCLUDE_ISAR_APT ?= "0" >> +SDK_FORMATS ?= "tar-xz" >> + >> +sdk_tar_xz() { >> + # Copy mount_chroot.sh for convenience >> + sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} >> + >> + # Create SDK archive >> + cd -P ${SDKCHROOT_DIR}/.. >> + sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ >> + -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz >> + bbnote "SDK rootfs available in ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz" >> +} >> >> do_populate_sdk[stamp-extra-info] = "${DISTRO}-${MACHINE}" >> do_populate_sdk[depends] = "sdkchroot:do_build" >> -do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT" >> +do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT SDK_FORMATS" >> do_populate_sdk() { >> + local sdk_container_formats="" >> + >> if [ "${SDK_INCLUDE_ISAR_APT}" = "1" ]; then >> # Copy isar-apt with deployed Isar packages >> sudo cp -Trpfx ${REPO_ISAR_DIR}/${DISTRO} ${SDKCHROOT_DIR}/isar-apt >> @@ -48,12 +62,35 @@ do_populate_sdk() { >> done >> done >> >> - # Copy mount_chroot.sh for convenience >> - sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} >> + # separate SDK formats: TAR and container formats >> + for sdk_format in ${SDK_FORMATS} ; do >> + case ${sdk_format} in >> + "tar-xz") >> + sdk_tar_xz >> + ;; >> + "docker-archive" | "oci" | "oci-archive") >> + if [ -z "${sdk_container_formats}" ] ; then > Unneeded, just use the else part unconditionally. The else part alone adds a heading whitespace. It's being ignored in containerize_rootfs, but it's still messing up some outputs. Not really useless, but not important (in fact that was my 1st version). I can change it in the next patch series version that I need anyway. > >> + sdk_container_formats="${sdk_format}" >> + else >> + sdk_container_formats="${sdk_container_formats} ${sdk_format}" >> + fi >> + ;; >> + "docker-daemon" | "containers-storage") >> + if [ -f /.dockerenv ] || [ -f /run/.containerenv ] ; then >> + die "Adding the SDK container image to a container runtime (${sdk_format}) not supported if running from a container (e.g. 'kas-container')" >> + fi > See above, should likely go into containerize_rootfs(). Right, will fix it. In fact this case section is really messed up, I have to clean it up completely. > >> + ;; >> + *) >> + die "unsupported SDK format specified: ${sdk_format}" >> + ;; >> + esac >> + done >> >> - # Create SDK archive >> - cd -P ${SDKCHROOT_DIR}/.. >> - sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ >> - -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz >> + # generate the SDK in all the desired container formats >> + if [ -n "${sdk_container_formats}" ] ; then >> + bbnote "Generating SDK container in ${sdk_container_formats} format" >> + containerize_rootfs "${SDKCHROOT_DIR}" "sdk-${DISTRO}-${DISTRO_ARCH}" "${sdk_container_formats}" >> + fi >> } >> + >> addtask populate_sdk after do_rootfs >> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass >> index eddc444..7fb7b7e 100644 >> --- a/meta/classes/image.bbclass >> +++ b/meta/classes/image.bbclass >> @@ -76,6 +76,7 @@ inherit image-tools-extension >> inherit image-postproc-extension >> inherit image-locales-extension >> inherit image-account-extension >> +inherit container-img >> >> # Extra space for rootfs in MB >> ROOTFS_EXTRA ?= "64" >> > Jan Silvano -- Siemens AG, T RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v3 1/2] images: add support for container images 2021-02-12 17:46 ` Silvano Cirujano Cuesta @ 2021-02-12 18:04 ` Silvano Cirujano Cuesta 2021-02-12 18:06 ` Jan Kiszka 1 sibling, 0 replies; 10+ messages in thread From: Silvano Cirujano Cuesta @ 2021-02-12 18:04 UTC (permalink / raw) To: isar-users On 12/02/2021 18:46, [ext] Silvano Cirujano Cuesta wrote: > On 12/02/2021 18:10, Jan Kiszka wrote: >> On 12.02.21 09:51, [ext] Silvano Cirujano Cuesta wrote: >>> Add support for creation of container images with the build root >>> filesystems. >>> >>> Extend also task "populate_sdk" to support the creation of a container image >>> containing the SDK. >> Should be done in to steps: container-img.bbclass frirst, and then a >> patch to use it for the SDK as well. > Ok. There are some many different tastes WRT to big vs small commits :-) > >>> Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com> >>> --- >>> meta/classes/container-img.bbclass | 88 ++++++++++++++++++++++++ >>> meta/classes/image-sdk-extension.bbclass | 51 ++++++++++++-- >>> meta/classes/image.bbclass | 1 + >>> 3 files changed, 133 insertions(+), 7 deletions(-) >>> create mode 100644 meta/classes/container-img.bbclass >>> >>> diff --git a/meta/classes/container-img.bbclass b/meta/classes/container-img.bbclass >>> new file mode 100644 >>> index 0000000..35c7bbc >>> --- /dev/null >>> +++ b/meta/classes/container-img.bbclass >>> @@ -0,0 +1,88 @@ >>> +# This software is a part of ISAR. >>> +# Copyright (C) Siemens AG, 2021 >>> +# >>> +# SPDX-License-Identifier: MIT >>> +# >>> +# This class provides the tasks 'containerize_rootfs' and 'containerize_sdk' >> Nope, it now only provides the former. > Yes, you're right, will fix it. >>> +# to create container images containing the target rootfs and the SDK >>> +# respectively. >>> + >>> +CONTAINER_FORMATS ?= "docker-archive" >>> + >>> +containerize_rootfs() { Wouldn't it make sense to put the "containerize_rootfs" function in a separate class "container.bbclass" or "image-container-extension.bbclass" or similar and let "image.bbclass" inherit from it? The current structure that I have come up to seems weird to me, it isn't obvious that "containerize_rootfs" is meant to be reused. (-) an additional class for a single function (+) better structured code >>> + local cmd="/bin/dash" >>> + local empty_tag="empty" >>> + local full_tag="latest" >>> + local oci_img_dir="${WORKDIR}/oci-image" >>> + local rootfs="$1" >>> + local rootfs_id="$2" >>> + local container_formats="$3" >>> + >>> + # prepare OCI container image skeleton >>> + bbdebug 1 "prepare OCI container image skeleton" >>> + rm -rf "${oci_img_dir}" >>> + sudo umoci init --layout "${oci_img_dir}" >>> + sudo umoci new --image "${oci_img_dir}:${empty_tag}" >>> + sudo umoci config --image "${oci_img_dir}:${empty_tag}" \ >>> + --config.cmd="${cmd}" >>> + sudo umoci unpack --image "${oci_img_dir}:${empty_tag}" \ >>> + "${oci_img_dir}_unpacked" >>> + >>> + # add root filesystem as the flesh of the skeleton >>> + sudo cp -a "${rootfs}"/* "${oci_img_dir}_unpacked/rootfs/" >>> + >>> + # pack container image >>> + bbdebug 1 "pack container image" >>> + sudo umoci repack --image "${oci_img_dir}:${full_tag}" \ >>> + "${oci_img_dir}_unpacked" >>> + sudo umoci remove --image "${oci_img_dir}:${empty_tag}" >>> + sudo rm -rf "${oci_img_dir}_unpacked" >>> + >>> + # no root needed anymore >>> + sudo chown --recursive $(id -u):$(id -g) "${oci_img_dir}" >>> + >>> + # convert the OCI container image to the desired format >>> + image_name="isar-${rootfs_id}" >>> + for image_type in ${CONTAINER_FORMATS} ; do >>> + image_archive="${DEPLOY_DIR_IMAGE}/${rootfs_id}-${image_type}.tar" >>> + bbdebug 1 "Creating container image type: ${image_type}" >>> + case "${image_type}" in >>> + "docker-archive" | "oci-archive") >>> + if [ "${image_type}" = "oci-archive" ] ; then >>> + target="${image_type}:${image_archive}:latest" >>> + else >>> + target="${image_type}:${image_archive}:${image_name}:latest" >>> + fi >>> + rm -f "${image_archive}" "${image_archive}.xz" >>> + bbdebug 2 "Converting OCI image to ${image_type}" >>> + skopeo --insecure-policy copy \ >>> + "oci:${oci_img_dir}:${full_tag}" "${target}" >>> + bbdebug 2 "Compressing image" >>> + xz -T0 "${image_archive}" >>> + ;; >>> + "oci") >>> + tar --create --xz --directory "${oci_img_dir}" \ >>> + --file "${image_archive}.xz" . >>> + ;; >>> + "docker-daemon" | "containers-storage") >>> + skopeo --insecure-policy copy \ >>> + "oci:${oci_img_dir}:${full_tag}" \ >>> + "${image_type}:${image_name}:latest" >>> + ;; >> Missing check for "Am I in a container?", like in the SDK. Maybe move >> that test here and share. > Not needed, since the usage of IMAGE_TYPE is fixing already to container type. > > In the case of the SDK the same task is provides the non-containerized format tar-xz. > >>> + *) >>> + die "Unsupported format for containerize_rootfs: ${image_type}" >>> + ;; >>> + esac >>> + done >>> +} >>> + >>> +do_container_image[stamp-extra-info] = "${DISTRO}-${MACHINE}" >>> +do_container_image[vardeps] += "CONTAINER_FORMATS" >>> +do_container_image(){ >>> + rootfs_id="${DISTRO}-${DISTRO_ARCH}" >>> + >>> + bbnote "Generate container image in these formats: ${CONTAINER_FORMATS}" >> Probabably more "bbdebug"? Unsure. But we aren't using bbnote in the >> core so far. Nor bbdebug, though. > At least bbdebug is IMO needed for debbuging if goes wrong. > > BTW I'm using bbdebug a lot in the containerize_rootfs section because I've missed those kind of traces much too often when trying to debug some issues on ISAR recipes. > > Perhaps we should have more debug verbosity in the logs to ease debugging... > >>> + containerize_rootfs "${IMAGE_ROOTFS}" "${rootfs_id}" "${CONTAINER_FORMATS}" >>> +} >>> + >>> +addtask container_image before do_image after do_image_tools >>> diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass >>> index a8c708a..63138da 100644 >>> --- a/meta/classes/image-sdk-extension.bbclass >>> +++ b/meta/classes/image-sdk-extension.bbclass >>> @@ -6,11 +6,25 @@ >>> # This class extends the image.bbclass to supply the creation of a sdk >>> >>> SDK_INCLUDE_ISAR_APT ?= "0" >>> +SDK_FORMATS ?= "tar-xz" >>> + >>> +sdk_tar_xz() { >>> + # Copy mount_chroot.sh for convenience >>> + sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} >>> + >>> + # Create SDK archive >>> + cd -P ${SDKCHROOT_DIR}/.. >>> + sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ >>> + -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz >>> + bbnote "SDK rootfs available in ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz" >>> +} >>> >>> do_populate_sdk[stamp-extra-info] = "${DISTRO}-${MACHINE}" >>> do_populate_sdk[depends] = "sdkchroot:do_build" >>> -do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT" >>> +do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT SDK_FORMATS" >>> do_populate_sdk() { >>> + local sdk_container_formats="" >>> + >>> if [ "${SDK_INCLUDE_ISAR_APT}" = "1" ]; then >>> # Copy isar-apt with deployed Isar packages >>> sudo cp -Trpfx ${REPO_ISAR_DIR}/${DISTRO} ${SDKCHROOT_DIR}/isar-apt >>> @@ -48,12 +62,35 @@ do_populate_sdk() { >>> done >>> done >>> >>> - # Copy mount_chroot.sh for convenience >>> - sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} >>> + # separate SDK formats: TAR and container formats >>> + for sdk_format in ${SDK_FORMATS} ; do >>> + case ${sdk_format} in >>> + "tar-xz") >>> + sdk_tar_xz >>> + ;; >>> + "docker-archive" | "oci" | "oci-archive") >>> + if [ -z "${sdk_container_formats}" ] ; then >> Unneeded, just use the else part unconditionally. > The else part alone adds a heading whitespace. It's being ignored in containerize_rootfs, but it's still messing up some outputs. > > Not really useless, but not important (in fact that was my 1st version). I can change it in the next patch series version that I need anyway. > >>> + sdk_container_formats="${sdk_format}" >>> + else >>> + sdk_container_formats="${sdk_container_formats} ${sdk_format}" >>> + fi >>> + ;; >>> + "docker-daemon" | "containers-storage") >>> + if [ -f /.dockerenv ] || [ -f /run/.containerenv ] ; then >>> + die "Adding the SDK container image to a container runtime (${sdk_format}) not supported if running from a container (e.g. 'kas-container')" >>> + fi >> See above, should likely go into containerize_rootfs(). > Right, will fix it. > > In fact this case section is really messed up, I have to clean it up completely. > >>> + ;; >>> + *) >>> + die "unsupported SDK format specified: ${sdk_format}" >>> + ;; >>> + esac >>> + done >>> >>> - # Create SDK archive >>> - cd -P ${SDKCHROOT_DIR}/.. >>> - sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ >>> - -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz >>> + # generate the SDK in all the desired container formats >>> + if [ -n "${sdk_container_formats}" ] ; then >>> + bbnote "Generating SDK container in ${sdk_container_formats} format" >>> + containerize_rootfs "${SDKCHROOT_DIR}" "sdk-${DISTRO}-${DISTRO_ARCH}" "${sdk_container_formats}" >>> + fi >>> } >>> + >>> addtask populate_sdk after do_rootfs >>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass >>> index eddc444..7fb7b7e 100644 >>> --- a/meta/classes/image.bbclass >>> +++ b/meta/classes/image.bbclass >>> @@ -76,6 +76,7 @@ inherit image-tools-extension >>> inherit image-postproc-extension >>> inherit image-locales-extension >>> inherit image-account-extension >>> +inherit container-img >>> >>> # Extra space for rootfs in MB >>> ROOTFS_EXTRA ?= "64" >>> >> Jan > Silvano > Silvano ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v3 1/2] images: add support for container images 2021-02-12 17:46 ` Silvano Cirujano Cuesta 2021-02-12 18:04 ` Silvano Cirujano Cuesta @ 2021-02-12 18:06 ` Jan Kiszka 2021-02-12 18:23 ` Silvano Cirujano Cuesta 1 sibling, 1 reply; 10+ messages in thread From: Jan Kiszka @ 2021-02-12 18:06 UTC (permalink / raw) To: Silvano Cirujano Cuesta, isar-users On 12.02.21 18:46, Silvano Cirujano Cuesta wrote: > > On 12/02/2021 18:10, Jan Kiszka wrote: >> On 12.02.21 09:51, [ext] Silvano Cirujano Cuesta wrote: >>> Add support for creation of container images with the build root >>> filesystems. >>> >>> Extend also task "populate_sdk" to support the creation of a container image >>> containing the SDK. >> Should be done in to steps: container-img.bbclass frirst, and then a >> patch to use it for the SDK as well. > > Ok. There are some many different tastes WRT to big vs small commits :-) Rather /wrt logically separatable steps. > >> >>> Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com> >>> --- >>> meta/classes/container-img.bbclass | 88 ++++++++++++++++++++++++ >>> meta/classes/image-sdk-extension.bbclass | 51 ++++++++++++-- >>> meta/classes/image.bbclass | 1 + >>> 3 files changed, 133 insertions(+), 7 deletions(-) >>> create mode 100644 meta/classes/container-img.bbclass >>> >>> diff --git a/meta/classes/container-img.bbclass b/meta/classes/container-img.bbclass >>> new file mode 100644 >>> index 0000000..35c7bbc >>> --- /dev/null >>> +++ b/meta/classes/container-img.bbclass >>> @@ -0,0 +1,88 @@ >>> +# This software is a part of ISAR. >>> +# Copyright (C) Siemens AG, 2021 >>> +# >>> +# SPDX-License-Identifier: MIT >>> +# >>> +# This class provides the tasks 'containerize_rootfs' and 'containerize_sdk' >> Nope, it now only provides the former. > Yes, you're right, will fix it. >> >>> +# to create container images containing the target rootfs and the SDK >>> +# respectively. >>> + >>> +CONTAINER_FORMATS ?= "docker-archive" >>> + >>> +containerize_rootfs() { >>> + local cmd="/bin/dash" >>> + local empty_tag="empty" >>> + local full_tag="latest" >>> + local oci_img_dir="${WORKDIR}/oci-image" >>> + local rootfs="$1" >>> + local rootfs_id="$2" >>> + local container_formats="$3" >>> + >>> + # prepare OCI container image skeleton >>> + bbdebug 1 "prepare OCI container image skeleton" >>> + rm -rf "${oci_img_dir}" >>> + sudo umoci init --layout "${oci_img_dir}" >>> + sudo umoci new --image "${oci_img_dir}:${empty_tag}" >>> + sudo umoci config --image "${oci_img_dir}:${empty_tag}" \ >>> + --config.cmd="${cmd}" >>> + sudo umoci unpack --image "${oci_img_dir}:${empty_tag}" \ >>> + "${oci_img_dir}_unpacked" >>> + >>> + # add root filesystem as the flesh of the skeleton >>> + sudo cp -a "${rootfs}"/* "${oci_img_dir}_unpacked/rootfs/" >>> + >>> + # pack container image >>> + bbdebug 1 "pack container image" >>> + sudo umoci repack --image "${oci_img_dir}:${full_tag}" \ >>> + "${oci_img_dir}_unpacked" >>> + sudo umoci remove --image "${oci_img_dir}:${empty_tag}" >>> + sudo rm -rf "${oci_img_dir}_unpacked" >>> + >>> + # no root needed anymore >>> + sudo chown --recursive $(id -u):$(id -g) "${oci_img_dir}" >>> + >>> + # convert the OCI container image to the desired format >>> + image_name="isar-${rootfs_id}" >>> + for image_type in ${CONTAINER_FORMATS} ; do >>> + image_archive="${DEPLOY_DIR_IMAGE}/${rootfs_id}-${image_type}.tar" >>> + bbdebug 1 "Creating container image type: ${image_type}" >>> + case "${image_type}" in >>> + "docker-archive" | "oci-archive") >>> + if [ "${image_type}" = "oci-archive" ] ; then >>> + target="${image_type}:${image_archive}:latest" >>> + else >>> + target="${image_type}:${image_archive}:${image_name}:latest" >>> + fi >>> + rm -f "${image_archive}" "${image_archive}.xz" >>> + bbdebug 2 "Converting OCI image to ${image_type}" >>> + skopeo --insecure-policy copy \ >>> + "oci:${oci_img_dir}:${full_tag}" "${target}" >>> + bbdebug 2 "Compressing image" >>> + xz -T0 "${image_archive}" >>> + ;; >>> + "oci") >>> + tar --create --xz --directory "${oci_img_dir}" \ >>> + --file "${image_archive}.xz" . >>> + ;; >>> + "docker-daemon" | "containers-storage") >>> + skopeo --insecure-policy copy \ >>> + "oci:${oci_img_dir}:${full_tag}" \ >>> + "${image_type}:${image_name}:latest" >>> + ;; >> Missing check for "Am I in a container?", like in the SDK. Maybe move >> that test here and share. > > Not needed, since the usage of IMAGE_TYPE is fixing already to container type. > > In the case of the SDK the same task is provides the non-containerized format tar-xz. > I cannot follow: What is the difference between CONTAINER_FORMATS="docker-daemon" and SDK_FORMATS="docker-daemon" when running inside a kas build container? Both do not work, do they? >> >>> + *) >>> + die "Unsupported format for containerize_rootfs: ${image_type}" >>> + ;; >>> + esac >>> + done >>> +} >>> + >>> +do_container_image[stamp-extra-info] = "${DISTRO}-${MACHINE}" >>> +do_container_image[vardeps] += "CONTAINER_FORMATS" >>> +do_container_image(){ >>> + rootfs_id="${DISTRO}-${DISTRO_ARCH}" >>> + >>> + bbnote "Generate container image in these formats: ${CONTAINER_FORMATS}" >> Probabably more "bbdebug"? Unsure. But we aren't using bbnote in the >> core so far. Nor bbdebug, though. > > At least bbdebug is IMO needed for debbuging if goes wrong. > > BTW I'm using bbdebug a lot in the containerize_rootfs section because I've missed those kind of traces much too often when trying to debug some issues on ISAR recipes. > > Perhaps we should have more debug verbosity in the logs to ease debugging... > >> >>> + containerize_rootfs "${IMAGE_ROOTFS}" "${rootfs_id}" "${CONTAINER_FORMATS}" >>> +} >>> + >>> +addtask container_image before do_image after do_image_tools >>> diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass >>> index a8c708a..63138da 100644 >>> --- a/meta/classes/image-sdk-extension.bbclass >>> +++ b/meta/classes/image-sdk-extension.bbclass >>> @@ -6,11 +6,25 @@ >>> # This class extends the image.bbclass to supply the creation of a sdk >>> >>> SDK_INCLUDE_ISAR_APT ?= "0" >>> +SDK_FORMATS ?= "tar-xz" >>> + >>> +sdk_tar_xz() { >>> + # Copy mount_chroot.sh for convenience >>> + sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} >>> + >>> + # Create SDK archive >>> + cd -P ${SDKCHROOT_DIR}/.. >>> + sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ >>> + -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz >>> + bbnote "SDK rootfs available in ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz" >>> +} >>> >>> do_populate_sdk[stamp-extra-info] = "${DISTRO}-${MACHINE}" >>> do_populate_sdk[depends] = "sdkchroot:do_build" >>> -do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT" >>> +do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT SDK_FORMATS" >>> do_populate_sdk() { >>> + local sdk_container_formats="" >>> + >>> if [ "${SDK_INCLUDE_ISAR_APT}" = "1" ]; then >>> # Copy isar-apt with deployed Isar packages >>> sudo cp -Trpfx ${REPO_ISAR_DIR}/${DISTRO} ${SDKCHROOT_DIR}/isar-apt >>> @@ -48,12 +62,35 @@ do_populate_sdk() { >>> done >>> done >>> >>> - # Copy mount_chroot.sh for convenience >>> - sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} >>> + # separate SDK formats: TAR and container formats >>> + for sdk_format in ${SDK_FORMATS} ; do >>> + case ${sdk_format} in >>> + "tar-xz") >>> + sdk_tar_xz >>> + ;; >>> + "docker-archive" | "oci" | "oci-archive") >>> + if [ -z "${sdk_container_formats}" ] ; then >> Unneeded, just use the else part unconditionally. > > The else part alone adds a heading whitespace. It's being ignored in containerize_rootfs, but it's still messing up some outputs. > > Not really useless, but not important (in fact that was my 1st version). I can change it in the next patch series version that I need anyway. > Looks like cosmetics, not functional issues. But if you dislike the leading whitespaces in the debug logs, make it trailing (prepend rather than append). >> >>> + sdk_container_formats="${sdk_format}" >>> + else >>> + sdk_container_formats="${sdk_container_formats} ${sdk_format}" >>> + fi >>> + ;; >>> + "docker-daemon" | "containers-storage") >>> + if [ -f /.dockerenv ] || [ -f /run/.containerenv ] ; then >>> + die "Adding the SDK container image to a container runtime (${sdk_format}) not supported if running from a container (e.g. 'kas-container')" >>> + fi >> See above, should likely go into containerize_rootfs(). > > Right, will fix it. > > In fact this case section is really messed up, I have to clean it up completely. > OK, seems we are again on the same page. >> >>> + ;; >>> + *) >>> + die "unsupported SDK format specified: ${sdk_format}" >>> + ;; >>> + esac >>> + done >>> >>> - # Create SDK archive >>> - cd -P ${SDKCHROOT_DIR}/.. >>> - sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ >>> - -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz >>> + # generate the SDK in all the desired container formats >>> + if [ -n "${sdk_container_formats}" ] ; then >>> + bbnote "Generating SDK container in ${sdk_container_formats} format" >>> + containerize_rootfs "${SDKCHROOT_DIR}" "sdk-${DISTRO}-${DISTRO_ARCH}" "${sdk_container_formats}" >>> + fi >>> } >>> + >>> addtask populate_sdk after do_rootfs >>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass >>> index eddc444..7fb7b7e 100644 >>> --- a/meta/classes/image.bbclass >>> +++ b/meta/classes/image.bbclass >>> @@ -76,6 +76,7 @@ inherit image-tools-extension >>> inherit image-postproc-extension >>> inherit image-locales-extension >>> inherit image-account-extension >>> +inherit container-img >>> >>> # Extra space for rootfs in MB >>> ROOTFS_EXTRA ?= "64" >>> >> Jan > Silvano > Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v3 1/2] images: add support for container images 2021-02-12 18:06 ` Jan Kiszka @ 2021-02-12 18:23 ` Silvano Cirujano Cuesta 2021-02-15 9:46 ` Silvano Cirujano Cuesta 0 siblings, 1 reply; 10+ messages in thread From: Silvano Cirujano Cuesta @ 2021-02-12 18:23 UTC (permalink / raw) To: Jan Kiszka, isar-users On 12/02/2021 19:06, Jan Kiszka wrote: > On 12.02.21 18:46, Silvano Cirujano Cuesta wrote: >> On 12/02/2021 18:10, Jan Kiszka wrote: >>> On 12.02.21 09:51, [ext] Silvano Cirujano Cuesta wrote: >>>> Add support for creation of container images with the build root >>>> filesystems. >>>> >>>> Extend also task "populate_sdk" to support the creation of a container image >>>> containing the SDK. >>> Should be done in to steps: container-img.bbclass frirst, and then a >>> patch to use it for the SDK as well. >> Ok. There are some many different tastes WRT to big vs small commits :-) > Rather /wrt logically separatable steps. > >>>> Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com> >>>> --- >>>> meta/classes/container-img.bbclass | 88 ++++++++++++++++++++++++ >>>> meta/classes/image-sdk-extension.bbclass | 51 ++++++++++++-- >>>> meta/classes/image.bbclass | 1 + >>>> 3 files changed, 133 insertions(+), 7 deletions(-) >>>> create mode 100644 meta/classes/container-img.bbclass >>>> >>>> diff --git a/meta/classes/container-img.bbclass b/meta/classes/container-img.bbclass >>>> new file mode 100644 >>>> index 0000000..35c7bbc >>>> --- /dev/null >>>> +++ b/meta/classes/container-img.bbclass >>>> @@ -0,0 +1,88 @@ >>>> +# This software is a part of ISAR. >>>> +# Copyright (C) Siemens AG, 2021 >>>> +# >>>> +# SPDX-License-Identifier: MIT >>>> +# >>>> +# This class provides the tasks 'containerize_rootfs' and 'containerize_sdk' >>> Nope, it now only provides the former. >> Yes, you're right, will fix it. >>>> +# to create container images containing the target rootfs and the SDK >>>> +# respectively. >>>> + >>>> +CONTAINER_FORMATS ?= "docker-archive" >>>> + >>>> +containerize_rootfs() { >>>> + local cmd="/bin/dash" >>>> + local empty_tag="empty" >>>> + local full_tag="latest" >>>> + local oci_img_dir="${WORKDIR}/oci-image" >>>> + local rootfs="$1" >>>> + local rootfs_id="$2" >>>> + local container_formats="$3" >>>> + >>>> + # prepare OCI container image skeleton >>>> + bbdebug 1 "prepare OCI container image skeleton" >>>> + rm -rf "${oci_img_dir}" >>>> + sudo umoci init --layout "${oci_img_dir}" >>>> + sudo umoci new --image "${oci_img_dir}:${empty_tag}" >>>> + sudo umoci config --image "${oci_img_dir}:${empty_tag}" \ >>>> + --config.cmd="${cmd}" >>>> + sudo umoci unpack --image "${oci_img_dir}:${empty_tag}" \ >>>> + "${oci_img_dir}_unpacked" >>>> + >>>> + # add root filesystem as the flesh of the skeleton >>>> + sudo cp -a "${rootfs}"/* "${oci_img_dir}_unpacked/rootfs/" >>>> + >>>> + # pack container image >>>> + bbdebug 1 "pack container image" >>>> + sudo umoci repack --image "${oci_img_dir}:${full_tag}" \ >>>> + "${oci_img_dir}_unpacked" >>>> + sudo umoci remove --image "${oci_img_dir}:${empty_tag}" >>>> + sudo rm -rf "${oci_img_dir}_unpacked" >>>> + >>>> + # no root needed anymore >>>> + sudo chown --recursive $(id -u):$(id -g) "${oci_img_dir}" >>>> + >>>> + # convert the OCI container image to the desired format >>>> + image_name="isar-${rootfs_id}" >>>> + for image_type in ${CONTAINER_FORMATS} ; do >>>> + image_archive="${DEPLOY_DIR_IMAGE}/${rootfs_id}-${image_type}.tar" >>>> + bbdebug 1 "Creating container image type: ${image_type}" >>>> + case "${image_type}" in >>>> + "docker-archive" | "oci-archive") >>>> + if [ "${image_type}" = "oci-archive" ] ; then >>>> + target="${image_type}:${image_archive}:latest" >>>> + else >>>> + target="${image_type}:${image_archive}:${image_name}:latest" >>>> + fi >>>> + rm -f "${image_archive}" "${image_archive}.xz" >>>> + bbdebug 2 "Converting OCI image to ${image_type}" >>>> + skopeo --insecure-policy copy \ >>>> + "oci:${oci_img_dir}:${full_tag}" "${target}" >>>> + bbdebug 2 "Compressing image" >>>> + xz -T0 "${image_archive}" >>>> + ;; >>>> + "oci") >>>> + tar --create --xz --directory "${oci_img_dir}" \ >>>> + --file "${image_archive}.xz" . >>>> + ;; >>>> + "docker-daemon" | "containers-storage") >>>> + skopeo --insecure-policy copy \ >>>> + "oci:${oci_img_dir}:${full_tag}" \ >>>> + "${image_type}:${image_name}:latest" >>>> + ;; >>> Missing check for "Am I in a container?", like in the SDK. Maybe move >>> that test here and share. >> Not needed, since the usage of IMAGE_TYPE is fixing already to container type. >> >> In the case of the SDK the same task is provides the non-containerized format tar-xz. >> > I cannot follow: What is the difference between > CONTAINER_FORMATS="docker-daemon" and SDK_FORMATS="docker-daemon" when > running inside a kas build container? Both do not work, do they? I misunderstood what you meant. But I got it now, and that's what I meant with the messed up case section. In the next version the "Am I a container?" is in the function, no need to do it twice. >>>> + *) >>>> + die "Unsupported format for containerize_rootfs: ${image_type}" >>>> + ;; >>>> + esac >>>> + done >>>> +} >>>> + >>>> +do_container_image[stamp-extra-info] = "${DISTRO}-${MACHINE}" >>>> +do_container_image[vardeps] += "CONTAINER_FORMATS" >>>> +do_container_image(){ >>>> + rootfs_id="${DISTRO}-${DISTRO_ARCH}" >>>> + >>>> + bbnote "Generate container image in these formats: ${CONTAINER_FORMATS}" >>> Probabably more "bbdebug"? Unsure. But we aren't using bbnote in the >>> core so far. Nor bbdebug, though. >> At least bbdebug is IMO needed for debbuging if goes wrong. >> >> BTW I'm using bbdebug a lot in the containerize_rootfs section because I've missed those kind of traces much too often when trying to debug some issues on ISAR recipes. >> >> Perhaps we should have more debug verbosity in the logs to ease debugging... >> >>>> + containerize_rootfs "${IMAGE_ROOTFS}" "${rootfs_id}" "${CONTAINER_FORMATS}" >>>> +} >>>> + >>>> +addtask container_image before do_image after do_image_tools >>>> diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass >>>> index a8c708a..63138da 100644 >>>> --- a/meta/classes/image-sdk-extension.bbclass >>>> +++ b/meta/classes/image-sdk-extension.bbclass >>>> @@ -6,11 +6,25 @@ >>>> # This class extends the image.bbclass to supply the creation of a sdk >>>> >>>> SDK_INCLUDE_ISAR_APT ?= "0" >>>> +SDK_FORMATS ?= "tar-xz" >>>> + >>>> +sdk_tar_xz() { >>>> + # Copy mount_chroot.sh for convenience >>>> + sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} >>>> + >>>> + # Create SDK archive >>>> + cd -P ${SDKCHROOT_DIR}/.. >>>> + sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ >>>> + -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz >>>> + bbnote "SDK rootfs available in ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz" >>>> +} >>>> >>>> do_populate_sdk[stamp-extra-info] = "${DISTRO}-${MACHINE}" >>>> do_populate_sdk[depends] = "sdkchroot:do_build" >>>> -do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT" >>>> +do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT SDK_FORMATS" >>>> do_populate_sdk() { >>>> + local sdk_container_formats="" >>>> + >>>> if [ "${SDK_INCLUDE_ISAR_APT}" = "1" ]; then >>>> # Copy isar-apt with deployed Isar packages >>>> sudo cp -Trpfx ${REPO_ISAR_DIR}/${DISTRO} ${SDKCHROOT_DIR}/isar-apt >>>> @@ -48,12 +62,35 @@ do_populate_sdk() { >>>> done >>>> done >>>> >>>> - # Copy mount_chroot.sh for convenience >>>> - sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} >>>> + # separate SDK formats: TAR and container formats >>>> + for sdk_format in ${SDK_FORMATS} ; do >>>> + case ${sdk_format} in >>>> + "tar-xz") >>>> + sdk_tar_xz >>>> + ;; >>>> + "docker-archive" | "oci" | "oci-archive") >>>> + if [ -z "${sdk_container_formats}" ] ; then >>> Unneeded, just use the else part unconditionally. >> The else part alone adds a heading whitespace. It's being ignored in containerize_rootfs, but it's still messing up some outputs. >> >> Not really useless, but not important (in fact that was my 1st version). I can change it in the next patch series version that I need anyway. >> > Looks like cosmetics, not functional issues. > > But if you dislike the leading whitespaces in the debug logs, make it > trailing (prepend rather than append). > >>>> + sdk_container_formats="${sdk_format}" >>>> + else >>>> + sdk_container_formats="${sdk_container_formats} ${sdk_format}" >>>> + fi >>>> + ;; >>>> + "docker-daemon" | "containers-storage") >>>> + if [ -f /.dockerenv ] || [ -f /run/.containerenv ] ; then >>>> + die "Adding the SDK container image to a container runtime (${sdk_format}) not supported if running from a container (e.g. 'kas-container')" >>>> + fi >>> See above, should likely go into containerize_rootfs(). >> Right, will fix it. >> >> In fact this case section is really messed up, I have to clean it up completely. >> > OK, seems we are again on the same page. > >>>> + ;; >>>> + *) >>>> + die "unsupported SDK format specified: ${sdk_format}" >>>> + ;; >>>> + esac >>>> + done >>>> >>>> - # Create SDK archive >>>> - cd -P ${SDKCHROOT_DIR}/.. >>>> - sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ >>>> - -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz >>>> + # generate the SDK in all the desired container formats >>>> + if [ -n "${sdk_container_formats}" ] ; then >>>> + bbnote "Generating SDK container in ${sdk_container_formats} format" >>>> + containerize_rootfs "${SDKCHROOT_DIR}" "sdk-${DISTRO}-${DISTRO_ARCH}" "${sdk_container_formats}" >>>> + fi >>>> } >>>> + >>>> addtask populate_sdk after do_rootfs >>>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass >>>> index eddc444..7fb7b7e 100644 >>>> --- a/meta/classes/image.bbclass >>>> +++ b/meta/classes/image.bbclass >>>> @@ -76,6 +76,7 @@ inherit image-tools-extension >>>> inherit image-postproc-extension >>>> inherit image-locales-extension >>>> inherit image-account-extension >>>> +inherit container-img >>>> >>>> # Extra space for rootfs in MB >>>> ROOTFS_EXTRA ?= "64" >>>> >>> Jan >> Silvano >> > Jan Silvano -- Siemens AG, T RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v3 1/2] images: add support for container images 2021-02-12 18:23 ` Silvano Cirujano Cuesta @ 2021-02-15 9:46 ` Silvano Cirujano Cuesta 2021-02-15 10:31 ` Jan Kiszka 0 siblings, 1 reply; 10+ messages in thread From: Silvano Cirujano Cuesta @ 2021-02-15 9:46 UTC (permalink / raw) To: isar-users Wouldn't it make sense to put the "containerize_rootfs" function in a separate class and let "image.bbclass" inherit from it? The current structure that I have come up to seems weird to me, it isn't obvious that "containerize_rootfs" is meant to be reused. (-) an additional class for a single function (+) better structured code Possibilities that seem to fit somehow: - specific class "container.bbclass", - specific class "image-container-extension.bbclass" - existing class already being inherited by "image.bbclass" ("rootfs.bbclass" -is it a rootfs feature?-, "image-postproc-extension.bbclass", "image-tools-extension.bbclass") and I cannot tell which one fits best. Silvano On 12/02/2021 19:23, [ext] Silvano Cirujano Cuesta wrote: > On 12/02/2021 19:06, Jan Kiszka wrote: >> On 12.02.21 18:46, Silvano Cirujano Cuesta wrote: >>> On 12/02/2021 18:10, Jan Kiszka wrote: >>>> On 12.02.21 09:51, [ext] Silvano Cirujano Cuesta wrote: >>>>> Add support for creation of container images with the build root >>>>> filesystems. >>>>> >>>>> Extend also task "populate_sdk" to support the creation of a container image >>>>> containing the SDK. >>>> Should be done in to steps: container-img.bbclass frirst, and then a >>>> patch to use it for the SDK as well. >>> Ok. There are some many different tastes WRT to big vs small commits :-) >> Rather /wrt logically separatable steps. >> >>>>> Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com> >>>>> --- >>>>> meta/classes/container-img.bbclass | 88 ++++++++++++++++++++++++ >>>>> meta/classes/image-sdk-extension.bbclass | 51 ++++++++++++-- >>>>> meta/classes/image.bbclass | 1 + >>>>> 3 files changed, 133 insertions(+), 7 deletions(-) >>>>> create mode 100644 meta/classes/container-img.bbclass >>>>> >>>>> diff --git a/meta/classes/container-img.bbclass b/meta/classes/container-img.bbclass >>>>> new file mode 100644 >>>>> index 0000000..35c7bbc >>>>> --- /dev/null >>>>> +++ b/meta/classes/container-img.bbclass >>>>> @@ -0,0 +1,88 @@ >>>>> +# This software is a part of ISAR. >>>>> +# Copyright (C) Siemens AG, 2021 >>>>> +# >>>>> +# SPDX-License-Identifier: MIT >>>>> +# >>>>> +# This class provides the tasks 'containerize_rootfs' and 'containerize_sdk' >>>> Nope, it now only provides the former. >>> Yes, you're right, will fix it. >>>>> +# to create container images containing the target rootfs and the SDK >>>>> +# respectively. >>>>> + >>>>> +CONTAINER_FORMATS ?= "docker-archive" >>>>> + >>>>> +containerize_rootfs() { >>>>> + local cmd="/bin/dash" >>>>> + local empty_tag="empty" >>>>> + local full_tag="latest" >>>>> + local oci_img_dir="${WORKDIR}/oci-image" >>>>> + local rootfs="$1" >>>>> + local rootfs_id="$2" >>>>> + local container_formats="$3" >>>>> + >>>>> + # prepare OCI container image skeleton >>>>> + bbdebug 1 "prepare OCI container image skeleton" >>>>> + rm -rf "${oci_img_dir}" >>>>> + sudo umoci init --layout "${oci_img_dir}" >>>>> + sudo umoci new --image "${oci_img_dir}:${empty_tag}" >>>>> + sudo umoci config --image "${oci_img_dir}:${empty_tag}" \ >>>>> + --config.cmd="${cmd}" >>>>> + sudo umoci unpack --image "${oci_img_dir}:${empty_tag}" \ >>>>> + "${oci_img_dir}_unpacked" >>>>> + >>>>> + # add root filesystem as the flesh of the skeleton >>>>> + sudo cp -a "${rootfs}"/* "${oci_img_dir}_unpacked/rootfs/" >>>>> + >>>>> + # pack container image >>>>> + bbdebug 1 "pack container image" >>>>> + sudo umoci repack --image "${oci_img_dir}:${full_tag}" \ >>>>> + "${oci_img_dir}_unpacked" >>>>> + sudo umoci remove --image "${oci_img_dir}:${empty_tag}" >>>>> + sudo rm -rf "${oci_img_dir}_unpacked" >>>>> + >>>>> + # no root needed anymore >>>>> + sudo chown --recursive $(id -u):$(id -g) "${oci_img_dir}" >>>>> + >>>>> + # convert the OCI container image to the desired format >>>>> + image_name="isar-${rootfs_id}" >>>>> + for image_type in ${CONTAINER_FORMATS} ; do >>>>> + image_archive="${DEPLOY_DIR_IMAGE}/${rootfs_id}-${image_type}.tar" >>>>> + bbdebug 1 "Creating container image type: ${image_type}" >>>>> + case "${image_type}" in >>>>> + "docker-archive" | "oci-archive") >>>>> + if [ "${image_type}" = "oci-archive" ] ; then >>>>> + target="${image_type}:${image_archive}:latest" >>>>> + else >>>>> + target="${image_type}:${image_archive}:${image_name}:latest" >>>>> + fi >>>>> + rm -f "${image_archive}" "${image_archive}.xz" >>>>> + bbdebug 2 "Converting OCI image to ${image_type}" >>>>> + skopeo --insecure-policy copy \ >>>>> + "oci:${oci_img_dir}:${full_tag}" "${target}" >>>>> + bbdebug 2 "Compressing image" >>>>> + xz -T0 "${image_archive}" >>>>> + ;; >>>>> + "oci") >>>>> + tar --create --xz --directory "${oci_img_dir}" \ >>>>> + --file "${image_archive}.xz" . >>>>> + ;; >>>>> + "docker-daemon" | "containers-storage") >>>>> + skopeo --insecure-policy copy \ >>>>> + "oci:${oci_img_dir}:${full_tag}" \ >>>>> + "${image_type}:${image_name}:latest" >>>>> + ;; >>>> Missing check for "Am I in a container?", like in the SDK. Maybe move >>>> that test here and share. >>> Not needed, since the usage of IMAGE_TYPE is fixing already to container type. >>> >>> In the case of the SDK the same task is provides the non-containerized format tar-xz. >>> >> I cannot follow: What is the difference between >> CONTAINER_FORMATS="docker-daemon" and SDK_FORMATS="docker-daemon" when >> running inside a kas build container? Both do not work, do they? > I misunderstood what you meant. > > But I got it now, and that's what I meant with the messed up case section. > > In the next version the "Am I a container?" is in the function, no need to do it twice. > >>>>> + *) >>>>> + die "Unsupported format for containerize_rootfs: ${image_type}" >>>>> + ;; >>>>> + esac >>>>> + done >>>>> +} >>>>> + >>>>> +do_container_image[stamp-extra-info] = "${DISTRO}-${MACHINE}" >>>>> +do_container_image[vardeps] += "CONTAINER_FORMATS" >>>>> +do_container_image(){ >>>>> + rootfs_id="${DISTRO}-${DISTRO_ARCH}" >>>>> + >>>>> + bbnote "Generate container image in these formats: ${CONTAINER_FORMATS}" >>>> Probabably more "bbdebug"? Unsure. But we aren't using bbnote in the >>>> core so far. Nor bbdebug, though. >>> At least bbdebug is IMO needed for debbuging if goes wrong. >>> >>> BTW I'm using bbdebug a lot in the containerize_rootfs section because I've missed those kind of traces much too often when trying to debug some issues on ISAR recipes. >>> >>> Perhaps we should have more debug verbosity in the logs to ease debugging... >>> >>>>> + containerize_rootfs "${IMAGE_ROOTFS}" "${rootfs_id}" "${CONTAINER_FORMATS}" >>>>> +} >>>>> + >>>>> +addtask container_image before do_image after do_image_tools >>>>> diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass >>>>> index a8c708a..63138da 100644 >>>>> --- a/meta/classes/image-sdk-extension.bbclass >>>>> +++ b/meta/classes/image-sdk-extension.bbclass >>>>> @@ -6,11 +6,25 @@ >>>>> # This class extends the image.bbclass to supply the creation of a sdk >>>>> >>>>> SDK_INCLUDE_ISAR_APT ?= "0" >>>>> +SDK_FORMATS ?= "tar-xz" >>>>> + >>>>> +sdk_tar_xz() { >>>>> + # Copy mount_chroot.sh for convenience >>>>> + sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} >>>>> + >>>>> + # Create SDK archive >>>>> + cd -P ${SDKCHROOT_DIR}/.. >>>>> + sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ >>>>> + -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz >>>>> + bbnote "SDK rootfs available in ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz" >>>>> +} >>>>> >>>>> do_populate_sdk[stamp-extra-info] = "${DISTRO}-${MACHINE}" >>>>> do_populate_sdk[depends] = "sdkchroot:do_build" >>>>> -do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT" >>>>> +do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT SDK_FORMATS" >>>>> do_populate_sdk() { >>>>> + local sdk_container_formats="" >>>>> + >>>>> if [ "${SDK_INCLUDE_ISAR_APT}" = "1" ]; then >>>>> # Copy isar-apt with deployed Isar packages >>>>> sudo cp -Trpfx ${REPO_ISAR_DIR}/${DISTRO} ${SDKCHROOT_DIR}/isar-apt >>>>> @@ -48,12 +62,35 @@ do_populate_sdk() { >>>>> done >>>>> done >>>>> >>>>> - # Copy mount_chroot.sh for convenience >>>>> - sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} >>>>> + # separate SDK formats: TAR and container formats >>>>> + for sdk_format in ${SDK_FORMATS} ; do >>>>> + case ${sdk_format} in >>>>> + "tar-xz") >>>>> + sdk_tar_xz >>>>> + ;; >>>>> + "docker-archive" | "oci" | "oci-archive") >>>>> + if [ -z "${sdk_container_formats}" ] ; then >>>> Unneeded, just use the else part unconditionally. >>> The else part alone adds a heading whitespace. It's being ignored in containerize_rootfs, but it's still messing up some outputs. >>> >>> Not really useless, but not important (in fact that was my 1st version). I can change it in the next patch series version that I need anyway. >>> >> Looks like cosmetics, not functional issues. >> >> But if you dislike the leading whitespaces in the debug logs, make it >> trailing (prepend rather than append). >> >>>>> + sdk_container_formats="${sdk_format}" >>>>> + else >>>>> + sdk_container_formats="${sdk_container_formats} ${sdk_format}" >>>>> + fi >>>>> + ;; >>>>> + "docker-daemon" | "containers-storage") >>>>> + if [ -f /.dockerenv ] || [ -f /run/.containerenv ] ; then >>>>> + die "Adding the SDK container image to a container runtime (${sdk_format}) not supported if running from a container (e.g. 'kas-container')" >>>>> + fi >>>> See above, should likely go into containerize_rootfs(). >>> Right, will fix it. >>> >>> In fact this case section is really messed up, I have to clean it up completely. >>> >> OK, seems we are again on the same page. >> >>>>> + ;; >>>>> + *) >>>>> + die "unsupported SDK format specified: ${sdk_format}" >>>>> + ;; >>>>> + esac >>>>> + done >>>>> >>>>> - # Create SDK archive >>>>> - cd -P ${SDKCHROOT_DIR}/.. >>>>> - sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ >>>>> - -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz >>>>> + # generate the SDK in all the desired container formats >>>>> + if [ -n "${sdk_container_formats}" ] ; then >>>>> + bbnote "Generating SDK container in ${sdk_container_formats} format" >>>>> + containerize_rootfs "${SDKCHROOT_DIR}" "sdk-${DISTRO}-${DISTRO_ARCH}" "${sdk_container_formats}" >>>>> + fi >>>>> } >>>>> + >>>>> addtask populate_sdk after do_rootfs >>>>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass >>>>> index eddc444..7fb7b7e 100644 >>>>> --- a/meta/classes/image.bbclass >>>>> +++ b/meta/classes/image.bbclass >>>>> @@ -76,6 +76,7 @@ inherit image-tools-extension >>>>> inherit image-postproc-extension >>>>> inherit image-locales-extension >>>>> inherit image-account-extension >>>>> +inherit container-img >>>>> >>>>> # Extra space for rootfs in MB >>>>> ROOTFS_EXTRA ?= "64" >>>>> >>>> Jan >>> Silvano >>> >> Jan > Silvano > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v3 1/2] images: add support for container images 2021-02-15 9:46 ` Silvano Cirujano Cuesta @ 2021-02-15 10:31 ` Jan Kiszka 0 siblings, 0 replies; 10+ messages in thread From: Jan Kiszka @ 2021-02-15 10:31 UTC (permalink / raw) To: [ext] Silvano Cirujano Cuesta, isar-users On 15.02.21 10:46, [ext] Silvano Cirujano Cuesta wrote: > Wouldn't it make sense to put the "containerize_rootfs" function in a separate class and let "image.bbclass" inherit from it? > Sounds reasonable to me, even if we end up with only one function in that class, at least so far. Jan > The current structure that I have come up to seems weird to me, it isn't obvious that "containerize_rootfs" is meant to be reused. > > (-) an additional class for a single function > > (+) better structured code > > Possibilities that seem to fit somehow: > - specific class "container.bbclass", > - specific class "image-container-extension.bbclass" > - existing class already being inherited by "image.bbclass" ("rootfs.bbclass" -is it a rootfs feature?-, "image-postproc-extension.bbclass", "image-tools-extension.bbclass") > and I cannot tell which one fits best. > > Silvano > > On 12/02/2021 19:23, [ext] Silvano Cirujano Cuesta wrote: >> On 12/02/2021 19:06, Jan Kiszka wrote: >>> On 12.02.21 18:46, Silvano Cirujano Cuesta wrote: >>>> On 12/02/2021 18:10, Jan Kiszka wrote: >>>>> On 12.02.21 09:51, [ext] Silvano Cirujano Cuesta wrote: >>>>>> Add support for creation of container images with the build root >>>>>> filesystems. >>>>>> >>>>>> Extend also task "populate_sdk" to support the creation of a container image >>>>>> containing the SDK. >>>>> Should be done in to steps: container-img.bbclass frirst, and then a >>>>> patch to use it for the SDK as well. >>>> Ok. There are some many different tastes WRT to big vs small commits :-) >>> Rather /wrt logically separatable steps. >>> >>>>>> Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com> >>>>>> --- >>>>>> meta/classes/container-img.bbclass | 88 ++++++++++++++++++++++++ >>>>>> meta/classes/image-sdk-extension.bbclass | 51 ++++++++++++-- >>>>>> meta/classes/image.bbclass | 1 + >>>>>> 3 files changed, 133 insertions(+), 7 deletions(-) >>>>>> create mode 100644 meta/classes/container-img.bbclass >>>>>> >>>>>> diff --git a/meta/classes/container-img.bbclass b/meta/classes/container-img.bbclass >>>>>> new file mode 100644 >>>>>> index 0000000..35c7bbc >>>>>> --- /dev/null >>>>>> +++ b/meta/classes/container-img.bbclass >>>>>> @@ -0,0 +1,88 @@ >>>>>> +# This software is a part of ISAR. >>>>>> +# Copyright (C) Siemens AG, 2021 >>>>>> +# >>>>>> +# SPDX-License-Identifier: MIT >>>>>> +# >>>>>> +# This class provides the tasks 'containerize_rootfs' and 'containerize_sdk' >>>>> Nope, it now only provides the former. >>>> Yes, you're right, will fix it. >>>>>> +# to create container images containing the target rootfs and the SDK >>>>>> +# respectively. >>>>>> + >>>>>> +CONTAINER_FORMATS ?= "docker-archive" >>>>>> + >>>>>> +containerize_rootfs() { >>>>>> + local cmd="/bin/dash" >>>>>> + local empty_tag="empty" >>>>>> + local full_tag="latest" >>>>>> + local oci_img_dir="${WORKDIR}/oci-image" >>>>>> + local rootfs="$1" >>>>>> + local rootfs_id="$2" >>>>>> + local container_formats="$3" >>>>>> + >>>>>> + # prepare OCI container image skeleton >>>>>> + bbdebug 1 "prepare OCI container image skeleton" >>>>>> + rm -rf "${oci_img_dir}" >>>>>> + sudo umoci init --layout "${oci_img_dir}" >>>>>> + sudo umoci new --image "${oci_img_dir}:${empty_tag}" >>>>>> + sudo umoci config --image "${oci_img_dir}:${empty_tag}" \ >>>>>> + --config.cmd="${cmd}" >>>>>> + sudo umoci unpack --image "${oci_img_dir}:${empty_tag}" \ >>>>>> + "${oci_img_dir}_unpacked" >>>>>> + >>>>>> + # add root filesystem as the flesh of the skeleton >>>>>> + sudo cp -a "${rootfs}"/* "${oci_img_dir}_unpacked/rootfs/" >>>>>> + >>>>>> + # pack container image >>>>>> + bbdebug 1 "pack container image" >>>>>> + sudo umoci repack --image "${oci_img_dir}:${full_tag}" \ >>>>>> + "${oci_img_dir}_unpacked" >>>>>> + sudo umoci remove --image "${oci_img_dir}:${empty_tag}" >>>>>> + sudo rm -rf "${oci_img_dir}_unpacked" >>>>>> + >>>>>> + # no root needed anymore >>>>>> + sudo chown --recursive $(id -u):$(id -g) "${oci_img_dir}" >>>>>> + >>>>>> + # convert the OCI container image to the desired format >>>>>> + image_name="isar-${rootfs_id}" >>>>>> + for image_type in ${CONTAINER_FORMATS} ; do >>>>>> + image_archive="${DEPLOY_DIR_IMAGE}/${rootfs_id}-${image_type}.tar" >>>>>> + bbdebug 1 "Creating container image type: ${image_type}" >>>>>> + case "${image_type}" in >>>>>> + "docker-archive" | "oci-archive") >>>>>> + if [ "${image_type}" = "oci-archive" ] ; then >>>>>> + target="${image_type}:${image_archive}:latest" >>>>>> + else >>>>>> + target="${image_type}:${image_archive}:${image_name}:latest" >>>>>> + fi >>>>>> + rm -f "${image_archive}" "${image_archive}.xz" >>>>>> + bbdebug 2 "Converting OCI image to ${image_type}" >>>>>> + skopeo --insecure-policy copy \ >>>>>> + "oci:${oci_img_dir}:${full_tag}" "${target}" >>>>>> + bbdebug 2 "Compressing image" >>>>>> + xz -T0 "${image_archive}" >>>>>> + ;; >>>>>> + "oci") >>>>>> + tar --create --xz --directory "${oci_img_dir}" \ >>>>>> + --file "${image_archive}.xz" . >>>>>> + ;; >>>>>> + "docker-daemon" | "containers-storage") >>>>>> + skopeo --insecure-policy copy \ >>>>>> + "oci:${oci_img_dir}:${full_tag}" \ >>>>>> + "${image_type}:${image_name}:latest" >>>>>> + ;; >>>>> Missing check for "Am I in a container?", like in the SDK. Maybe move >>>>> that test here and share. >>>> Not needed, since the usage of IMAGE_TYPE is fixing already to container type. >>>> >>>> In the case of the SDK the same task is provides the non-containerized format tar-xz. >>>> >>> I cannot follow: What is the difference between >>> CONTAINER_FORMATS="docker-daemon" and SDK_FORMATS="docker-daemon" when >>> running inside a kas build container? Both do not work, do they? >> I misunderstood what you meant. >> >> But I got it now, and that's what I meant with the messed up case section. >> >> In the next version the "Am I a container?" is in the function, no need to do it twice. >> >>>>>> + *) >>>>>> + die "Unsupported format for containerize_rootfs: ${image_type}" >>>>>> + ;; >>>>>> + esac >>>>>> + done >>>>>> +} >>>>>> + >>>>>> +do_container_image[stamp-extra-info] = "${DISTRO}-${MACHINE}" >>>>>> +do_container_image[vardeps] += "CONTAINER_FORMATS" >>>>>> +do_container_image(){ >>>>>> + rootfs_id="${DISTRO}-${DISTRO_ARCH}" >>>>>> + >>>>>> + bbnote "Generate container image in these formats: ${CONTAINER_FORMATS}" >>>>> Probabably more "bbdebug"? Unsure. But we aren't using bbnote in the >>>>> core so far. Nor bbdebug, though. >>>> At least bbdebug is IMO needed for debbuging if goes wrong. >>>> >>>> BTW I'm using bbdebug a lot in the containerize_rootfs section because I've missed those kind of traces much too often when trying to debug some issues on ISAR recipes. >>>> >>>> Perhaps we should have more debug verbosity in the logs to ease debugging... >>>> >>>>>> + containerize_rootfs "${IMAGE_ROOTFS}" "${rootfs_id}" "${CONTAINER_FORMATS}" >>>>>> +} >>>>>> + >>>>>> +addtask container_image before do_image after do_image_tools >>>>>> diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass >>>>>> index a8c708a..63138da 100644 >>>>>> --- a/meta/classes/image-sdk-extension.bbclass >>>>>> +++ b/meta/classes/image-sdk-extension.bbclass >>>>>> @@ -6,11 +6,25 @@ >>>>>> # This class extends the image.bbclass to supply the creation of a sdk >>>>>> >>>>>> SDK_INCLUDE_ISAR_APT ?= "0" >>>>>> +SDK_FORMATS ?= "tar-xz" >>>>>> + >>>>>> +sdk_tar_xz() { >>>>>> + # Copy mount_chroot.sh for convenience >>>>>> + sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} >>>>>> + >>>>>> + # Create SDK archive >>>>>> + cd -P ${SDKCHROOT_DIR}/.. >>>>>> + sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ >>>>>> + -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz >>>>>> + bbnote "SDK rootfs available in ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz" >>>>>> +} >>>>>> >>>>>> do_populate_sdk[stamp-extra-info] = "${DISTRO}-${MACHINE}" >>>>>> do_populate_sdk[depends] = "sdkchroot:do_build" >>>>>> -do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT" >>>>>> +do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT SDK_FORMATS" >>>>>> do_populate_sdk() { >>>>>> + local sdk_container_formats="" >>>>>> + >>>>>> if [ "${SDK_INCLUDE_ISAR_APT}" = "1" ]; then >>>>>> # Copy isar-apt with deployed Isar packages >>>>>> sudo cp -Trpfx ${REPO_ISAR_DIR}/${DISTRO} ${SDKCHROOT_DIR}/isar-apt >>>>>> @@ -48,12 +62,35 @@ do_populate_sdk() { >>>>>> done >>>>>> done >>>>>> >>>>>> - # Copy mount_chroot.sh for convenience >>>>>> - sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} >>>>>> + # separate SDK formats: TAR and container formats >>>>>> + for sdk_format in ${SDK_FORMATS} ; do >>>>>> + case ${sdk_format} in >>>>>> + "tar-xz") >>>>>> + sdk_tar_xz >>>>>> + ;; >>>>>> + "docker-archive" | "oci" | "oci-archive") >>>>>> + if [ -z "${sdk_container_formats}" ] ; then >>>>> Unneeded, just use the else part unconditionally. >>>> The else part alone adds a heading whitespace. It's being ignored in containerize_rootfs, but it's still messing up some outputs. >>>> >>>> Not really useless, but not important (in fact that was my 1st version). I can change it in the next patch series version that I need anyway. >>>> >>> Looks like cosmetics, not functional issues. >>> >>> But if you dislike the leading whitespaces in the debug logs, make it >>> trailing (prepend rather than append). >>> >>>>>> + sdk_container_formats="${sdk_format}" >>>>>> + else >>>>>> + sdk_container_formats="${sdk_container_formats} ${sdk_format}" >>>>>> + fi >>>>>> + ;; >>>>>> + "docker-daemon" | "containers-storage") >>>>>> + if [ -f /.dockerenv ] || [ -f /run/.containerenv ] ; then >>>>>> + die "Adding the SDK container image to a container runtime (${sdk_format}) not supported if running from a container (e.g. 'kas-container')" >>>>>> + fi >>>>> See above, should likely go into containerize_rootfs(). >>>> Right, will fix it. >>>> >>>> In fact this case section is really messed up, I have to clean it up completely. >>>> >>> OK, seems we are again on the same page. >>> >>>>>> + ;; >>>>>> + *) >>>>>> + die "unsupported SDK format specified: ${sdk_format}" >>>>>> + ;; >>>>>> + esac >>>>>> + done >>>>>> >>>>>> - # Create SDK archive >>>>>> - cd -P ${SDKCHROOT_DIR}/.. >>>>>> - sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ >>>>>> - -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz >>>>>> + # generate the SDK in all the desired container formats >>>>>> + if [ -n "${sdk_container_formats}" ] ; then >>>>>> + bbnote "Generating SDK container in ${sdk_container_formats} format" >>>>>> + containerize_rootfs "${SDKCHROOT_DIR}" "sdk-${DISTRO}-${DISTRO_ARCH}" "${sdk_container_formats}" >>>>>> + fi >>>>>> } >>>>>> + >>>>>> addtask populate_sdk after do_rootfs >>>>>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass >>>>>> index eddc444..7fb7b7e 100644 >>>>>> --- a/meta/classes/image.bbclass >>>>>> +++ b/meta/classes/image.bbclass >>>>>> @@ -76,6 +76,7 @@ inherit image-tools-extension >>>>>> inherit image-postproc-extension >>>>>> inherit image-locales-extension >>>>>> inherit image-account-extension >>>>>> +inherit container-img >>>>>> >>>>>> # Extra space for rootfs in MB >>>>>> ROOTFS_EXTRA ?= "64" >>>>>> >>>>> Jan >>>> Silvano >>>> >>> Jan >> Silvano >> > -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v3 2/2] docs: document creation of container images 2021-02-12 8:51 [PATCH v3 0/2] Add support for containerized root filesystems Silvano Cirujano Cuesta 2021-02-12 8:51 ` [PATCH v3 1/2] images: add support for container images Silvano Cirujano Cuesta @ 2021-02-12 8:51 ` Silvano Cirujano Cuesta 1 sibling, 0 replies; 10+ messages in thread From: Silvano Cirujano Cuesta @ 2021-02-12 8:51 UTC (permalink / raw) To: isar-users Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com> --- doc/user_manual.md | 127 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 127 insertions(+) diff --git a/doc/user_manual.md b/doc/user_manual.md index a4f3d1d..f6f49bc 100644 --- a/doc/user_manual.md +++ b/doc/user_manual.md @@ -19,6 +19,7 @@ Copyright (C) 2016-2019, ilbers GmbH - [Add a Custom Application](#add-a-custom-application) - [Enabling Cross-compilation](#isar-cross-compilation) - [Create an ISAR SDK root filesystem](#create-an-isar-sdk-root-filesystem) + - [Create a containerized ISAR SDK root filesystem](#create-a-containerized-isar-sdk-root-filesystem) - [Creation of local apt repo caching upstream Debian packages](#creation-of-local-apt-repo-caching-upstream-debian-packages) @@ -84,6 +85,9 @@ If your host is >= buster, also install the following package. apt install python3-distutils ``` +If you want to generate containerized SDKs, also install the following packages: `umoci` and `skopeo`. +Umoci is provided by Debian Buster and can be installed with `apt install umoci`, Skopeo is provided by Debian Bullseye/Unstable and has to be installed either manually downloading the DEB and installing it (no other packages required) or with `apt install -t bullseye skopeo` (if unstable/bullseye included in `/etc/apt/sources.list[.d]`). + Notes: * BitBake requires Python 3.4+. @@ -223,6 +227,54 @@ qemu-system-x86_64 -m 256M -nographic -bios edk2/Build/OvmfX64/RELEASE_*/FV/OVMF qemu-system-i386 -m 256M -nographic -hda tmp/deploy/images/qemui386/isar-image-base-debian-buster-qemui386.wic.img ``` +### Generate container image with root-filesystem + +A runnable container image is generated if you set IMAGE_TYPE to 'container-img'. +Getting a container image can be the main purpose of an ISAR configuration, but not only. +A container image created from an ISAR configuration meant for bare-metal or virtual machines can be helpfull to test certain applications which requirements (e.g. libraries) can be easily resolved in a containerized environment. + +Container images can be generated in different formats, selected with the variable `CONTAINER_FORMAT`. One or more (whitespace separated) of following options can be given: + - `docker-archive`: (default) an archive containing a Docker image that can be imported with [`docker import`](https://docs.docker.com/engine/reference/commandline/import/) + - `docker-daemon`: resulting container image is made available on the local Docker Daemon + - `containers-storage`: resulting container image is made available to tools using containers/storage back-end (e.g. Podman, CRIO, buildah,...) + - `oci-archive`: an archive containing an OCI image, mostly for archiving as seed for any of the above formats + +Following formats don't work if running `bitbake ...` (to build the image) from inside of a container (e.g. using `kas-container`): `docker-daemon` and `containers-storage`. +It's technically possible, but requires making host resources (e.g. the Docker Daemon socket) accessible in the container. +What can endanger the stability and security of the host. + +The resulting container image archives (only for `docker-archive` and `oci-archive`) are made available as `tmp/deploy/images/${MACHINE}/${DISTRO}-${DISTRO_ARCH}-${container_format}.tar.xz` (being `container_format` each one of the formats specified in `CONTAINER_FORMAT`). + +### Example + + - Make the relevant environment variables available to the task + +For one-shot builds (use `local.conf` otherwise): + +``` +export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE IMAGE_TYPE CONTAINER_FORMAT" +export IMAGE_TYPE="container-img" +export CONTAINER_FORMAT="docker-archive" +``` + + - Trigger creation of container image from root filesystem + +``` +bitbake mc:qemuarm-buster:isar-image-base +``` + + - Load the container image into the Docker Daemon + +``` +xzcat build/tmp/deploy/images/qemuarm/debian-buster-armhf-docker-archive.tar.xz | docker load +``` + + - Run a container using the container image (following commands starting with `#~:` are to be run in the container) + +``` +docker run --rm -ti --volume "$(pwd):/build" isar-buster-armhf:latest +``` + --- ## Terms and Definitions @@ -834,6 +886,81 @@ ii crossbuild-essential-armhf 12.3 all Inf ~# ``` +## Create a containerized ISAR SDK root filesystem + +### Motivation + +Distributing and using the SDK root filesystem created following the instructions in "[Create an ISAR SDK root filesystem](#create-an-isar-sdk-root-filesystem)" becomes easier using container images (at least for those using containers anyway) +A "containerized" SDK adds to those advantages of a normal SDK root filesystem the comfort of container images. + +### Approach + +Create container image with SDK root filesystem with installed cross-toolchain for target architecture and ability to install already prebuilt target binary artifacts. +Developer: + - runs a container based on the resulting container image mounting the source code to be built, + - develops applications for target platform on the container and + - leaves the container getting the results on the mounted directory. + +### Solution + +User specifies the variable `SDK_FORMAT` providing a space-separated list of SDK formats to generate. + +Supported formats are: + - `tar-xz`: (default) is the non-containerized format that results from following the instructions in "[Create an ISAR SDK root filesystem](#create-an-isar-sdk-root-filesystem)" + - `docker-archive`: an archive containing a Docker image that can be imported with [`docker import`](https://docs.docker.com/engine/reference/commandline/import/) + - `docker-daemon`: resulting container image is made available on the local Docker Daemon + - `containers-storage`: resulting container image is made available to tools using containers/storage back-end (e.g. Podman, CRIO, buildah,...) + - `oci-archive`: an archive containing an OCI image, mostly for archiving as seed for any of the above formats + +User manually triggers creation of SDK formats for his target platform by launching the task `do_populate_sdk` for target image, f.e. +`bitbake -c do_populate_sdk mc:${MACHINE}-${DISTRO}:isar-image-base`. +Packages that should be additionally installed into the SDK can be appended to `SDK_PREINSTALL` (external repositories) and `SDK_INSTALL` (self-built). + +Following formats don't work if running `bitbake -c do_populate_sdk ...` (to generate the containerized SDK) from inside of a container (e.g. using `kas-container`): `docker-daemon` and `containers-storage`. +It's technically possible, but requires making host resources (e.g. the Docker Daemon socket) accessible in the container. +What can endanger the stability and security of the host. + +The resulting SDK formats are archived into `tmp/deploy/images/${MACHINE}/sdk-${DISTRO}-${DISTRO_ARCH}-${sdk_format}.tar.xz` (being `sdk_format` each one of the formats specified in `SDK_FORMATS`). +The SDK container directory `/isar-apt` contains a copy of isar-apt repo with locally prebuilt target debian packages (for <HOST_DISTRO>). +One may get into an SDK container and install required target packages with the help of `apt-get install <package_name>:<DISTRO_ARCH>` command. +The directory with the source code to develop on should be mounted on the container (with `--volume <host-directory>:<container-directory>`) to be able to edit files in the host with an IDE and build in the container. + +### Example + + - Make the SDK formats to generate available to the task + +For one-shot builds (use `local.conf` otherwise): + +``` +export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE SDK_FORMATS" +export SDK_FORMATS="docker-archive" +``` + + - Trigger creation of SDK root filesystem + +``` +bitbake -c do_populate_sdk mc:qemuarm-buster:isar-image-base +``` + + - Load the SDK container image into the Docker Daemon + +``` +xzcat build/tmp/deploy/images/qemuarm/sdk-debian-buster-armhf-docker-archive.tar.xz | docker load +``` + + - Run a container using the SDK container image (following commands starting with `#~:` are to be run in the container) + +``` +docker run --rm -ti --volume "$(pwd):/build" isar-sdk-buster-armhf:latest +``` + + - Check that cross toolchains are installed + +``` +:~# dpkg -l | grep crossbuild-essential-armhf +ii crossbuild-essential-armhf 12.3 all Informational list of cross-build-essential packages +``` + ## Creation of local apt repo caching upstream Debian packages ### Motivation -- 2.30.0 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-02-15 10:31 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-02-12 8:51 [PATCH v3 0/2] Add support for containerized root filesystems Silvano Cirujano Cuesta 2021-02-12 8:51 ` [PATCH v3 1/2] images: add support for container images Silvano Cirujano Cuesta 2021-02-12 17:10 ` Jan Kiszka 2021-02-12 17:46 ` Silvano Cirujano Cuesta 2021-02-12 18:04 ` Silvano Cirujano Cuesta 2021-02-12 18:06 ` Jan Kiszka 2021-02-12 18:23 ` Silvano Cirujano Cuesta 2021-02-15 9:46 ` Silvano Cirujano Cuesta 2021-02-15 10:31 ` Jan Kiszka 2021-02-12 8:51 ` [PATCH v3 2/2] docs: document creation of " Silvano Cirujano Cuesta
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox