New installed module in Ignition 8.1.5 docker container is gone after container reboot

Ignition
1

I am running ignition 8.1.5 in docker on MacOS Mojave, with a named volume attached to /usr/local/bin/ignition/data within the container.

Today I was successfully installed MQTT distributor module, however this module go away after container reboot, I guess attach /usr/local/bin/ignition/data folder is not enough, any workaround?

2

Modules are located in /usr/local/bin/ignition/user-lib/modules/ by default.

3

It’s works, it would be wonderful to update the doc in docker hub as well (Docker Hub)

4

We have a ticket in the works for better support of third-party modules in a container. Currently the system locates all modules at /usr/local/bin/ignition/user-lib/modules/, like @paul-griffith mentioned. Choosing the /usr/local/bin/ignition/data/ path for your named volume is the correct strategy for preserving gateway state. The user-lib/modules should stay “with” the image (of version 8.1.5, for example) so that you can upgrade your deployment by just swapping image versions (and keeping your data volume).

The best method right-now is to bind-mount the module directly into /usr/local/bin/ignition/user-lib/modules. See the example screenshot below:

2021-06-04 at 5.43 PM
2021-06-04 at 5.43 PM851Ă—218 72.7 KB

Once you start your container with this setup, you’ll then need to go to the gateway webpage (Config->Modules) and accept the EULA and certificate to conclude the module installation. The good news is that with this strategy, you can still upgrade to newer versions by just stopping/removing this container, and starting a newer one (such as inductiveautomation/ignition:8.1.7) in its place against the same data volume.

Another alternative is to build your own derived image where you’ve copied that module into place. Then upgrading would simply be a matter of changing the FROM directive in the Dockerfile and then rebuilding your image, and then relaunching your container (again, still using your data volume).

2 Likes
5

@kcollins1 Has this been improved over the past few years?

The documentation here has no mention of the the technique you listed above, which may be easier for some.

Could the documentation be re-organized to have a section titled “How to preserve your state across container restarts” and include steps that are needed for all things that could get modified to persist across reboots?

For modules specifically, seems it would be best for Ignition to allow mounting docker volume against a directory for 3rd party modules to land in.

6

This is vastly improved with Ignition 8.3. Here are some feature highlights:

  • When running the container image, modules that are installed through the Web UI end up in a folder that is within the data volume (specifically, /usr/local/bin/ignition/data/var/ignition/modl).
  • If you happen to install a module with the same module ID as a built-in module, it will "shadow" the built-in module and load from your external folder. Note that in this situation, uninstalling the module will simply revert to the built-in module. This is probably a rare situation but perhaps worthy of mention.
  • Uninstallation of built-in images (located in the traditional location of /usr/local/bin/ignition/user-lib/modules) is blocked since these modules are part of the image itself.
  • Enable/disable of any module is persisted in the module configuration file under data/modules.json
  • If you’re using GATEWAY_MODULES_ENABLED env var, changes to enable/disable status of any module is blocked. Note: use of this var used to be required in order to keep built-in modules from popping back to life after container recreation, but that is no longer a problem.
  • There are new ACCEPT_MODULE_LICENSES and ACCEPT_MODULE_CERTS environment variables that will accept fully qualified module identifiers to automate module license/cert acceptance on startup.
    The module ID of a given module can be discovered with this helpful little shell snippet (substituting the path to your module file):
    unzip -c -q path/to/module.modl module.xml | \
  xmlstarlet sel -t -v "modules/module/id" -nl

The result is that you no longer need special handling for third-party modules. As long as you're persisting your data volume, module installations (that flow to that new folder) and enable/disable changes will stay put as expected, just like a traditional installation.

2 Likes