We have been using the Ignition Docker images, and it’s been great to use them.
However, there is one issue we want to highlight. We have installed the container just like the manual suggests, with volume in place.
With that volume, we manage to save almost every data on our gateway, except for one thing, the installed modules.
The modules always reset to the default installation modules.
So f.e. we also have the MQTT Engine module, but when we create a new container with our stored Volume, de MQTT Engine is not installed anymore. Also modules we don’t use and where uninstalled, are back. When we install MQTT Engine module again, all our module settings are being restored though.
Is there another volume we should create? Or is this something IA is aware of and is fixing?
We found it strange that nothing of this was documented.
I had the same problem but I was able to get around it by updating my Docker compose file to copy the external modl file into the container. This is what I did…
This copies the module file from my host into the container. It works, I can see the Apex Charts module in the my Docker container after any restart or creation of the container.
Hey All,
I know this is an older thread but one of the last comments from 2022 states that this is being worked on as a possible feature, maybe. Does anyone know if this has been released? I am using Azure IoT Hub to deploy a container (Azure calls it a Module). I can pass environment variables and adjust a runtime config with other settings like gateway name, jvm memory, port assignment, and volume persistence. However, when it comes to 3rd party modules, I have not found a way to do this. Full disclosure, the device I deploy to is essentially a black box, so I have to rely on my config from Azure to do all the work. So, I do not have the option of drilling in locally and running CLI to make any adjustments. Other than not being able to persist my 3rd party modules, this solution has been working really well.
@kcollins1 can verify, but if the ticket I'm looking at is the right one, then no it hasn't been released. It looks like right now the target is to release this alongside Ignition 8.3, late next year.
@kcollins1 any good advice on how I can accomplish this manually with my current setup? I will gladly share any information you would like and I am very open to suggestions. I am especially open to suggestions if the approach we are taking to deploy Ignition containers is not a great idea.
I can gladly take my thoughts to another thread if that is a better option to discuss this in more detail.
It is true that we're planning on reworking how modules can be loaded with the 8.3 container image. Currently, Ignition modules get installed in user-lib/modules, alongside the ones that are built into the image. This causes some complications with separating gateway state data (i.e. our data folder) from the image. If you install a third-party module through the web UI, then it gets placed in user-lib/modules and things will appear to be working fine until that container is replaced (i.e. from an upgrade or any number of other events that could happen within a given orchestrator (such as Azure IoT Edge Runtime)).
The best solution (and it is a perfectly fine one) is to utilize a derived image. I maintain some useful examples here, but you don't necessarily need anything super-complex. You could do something as simple as with the following Dockerfile, for example:
FROM inductiveautomation/ignition:8.1.30
COPY --chown=ignition:ignition my-module-in-local-folder.modl ${IGNITION_INSTALL_LOCATION}/user-lib/modules/
# Optionally pre-load the set of built-in modules that will be enabled
# so they don't revert to the full set on container lifecycle events.
ENV GATEWAY_MODULES_ENABLED=enterprise-administration,logix-driver,opc-ua,perspective
Build and then push that image to a container registry (i.e. an Azure Container Registry for your IoT Edge deployments) and use that for your deployment configuration.
Thank you for all of that useful information! I have been trying to learn container deployments, but things don't always click all the time in my head. I had felt pretty comfortable using Docker Desktop with yaml files but now that we moved to Azure IoT Hub its like I'm starting over. The way we built the deployment is to use/pull the Ignition image from docker hub and then pass in environment variables and runtime arguments. I have a few screenshots below that highlight this method. Are you suggesting that we can modify the runtime arguments to accomplish this or do a different route? Thanks in advance!
You're welcome! See also this ICC session from last year for some more details on various aspects of interest.
I'm suggesting that you'd use a different image URI than docker.io/inductiveautomation/ignition:x.y.z; one that has been customized with the additional [modl] files/configuration you need.
Ahhh, I see. I don't know if I am savvy enough to make a custom image (unless I am downplaying my knowledge of this technology). Would you recommend that I call up my IA Account Manager to get me in touch with an IA resource or should I reach out to an Ignition integrator? I know that IA usually has customers work with integrators on specific use cases and deployments but wasn't sure if this could be discussed on a broad enough level with IA Support.
There are some efforts underway for improving third-party module support in the container image. However, for 8.1.x, the path forward is still as described above, a custom derived image with your third-party modules added in. Keep in mind that the GATEWAY_MODULES_ENABLEDenvironment variable is already there for defining which built-in modules you want to have loaded on container start.
