cf19090b83
3 Commits
Author | SHA1 | Message | Date | |
---|---|---|---|---|
Yann E. MORIN
|
08d65d81d8 |
fs/oci: entrypoint and command are space-separated lists
The prompt and variable name for the OCI "entrypoint arguments" are somewhat incorrect. Indeed, they are in fact used to set the image "command". Yet, using "command" would be confusing too, because the interplay between entrypoint and command is tricky [0]. TL-DR; when both entrrypoint and command are set, command acts as arguments passed to the entrypoint. Additionally, we currently can only pass a single item as either entrypoint or command. This precludes passing actual arguments to the entrypoint, or passing multiple arguments as command. For example: BR2_TARGET_ROOTFS_OCI_ENTRYPOINT="/bin/tini -g -p SIGTERM --" BR2_TARGET_ROOTFS_OCI_ENTRYPOINT_ARGS="/usr/bin/env sh" generates an images with (only relevant fields are included below): { "config": { "Entrypoint": [ "/bin/tini -g -p SIGTERM --" ], "Cmd": [ "/usr/bin/env sh" ] } } This is obviously incorrect, and not what one would expect: { "config": { "Entrypoint": [ "/bin/tini", "-g", "-p", "SIGTERM", "--" ], "Cmd": [ "/usr/bin/env", "sh" ] } } However, some people do want to be able to pass an actual shell scriptlet as a command, such as: { "config": { "Entrypoint": [ "/bin/sh", "-c" ], "Cmd": [ "my shell logic goes here" ] } } Handling both is obviously conflicting: we can't both split-on-spaces and not-split-on-spaces at the same time... So, we fix that in two ways: - make the current _OCI_ENTRYPOINT_ARGS a legacy option, and introduce the new _OCI_CMD option with different semantics (see below) and an appropriate prompt; - we interpret both _OCI_ENTRYPOINT and _OCI_CMD as shell strings, which we subject to the usual shell quoting [1] and token recognition [2]; Since _OCI_ENTRYPOINT_ARGS used to be interpreted as a single string, we can't easily change its meaning to be a space-separated list, as that would break existing setups, which is the reason we make it legacy and introduce a new option. Ideally, we would like to default the new option _OCI_CMD to be the quoted value of the previous _OCI_ENTRYPOINT_ARGS, but this is not possible in Kconfig. Still, users that had a _OCI_ENTRYPOINT_ARGS set will now get an early build error, and can still detect they need to do something about it. As for _OCI_ENTRYPOINT, it does not make much sense to support both cases. Indeed, without splitting on spaces, we'd end up with an entrypoint that would have a single item: { "config": { "entrypoint: [ "some string with some spaces" ] } } which in this case would try to execute the program which name is actually "some string with some spaces", so we do not expect that existing entrypoints are set with any space in them, and so the new behaviour, unlike for _OCI_ENTRYPOINT_ARGS vs. _OCI_CMD, is compatible with existing configurations, and so we do not need to make it a legacy option and introduce a new one. [0] https://docs.docker.com/engine/reference/builder/#understand-how-cmd-and-entrypoint-interact [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02 [2] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_03 Signed-off-by: Yann E. MORIN <yann.morin@orange.com> Cc: Sergio Prado <sergio.prado@e-labworks.com> Cc: Matthew Weber <matthew.weber@collins.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> |
||
Fabrice Fontaine
|
efe832dbc3 |
fs/oci: depends on BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS
Add a dependency on BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS to avoid
the following build failure when GO_GOARCH is empty (e.g. on mips32)
which leads to an empty --arch argument in the sloci-image call, raised
since the addition of the package in commmit
|
||
Sergio Prado
|
ccda2f4bdc |
fs: new OCI filesystem type
Add support to generate OCI (Open Container Initiative) images. An OCI image consists of a manifest, an image index (optional), a set of filesystem layers, and a configuration. The complete specification is available in the link below: https://github.com/opencontainers/image-spec/blob/master/spec.md The image is generated with the host tool sloci-image, and config options can be used to configure image parameters. By default, the image is generated in a directory called rootfs-oci: $ cd output/images $ ls rootfs-oci/ blobs index.json oci-layout Optionally, the image can be packed into a tar archive. The image can be pushed to a registry using containers tools like skopeo: $ skopeo copy --dest-creds <user>:<pass> oci:rootfs-oci:<tag> \ docker://<user>/<image>[:tag] And then we can pull/run the container image with tools like docker: $ docker run -it <user>/<image>[:tag] Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com> Signed-off-by: Matthew Weber <matthew.weber@collins.com> [Arnout: - mention in help text that options are space separated; - use GO_GOARCH and GO_GOARM for architecture; - quote all arguments; - don't cd to BINARIES_DIR; - remove ROOTFS_OCI_IMAGE_NAME variable; - remove wildcard from rm. ] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> |