mirror of https://github.com/containers/podman.git
docs/podman-systemd: Try to clarify `Exec=` more
In podman-systemd we are intersecting the worlds of containers and systemd, and I had to stop and think to understand what `Exec=` does. I tried to clarify things more here. I found it especially confusing because the example at the very top of the file does: ``` Image=quay.io/fedora/fedora Exec=sleep 10 ``` But that only makes sense because the fedora base image (being generic) doesn't define an `ENTRYPOINT`, just a `CMD`. But IMO by far the most common usage for podman-systemd is "app images" which conventionally should use `ENTRYPOINT` in general. Maybe we should change the default example, but I'm leaving that for a later followup. (It perhaps would have been less confusing if this field had been called `Args=` to make clear it's quite different in practice from systemd `ExecStart=`) Signed-off-by: Colin Walters <walters@verbum.org>
This commit is contained in:
parent
40df14012b
commit
d26341332c
|
|
@ -435,9 +435,19 @@ Use the host environment inside of the container.
|
|||
|
||||
### `Exec=`
|
||||
|
||||
If this is set then it defines what command line to run in the container. If it is not set the
|
||||
default entry point of the container image is used. The format is the same as for
|
||||
[systemd command lines](https://www.freedesktop.org/software/systemd/man/systemd.service.html#Command%20lines).
|
||||
Additional arguments for the container; this has exactly the same effect as passing
|
||||
more arguments after a `podman run <image> <arguments>` invocation.
|
||||
|
||||
The format is the same as for [systemd command lines](https://www.freedesktop.org/software/systemd/man/systemd.service.html#Command%20lines),
|
||||
However, unlike the usage scenario for similarly-named systemd `ExecStart=` verb
|
||||
which operates on the ambient root filesystem, it is very common for container
|
||||
images to have their own `ENTRYPOINT` or `CMD` metadata which this
|
||||
which this interacts with.
|
||||
|
||||
The default expectation for many images is that the image will include an `ENTRYPOINT`
|
||||
with a default binary, and this field will add arguments to that entrypoint.
|
||||
|
||||
Another way to describe this is that it works the same way as the [args field in a Kubernetes pod](https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell).
|
||||
|
||||
### `ExposeHostPort=`
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue