supporting custom bundle file name

[ianpark]

Related post: opencontainers/runc#1029

I've been using Docker for my project which uses short-lived containers. The basic concept of the project is running an unsafe (good but not guaranteed to be 100% secure) application handling confidential information of users. So, lots of docker containers are created and then removed simultaneously.

While I was trying to replace Docker with Runc, I realised that Runc does not support "-v" option, which was useful to mount random unique input paths dynamically for each container. So the realistic alternative is creating config.json with the required mount points for every single task.
And now I am encountering another issue. In order to create many containers with different mount locations, I will have to create a new directory for each config.json file, only because Runc CLI does not allow to change the config file name.

It may be useful to have an option to specify the file name (which defaults 'config.json' of course), or to upgrade the -b option to grab the json file name if it's provided.

[wking]

On Mon, Sep 12, 2016 at 06:04:42AM -0700, Ian Park wrote:

In order to create many containers with different mount locations, I
will have to create a new directory for each config.json file, only
because Runc CLI does not allow to change the config file name.

It may be useful to have an option to specify the file name (which
defaults 'config.json' of course), or to upgrade the -b option to
grab the json file name if it's provided.

My preferred solution to this would be to relax the “configuration
must be config.json on the filesystem” requirement (#423 and
subsequent PRs pulling in pieces of that idea). The only functional
changes we'd have to make would be interpreting relative paths
relative to the runtime's current working directory (instead of
relative to the bundle path, see #558).

Making the filename/path adjustable is a step in the flexibility
direction, but I don't see a reason to make presence on a filesystem a
hard requirement at all (see also opencontainers/runc#202).

[ianpark]

@wking Thanks!
current runC does not run in that way anyway. You can run runC with config.json of which root.path points to any absolute path. Please see below.

/home/vagrant/runc/job1/config.json

   "root": {
      "path": "/usr/local/runc/rootfs",
      "readonly": true
   },

And following command works normally.

vagrant@safeview1404 ~ $ pwd
/home/vagrant
vagrant@safeview1404 ~ $ sudo runc create -b ~/runc/job1 test

[wking]

On Tue, Sep 13, 2016 at 07:54:58AM -0700, Ian Park wrote:

You can run runC with config.json of which root.path points to any
absolute path. Please see below.

/home/vagrant/runc/job1/config.json

   "root": {
      "path": "/usr/local/runc/rootfs",
      "readonly": true
   },

I agree that this should be legal, but I think the current spec
wording makes this an invalid bundle. I have proposed a fix to allow
root.path like that in #469.

[vbatts]

with #558 merged is this issue resolved?

On Tue, Sep 13, 2016 at 11:15 AM W. Trevor King [email protected]
wrote:

On Tue, Sep 13, 2016 at 07:54:58AM -0700, Ian Park wrote:

You can run runC with config.json of which root.path points to any
absolute path. Please see below.

/home/vagrant/runc/job1/config.json

"root": {
"path": "/usr/local/runc/rootfs",
"readonly": true
},

I agree that this should be legal, but I think the current spec
wording makes this an invalid bundle. I have proposed a fix to allow
root.path like that in #469.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#560 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEF6buDrszHvM4QvdEDjS0PFuS7Hmotks5qpr37gaJpZM4J6j4S
.

[ianpark]

@vbatts it seems like #558 resolved #469 but #560 (this one)
I found no understandable reason to fix the bundle file name to config.json. It's just preventing aggregating multiple bundle files in a same directory. Especially with the fix #558, bundle file and the root.path are no more in a relative paths from each other anyway.

I want to use runC for my project using short-lived containers, where each container instance needs different configuration and mount points. For that I have to create a unique directory for each config.json just because of the file name collision. Considering that Docker supports this use case in a simply way, runC should also do so.

[wking]

On Wed, Sep 14, 2016 at 02:23:43AM -0700, Ian Park wrote:

@vbatts it seems like #558 resolved #469 but #560 (this one)

#469 is about the same-directory bundle.md requirement. I don't think
it was resolved by #558, which only touched config.md.

[crosbymichael]

@ianpark Why is making a directory such an issue? Its cheap and also acts as a synchronization point for multiple processes trying to reserve an ID as mkdir is atomic.

Overall, runc is not going to have the polish of docker as its not designed to, much of the orchestration is left up to the caller of runc. Leaving the docker features out of runc is what makes it generally useful for everyone.

[c4milo]

@ianpark from what i've been reading so far, assuming I've understood well, it seems you would like to generate spec files dynamically. https://github.com/opencontainers/runtime-tools could be used for that purpose.

[wking]

On Wed, Aug 02, 2017 at 11:58:30AM -0700, Camilo Aguilar wrote: @ianpark from what i've been reading so far, assuming I've understood well, it seems you would like to generate spec files dynamically.

I think @ianpark's point was less about “how/when do I generate the configuration JSON?” and more about “why do I have to create per-container bundle directories to hold my configuration JSON?”. The spec currently requires a bundle directory holding ‘config.json’, but I don't see a solid reason for that requirement (e.g. see #423, where I attempted to remove the requirement).