Ignition architecture question DEV to PROD

Ignition
1

Hello i currently have an Ignition DEV instance and SQL Server DEV instance. At the same time i have an Ignition PROD instance and a SQL Server PROD instance. (4 VMS in total)
The goal was to do all development in the DEV instance and do periodic gateway backup restores for the PROD version. I was just wondering if this is the right way to go about things or is there a way to push updates directly from the DEV instance to the PROD instance?

2

Hello,

To do this right, you will want to layout and follow a DEVOPS process. Ignition itself I have found does not lend it self particularly well to DEVOPS, but following a rigid process is the key. There are a lot of tools out there to assist in all Phases of the DEVOPS lifecycle.

Frank

3

If you make your dev environment identical to the production environment, right down to DNS names (or IP addresses), then restoring a dev backup into a production gateway is possible. But pretty hard on production while the gateway restarts.

Consider using EAM to move resources around.

You could use git pushes and checkouts to move many types of resources, but certain items are only configured in the gateway's internal database at this time (tags, in particular).

Many of us are looking forward to v8.3.....

4 Likes
4

if i had EAM installed on the DEV server would i be able to push updates into the PROD server?

Will ignition 8.3 make this easier?

5

I need to check into the EAM module as well. I currently mirror my Dev and Pro environments except for the database connections. I have a gateway startup script that adjusts the data source connections based on the gateway name. I'm sure Phil will have a reason for this to be a bad idea though :sweat_smile:

host = system.tag.readBlocking(["[System]Gateway/SystemName"])[0].value

if 'dev' in host.lower():
	dbHost = 'something'
else:
	dbHost = 'somethingElse'	

sources = ["connection1","connection2"]
path = "jdbc:mysql://{:s}:3306/{:s}"

for source in sources:
	system.db.setDatasourceConnectURL(source, path.format(dbHost,source))
6

Any typo or side effect that prevents that from running, or running immediately, will cause a production backup loaded into DEV to write to your production database in parallel with production. Could be something as simple as that project being disabled in production when the backup is taken.

I would not take that chance.

I recommend using a DNS name in the connection URL that resolves to the correct DB for the environment.

2 Likes
7

The other annoyance I've run into when doing this, is report scheduling. If you have any reports that use the scheduling functionality you will get double reports unless you open each one and disable the schedule.

I moved all my report scheduling to scheduled gateway scripts in a separate project so if I do export/import from Pro to Dev, I just disable the report scheduling project.

8

FWIW, I recommend making your dev environment identical to your production environment as far as DNS names or IP addresses are concerned, regardless what method you use to move updates in the dev => prod direction. It reduces the chances that a forgotten incorrect setting anywhere in the system ends up in production.

2 Likes
9

Have a separate mail server in DEV impersonate the PROD mail server (with same DNS name) and blackhole any unwanted messages. You could also use msmtpd or similar mail forwarders installed in the gateway servers and have all email configurations in Ignition go through localhost. The forwarder in DEV would handle everything differently.

1 Like
10

That makes a lot of sense :slight_smile: Our Ignition gateways are hosted on Windows Server 2019. For anyone else that finds this thread, You can add a local DNS name in the C:\Windows\System32\drivers\etc\hosts file and use that name in Ignition's DB configuration. Do this on both production and development servers with the correct associated IP for easier gateway exports/imports. Thanks, Phil.

<db_ip_address_here>    my_db_dns_name
1 Like