Hello everyone,
I would like to understand the difference between development, testing, and production environments in Ignition. My specific concern is on how environments are set up. Detailed explanation will be greatly appreciated (I am newbie to Ignition).
There's no difference, technically, except that development and testing aren't connected to real production equipment and data sources. Ideally, they are connected to real or simulated substitutes so that proper functionality in dev and test translates to proper functionality in production.
Is it advisable to have the designer, gateway, and MySQL DB in the same PC for a small Ignition project?
Then for project deployment, what are the steps involved?
No. With an exception for GW and DB in separate VMs (carefully configured to not conflict) in the same hypervisor. Designers should always be run separately. (As a side benefit, running the designer separate from the GW ensures that you have the GW's networking configuration correct for later client and external device connections.)
I count a designer running in a laptop or desktop to be "separate" from VMs or Docker instances running in that system, as long as the connection URLs do not have localhost in them.
Install your database in the production DB server. Copy starting table schemas and static data. (Backup from dev, restore to production, then prune is often most convenient.)
Install Ignition in the target production GW server. Select the same modules you selected in development (should be the set you intend to license). Add any extra modules you need that aren't part of the installer.
Take a gateway backup from your dev/test environment. Restore into your production GW. If you didn't mirror IP addresses or DNS names in your dev environment, you will need to fix all that in your new-restored GW. Do the database connection first.
Connect clients and/or designers to the production GW.
2 Likes
One other thing we've done, at @pturmel's suggestion, is to use /etc/hosts records on the gateway host as a way to address all other hosts (PLCs, databases, etc). Of course it would be ideal to have full DNS, but the /etc/hosts method at least allows you to have the same hostname pointing to a prod device/db from a prod gateway, and dev/sim device/db from a dev gateway.
1 Like
@pturmel how can I change the Ignition gateway IP to that of my PC instead of localhost to make it accessible to other devices within the same network?
Ignition listens on all of the IP addresses in your machine. Whether other machines in your network can reach via one of them depends on your machine's firewall. (But the better answer is to not run any Ignition gateway directly in your machine.)
1 Like
@pturmel
How significant of a concern is assigning a publicly accessible IP to a SCADA system? Must SCADA systems be deployed and hosted on an external platform to make them accessible outside the LAN?
Huge.
You can do this, but you'd better have every security "i" dotted and "t" crossed.
Best is to publicly expose a proxy which then forwards only the necessary client URLs to the actual Ignition server. Maintenance and management and design would remain local, or accessed via VPN.
5 Likes
when promoting new/edited resource (DB, Views, Tags, Scripts etc) from Dev->Test->Production
What is the best culture to follow?
Do you use an external tool, tracker to note down the changes, and COPY those changes to test and production?
I am not a DB guy, but how do they track changes made from Dev DB to Prod DB? any insight?