You can deploy an operating system, use the package manager to install software, use a configuration management system to… manage configurations… and you can do so to a piece of hardware or a virtual machine.

It’s really tempting to clone the VM, file off the serial numbers and use it again. That might be OK.

Containers spin up faster than VMs, and once you have a container image, well, it’s just jumping up and down telling you that you should copy it and send it off to a thousand happy servers to run on each of them. And that could be OK…

Then someone has the nifty idea that they will offer you their application all nicely bundled up inside a container image. All the dependencies are sealed inside! They just work! Even if they conflict with something else on your base system or in another container!

And that’s just wrong. Don’t do that.

Because the container image that they offer you does not tell your system how to re-create it, and it hides all the dependencies away inside. All the dependencies are there, of course. And when your HTML-to-PDF printer uses a fat lot of code from six projects to do the job, you will have no idea that it is using the flawed regexp lib that gives root control for a buffer overflow.

Do not deploy images that you don’t understand, do not deploy images that you cannot recreate, and most of all, beg your container system to establish a notification system so that you have a bare chance of staying ahead of the wolves.