Running Ignition at the edge as a container

Ignition is excellent software and most people deploy it in a way that guarantees pain later. Not because they chose badly, but because the obvious path is to install it on a panel PC next to the line, and the obvious path scales until roughly the tenth one.

At ten gateways you have ten machines with slightly different Java versions, module sets, and patch levels. At forty you have a project that nobody wants to own, and a standard practice of not touching a gateway that currently works.

What the container changes, and what it does not

It is worth being precise, because containerising SCADA attracts more claims than it deserves. Running an Ignition Edge gateway as a container does not make it faster, does not change how it talks to a PLC, and does not remove a single line of your project.

What it changes is everything around the gateway.

• The gateway becomes a version rather than a machine. Deploying 8.3.8 to forty nodes is one change rather than forty visits, and every node runs the same bytes.
• A failed node stops being an event. The gateway is redeployed onto replacement hardware from the same image and the same configuration, and the recovery is measured in minutes rather than in whether somebody documented the original build.
• Rollback exists. If a version misbehaves, the previous one is still there, and going back is a deployment rather than a reinstall.

The part that trips people up

Persistent data. An Ignition gateway is not stateless: it holds its configuration, its tag history if you are historising locally, and its modules. Treat the container as disposable and the first redeploy takes your project with it.

So the volumes matter more than the image does. In the EmberNet App Store the Ignition Edge entry ships with its data, modules, and backup volumes defined up front, precisely so this is decided before the first deploy rather than discovered after the second one.

The failure mode is always the same. Somebody proves it works in a lab where the volume never had to survive anything, then meets the difference in production.

Edge, Standard, or Cloud

The three run differently and people pick by licence cost rather than by role, which is backwards. A rough guide that has held up for us:

• Edge belongs at the machine, doing local HMI, collection, and store and forward when the link upstream is unavailable.
• Standard belongs where a real SCADA tier lives, with alarming, a historian, and the full tag set.
• Cloud belongs where aggregation happens across sites, and should not be doing anything a line depends on second by second.

Getting that split right matters more than the deployment mechanism. A containerised gateway placed at the wrong tier is still at the wrong tier.

What we would check before starting

1. Where does tag history live, and can you lose the local copy without losing the record.
2. Which modules are actually in use, because the answer is usually fewer than the installed set.
3. What the line does when the gateway restarts, and whether anyone has tested that rather than assumed it.

None of those are container questions. They are the questions containerising forces you to answer, which is most of the value.