Docker Image
💡Have feedback for this page? Let us know on the IA Forum.
The Ignition Platform offers a container image for use on popular container runtimes such as Docker. You can find the image on Docker Hub at https://hub.docker.com/r/inductiveautomation/ignition. Our official image is a Linux container, based on Ubuntu Linux.
Ignition's Docker Image build is multi-architecture and supports linux/amd64, linux/arm64, and linux/arm/v7. Users can docker pull inductiveautomation/ignition and get an image that automatically matches their system architecture.
Getting Started
To get started with Ignition running as a container, you'll need a container runtime. Docker Desktop, available for Windows and macOS, includes both the Docker Engine container runtime as well as container tooling and supporting tools such as Docker Compose. If you are running Linux, you'll need to download and install the container runtime and tools such as Docker Compose individually. Guidance for the installation and configuration of Docker (on all platforms) are available here: Get Docker
Configuration
Various aspects of the Ignition Gateway can be configured through the use of either command-line arguments to the container or environment variables. This section will detail the available configuration options and how best to use them.
Environment Variables
The available environment variables can either accept explicit values or load the target values from a file. Specifying any of the environment variables below with a _FILE suffix will direct the system to take that environment variable value as a path to a file containing the value of interest. This is useful for secrets management systems when you want to keep the values out of the process environment, where individuals with access to docker inspect <container> might be able to see the values.
Some of the variable descriptions below make use of a # character. In these cases, you can specify the same variables multiple times by replacing the # character with a new number for each use.
GATEWAY_NETWORK_0_HOST=1.2.3.4
GATEWAY_NETWORK_0_PORT=8088
GATEWAY_NETWORK_0_DESCRIPTION="For tag server"
GATEWAY_NETWORK_1_HOST=5.6.7.8
GATEWAY_NETWORK_1_PORT=8089
GATEWAY_NETWORK_1_DESCRIPTION="For edge server"
The table below describes the environment variables exclusive to Docker. For a full list of environment variables supported by the Ignition platform, see the Platform Environment Variables reference page.
| Environment Variable | Description |
|---|---|
GATEWAY_RESTORE_DISABLED | Set to true to have the restored gwbk disabled on startup. |
IGNITION_UID | Numeric user ID for the target user. Passing this variable and IGNITION_GID allows Ignition to run within a container as an ignition user rather than as the root user. When set, the entrypoint will automatically update file ownerships for the Ignition installation on startup to match the target user prior to stepping down from the root user to launch the Gateway. |
IGNITION_GID | Numeric group ID for the target user. Passing this variable and IGNITION_UID allows Ignition to run within a container as an ignition user rather than as the root user. When set, the entrypoint will automatically update file ownerships for the Ignition installation on startup to match the target user prior to stepping down from the root user to launch the Gateway. |
Module Identifiers Table
Module identifiers are used by Ignition to search and find modules. The module identifiers listed below represent the modules that are built-in with the container image. These modules are saved in the /usr/local/bin/ignition/user-lib/modules folder. Any third party modules installed through the Gateway will be saved in the /usr/local/bin/ignition/data/local/modl folder. This third party folder location is defined by the ignition.gateway.externalModulesFolder system property.
Ignition will still include the module identifiers listed in version 8.1 when attempting a search, but it is recommended to use the full module identifiers listed in the table below.
| Module Identifier | Module Filename |
|---|---|
| com.inductiveautomation.alarm-notification | Alarm Notification-module.modl |
| com.inductiveautomation.opcua.drivers.ablegacy | Allen-Bradley Drivers-module.modl |
| com.inductiveautomation.opcua.drivers.bacnet | BACnet Driver-module.modl |
| com.inductiveautomation.opcua.drivers.dnp3 | DNP3-Driver.modl |
| com.inductiveautomation.opcua.drivers.dnp3v2 | DNP3-Driver-v2.modl |
| com.inductiveautomation.eam | Enterprise Administration-module.modl |
| com.inductiveautomation.eventstream | EventStream-module.modl |
| com.inductiveautomation.historian | Historian-module.modl |
| com.inductiveautomation.opcua.drivers.iec61850 | IEC 61850 Driver-module.modl |
| com.inductiveautomation.connectors.kafka | Kafka Connector-module.modl |
| com.inductiveautomation.opcua.drivers.logix | Logix Driver-module.modl |
| com.inductiveautomation.opcua.drivers.micro800 | Micro800 Driver-module.modl |
| com.inductiveautomation.opcua.drivers.mitsubishi | Mitsubishi-Driver.modl |
| com.inductiveautomation.opcua.drivers.modbus | Modbus Driver v2-module.modl |
| com.inductiveautomation.connectors.mongodb | MongoDB Connector-module.modl |
| com.inductiveautomation.opcua.drivers.omron | Omron-Driver.modl |
| com.inductiveautomation.opcua | OPC-UA-module.modl |
| com.inductiveautomation.perspective | Perspective-module.modl |
| com.inductiveautomation.reporting | Reporting-module.modl |
| com.inductiveautomation.sfc | SFC-module.modl |
| com.inductiveautomation.opcua.drivers.siemens | Siemens Drivers-module.modl |
| com.inductiveautomation.opcua.drivers.siemens-symbolic | Siemens S7 Symbolic Driver-module.modl |
| com.inductiveautomation.sms-notification | SMS Notification-module.modl |
| com.inductiveautomation.sqlbridge | SQL Bridge-module.modl |
| com.inductiveautomation.historian.sql | SQL Historian-module.modl |
| com.inductiveautomation.symbol-factory | Symbol Factory-module.modl |
| com.inductiveautomation.opcua.drivers.tcpudp | UDP and TCP Drivers-module.modl |
| com.inductiveautomation.vision | Vision-module.modl |
| com.inductiveautomation.phone-notification | Voice Notification-module.modl |
| com.inductiveautomation.webdev | Web Developer Module.modl |
Runtime Arguments
The following options and flags are accepted by the container as runtime arguments. Options should be followed by a value, while flags are stand-alone. Note that these arguments are passed after the image name in a Docker Run statement.
Options
| Option | Requires | Arguments |
|---|---|---|
-n | String | Gateway name to be applied to the Ignition Gateway on startup |
-a | String | Public web address* |
-h | Integer | Public HTTP port* |
-s | Integer | Public HTTPS port* |
-m | Integer | Max memory for JVM |
-r | String | Path to Gateway Backup for Automated Restore |
* Specify Public address/HTTP/HTTPS ports together, all three must be specified
Flags
| Flag | Description |
|---|---|
-d | Debug mode, applicable to development and attaches port 8000 for remote JVM debugging. Note that port 8000 may need to be published on the container. |
Supplemental JVM and Wrapper Arguments
You can also specify JVM and Java Service Wrapper arguments to your Docker containers runtime arguments by adding a double-hyphen to delimit these arguments from the other runtime arguments listed above. Wrapper arguments (starting with wrapper.* ) will be merged and JVM arguments will be added to those specified in the ignition.conf file. Refer to Customizing JVM/Wrapper/Gateway Arguments on Container Launch for an example.
A couple parameters to be aware of are the Leased Licensing Parameters. Since leased activation license session termination on shutdown is necessary to ensure the session is returned to the activation server, these allow you to modify your session termination settings.
Gateway Arguments
The image also supports the use of Gateway arguments, allowing you to modify the gateway.xml file when launching a container. Like JVM and wrapper arguments, Gateway arguments must be specified after a double-hyphen. Only entries in the file that follow the pattern of gateway.# can be modified in this way.
Logging Settings
Unlike the non-containerized version of Ignition, the Ignition container image is designed to emit logs to stdout (“standard out”) so they can be leveraged by various logging drivers in the container engine. This is done by directing what would normally be stored in the logs/wrapper.log file to stdout. As a result, Ignition itself doesn’t control rotating the wrapper.log based on size, which can result in container logs growing unbounded. You can configure the default logging driver to constrain maximum log sizes. Reference the Docker logging configuration page to specify logger size limits.
Licensing
The Inductive Automation software contained in this Docker container image is licensed under the terms of the Inductive Automation Software License Agreement.
By passing the environment variable value ACCEPT_IGNITION_EULA=Y, you agree that your use of Inductive Automation software running in this Docker container image is governed by the terms of the Inductive Automation Software License Agreement.
All third party software (whether open or closed) running in this Docker container image is licensed as indicated in this Docker Hub “License” section or in the container itself, usually as a NOTICE or LICENSE file. You agree to comply with any relevant licenses for third party software contained in this Docker container image.
Examples
Refer to the Docker Image Examples page to learn more about how to run and configure the Ignition Docker image, as well as some standard best practices.