Should we use Docker in Production?

Ignition
, , ,
1

Hey all, my question: Should we use Docker in Production? Or development, for that matter?

Our setup:

  • corporate managed, on-site, physical servers
  • multiple VMs running licensed Ignition, Trial Ignition and Backup gateways
  • Physical servers have failovers/backups
  • Running MSSQL Server on a VM
  • Three production lines, one entirely on Vision, all three will be using Vision/Perspective depending on user needs. Vision for the HMI, Perspective for other tasks, KPIs, etc.
  • Perspective is also being used for spare parts inventory, and service logs for several departments.
  • We have four developers working, on-site, within Vision, I am the only one using Perspective.

Our design/testing process:

  • We create new folders/screens for development/testing in the Designer(Trial)
  • Try to test as much as possible without using live Tags, since we need data from machines to test against
  • Sometimes we may want to work on the same screen for a production update, which can cause problems. Someone may lose their work.
  • Production updates cause screens to 'reset' to Main Window, the primary "landing page" for the Vision projects, unless we use a custom tag/script setup that allows us to "remember" which screen each client is on and navigate to said screen after the project update.
  • I manage a MySQL DB (which we are in the process of migrating off of) and several MSSQL DB's via the SSMS.
  • We use the export/import feature to push updates to Production.
  • And nobody here uses Linux... Corporate policy, I think.

So, I just found the Webinar on the Docker thing from 2023, from somewhere near this post (https://forum.inductiveautomation.com/t/what-external-tools-do-you-use-for-ignition-development-and-why/93759/51)
(Also, just got extensions for VS Code setup for me, and am reading through other threads on Docker.)

This really got me thinking about the way we design and test screens, how we deploy Vision/Perspective on each client and how we push updates for production. I'm just wondering if this is the most efficient, cost-effective way?

One more bit of information: the other devs don't use VS Code, only working in the Designer and Notepad++.

So, could using Docker in development benefit us? In Production? And what does the road look like to get going?

Thanks!

2

If nobody uses Linux, then I think Docker is out of the question for production. I wouldn't use Docker Desktop for Windows to try to run production Ignition systems, as I believe there are issues with even trying to get it to run automatically on startup (if I recall when I checked into it). I would however use it for development and testing, as it allows you to spin up instances easily for testing.

3 Likes
3

Corporate policy is to leave the front door unlocked. At all costs...

4

Docker running on Windows is basically only for developers that are using it on their own machines that are already running Windows.
Docker itself runs on Linux, so to run it on windows you are running the WSL abstraction layer, which is not very stable, but on a dev machine where you can reboot it with no consequences and where speed of deployment and ease of use is needed, it is great.
Running Docker in the workplace is more of a multipart solution.

  • Docker for developers: Each developer runs and develops their code on temporary docker containers on their local machine with Docker Desktop. This enables them to have many projects on the go that can be developed on many containers that do not interact with each other till they want to combine the development features.
  • Docker for staging: A central server runs easily replicated docker containers for multi-user testing of new changes and features. Docker enables the staging server to have multiple gateways running as needed. Bad feature sets can be simply deleted and in seconds there is a fresh instance ready to be developed against. In Windows environments this is of limited value due to WSL and the limitations of Windows.
  • Docker for production: A central Linux server runs your main gateway on docker, making updates, backups, config changes and feature releases much easier to automate. Windows is not an option here.
5

I see. After taking a few moments to reflect on our varying levels of development and time available to learn Docker, and the requirements needed for staging (if we were all to use Docker), I'm thinking my co-workers will probably not jump on this boat, but I would like to try and use it to run tests locally.

This, then, being the case, I should have no problem exporting all the necessary gateway configs, Tags and projects needed. However, for accurate testing with the tags, I might require a Simulator of some sort for various real devices. I wonder, how easy would it be to take the current tags and remap the ones I want to use to Simulator devices?

And, if I understand correctly so far, I should be able to create a connection to our SQL Server in Docker so I can use the DB already setup for testing.

Thank you, Michael and David, for your input!

6

If you restore a gateway backup on to a docker, your gateway will seek to connect to the PLCs directly just the same as the original gateway. This may or may not be what you want due to comms load on the PLCs.
I have seen multiple ways of dealing with this, which is easier on a scale-out architecture as you likely have a devices gateway that you can GAN connect to for remote tag provider tags.

7

I strongly encourage my clients to create truly isolated networks in which to run development and staging gateways, so an unintended connection doesn't corrupt/disrupt production systems.

1 Like
8

We, uh, have just one Production gateway, the backup and the developer/trial.

9

So do most people, I only added that bit in case you had a big install.