Licenses being removed with a docker compose down

Hi all,

I recently posed a question here about storing python scripts in the system and doing a docker mount. That is all fixed now and we are storing our custom scripts in user-lib/pylib/site-packages - thanks for the help!

The other thing we noticed during this period is that after a docker-compose down any licenses we had installed on the GW were lost and had to be re-added when we reinstalled the modules. Is there any way to persist the license files if we need to take the containers down for some reason? I'm not even sure where the licenses are installed!

Thanks for any help

NO.

You must use lease licenses (8-character, with continuous internet access for rechecking) instead of standard (6-character, with no internet necessary after activation).

To add to this, there is a video in the elective course for Ignition with Docker that talks about licenses.

2 Likes

Thanks all - this clears it all up.

1 Like

Hi @pturmel,

Can you please advise if your Advanced Modbus driver needs to be deactivated and reactivated between container upgrades (as per the main ignition license)?

Or does your license survive a container upgrade?

Cheers,
Ben

Same behavior as IA's licenses, as it uses IA's licensing infrastructure. You should use 8-character leased licenses with container technology.

Except our systems are air-gapped.

Thanks for the answer :+1:

Containerization seems to be a poor choice, then.

1 Like

It actually works really well.

We build the container image into a tarball using podman pull and podman save on an internet connected machine, transfer that tarball into the OT environment as we would any installer, and then use podman load to import the tarball as an image on the air-gapped machine.

We’ll just incorporate license deactivation and reactivation into our upgrade procedures.