Hi,
does anyone have experience with ignition docker container in production environment?
Is it stable?
Is it durable?
Regards
I’d say that it isn’t much different than running Ignition on a bare Linux host… There are some aspects that you do need to think a little differently on, especially pertaining to aspects of your Ignition installation that might place content outside of your data volume. These are situations where you might consider having a derived image to package in known libraries (as one example).
As far as licensing goes, if you bind-mount /bin from your host into /bin in the container (I’d recommend a read-only mount, too), you’ll be able to successfully license the gateway in the container and survive image upgrades. This is due to utilizing the inode number and change time of the /bin folder for the licensing. These will change [in the container filesystem] with a new docker pull (even of the same image, since it has to do with those files being created on the filesystem when you download an image). By bind-mounting that path against the host, licensing will remain intact since the containers view of /bin will remain constant.
If you’re going to deploy on Docker Engine, I’d recommend looking at enabling live-restore (docs here in the daemon configuration to help keep containers running through something like a Docker Engine restart.
As to the rest of things, general security practices and backup strategies still apply–those don’t go away from leveraging some of the convenience aspects of Docker for the runtime.
Ewww. That will put a bunch of unneeded executables in the container. Possibly mismatched to container libraries, which can create vulnerabilities on top of the simple presence of unwanted suid items. Not good.
Not good, indeed.. But, the only option available right now, unfortunately.
So, host all of your containers in a stripped-down machine or VM. Noted.
At the very least, /bin is a sym-link /usr/bin in ubuntu:20.04 (the base image for both kcollins/ignition and inductiveautomation/ignition images). I just took a look and it appears that I’ve updated the entry point and associated scripts in inductiveautomation/ignition to use a #!/usr/bin/env bash shebang to ensure that PATH is used for resolving bash. This will at least help with version contention within this /bin mount situation. Seems like removing /bin from PATH altogether is probably a reasonable thing to consider too. Doesn’t solve the problem, but helps keep it from getting in the way in strange ways in normal scenarios.
1 Like
that's a lot of useful informations.
thanks for that.
i think i will push toward to install the gateway directly on the host.
Any idea when this licensing problem could be solved?
regards