Description

I'd like to be able to convince container-canary to run containers with --network host.

@trxcllnt and I have been using container-canary in a docker-in-docker context in CI, and he observed some networking instability in that environment that might be be resolved by avoiding double-nested network isolation.

Benefits of this work

Allows finer-grained control over how container-canary is run.

If this does seem to help for the docker-in-docker case specifically, would improve container-canary's usability in a common pattern used in CI.

Acceptance Criteria

• it is possible to make container-canary pass --network host to docker run

Approach

Options Considered

I see 3 options for exposing this configuration, @jacobtomlinson I'll happily defer to your opinion on which to pursue (assuming you're open to this idea generally).

Option 1: hostNetwork

The k8s V1 podSpec has an option hostNetwork, for exactly this purpose. (k8s docs).

hostNetwork (boolean)

Host networking requested for this pod. Use the host's network namespace. If this option is set, the ports that will be used must be specified. Default to false.

So that'd look like the container-canary config picking up a new boolean option:

hostNetwork: true

Option 2: named network argument

container-canary could instead support passing any network name via a top-level config argument.

network: host

This would allow greater customization, of the form described in "User-defined networks" (Docker docs).

Option 3: arbitrary array of extra arguments

container-canary could support passing arbitrary flags to the container runtime via an array.

runOptions:
  --network: host
  --gpus: all

Where the implication is that for each key: value pair there, {key} {value} is passed to docker run. Similar to this:

GitHub Actions has a similar interface, where there are some container characteristics that are set via top-level configuration, and then any other arbitrary flags can be passed via jobs.<job_id>.container.options (GitHub Actions docs)

Proposal

I (@jameslamb) personally prefer option 3. It offers high flexibility to experiment, so could add a lot of capability to container-canary all at once (beyond just --network host).

For example, it'd immediately also add support for running tests that require GPUs (you could just pass --gpus all).

And having the arguments be keys in the YAML map means that if, in the future, we wanted to have container-canary prohibit setting some option or require that it be set by some other top-level configuration value, it'd be straightforward to issue deprecation warnings and eventually errors like "Passing --gpus via runOptions is now allowed. Please use top-level key gpus: instead".