Drop the Buildah dependency and the need for the user-specific customized image by debarshiray · Pull Request #160 · containers/toolbox

debarshiray · 2019-05-14T14:53:37Z

Currently, the toolbox script depends on both the buildah and podman commands. However, both are Go programs, and like all Go programs the absense of shared libraries leads to bigger binaries. eg., the buildah and podman binaries are approximately 22 MB and 48 MB respectively, whereas the flatpak binary is a mere 1.4 MB.

Due to this, there's some nascent desire from the Endless OS folks to reduce the dependency footprint of the toolbox script by dropping the Buildah dependency.

Tied to this is the use of the user-specific customized image. If nothing else, the purpose of this second image is hard to explain to users in Toolbox documentation.

Secondly, since the configuration happens during the toolbox create command, backwards compatibility becomes difficult. Since these are pet containers, users are expected to use create only once. Therefore it's smart to make it more minimal and do more work in enter.

Both the above problems are solved by configuring the toolbox container after it has been created, instead of before. This can be done by making the toolbox script itself the entry point of the container, which can exec sleep +Inf once the initialization is done.

Based on an idea from Colin Walters.

Commit 8127daa added the com.github.debarshiray.toolbox label to the user-specific customized image generated by the 'create' command, which gets inherited by toolbox containers using the image. However, there might be really old images lying around in users' caches that don't have the label, and in those cases the damage can be limited by adding it directly to the newly created toolbox container. Moreover, a subsequent commit will remove the need for the user-specific customized image, and which will make this change mandatory. https://github.com/debarshiray/toolbox/pull/160

A subsequent commit will add a new command to configure a toolbox container after it has been created. This command is meant to be the container's entry point, and will need to do things as root:root relative to the user namespace. Even though root:root is the default in 'podman create', explicitly specifying it overrides any other value inherited from the user-specific customized image. eg., older images had $USER as the default user. https://github.com/debarshiray/toolbox/pull/160

Consolidate the code to forward commands to the host in one place instead of doing it repeatedly for each command. This reduces the levels of indentation in the code, making it easier to read. https://github.com/debarshiray/toolbox/pull/160

A subsequent commit will add a new command to configure a toolbox container after it has been created. This command is meant to run inside the container without being forwarded to the host. Therefore, just running inside a container doesn't mean that flatpak-spawn(1) is mandatory. This should help with toolbox containers created from images which don't have flatpak-spawn(1) in them. eg., the fedora-toolbox base image for Fedora 28. https://github.com/debarshiray/toolbox/pull/160

A subsequent commit will add a new command to configure a toolbox container after it has been created. This command is meant to be the container's entry point, which runs before /run/.toolboxenv gets created. Given that the entry point will be set by 'toolbox create' it's safe to assume that it's a toolbox container anyway. https://github.com/debarshiray/toolbox/pull/160

https://github.com/debarshiray/toolbox/pull/160

Commit 8127daa added the com.github.debarshiray.toolbox label to the user-specific customized image generated by the 'create' command, which gets inherited by toolbox containers using the image. However, there might be really old images lying around in users' caches that don't have the label, and in those cases the damage can be limited by adding it directly to the newly created toolbox container. Moreover, a subsequent commit will remove the need for the user-specific customized image, and which will make this change mandatory. https://github.com/debarshiray/toolbox/pull/160

A subsequent commit will add a new command to configure a toolbox container after it has been created. This command is meant to be the container's entry point, and will need to do things as root:root relative to the user namespace. Even though root:root is the default in 'podman create', explicitly specifying it overrides any other value inherited from the user-specific customized image. eg., older images had $USER as the default user. https://github.com/debarshiray/toolbox/pull/160

Consolidate the code to forward commands to the host in one place instead of doing it repeatedly for each command. This reduces the levels of indentation in the code, making it easier to read. https://github.com/debarshiray/toolbox/pull/160

