Support --user option in "docker-compose up"

[mrzechonek]

I need to pass --user option to run orchestrated containers under my own UID. This is mostly because of mounted host volumes, and I'd like the dockerized app to generate files owned by me, not the root.

With docker-compose up, this is not possible, at least not directly. Right now I'm using a crazy workaround:

NAME=`compose run -d --user="$UID" someservicename`
docker rename $NAME ${NAME/_run/}

which is suboptiomal, to be gentle.

[dnephin]

I'm not sure I understand, docker-compose run --user is an option, and the docker-compose.yml supports the user key (http://docs.docker.com/compose/yml/#working95dir-entrypoint-user-hostname-domainname-mem95limit-privileged-restart-stdin95open-tty-cpu95shares).

I guess we'd need to support environment variable resolution in the user field so that you can set it to $UID is that right? #1377

[mrzechonek]

Hi. Yeah, $UID expansion would do the trick in this case. Still, --user option for docker-compose up command (not only for docker-compose run) would be useful to start the whole project as particular user.

The point is to allow specifying the user without touching yml.

[aanand]

start the whole project as particular user

It never occurred to me that people might want to do this. Could you elaborate on the use case?

[aanand]

Never mind, I scrolled up. Am I right in thinking you're on Linux? When using boot2docker it creates files with sensible permissions.

I wonder if there's a way to configure the Docker daemon to do this for every volume it mounts.

[mrzechonek]

Yes, on Linux.

I'm using compose to run tests on CI by mounting host volume (yeah, I know). Without this option, some files get created with "wrong" ownership, i. e. root:root

[mrzechonek]

I know I could use a data only container and inspect/copy files from it, but a host volume is much more convenient and requires less scripting.

[josephpage]

up --user could be dangerous if some containers/services already specify a user.

@mrzechonek I don't think that modifying a container because of its environment is a good practice.

[mrzechonek]

@josephpage yeah, it might be. $UID expansion would do the trick though.

Pretty much the only thing I need is proper permissions on host volumes. I don't know of any other way to achieve that, besides running container process as $UID...

I would actually prefer this feature to be present in the Damon itself, like @aanand said. Or maybe an option to mount a volume in such a mode (a storage driver maybe?).

[wildsurfer]

@mrzechonek, have you found a workaround?

[mrzechonek]

Not really, no. Right now we're doing docker-compose run --user and then rename/relabel the container to make compose think it was started by up command, so that stop and ps would work.

[dnephin]

#1377 is in master and will be in the 1.5.0 release, so you'll be able to do user: $UID in docker-compose.yml. If you're comfortable using master you can try it out now, otherwise an RC release should be along in the next few weeks.

I'm going to close this issue since the feature itself is implemented as part of #1377

[dnephin]

and then rename/relabel the container to make compose think it was started by up command

This is actually not the first time I've heard of the need for this (although in this case I guess it's just temporary). I have a proposed fix for it in #2042