Restore gateway configuration only

Now that Ignition 8 stores all project resources on the filesystem, and one could use external source control to manage code through different environments…

I’m wondering if anyone has messed with restoring only the “gateway configuration” items to a gateway through a gateway backup.

PS I realize the Deployment Best Practices document, highlights that backups aren’t normally used manage gateway configuration because they are “all or nothing”. If there is an answer, its probably a hack.

The use case would be something like a template’d containerized Ignition instance…if you catch my drift.

You mean like @kgamble’s work?

No promises and no timelines, but things are afoot.

2 Likes

Essentially yes, same sort of thing.

Very exciting. I have a solution, but it uses some utility scripts I would rather not need to maintain and creates unnecessary coupling with git.

If you are talking about “containerized” in terms of using something like docker, then you could automatically provide a gateway config parameter to the dockerfile the same way a gateway backup is automatically handled. This should allow you to include a templatized configuration. I havent tested it, but I wouldnt be surprised if you could replace the config.idb on the gateway after installing it but before restoring it, and see if it retains your customizations.

If you are talking about outside of Docker then you could pre-package your own default ignition implementation as a ZIP, and instead of using the installer.exe you could handle your installations with the included install.bat or install.sh

I guess it would really boil down to what specifically you want to “templatize” about the configuration.

I dont know the specifics about what he’s talking about here, but I will say that it would be nice to be able to export your gateway config settings and provide them to the installer. Even if you were able to provide a gateway backup to the installer and it grab the “config” parts of the backup for the installation.

In this situation I’m working with Docker, but any environment (containerized or not) is a theoretical target.

I ended up unzipping the gwbk, manipulating it hoping for desired results, rezipping, and using it as a restore on docker run, and things ended up behaving the way I hoped. That said its definitely “undocumented”, but it serves my immediate purposes. So I can package a modified .gwbk with a docker-compose setup that lets me ship a portable Ignition environment (at least, as portable as docker gets).

1 Like