Rkt: Sharing files among application containers

Created on 15 Jun 2015  Â·  8Comments  Â·  Source: rkt/rkt

I'm building a pod that runs nginx/php-fpm. I would like for nginx/php-fpm to be separate aci's, but nginx/php-fpm both need access to the same php files (index.php, etc).

The empty mount type (see #1040) provides a solution (although inelegant) for this problem. By sharing an empty mount, the php-fpm image can copy the php code files into the shared mount during a pre-start event handler. This gives both app containers access the the same files.

It seems like there should be an easier way to accomplish this. I've looked into how aci dependencies might solve this problem, but I don't think that would be the right approach.

Am I missing something obvious? How have other people solved this problem?


Manifest snippets of what I'm doing:

php-fpm ImageManifest:
...
"eventHandlers": [ { "exec": [ "/bin/bash", "-c", "shopt -s dotglob; mv /sharedDirs/code/* /code;" ],
                     "name": "pre-start" } ],
"mountPoints":   [ { "name": "code", "path": "/code", "readOnly": true } ]
...
nginx ImageManifest:
...
"eventHandlers": [ { "exec": [ "/bin/bash", "-c", "sleep 1" ], 
                     "name": "pre-start" } ],
"mountPoints":   [ { "name": "code", "path": "/code", "readOnly": true } ]
...
PodManifest:
...
"volumes": [ { "name": "code", "kind": "empty", "readOnly": false } ]
...
areusability kinquestion prioritPmaybe

All 8 comments

To be clear, do you need the shared files to be mutable?

@jonboulle Unfortunatly, yes. PHP code has habit of self modification.

OK, good to know. I'm curious why you think a shared volume is inelegant - just because you need to write files into it at pod launch time?

@jonboulle
It's inelegant because I'm reduced to to using something like the following. This incurs a disk usage and pod start-up time penalty (both of which are highly undesirable for us):

image 1 (needs startup data copied in) pre-start:
while [[ ! -e ${DATADIR}/COPY_COMPLETE ]] do sleep 1; done

image 2 (container has data in it) pre-start:
copy_data; touch ${DATADIR}/INSTALL_COMPLETE

see: https://github.com/GoogleCloudPlatform/kubernetes/issues/1589#issuecomment-58043463

A well-thought out 'container' volume type might get around this, i.e. something along these lines: https://github.com/GoogleCloudPlatform/kubernetes/issues/831

I could imagine:

  1. Using a volume kind of container that has parameters:

    • srcContainer reference to another container in this pod

    • srcPath path relative to the source containers root to share

  2. stage1 would bind mount srcContainer:/srcPath into the appropriate containers before starting any

I'll think on this a little more. If it doesn't sound too crazy, I'll clean up the idea and likely submit a PR to appc/spec

At first blush that sounds like it could be workable.

On Mon, Jun 15, 2015 at 9:08 PM, kibra [email protected] wrote:

A well-thought out 'container' volume type might get around this, i.e.
something along these lines: GoogleCloudPlatform/kubernetes#831
https://github.com/GoogleCloudPlatform/kubernetes/issues/831

I could imagine:

  1. Using a volume kind of container that has parameters:

    • _srcContainer_ reference to another container in this pod

    • _srcPath_ path relative to the source containers root to share



      1. stage1 would bind mount srcContainer:/srcPath into the appropriate


        containers before starting any



I'll think on this a little more. If it doesn't sound too crazy, I'll
clean up the idea and likely submit a PR to appc/spec

—
Reply to this email directly or view it on GitHub
https://github.com/coreos/rkt/issues/1041#issuecomment-112278783.

@jonboulle any updates? Would love to see this feature implemented.

@storvik we don't have any plan to work on this but would welcome contributions

Was this page helpful?
0 / 5 - 0 ratings

Related issues

trusch picture trusch  Â·  7Comments

sgotti picture sgotti  Â·  5Comments

tomByrer picture tomByrer  Â·  3Comments

artem-sidorenko picture artem-sidorenko  Â·  6Comments

kallisti5 picture kallisti5  Â·  6Comments