Version Control with GitOps and Kubernetes

Ignition
1

Hi all,

We have a question about GitOps best practices for the Kubernetes version of Ignition.

We have two gateways (dev and prod) deployed using the official Inductive Automation Helm chart: https://charts.ia.io/.

Our current workflow is to manually copy projects from prod to dev, connect to the dev gateway with Designer, make our changes, and then move the updated project back to prod. This works, but we'd like to improve it with a GitOps approach so that project changes are versioned in Git.

We've come up with two possible approaches:

  • Install Git in the Ignition container so we can push and pull project files directly. The downside is that we'd have to modify the official Ignition image and store Git credentials inside the container.

  • Sync through a local machine by copying the projects folder from the gateway, committing the changes to Git, and then copying the updated files to the target gateway. The downside is that this relies on developers remembering to sync every change, so we could lose track of which project version is actually running in dev or prod (Contrary to the GitOps approach).

Has anyone implemented a GitOps workflow for Ignition on Kubernetes? How are you handling project versioning and promotion between environments?

2

Bump

3

Hello,

Are you on 8.1 or 8.3?

Ideally for a GitOps approach, you would make a change on dev and push it to your VCS. From there a runner would deploy those changes via ssh. This runner can either directly copy the files or issue a command to the container to pull the specific release/commit. It is up to you. The less the container knows IMO the better. You can track what has been deployed to what environment usually through your VCS.

Basic example below:

image
image2133×596 42.3 KB

4

Hi thanks for the feedback!
We hare running Ignition 8.3.

We hoped for something more integrated in Ignition, like it has been done on Thingsboard for the GitOps part ( Version Control | Docs | ThingsBoard PE ). What you described is interesting, but it is a generic approach can an adopted for every system that has a file based configuration.

Probably the most critical part would be the beginning of the chart: how we put the project change on the VCS from the Dev Ignition wihout having to install git on the Ignition image.

5

I'd recreate your environment in a VM and have an agent define a good procedure, tailored to your environment/desires, for you. This is the perfect task for opencode/codex/claude code.