Files generated within the docker container should belong to the host user

[demestav]

Description

In docker development in Linux (and Mac?) when a file is generated in the docker container, it belongs to the root user. Since the project directory is a volume to the host machine directory, those files belong to the root user in the host as well. If you want to edit those files, you need to become root or change the permissions. It would be nice to not have to deal with this.

Examples of iles that are generated by the application:

• migrations
• media
• translations

This does not only apply to editing the files; sometimes permissions cause problems when rebuilding an image.

Rationale

Removing the need to deal with permissions will improve the development workflow

Suggestion

Without being an expert on the subject, I deal with this problem by assigning user 1000 to the container. However, I think this does not generalize since not all users will have the id 1000. Also I am not sure if this conflicts with #1410

[rolep]

One example i use:
docker run --rm -it --user="$(id -u):$(id -g)" image command

For container itself - gosu might do the trick, used in entrypoint, while also passing current user id from docker-compose file.

P.S. During local development I actually run all management commands locally, not in docker.
runserver - run in docker - either by docker-compose up django or similarly via pycharm.
This may result in root .pyc files, but its ok if i always run it that way (or if i add such a fix with my user id to compose file).

This is very broad issue of local vs docker.
Personally, I prefer such setup - actually running services in docker while making all development (i.e. local manage.py commands and others) equally possible from local shell

• local pipenv (not compose virtualenv)
• while still running all services (db, redis, runserver, celery, etc) with docker
• exposing ports on some containers (db, redis), so i can connect to them from local shell
• local django config is populated with default vars in case none provided (i.e. user=user/project_slug, db_name=project_slug, password=password ...), also for db connection try common PGxxx vars if they are defined (in addition to POSTGRES_ vars), like PGHOST, PGUSER, and setting them in local .env I get: their availablity via local manage.py, their availability directly to local psql or pgcli commands (with the help of direnv to autoload them)

This brings advantage of local shell, which I am still in process of customizing, using vim, simplifies using other system tools. Docker in such case is just a tool of installing software - i can either install db / redis system-wide (which may be not so simple, and is different on different os), probably bound to only one version / instance, or i can run multiple versions with docker.

Not all devs know docker, such setup allows running management commands, heck, all commands, both in docker or locally, with only starting required services (db / redis) in docker, which is far simpler, pycharm has hooks to autostart containers on project load.

Good discussion with example of dev environment with vim and other tools in docker - looks nice and feels worth trying, although i think its more personal tool and requires some understanding of what's under the hood.

[rolep]

Usage with gosu as entrypoint script.
Current user / group id is determined based on manage.py file owner.

/gosu-entrypoint

#!/bin/sh

set -eu

EUID=1000
EGID=1000

# Setting user and group id based on manage.py file owner
if [ -f "manage.py" ]; then
  EUID=$(stat -c %u manage.py)
  EGID=$(stat -c %g manage.py)
fi

# Creating user and group django with required ids, needed by some libs
if ! getent passwd django > /dev/null; then
  addgroup -g $EGID django
  adduser -h /app -H -u $EUID -G django -s /bin/bash -D -g DJANGO django
fi

exec gosu django:django "$@"