I'm looking at how to manage database connections in Ignition 8.3 as part of a CI/CD workflow and hoping someone can point me in the right direction.
My goal is to have a declarative configuration for database connections stored in source control and then apply that configuration to a gateway, similar to how infrastructure-as-code tools work.
After reviewing the Gateway API documentation, it appears that I would need to implement logic that:
Retrieves the current database connections from the gateway.
Compares them to a desired configuration.
Determines whether each connection needs to be created, updated, or deleted.
Uses the API to reconcile the gateway state to match the desired configuration.
While that approach seems possible, I was under the impression that Ignition 8.3 moved gateway configuration away from the internal database and toward a flat-file based configuration model. Because of that, I expected there might be a more declarative approach available for managing gateway resources such as database connections.
Am I misunderstanding how database connection configuration is stored in 8.3?
Is there any documentation, examples, or recommended patterns for managing database connections declaratively in 8.3 that I may have missed?
For those implementing CI/CD around Ignition gateways, how are you handling database connection configuration today? Are you using the Gateway API to perform state reconciliation, or is there another supported approach?
You would make a change locally on your shared/local dev environment and commit the change.
# Example of committing core resource
git add ignition/resources/core/ignition/database-connection/TEST
# OR a dev resource override what ever resource override you define
git add ignition/resources/dev/ignition/database-connection/TEST
git commit -m "refactor: changed db connection"
git push
From there you would create a pipeline that deploys your changes to the actual gateway instances e.g. .gitlab-ci.yml config.
Consider having your CI system deliver required configuration into the external resource collection, so that it's immutable and cannot be removed at runtime by end users:
Around February 2027, when we release our new major version, we're planning to release a series of Ansible extensions that work with 8.3 and 2027 and allow you to express gateway state changes. It's still the gateway REST API "under the hood", but wrapped in way you don't have to think about the details.
I'll also say,
How else could this possibly work? There's a set of files on disk. That's the source of truth. If you want to change what's loaded in the gateway, you have to change that set of files. Ultimately, doing that remotely is a series of CRUD calls to the REST API.
We don't put everything in one or more mega YAML files or whatever because:
It would be extremely painful to read/write/edit
While ~80% of them are just JSON files, there are many other types of resource file that have to be encapsulated as well - images, themes/css, keystores, driver csv files, etc, etc
We already had a well tested, proven model for file based resources - Ignition's project system.
I am interested in how people are doing this piece? How are you comparing what is on the target system verses what is in the version control system and then creating an apply script to make the target system match the version control config files.
The first post I linked is itself a list of more posts describing things in more detail.
The gist is this: core is one "resource collection".
Each deployment mode you add is another. external is also a resource collection, and it's special in two ways:
It's loaded first/the top of the inheritance hierarchy
It's immutable.
So in one brand of gitops/CI/CD workflow:
Do your development on a local/dev gateway as normal, in core.
Push/commit your changes.
Deploy those changes to prod by pushing the literal files on disk into the external directory.
Et voila, the configuration you developed is now guaranteed to be present on the target gateway(s).
This isn't a complete solution because someone could still override it, so you probably want to lock down access controls on your production deployments, but if you do things this way you can guarantee nothing changes the state of things at runtime.
Running a new deployment? Replace the contents of external and reload the gateway's configuration from the filesystem.
I say 'one brand' because there isn't really a single canonical way to do this. Basically every shop I've ever talked to does things at least somewhat differently, in whatever workflow makes sense for them and their tooling.
This sounds great. I can just take the entire contents of core from my version control and put it in the external directory on my target gateway? Do I then need to restart the target gateway or use the API endpoint to do a file scan? The target Ignition gateway will handle updating all the configs to match what was put in external?
Essentially. I'd recommend, on a test system if preferred, creating a deployment mode, putting some resource override into it, and then looking at how that's represented on disk under the deployment mode directory. The trick is to make sure that what you put under external/ looks exactly the same as what you put under core/ - extra folder nesting or anything like that won't work.
Either one.
Correct. When you initiate a filesystem scan, if the state of things in memory doesn't match what was on disk, we'll reconcile by e.g. shutting down or removing things that no longer exist, starting up/creating things that need to, and so on.
