Upgrade methodology

With my database upgrade/migration out of the way, I need to start planning the Ignition upgrade/migration. I’m currently on 7.9.6 and will be moving to whatever the latest stable version is at the time I’m doing the migration.

My current thought is to spin up a fresh Ubuntu instance, install Ignition 8.1.x, go through the commissioning process (need to figure out SSL stuff…) and then import a 7.9.6 gateway backup, but checking the box to restore disabled. After that it gets a little fuzzy. I can check the individual devices and ensure that they are disabled, along with my database connection. I may setup a second database server for this test server to connect to using the previous day’s data backup.

Then, I guess check to make sure everything is looking ok, and functional, at least as far as I can without actually connecting to my devices. I’ve read that I might be able to connect this test server to the current 7.9.6 server as a remote OPC provider. I’m not sure how I would go about re configuring the drivers to do that, or if it would cause headaches to try to convert them back whenever I do the go-live with 8.1. The server might be in testing mode for a while so I can develop new disk images for my various raspberry pi installs that will have trouble connecting to the 8.1 instance on their own.

Sound reasonable? Any advice from those who’ve done this a couple times?

Don’t change anything. Use a VM on a completely isolated network that uses the same IP addresses as the original. Fake devices as best you can, on their correct IP addresses (trial mode on my Ethernet/IP and Modbus Server drivers on a “simulation” VM, perhaps). Duplicate your DB into another VM and run the copy in the isolated network, too.

Then you can restore without disabling anything.

2 Likes

Makes sense. Might be a little more work on the front end, but if I can get everything working properly, I’m guessing the go-live is simply a matter of plugging the VM into the production network and shutting down the old VM. I suppose one could even keep a copy of the isolated network setup for development purposes. Hmm…

I find having an isolated dev environment invaluable.

This is one of the reasons my laptop runs Linux. I have multiple virtual networks defined with specific VMs configured for each, set up to mimic client setups. (With some heavier-duty spreads on the office servers.)

@pturmel what Linux OS do you run? I’m assuming a big benefit is freeing up hardware while running VMs?

Kubuntu 20.04.

And yes, VMs can be very space-efficient. I normally allocate only 8G or 12G storage for a typical headless gateway. One of these days I’ll start doing more with containers, but I haven’t taken the time to work out the incantations for multiple virtual networks.

having a windows host machine kills my hardware lol

I wouldn’t know anything about that. I haven’t run Windows on bare metal in about eight ten years.

{ I was already running exclusively in VMs by the time I migrated from Windows XP to Windows 7. Sometime after its SP1, which was in 2011. }

1 Like