cri-o/hooks.md
W. Trevor King c80cdedbee hooks: Use RFC 2119 for the hook configuration specification
Make this more like the runtime spec, using the RFC 2119 keywords for
both JSON-author and CRI-O requirements.  This also clarifies the
regular expression language (POSIX EREs), links to a JSON spec, and
tightens wording for the various matching criteria.

I think the hook-config format could be improved (versioning it, and
reusing the runtime-spec hook structure instead of renaming 'path' to
'hook', dropping 'timeout', etc.).  But I'm leaving that sort of thing
to future work.

Signed-off-by: W. Trevor King <wking@tremily.us>
2018-02-20 15:02:54 -08:00

4.6 KiB

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 Kpod create create the OCI configuration for you, and this documentation allows developers to configure CRI-O 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).

Notational Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119.

JSON Definition

CRI-O reads all JSON files in /usr/share/containers/oci/hooks.d/*.json and /etc/containers/oci/hooks.d/*.json to load hook configuration. If the same file is in both directories, the one in /etc/containers/oci/hooks.d takes precedence.

Each JSON file should contain an object with the following properties:

  • hook (REQUIRED, string) Sets path in the injected hook.
  • arguments (OPTIONAL, array of strings) Additional arguments to pass to the hook. The injected hook's args is hook with arguments appended.
  • stages (REQUIRED, array of strings) Stages when the hook MUST be injected. Entries MUST be chosen from:
  • cmds (OPTIONAL, array of strings) The hook MUST be injected if the configured process.args[0] matches an entry. Entries MUST be POSIX extended regular expressions.
  • annotations (OPTIONAL, array of strings) The hook MUST be injected if the configured annotations matches an entry. Entries MUST be POSIX extended regular expressions.
  • hasbindmounts (OPTIONAL, boolean) The hook MUST be injected if hasbindmounts is true and the container is configured to bind-mount host directories into the container.

The matching properties (cmds, annotations and hasbindmounts) are orthogonal, and the hook is injected if any of those properties match.

Example

cat /etc/containers/oci/hooks.d/oci-systemd-hook.json
{
    "cmds": [".*/init$" , ".*/systemd$" ],
    "hook": "/usr/libexec/oci/hooks.d/oci-systemd-hook",
    "stages": [ "prestart", "poststop" ]
}

In the above example CRI-O will only run the oci-systemd-hook in the prestart and poststop stage, if the command ends with /init or /systemd

cat /etc/containers/oci/hooks.d/oci-systemd-hook.json
{
    "hasbindmounts": true,
    "hook": "/usr/libexec/oci/hooks.d/oci-umount",
    "stages": [ "prestart" ]
    "arguments": [ "--debug" ]
}

In this example the oci-umount will only be run during the prestart phase if the container has volume/bind mounts from the host into the container, it will also execute oci-umount with the --debug argument.