A subsequent commit will add a new command to configure a toolbox container after it has been created. This command is meant to run inside the container without being forwarded to the host. Therefore, just running inside a container doesn't mean that flatpak-spawn(1) is mandatory. This should help with toolbox containers created from images which don't have flatpak-spawn(1) in them. eg., the fedora-toolbox base image for Fedora 28. https://github.com/debarshiray/toolbox/pull/160

A subsequent commit will add a new command to configure a toolbox container after it has been created. This command is meant to be the container's entry point, which runs before /run/.toolboxenv gets created. Given that the entry point will be set by 'toolbox create' it's safe to assume that it's a toolbox container anyway. https://github.com/debarshiray/toolbox/pull/160

https://github.com/debarshiray/toolbox/pull/160

This will make a subsequent commit easier to read. https://github.com/debarshiray/toolbox/pull/160

Commit 8127daa added the com.github.debarshiray.toolbox label to the user-specific customized image generated by the 'create' command, which gets inherited by toolbox containers using the image. However, there might be really old images lying around in users' caches that don't have the label, and in those cases the damage can be limited by adding it directly to the newly created toolbox container. Moreover, a subsequent commit will remove the need for the user-specific customized image, and which will make this change mandatory. https://github.com/debarshiray/toolbox/pull/160

A subsequent commit will add a new command to configure a toolbox container after it has been created. This command is meant to be the container's entry point, and will need to do things as root:root relative to the user namespace. Even though root:root is the default in 'podman create', explicitly specifying it overrides any other value inherited from the user-specific customized image. eg., older images had $USER as the default user. https://github.com/debarshiray/toolbox/pull/160

Consolidate the code to forward commands to the host in one place instead of doing it repeatedly for each command. This reduces the levels of indentation in the code, making it easier to read. https://github.com/debarshiray/toolbox/pull/160

A subsequent commit will add a new command to configure a toolbox container after it has been created. This command is meant to run inside the container without being forwarded to the host. Therefore, just running inside a container doesn't mean that flatpak-spawn(1) is mandatory. This should help with toolbox containers created from images which don't have flatpak-spawn(1) in them. eg., the fedora-toolbox base image for Fedora 28. https://github.com/debarshiray/toolbox/pull/160

A subsequent commit will add a new command to configure a toolbox container after it has been created. This command is meant to be the container's entry point, which runs before /run/.toolboxenv gets created. Given that the entry point will be set by 'toolbox create' it's safe to assume that it's a toolbox container anyway. https://github.com/debarshiray/toolbox/pull/160

A subsequent commit will create toolbox container names based on both the base image and the user-specific customized image. This will make it easier to read. https://github.com/debarshiray/toolbox/pull/160

https://github.com/debarshiray/toolbox/pull/160

This will make a subsequent commit easier to read. https://github.com/debarshiray/toolbox/pull/160

Commit 8127daa added the com.github.debarshiray.toolbox label to the user-specific customized image generated by the 'create' command, which gets inherited by toolbox containers using the image. However, there might be really old images lying around in users' caches that don't have the label, and in those cases the damage can be limited by adding it directly to the newly created toolbox container. Moreover, a subsequent commit will remove the need for the user-specific customized image, and which will make this change mandatory. https://github.com/debarshiray/toolbox/pull/160

A subsequent commit will add a new command to configure a toolbox container after it has been created. This command is meant to be the container's entry point, and will need to do things as root:root relative to the user namespace. Even though root:root is the default in 'podman create', explicitly specifying it overrides any other value inherited from the user-specific customized image. eg., older images had $USER as the default user. https://github.com/debarshiray/toolbox/pull/160

Consolidate the code to forward commands to the host in one place instead of doing it repeatedly for each command. This reduces the levels of indentation in the code, making it easier to read. https://github.com/debarshiray/toolbox/pull/160

A subsequent commit will add a new command to configure a toolbox container after it has been created. This command is meant to be the container's entry point, which runs before /run/.toolboxenv gets created. Given that the entry point will be set by 'toolbox create' it's safe to assume that it's a toolbox container anyway. https://github.com/debarshiray/toolbox/pull/160

A subsequent commit will create toolbox container names based on both the base image and the user-specific customized image. This will make it easier to read. https://github.com/debarshiray/toolbox/pull/160

This works by configuring the toolbox container after it has been created, instead of before. The toolbox script itself is mentioned as the entry point of the container, which does 'exec sleep +Inf' once the initialization is done. A new command 'init-container' was added to perform the initialization. It is primarily meant to be used as the entry point for all toolbox containers, and must be run inside the container that's to be initialized. It is not expected to be directly invoked by humans, and cannot be used on the host. As a result, the default name for the toolbox containers is now fedora-toolbox-<version-id>, not fedora-toolbox-<-user>:<version-id>. For backwards compatibility, 'toolbox enter' and 'toolbox run' will continue to work with containers using the old naming scheme. https://github.com/debarshiray/toolbox/pull/160

This works by configuring the toolbox container after it has been created, instead of before. The toolbox script itself is mentioned as the entry point of the container, which does 'exec sleep +Inf' once the initialization is done. A new command 'init-container' was added to perform the initialization. It is primarily meant to be used as the entry point for all toolbox containers, and must be run inside the container that's to be initialized. It is not expected to be directly invoked by humans, and cannot be used on the host. As a result, the default name for the toolbox containers is now fedora-toolbox-<version-id>, not fedora-toolbox-<user>-<version-id>. For backwards compatibility, 'toolbox enter' and 'toolbox run' will continue to work with containers using the old naming scheme. https://github.com/debarshiray/toolbox/pull/160

Ever since version 0.0.10, all newly created toolbox containers use a reflexive entry point [1] and don't need a user-specific customized image. Older containers that don't use a reflexive entry point were deprecated in version 0.0.17 [2], and aren't even supported in the Go implementation. Therefore, it's time to finally update the manuals to document the current way of doing things. Since the reflexive entry point is a key feature of toolbox containers, some text was added to explain why it's necessary and what it does. [1] Commit 8b84b5e containers#160 [2] Commit 9dc5281 containers#336

Ever since version 0.0.10, all newly created toolbox containers use a reflexive entry point [1] and don't need a user-specific customized image. Older containers that don't use a reflexive entry point were deprecated in version 0.0.17 [2], and aren't even supported in the Go implementation. Therefore, it's time to finally update the manuals to document the current way of doing things. Since the reflexive entry point is a key feature of toolbox containers, some text was added to explain why it's necessary and what it does. [1] Commit 8b84b5e containers#160 [2] Commit 9dc5281 containers#336 containers#677

Toolbox does not use Buildah for a considerable time now[0]. We can stop referencing it in the "See also" sections of the documentation. In some places mention podman command man pages where they are relevant. [0] containers#160

- Update "See also" sections Toolbox does not use Buildah for a considerable time now[0]. We can stop referencing it in the "See also" sections of the documentation. In some places mention podman command man pages where they are relevant. - Add section about toolbox images/containers Toolbox only supports certain OCI images. These should be documented. Also, document the change of fedora-toolbox image name. - Add a section about toolbox container setup Toolbox containers are specifically configured OCI containers. This should be documented so that users know what they're using. - Remove redundant part documentation The description of what `toolbox init-container` does is already in toolbox-init-container(1). There's no need to have it in toolbox-create(1). Instead, replace the text with a hint to visit the other part of documentation. - Clarify behaviour of --image option The fact that Toolbox by default tries to pull from the Fedora registry[1] should be noted. - Update synopsis & description of commands Mention options passed to `podman exec`. Remove redundant paragraph about container names (is already dealt with in toolbox-create(1)). There's no need to mention the name of the default container on Fedora since Toolbox now also supports RHEL. Mention the default used image on unrecognised systems. Emphasize the fact that toolboxes are not a fully sandboxed environment. Update the wording of the description and splits it into a few subsections. The description of the --monitor-host was inaccurate and while the option will go away in the future[2], it is currently in and should be more documented. [0] containers#160 [1] https://registry.fedoraproject.org [2] containers#617 containers#512

