2021-08-27 22:54:29 +02:00
|
|
|
config BR2_TARGET_ROOTFS_OCI
|
|
|
|
|
bool "oci image"
|
2022-04-02 22:01:18 +02:00
|
|
|
depends on BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS
|
2021-08-27 22:54:29 +02:00
|
|
|
help
|
|
|
|
|
Build an OCI (Open Container Initiative) image.
|
|
|
|
|
|
|
|
|
|
By default, the image is generated in a directory called
|
|
|
|
|
rootfs-oci:
|
|
|
|
|
|
|
|
|
|
$ cd output/images
|
|
|
|
|
$ ls rootfs-oci/
|
|
|
|
|
blobs index.json oci-layout
|
|
|
|
|
|
|
|
|
|
You can push the image to a registry. Example using skopeo:
|
|
|
|
|
|
|
|
|
|
$ skopeo copy --dest-creds <user>:<pass> \
|
|
|
|
|
oci:rootfs-oci:<tag> docker://<user>/<image>[:tag]
|
|
|
|
|
|
|
|
|
|
And pull/run it with docker:
|
|
|
|
|
|
|
|
|
|
$ docker run -it <user>/<image>[:tag]
|
|
|
|
|
|
|
|
|
|
if BR2_TARGET_ROOTFS_OCI
|
|
|
|
|
|
|
|
|
|
config BR2_TARGET_ROOTFS_OCI_AUTHOR
|
|
|
|
|
string "author name and/or email address"
|
|
|
|
|
default "Buildroot"
|
|
|
|
|
help
|
|
|
|
|
Name and/or email address of the person which created the
|
|
|
|
|
image.
|
|
|
|
|
|
|
|
|
|
config BR2_TARGET_ROOTFS_OCI_TAG
|
|
|
|
|
string "image tag"
|
|
|
|
|
default "latest"
|
|
|
|
|
help
|
|
|
|
|
Tag to be used in the container image. If empty, 'latest' will
|
|
|
|
|
be used by default.
|
|
|
|
|
|
|
|
|
|
config BR2_TARGET_ROOTFS_OCI_ENTRYPOINT
|
|
|
|
|
string "entrypoint"
|
|
|
|
|
default "sh"
|
|
|
|
|
help
|
|
|
|
|
Command to execute when the container starts.
|
|
|
|
|
|
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>
2022-05-13 15:17:45 +02:00
|
|
|
Spaces must be quoted or escaped, like for a shell string:
|
|
|
|
|
/usr/bin/env sh -c
|
|
|
|
|
/bin/my-init --some-option "1 2 3 4" some\ arg --
|
|
|
|
|
|
|
|
|
|
See the Docker documentation on how entrypoint and command
|
|
|
|
|
interact together:
|
|
|
|
|
https://docs.docker.com/engine/reference/builder/#understand-how-cmd-and-entrypoint-interact
|
|
|
|
|
|
|
|
|
|
config BR2_TARGET_ROOTFS_OCI_CMD
|
|
|
|
|
string "command (or entrypoint arguments)"
|
2021-08-27 22:54:29 +02:00
|
|
|
help
|
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>
2022-05-13 15:17:45 +02:00
|
|
|
Default command, or entrypoint arguments, of the container.
|
|
|
|
|
|
|
|
|
|
Spaces must be quoted or escaped, like for a shell string:
|
|
|
|
|
"your shell scriptlet"
|
|
|
|
|
/usr/bin/env sh
|
|
|
|
|
|
|
|
|
|
See the Docker documentation on how entrypoint and command
|
|
|
|
|
interact together:
|
|
|
|
|
https://docs.docker.com/engine/reference/builder/#understand-how-cmd-and-entrypoint-interact
|
2021-08-27 22:54:29 +02:00
|
|
|
|
|
|
|
|
config BR2_TARGET_ROOTFS_OCI_WORKDIR
|
|
|
|
|
string "working directory"
|
|
|
|
|
help
|
|
|
|
|
Working directory of the entrypoint process in the
|
|
|
|
|
container.
|
|
|
|
|
|
|
|
|
|
config BR2_TARGET_ROOTFS_OCI_UID
|
|
|
|
|
string "username or UID"
|
|
|
|
|
default "0"
|
|
|
|
|
help
|
|
|
|
|
The username or UID of user the process run as.
|
|
|
|
|
|
|
|
|
|
config BR2_TARGET_ROOTFS_OCI_ENV_VARS
|
|
|
|
|
string "environment variables"
|
|
|
|
|
help
|
|
|
|
|
Default environment variables for the container.
|
|
|
|
|
Space-separated list of variable=value assignments.
|
|
|
|
|
|
|
|
|
|
config BR2_TARGET_ROOTFS_OCI_PORTS
|
|
|
|
|
string "ports"
|
|
|
|
|
help
|
|
|
|
|
Default set of ports to expose from a container running
|
|
|
|
|
this image as a space-separted list of ports in the following
|
|
|
|
|
format:
|
|
|
|
|
|
|
|
|
|
<port>/tcp, <port>/udp, <port> (same as <port>/tcp).
|
|
|
|
|
|
|
|
|
|
config BR2_TARGET_ROOTFS_OCI_LABELS
|
|
|
|
|
string "labels"
|
|
|
|
|
help
|
|
|
|
|
Metadata in the format KEY=VALUE for the container compliant
|
|
|
|
|
with OCI annotation rules. If KEY starts with a dot, it will
|
|
|
|
|
be prefixed with "org.opencontainers.image"
|
|
|
|
|
(e.g. .url -> org.opencontainers.image.url).
|
|
|
|
|
|
|
|
|
|
config BR2_TARGET_ROOTFS_OCI_ARCHIVE
|
|
|
|
|
bool "pack oci image into a tar archive"
|
|
|
|
|
help
|
|
|
|
|
Select whether the image should be packed into a TAR archive.
|
|
|
|
|
|
|
|
|
|
endif
|
