99e642d940
For example:
$ cat /etc/containers/oci/hooks.d/test.json
{
"version": "1.0.0",
"hook": {
"path": "/bin/sh",
"args": ["sh", "-c", "echo 'oh, noes!' >&2; exit 1"]
},
"when": {
"always": true
},
"stages": ["precreate"]
}
$ podman run --rm docker.io/library/alpine echo 'successful container'
error setting up OCI Hooks: executing [sh -c echo 'oh, noes!' >&2; exit 1]: exit status 1
The rendered command isn't in in the right syntax for copy/pasting
into a shell, but it should be enough for the user to be able to
locate the failing hook. They'll need to know their hook directories,
but with the previous commits requiring explicit hook directories it's
more likely that the caller is aware of them. And if they run at a
debug level, they can see the lookups in the logs:
$ podman --log-level=debug --hooks-dir=/etc/containers/oci/hooks.d run --rm docker.io/library/alpine echo 'successful container' 2>&1 | grep -i hook
time="2018-12-02T22:15:16-08:00" level=debug msg="reading hooks from /etc/containers/oci/hooks.d"
time="2018-12-02T22:15:16-08:00" level=debug msg="added hook /etc/containers/oci/hooks.d/test.json"
time="2018-12-02T22:15:16-08:00" level=debug msg="hook test.json matched; adding to stages [precreate]"
time="2018-12-02T22:15:16-08:00" level=warning msg="container 3695c6ba0cc961918bd3e4a769c52bd08b82afea5cd79e9749e9c7a63b5e7100: precreate hook: executing [sh -c echo 'oh, noes!' >&2; exit 1]: exit status 1"
time="2018-12-02T22:15:16-08:00" level=error msg="error setting up OCI Hooks: executing [sh -c echo 'oh, noes!' >&2; exit 1]: exit status 1"
Signed-off-by: W. Trevor King <wking@tremily.us>
|
||
|---|---|---|
| .. | ||
| 0.1.0 | ||
| 1.0.0 | ||
| docs | ||
| exec | ||
| hooks.go | ||
| hooks_test.go | ||
| monitor.go | ||
| monitor_test.go | ||
| read.go | ||
| read_test.go | ||
| README.md | ||
| version.go | ||
OCI Hooks Configuration
For POSIX platforms, the OCI runtime configuration supports hooks for configuring custom actions related to the life cycle of the container.
The way you enable the hooks above is by editing the OCI runtime configuration before running the OCI runtime (e.g. runc).
CRI-O and podman create create the OCI configuration for you, and this documentation allows developers to configure them to set their intended hooks.
One problem with hooks is that the runtime actually stalls execution of the container before running the hooks and stalls completion of the container, until all hooks complete.
This can cause some performance issues.
Also a lot of hooks just check if certain configuration is set and then exit early, without doing anything.
For example the oci-systemd-hook only executes if the command is init or systemd, otherwise it just exits.
This means if we automatically enabled all hooks, every container would have to execute oci-systemd-hook, even if they don't run systemd inside of the container.
Performance would also suffer if we exectuted each hook at each stage (pre-start, post-start, and post-stop).
The hooks configuration is documented in oci-hooks.5.