- Update "See also" sections Toolbox does not use Buildah for a considerable time now[0]. We can stop referencing it in the "See also" sections of the documentation. In some places mention podman command man pages where they are relevant. - Add section about toolbox images/containers Toolbox only supports certain OCI images. These should be documented. Also, document the change of fedora-toolbox image name. - Add a section about toolbox container setup Toolbox containers are specifically configured OCI containers. This should be documented so that users know what they're using. - Remove redundant part documentation The description of what `toolbox init-container` does is already in toolbox-init-container(1). There's no need to have it in toolbox-create(1). Instead, replace the text with a hint to visit the other part of documentation. - Clarify behaviour of --image option The fact that Toolbox by default tries to pull from the Fedora registry[1] should be noted. - Update synopsis & description of commands Mention options passed to `podman exec`. Remove redundant paragraph about container names (is already dealt with in toolbox-create(1)). There's no need to mention the name of the default container on Fedora since Toolbox now also supports RHEL. Mention the default used image on unrecognised systems. Emphasize the fact that toolboxes are not a fully sandboxed environment. Update the wording of the description and splits it into a few subsections. The description of the --monitor-host was inaccurate and while the option will go away in the future[2], it is currently in and should be more documented. [0] #160 [1] https://registry.fedoraproject.org [2] #617 #512

There's no need to specify a CMD in a Toolbox image because it's specified by 'toolbox create', through 'podman create', when creating a container. A CMD was specified [1] because the Fedora Container Guidelines requires it [2]. The idea behind the guidelines is that the right thing should happen when one runs: $ podman run <image> However, that only makes sense for images targeting single service containers. Toolbox containers and images are different - they are not meant to be used like that to run a single one-off service. Conceptually, 'running' a Toolbox container is expected to provide the user with a reasonable interactive command line experience. Arguably, that means offering something like /bin/bash, not /bin/sh. Also, note that when the CMD was introduced [1], Toolbox containers were actually created, through 'podman create', with /bin/sh as their entry points. So, it did make some sense. However, things have changed since then [3]. The entry point is now 'toolbox init-container'. It's not possible to mention it in the Toolbox image because the /usr/bin/toolbox binary isn't present in the image, and it's not meant to be present. Therefore, today, /bin/sh is simply not the right fit for a Toolbox image's CMD. A better option would be /bin/bash. Note that the fedora base images have their CMD set to /bin/bash, which is inherited by the fedora-toolbox images. So, there are two options. Either repeat the same CMD in the fedora-toolbox images and satisfy the guidelines, or take some liberties and let the CMD be inherited from the fedora base images. This commit takes the latter option. People tend to use the fedora-toolbox images as the starting point for other custom Toolbox images, sometimes for other operating system distributions. It's better to keep them minimal to avoid implying extra requirements. In this case, the CMD is an abstract concept, and the actual entry point is 'toolbox init-container' as specified by 'toolbox create'. Specifying /bin/bash might discourage people from creating custom images that are only meant to have /bin/zsh. Also, note that the current CMD was actually '/bin/sh -c /bin/sh', not /bin/sh. Unless a CMD is specified as an array of command line arguments, it's passed as a single argument to '/bin/sh -c' [4]. So, this: CMD foo bar ... is the same as: CMD [ "/bin/sh", "-c", "foo bar" ] Only the images for currently maintained Fedoras (ie., 34 and 35) were updated. This reverts commit 5cc2678. [1] Commit 5cc2678 [2] https://docs.fedoraproject.org/en-US/containers/guidelines/creation/ [3] Commit 8b84b5e containers#160 [4] https://docs.docker.com/engine/reference/builder/#cmd containers#885

The concept of a 'base' image for creating Toolbx containers hasn't existed since Toolbx 0.0.10, when the Buildah dependency and the user-specific customized image were dropped [1]. That was a long time ago. Toolbx containers created before that were never supported by the Go implementation [2]. Therefore, it's time to update the terminology. Only the images for currently maintained Fedoras (ie., 38 and 39) were updated. [1] Commit 8b84b5e containers@8b84b5e4604921fa containers#160 [2] Commit 238f245 containers@238f2451e7d7d54a containers#318 containers#1456

The concept of a 'base' image for creating Toolbx containers hasn't existed since Toolbx 0.0.10, when the Buildah dependency and the user-specific customized image were dropped [1]. That was a long time ago. Toolbx containers created before that were never supported by the Go implementation [2]. Therefore, it's time to update the terminology. [1] Commit 8b84b5e containers@8b84b5e4604921fa containers#160 [2] Commit 238f245 containers@238f2451e7d7d54a containers#318 containers#1456

A subsequent commit will switch to unmarshalling the JSON returned from 'podman inspect --format json --type image' directly inside podman.InspectImage() to confine the details within the podman package and make it easier to write unit tests for it. eg., it requires tracking changes to the JSON output across different Podman versions. Unfortunately, the JSON from 'podman inspect --format json --type image' and 'podman images --format json' are considerably different and it will be awkward to use the same implementation of the json.Unmarshaler interface [1] for both. One option is to have two different concrete types separately implement json.Unmarshaler to handle the differences in the JSON, and then hiding these concrete types behind an Image interface that provides access to the values parsed from the JSON. The JSON samples for the unit tests were taken using the default Toolbx image on versions of Fedora that shipped a specific Podman and Toolbx version. This accounts for differences in the JSON caused by different major versions of Podman and the way different Toolbx images were built. One exception was Fedora 28, which had Podman 1.1.2 and Toolbx 0.0.9, which was the last Toolbx version before 'toolbox init-container' became the entry point for all Toolbx containers [2]. However, the default Toolbx image is no longer available from registry.fedoraproject.org. Hence, the image for Fedora 29 was used. The minimum required Podman version is 1.6.4 [3], and the Go implementation has been encouraging users to create containers with Toolbx version 0.0.97 or newer [4]. The versions used to collect the JSON samples for the unit tests were chosen accordingly. They don't exhaustively cover all possible supported and unsupported version combinations, but hopefully enough to be useful. The fedora-toolbox image went through a series of significant changes during the Fedora 39 and 40 development cycles. Fedora 38 was the last release where the image was built from a Container/Dockerfile [5]. For Fedora 39, it was rewritten in terms of fedora-kickstarts and pungi-fedora for the ToolbxReleaseBlocker Change [6]. For Fedora 40, it was rewritten as a KIWI description as part of the KiwiBuiltCloudImages Change [7]. Hence, all three Fedora versions were chosen to cover this transition. [1] https://pkg.go.dev/encoding/json#Unmarshaler [2] Commit 8b84b5e containers@8b84b5e4604921fa containers#160 [3] Commit 8e80dd5 containers@8e80dd5db1e6f40b containers#1253 [4] Commit af1216b containers@af1216b2720c7ab5 containers#1697 containers#1684 [5] https://src.fedoraproject.org/container/fedora-toolbox [6] https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker [7] https://fedoraproject.org/wiki/Changes/KiwiBuiltCloudImages containers#1724 containers#1779

Unmarshal the JSON from 'podman inspect --format json --type image' directly inside podman.InspectImage() to confine the details within the podman package. The JSON samples for the unit tests were taken using the default Toolbx image on versions of Fedora that shipped a specific Podman and Toolbx version. This accounts for differences in the JSON caused by different major versions of Podman and the way different Toolbx images were built. One exception was Fedora 28, which had Podman 1.1.2 and Toolbx 0.0.9, which was the last Toolbx version before 'toolbox init-container' became the entry point for all Toolbx containers [1]. However, the default Toolbx image is no longer available from registry.fedoraproject.org. Hence, the image for Fedora 29 was used. The minimum required Podman version is 1.6.4 [2], and the Go implementation has been encouraging users to create containers with Toolbx version 0.0.97 or newer [3]. The versions used to collect the JSON samples for the unit tests were chosen accordingly. They don't exhaustively cover all possible supported and unsupported version combinations, but hopefully enough to be useful. [1] Commit 8b84b5e containers@8b84b5e4604921fa containers#160 [2] Commit 8e80dd5 containers@8e80dd5db1e6f40b containers#1253 [3] Commit af1216b containers@af1216b2720c7ab5 containers#1697 containers#1684 containers#1724 Signed-off-by: Dalibor Kricka <dalidalk@seznam.cz>

