Allow use of dynamic user in fig

[arruda]

It would be nice if fig could do the same as:

docker run --rm -i --user="$(id -u):$(id -g)" ubuntu /bin/bash -v $PWD:/data

This way one would be able to set the same user user/group as the current user without having to set manually each time for every different user.

(using this would make the files created within the container to be with the same permission of the actual user)

[Starefossen]

A very similar feature like this has been suggested in #495

[dnephin]

This is not related to #495. I think it's part of #363

[aanand]

What's the use case?

With environment variable support, passing in $USER will be trivial. Not true for groups though.

[IanVS]

@aanand From what I can tell, these two fig.yaml files behave very differently:

Setting user directly:

server:
  image: artificial/docker-sails:stable-pm2
  volumes:
    - server/:/server
  user: 1000

Setting USER environment variable:

server:
  image: artificial/docker-sails:stable-pm2
  volumes:
    - server/:/server
  environment: 
    - USER=1000

In the first case, when setting the user, files generated with a fig run server sails new . creates a new sails project inside the /server directory with ownership of 1000:0 which is what I want in this case. I see this same behavior when using fig run -e USER=1000 server sails new .

However, when setting the environment variable "USER", the files are all still created with 0:0 (root:root). I see this same behavior when using fig run -e USER=1000 server sails new . All the files are still owned by root, even though a fig run server env confirms that USER=1000

It would be really nice to be able to set the user in the fig run command, as suggested in this issue report, because then I could control the ownership of the files being created.

[dnephin]

#737 is related to this

[ioggstream]

Using the approach I proposed in #1006 we could provide a safe variable substitution.

This could include eg: %%user%% and %%group%% variables.

Those variables will be resolved via python (and not prone to shell-expansion)

[glappen]

It would be nice if you could have environment variables in docker-compose.yml that are substituted by python when the file is read. For example, you could have user: $UID in a service so it runs as the same user that is running docker-compose. This is useful for development scenarios among other things where containers might generate files you then want to edit.

[pwaller]

@aanand asked for a use case:

In development, I want to bind mount $HOME/Projects/foo to /path/to/foo - so that I can have live updates to the app when I save the source on the host without restarting the container, for example.

My development container needs to be able to build foo which involves writing to /path/to/foo/bar in the container. If I don't setuid to the same ID as my user on the host, then my container can't write there, and can't build the project - unless uid=root.

As a workaround, I currently build as root, which sucks, and results in files that $USER on the host doesn't have ownership of in $HOME/Projects/foo, and causes all sorts of other problems for myself and colleagues.

In an ideal world, I would ensure that foo's build system didn't try to write to /path/to/foo, but to some other temporary place in the container which it had ownership of. But this does not seem easy to arrange. (It's go install which is writing those files because /path/to/foo is one of the things in $GOPATH, so it wants to put libraries in /path/to/foo/pkg).

(Finally, I'd like to instruct my colleagues to just run docker-compose up, rather than needing to teach them to do docker-compose up --user ... or something baroque like that).

[dnephin]

With environment interpolation and user: in the yml, this is now supported.

We also have --user on docker-compose run

[IanVS]

👍

Can you please give an example of how to use the environment interpolation?

[dnephin]

The docs are here: https://github.com/docker/compose/blob/master/docs/yml.md#variable-substitution

The feature is in master, and will be in the 1.5.0 release.

web:
    user: ${USER}
    ...