Best Practive Integrator Dev Environment

Ignition
1

I lead a group of engineers in a medium size integration company, working on multiple different ignition projects at once, for different customers, in different environments, on different versions.

Currently for local development we have been spinning up a windows VM for each different gateway our end projects have, and developing off of those. Utilizing locally created memory tag versions of UDTs, and a central SQL Server instance. As you can imagine that starts to really add up, when you have 5 different gateways running and 4 different edge gateways, just for development.

Is this the standard for groups in situations like ours? I have thought about taking smaller projects and putting them all on one gateway, and leaving our enterprise level (multi-location) projects on their own gateways.

Any advice would be greatly appreciated!

2

It may be worth looking into Docker - it’s a lighter weight way to run multiple, separated instances of applications, compared to VMs. Generally speaking, you’ll have the best experience running it on a Linux host (which can, itself, be a virtual machine, in a real ‘nesting-doll’ type of situation). Once you’ve got Docker, I highly recommend using a GUI frontend like portainer to manage your actual containers. You can also pull down community-created Ignition templates: https://hub.docker.com/r/kcollins/ignition (at some point, we would like to have official Ignition docker images published, but no timeline on that).

You can even run database instances in separate docker containers, and easily wipe their data/reset them as needed.

There’s some startup cost, but (in my opinion) it’s easily worth it. I’m using an Ubuntu workstation, and I have at least 5 docker containers running all the time - two databases, a few Ignition instances on different versions, etc. That’s just for personal use - if you’ve got a beefy server, you can easily scale that to multiple users.

7 Likes
3

I run separate VMs for every customer gateway, configured with identical networking on dedicated VLANs. It makes dropping a customer backup into my dev environment a trivial task. Some of the databases are shared, with multiple VLAN interfaces. Other DBs are isolated. All of those VMs are hosted in my office server (Ubuntu) that has gobs of storage and RAM. I also maintain VMs on my laptop (Kubuntu) with specific versions of Ignition for module testing. Also on VLANs in the laptop, some of which are bridged to the office VLANs (for all the PLCs in my lab).

Linux makes this stuff relatively easy.

4 Likes
4

Another vote for Docker + Portainer here. Kevin Collins has done a fantastic job setting things up, including great documentation. We routinely run over 20 Docker containers on our Debian server with multiple databases (including SQL Server!) and multiple Ignition systems (and hosting our own map tile server and our own website and public facing database systems and more!).

In our experience Docker containers are vastly better than VMs: lighter, quicker to set up and faster to start and stop. No downsides really.

2 Likes
5

Do you use the community edition of both Docker and Portainer?

As well what do you mean by this? Do you just mean the overhead of setup in terms of labor hours?

6

Mostly startup in terms of “time investment to get used to the features and what Docker can (and can’t) do”. It looks like you’re mostly a Windows shop, just based on the original post, and Linux environments can be less friendly to get used to if you’re more familiar with GUI setups. Pretty much everything in Docker is done through the command line (which is why I recommend Portainer; ain’t nobody got time to memorize every docker command and flag) - but it’s also pretty easy to just google how to do whatever you’re trying - and an advantage to docker and portainer is that once it’s set up on a linux host, you likely won’t ever really need to do anything to that linux host.

3 Likes
7

Thanks for all the advice Paul.

8

Another alternative that could possibly be lighter than Docker for a linux environment is using LXC. I’ve been utilizing the Proxmox distribution for that at home. With some effort you can also add in the ability to run Docker on top. But for just Ignition, the basic LXC environment that Proxmox supplies should be good enough.

On the other hand, if you don’t need to completely separate Gateways, with some planning you can have multiple projects running on one gateway. This supposes that you don’t install multiple versions of the gateway since if you update the gateway, you then are required to update all of your clients before you could send any updates to them. Project backups will not install on an older gateway then what the were produced on, unless you muck with the XML (which is not particularly safe).

What I have done here with the limited number of projects we’ve done so far, is to:

  1. Any Tag Data Types defined go under a path that includes the customer and job identifications
  2. Any Defined Tags also go under a path that includes the customer and job identifications.
  3. Any Projects Include the Job Identification
  4. We have installed the EthernetIP Class 1 Communications Module from Automation Professionals to aid with providing “virtual” tags when the PLC’s go away. I have found that way to be better than the effort of defining Memory tags shadowing the PLC tags. I only recommend that if you have a limited number of gateways, since the cost would be prohibitive for doing that for lots of development gateways.
  5. Most Tags are accessed as Indirect Tags with the Base Path to the Tags defined from a client tag. This allows the base of the tags to be whatever the client wants at install time and still be compatible with what is on your dev gateway. This doesn’t work very well for the gateway and client tag scripts which is unfortunate but hasn’t been a big problem. That also doesn’t work well for SQLBridge which we haven’t utilized much.

I often get the feeling that my way of doing things was not expected by the Ignition design team. Which strongly suggests that it might not be the best way of course :face_with_raised_eyebrow:

Anyway, hope this gives you some ideas going forward.
Bill

1 Like
9

In a pinch, you can set up one instance of Ignition with my module and point other gateways at it with the v21+ Logix driver.... And when it is time to deploy, you just change the IP address and/or processor slot. (:

Since that is passive mode, you can emulate 100 different PLCs simultaneously (with sufficient horsepower, of course).