debarshiray force-pushed the wip/rishi/init-container branch from 57a0cd6 to 5a1603c Compare May 14, 2019 15:29

debarshiray referenced this pull request May 14, 2019

Drop the Buildah dependency and the user-specific customized image

5a1603c

https://github.com/debarshiray/toolbox/pull/160

debarshiray force-pushed the wip/rishi/init-container branch from 5a1603c to 72558d8 Compare May 14, 2019 16:34

debarshiray referenced this pull request May 14, 2019

Drop the Buildah dependency and the user-specific customized image

72558d8

https://github.com/debarshiray/toolbox/pull/160

debarshiray force-pushed the wip/rishi/init-container branch from 72558d8 to 57554e1 Compare May 15, 2019 13:22

debarshiray referenced this pull request May 15, 2019

Drop the Buildah dependency and the user-specific customized image

57554e1

https://github.com/debarshiray/toolbox/pull/160

debarshiray force-pushed the wip/rishi/init-container branch from 57554e1 to 619902f Compare May 15, 2019 17:25

debarshiray referenced this pull request May 15, 2019

Tweak the debug output

5a618d0

This will make a subsequent commit easier to read. https://github.com/debarshiray/toolbox/pull/160

debarshiray referenced this pull request May 15, 2019

Drop the Buildah dependency and the user-specific customized image

619902f

https://github.com/debarshiray/toolbox/pull/160

debarshiray mentioned this pull request May 16, 2019

Created containers do not have network connection #152

Closed

debarshiray added 4 commits May 16, 2019 14:50

Tweak the debug output

48ddffb

This will make a subsequent commit easier to read. https://github.com/debarshiray/toolbox/pull/160

Shuffle some code around

85f5b3e

Consolidate the code to forward commands to the host in one place instead of doing it repeatedly for each command. This reduces the levels of indentation in the code, making it easier to read. https://github.com/debarshiray/toolbox/pull/160

debarshiray added 2 commits May 16, 2019 14:50

Shuffle some code around

dadb21d

A subsequent commit will create toolbox container names based on both the base image and the user-specific customized image. This will make it easier to read. https://github.com/debarshiray/toolbox/pull/160

debarshiray force-pushed the wip/rishi/init-container branch from 619902f to 9498a18 Compare May 16, 2019 13:19

debarshiray force-pushed the wip/rishi/init-container branch from 9498a18 to 8b84b5e Compare May 16, 2019 13:48

debarshiray merged commit 8b84b5e into master May 16, 2019

debarshiray deleted the wip/rishi/init-container branch May 16, 2019 13:50

debarshiray mentioned this pull request Sep 20, 2019

merge with coretoolbox, or not #265

Closed

This was referenced Jun 26, 2020

RFE: supporting adding new bind mounts on existing containers containers/podman#1320

Closed

[RFE] Introduce a command to recreate a toolbox #143

Closed

debarshiray mentioned this pull request Jan 22, 2021

doc/toolbox-create, doc/toolbox-init-container: Mention the entry point #677

Merged

debarshiray mentioned this pull request Nov 30, 2021

images, README.md: Remove misleading and redundant CMD and update the requirements around ENTRYPOINT #940

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Drop the Buildah dependency and the need for the user-specific customized image#160

Drop the Buildah dependency and the need for the user-specific customized image#160
debarshiray merged 8 commits intomasterfrom
wip/rishi/init-container

debarshiray commented May 14, 2019 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

debarshiray commented May 14, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

debarshiray commented May 14, 2019 •

edited

Loading