Docker Image: Custom UID/GID for running as non-root

Greetings container users! I wanted to drop some additional context on an upcoming enhancement to the official Ignition Docker image. In the nightly builds right now, there is support for two new environment variables that can be used to drive the user ID (UID) and group ID (GID) of the running gateway process in the container. When left undefined, the container will continue to launch as root as it did before.

variable name type description
IGNITION_UID integer Numeric ID of user to launch gateway, i.e. 999
IGNITION_GID integer Numeric ID of group to launch gateway, i.e 999

This means you should be able to launch an image like so:

$ docker run -d 8088:8088 \
    -e IGNITION_UID=999 -e IGNITION_GID=999 \
    -v forum-xxxx-data:/usr/local/bin/ignition/data \
    --pull always \

When it starts, the entrypoint will re-map the built-in ignition user/group within the image to 999:999. Additionally, filesystem permissions for the Ignition installation will be updated to match the user/group ownership. This will take a few moments when the container starts up. Subsequent restarts of that container will not incur that initial re-mapping delay. If you do re-create the container (to change configuration, leaning on your preserved data volume for your gateway state), you’ll observe another short delay as filesystem ownerships (from the base image contents, now fresh again) are once more updated.

If you’d like to build your own derived image to bake-in these environment variables, it is pretty to achieve with a Dockerfile such as the one below (EDIT: be warned that this does have the unfortunate circumstance of increasing the image size substantially due to the extra image layer being generated):

FROM inductiveautomation/ignition:nightly


RUN chown -R ${IGNITION_UID}:${IGNITION_GID} ${IGNITION_INSTALL_LOCATION:?expected in environment}

You could then build this with:

$ docker build . --build-arg IGNITION_UID=1002 \
    --build-arg IGNITION_GID=1002 \
    -t <organization>/ignition:nightly

I hope this feature helps those who are leveraging bind-mounts back to their host (with specific permissions) align the container’s UID/GID with their host system.