| Message ID | 20210209141005.45491-1-silvano.cirujano-cuesta@siemens.com |
|---|---|
| Headers | show |
| Series | Add support for containerized root filesystems | expand |
On 09.02.21 15:10, [ext] Silvano Cirujano Cuesta wrote: > 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 rootfilesystems `IMAGE_TYPE` as to be > `container-img`, additionally the container image format can be selected > with the variable `CONTAINER_FORMAT`. The default format is > `docker-archive`. > But you dropped control over building the SDK (and only the SDK) as container, didn't you? Where did that SDK_FORMATS go? Jan > 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 > > 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 | 99 ++++++++++++++++++++++ > 2 files changed, 226 insertions(+) > create mode 100644 meta/classes/container-img.bbclass >
On 09/02/2021 17:50, Jan Kiszka wrote: > On 09.02.21 15:10, [ext] Silvano Cirujano Cuesta wrote: >> 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 rootfilesystems `IMAGE_TYPE` as to be >> `container-img`, additionally the container image format can be selected >> with the variable `CONTAINER_FORMAT`. The default format is >> `docker-archive`. >> > But you dropped control over building the SDK (and only the SDK) as > container, didn't you? Where did that SDK_FORMATS go? > > Jan Yes, if we want to have so much control, them we'll need at least 3 variables instead of 2. But I can introduce them, if desired. Two of them to select the container format(s) to generate. For these I'd propose CONTAINER_FORMAT and SDK_FORMAT. Another one to select the build of a container image for target, IMAGE_TYPE="container-img" would be my proposal. The selection of containerized SDK would be implicit with the presence of a valid SDK_FORMAT. If that selection should be explicit, then a 4th variable would be needed. I don't have a strong opinion on this, so simply make a wish. Silvano > >> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsiemens%2Fmeta-iot2050&data=04%7C01%7Csilvano.cirujano-cuesta%40siemens.com%7Cb07a56105809427e9b7308d8cd1ac275%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637484862105605050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=odtZPJwWKcqoXH5VrvsRtfqDzHS8wwYSS0M6WsNtzmU%3D&reserved=0. >> Jan Kiszka already tested and liked it! => >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsiemens%2Fmeta-iot2050%2Fissues%2F86%23issuecomment-768907845&data=04%7C01%7Csilvano.cirujano-cuesta%40siemens.com%7Cb07a56105809427e9b7308d8cd1ac275%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637484862105605050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bXFPjdM8f5VwsFozf5vGHoMRwfo6kv2D%2FxvL76mtZtw%3D&reserved=0 >> >> In order to get a feeling about its usage (you need Docker or Podman), >> follow these simple copy&paste instructions: >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSilvanoc%2Fmeta-iot2050%2Fblob%2Fmaster%2Fkas%2FBUILDING-SDK-CONTAINER.md%23running-the-sdk&data=04%7C01%7Csilvano.cirujano-cuesta%40siemens.com%7Cb07a56105809427e9b7308d8cd1ac275%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637484862105605050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mONGFofFottYo4fVJ%2BMADZ%2Fx%2FZ6NmOj8w6POjw1FlAk%3D&reserved=0 >> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsiemens%2Fkas&data=04%7C01%7Csilvano.cirujano-cuesta%40siemens.com%7Cb07a56105809427e9b7308d8cd1ac275%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637484862105605050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X2OZUddd2z%2BWIRHIZuSdBXTI%2BJvr9Jh%2FXw%2BgrqO1Ni4%3D&reserved=0 (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 | 99 ++++++++++++++++++++++ >> 2 files changed, 226 insertions(+) >> create mode 100644 meta/classes/container-img.bbclass >>
On 09.02.21 18:37, Silvano Cirujano Cuesta wrote: > > On 09/02/2021 17:50, Jan Kiszka wrote: >> On 09.02.21 15:10, [ext] Silvano Cirujano Cuesta wrote: >>> 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 rootfilesystems `IMAGE_TYPE` as to be >>> `container-img`, additionally the container image format can be selected >>> with the variable `CONTAINER_FORMAT`. The default format is >>> `docker-archive`. >>> >> But you dropped control over building the SDK (and only the SDK) as >> container, didn't you? Where did that SDK_FORMATS go? >> >> Jan > > Yes, if we want to have so much control, them we'll need at least 3 variables instead of 2. But I can introduce them, if desired. > > Two of them to select the container format(s) to generate. For these I'd propose CONTAINER_FORMAT and SDK_FORMAT. > > Another one to select the build of a container image for target, IMAGE_TYPE="container-img" would be my proposal. > > The selection of containerized SDK would be implicit with the presence of a valid SDK_FORMAT. If that selection should be explicit, then a 4th variable would be needed. > > I don't have a strong opinion on this, so simply make a wish. There are two use cases (target image format = container, SDK = container), and those should be independently configurable. I was fine with your previous way of configuring the SDK_FORMATS. Here, we should add container-img as another IMAGE_TYPE, further configurable regarding its output formats (CONTAINER_FORMATS). And both use cases should share container-img.bbclass for their common bits. Jan