Scripting Gateway installation and project configuration

Ignition
1

For our product which is built on Ignition we distribute the Ignition project and its artifacts (tags, etc). We are exploring ways to script the installation of the gateway and deployment of these artifacts. Looking for resources, guides, etc we could use to achieve this.

Thanks!

2

The installers can be run with a variety of command line arguments that should get you started: Command Line Installations - Ignition User Manual 8.1 - Ignition Documentation

3

Thanks Kevin.
We are currently getting the UNIX install file from Archived Ignition Releases | Inductive Automation and doing the installation. The resource you referred has good info that should help us script this part of installation.But as you know there are lot more that follows after a gateway installation. I will list the main ones that we are doing so you get a sense of what we are trying to achieve.

Steps following installing the gateway that we would like to script:

  • configuring the database connection under Database:Connections
  • configuring user/roles under Security:Users,Roles where we have 5 DB queries configured (User’s Roles Query, List User Query, etc)
  • create Reatime Tag provider under Tags:Realtime
  • importing Ignition project
  • and associating newly created tag provider and database with the project

After launching the Designer, we import a tags json (via Tag Browser) and import image via Tools:Image Management.

Can these be scripted as well? Since we are providing these tools to DevOps folks with little/no Ignition knowledge, we are seeking to make this deployment run with minimum manual intervention.

Thanks in advance.

4

No, all of that should be accomplished by just restoring a gateway backup, which can be done via the gateway command line utility.

https://docs.inductiveautomation.com/display/DOC81/Gateway+Command-line+Utility+-+gwcmd

5

Thanks Kevin, I will explore the gateway backup utility.

The product we are building bundles Ignition as its MES capability. And all our work is mostly in a Ignition project which we were originally hoping we would distribute along with some scripts to deploy and configure it. Based on what I am learning here sounds like we have to look into distributing the gateway backup instead, since it seems to bundle the project as well the various configuration I listed earlier.
Some question I wonder about if we start distributing gateway backup:

  • I am wondering about product support. So, how would we distribute maintenance fixes made to the project to customer deployments? Or upgrade customer deployments to a new versions of the project? In those case, we probably want to import the new project instead of restoring the entire gateway backup?

  • After launching the Designer, we import a tags json (via Tag Browser) and import image via Tools:Image Management. Would that also be covered by the gateway backup?

  • For some of the actions I listed are there API we could consider using that would let us affect things in a more granular way?

Thanks in advance!

6

Hmm, it depends. If you are only making changes to project resources then it could be just a project to import. If you make changes to tags, UDTs, DB connections, auth profiles, etc... (any resource that isn't part of a project), then a simple project import won't work. This also assumes your users will not be making any changes that might get overwritten by the import.

Yes these would be included in the backup.

If you're willing to write and distribute a custom module some of these things may be accessible.

7

@Kevin.Herron I’d like to second the request here from Vinay_N to have a way that we can provide parameters and properties to the ignition gateway during commissioning to automate the configuration.

I’ve looked at the init.properties functionality which has a couple of limited functionalities here for setting up the gateway network but does not enable setting up database connections, opc connection, user profiles etc.

The key reasons I’d like this feature are three-fold.

  1. It encourages us as developers to document the configuration of our gateways, store it in a SCM, and track changes
  2. If we’re setting up a brand new facility or project we can document and configure in advance of what the system is supposed to be even if an integrator or engineer doesn’t have access to the actual devices, databases, User/roles etc.
  3. Cloning from Gateway backups can create issues as there are settings and features that may be created for one site but not always easily removed from the gateway and can muddy the waters transitioning over to other sites. This requires extra work to start from scratch and doing the pointing and clicking to set up the gateway all over again.

I have done some of this using curl payloads during the commissioning phase but to do that for the entire gateway config would be tedious.

8

In 8.2 every piece of config that currently lives in the internal DB will be exploded out to the file system, much like projects are now, using human- and program-friendly file formats wherever possible. I’d imagine this will allow for the ultimate flexibility in commissioning and post-commissioning configuration of a gateway…

3 Likes
9

@Kevin.Herron That sounds exactly like what I’m looking for, can’t wait to give it a whirl when it becomes available as a preview!

10

I’d love to have a preview of what that means for my modules…

11

Ha, this is all theory today. I’d like a preview too.

1 Like
12

@Kevin.Herron I'm very interested in that ... I looking to create "on-fly" a skeleton of the gateway in the docker container: at the moment is not possible to create a database connection tag provider etc... during the creation of the container. so maybe version 8.2 can be?