Building Custom Ignition Gateway Docker Images

[jacobb]

Hi all,

I’m working on a project where I'd like to build a custom Ignition Gateway Docker image that includes my data directory with my development changes. My goal is for the resulting image to be fully self-contained—so that when I run a container from it, the Gateway starts up with all our customizations and resources in place (tags, projects, etc.). I'm working on a local development environment and trying to get a reproducible image created in CI.

Here’s what I’m doing so far:

- I’m starting from the official Inductive Automation Ignition image (currently using inductiveautomation/ignition:8.3.0).

- I copy our data directory into the image using: `COPY --chown=2003:2003 data /usr/local/bin/ignition/data`

The Ignition process runs as user/group 2003, so I set ownership accordingly.

Problems/Questions:

When I build and run the image, the Gateway doesn’t pick up all the customizations as expected - though it does if I run from the base image with the customizations bound as a volume.

I want to ensure that all files and directories in /usr/local/bin/ignition/data are accessible to the Ignition process.

Are there best practices for copying the data directory and setting permissions/ownership in the Dockerfile?

Is there anything else I should be aware of to make sure the Gateway starts up cleanly with all our development changes included?

Thanks in advance!

[paul-griffith]

Don't mount into /data/, that's too broad. If you need to load 'gateway config', then mount the things you care about from /data/config/resources/core/ (on your development system) into the container at the /data/config/resources/external/ directory. The external directory is automatically scanned in on gateway startup and treated as an immutable set of resources that the gateway will not ever attempt to make changes to.

Some more context:

Deployment modes override and rename to override with another type?

Deployment modes can change anything (though it's not necessarily recommended). If it helps, think of it as a single project inheritance tree. If you're in the dev mode, you're consuming external -> system -> core, then whatever dev defines, and then potentially overridden by anything local: Tree External External System System External->System Core Core System->Core Dev Dev Core->Dev Test Test Core->Test Prod Prod Core->Prod Local Local …

Creating tag groups with the openapi endpoints in the gateway?

No, not through the rest API nor directly via scripting at present. It's very poorly documented at present because it's brand new to 8.3, but there is another possible solution to your issue; more on that later. Correct, the entire many file based configuration storage is new to 8.3; prior versions used a SQLite "internal database" to store all configuration and we did not support editing that database directly. For posterity, while you can do this, the address mapping feature is generally …

The project inheritance situation is different, but you should generally follow the same pattern:
Mount /data/projects/ (or even individual projects within that folder) - don't try to mount the entire data/ directory, because Ignition needs to do certain things there related to the runtime that don't make sense to VCS/store outside of the container.