Passing arguments to the docker run command about container-structure-test

[donmccasland]

Okay. There's community interested in this one and an old PR.

I'm going to file this 'help wanted' and put it in the Icebox, but if any of you want to pick up where the previous author left off, let me know and I'll put it 'In Progress'

[mogthesprog]

I'm actually happy to have a go at this, but wanted to check if you'd thought about how you might do this?

Use case for us is we have an auditd container that contains some audisp plugins we'd like to test, which needs some extra privileges in order to run successfully.

I'm wondering whether we could add a dockerRunOpts top-level field to test yaml? that might allow you to set global docker run options. Something the below. We wouldn't need to support all the options really, since some of them are constructued by the driver at runtime.

type dockerRunOpts struct {
  Mounts []docker.Mount
  // by default drop all capabilites
  Capabilites []string
  Privileged bool
}

and the yaml might look like:

dockerRunOpts:
  mounts:
    -  source: /tmp/beans
        destination /tmp/cheese
        readWrite: false
  privileged: false
  capabilities:
    - SYS_ADMIN

We'd then need to pass the capabilities to the docker.HostConfig and the mounts to the docker.Config.

[nkubala]

Hey @mogthesprog, thanks for filing. I think I'm ok with with the general design here, seems like there's enough desire for run options here to warrant taking a stab at it. The one change I think we'll have to make to the UX is probably embedding the driver flag into the yaml, so that it's a little more explicit when you specify a dockerRunOpts field that it'll be used with the docker driver, or that it will be ignored if you specify a different driver.

As far as fields in the dockerRunOpts, I'd say the 3 you have in there right now are fine, we might want to consider adding support for networking options as well.

[mogthesprog]

so maybe something like this? also means if we end up supporting a different container driver then it's a little more generic.

containerRunOpts:
  driver: docker
  mounts:
    - source: /tmp/beans
      destination: /tmp/cheese
      readWrite: false
  privileged: false
  capabilities:
    - SYS_ADMIN

[nkubala]

I think the driver should be outside the containerRunOpts field. if the user wants to specify the tar driver for example, there won't be any run options. other than that, seems fine

[mogthesprog]

ah great. That's the bit i was missing. I've had a quick stab this evening, i'll hopefully have something put together over the next few days, will keep you posted.

[alysivji]

+1 for this feature.

I'm currently using docker-py to make sure we have the correct libraries installed after mounting a volume containing scripts. This seems like a more robust solution.

[helmut-hoffer-von-ankershoffen]

+1 for this feature

[fentonfentonfenton]

+1

[zerstoeren]

If your Entrypoint is /bin/bash, you can pass arguments as docker run -it container something.sh argument argument argument

[setola]

+1

If possible this feature should change docker run user parameter too.

I mean the equivalent of running:
docker run --user 405:100 alpine whoami

This should be very useful when testing commands required to be run as unprivileged user.