-
Notifications
You must be signed in to change notification settings - Fork 11
##Chaperone-based Images FAQ
The container setup is designed to set-up the user for you. Here is how it works:
By default, the baseimage Dockerfile specifies the following environment variable:
_CHAP_OPTIONS="--config apps/chaperone.d --default-home / --user runapps"
That tells Chaperone to use that user for all services by default, and all built-in scripts (such as the provided build/install.sh script) assure that files copied into the container are owned by runapps.
However, when you run your image in development mode, using chaplocal, the docker command in run.sh overrides this in a way similar to the following:
docker run -i -t chapdev/chaperone-alpinejava --create-user alex:/Users/alex/dev/installs/chap/changeup/chaperone.d /bin/bash
What this does is tell Chaperone to create a brand new user inside the container called alex with the UID/GID credentials that are the same as the chaperone.d directory (whatever they are). This is a clever way to get the container to "mimic" the user account credentials on your local system so that everything works fine.
In production, you often will want to do the same thing with attached storage. The build assumes that the only writes will occur to /apps/var, so in production scenarios the entire app is stored inside the container, but any persistent data is on attached storage. Then, you can tell Chaperone to create a user to match the attached storage credentials:
docker run -v /mnt/persistent/myapp/var:/apps/var -d myapp-image --create-user produser:/apps/var
The above command thus attaches persistent storage to the container's /apps/var directory, and also tells Chaperone to run all services as a newly-created user produser whose credentials will mimic those of the /apps/var mounted directory. That way, your container services have full write access to attached storage without requiring root.
You can, using Chaperone's uid and gid service directives, specify that services run as any existing user on the system, including root, so you can override this on a per-service basis, or globally, but generally, that should be needed only for special cases.