> I use debian:latest. I don't see a problem with that. That's not the advice he was giving. He was talking about tagging the images you create. If you always

> I use debian:latest. I don't see a problem with that. That's not the advice he was giving. He was talking about tagging the images you create. If you always use latest, you're not keeping a history of images in your registry that allows for easy rollbacks. Latest is an entirely appropriate tag to use so long as it's always a synonym for some other longer-lived tag. > There are many reasons why it could be meaningful for a program to use more than one process. There are, but there are people (like Phusion) that want to run lots of processes inside a container. That is, IMHO and that of the story author, a bad idea. I may be more lenient than the author, but I believe a single container should represent a single logical process, whether that makes to a single OS process or not. But when you have many distinct logical tasks, they should be separated into their own containers. > Both are pretty much the same problem. If the attacker can read files containing credentials, he will also be able to read environment variables with them. This is very, very wrong. Credentials stored inside the image are less flexible and stored in more places than credentials that are supplied as environment variables. Images are designed to be copied around easily and trying to add authorization to the copying process is never going to be particularly successful. In contrast, credentials supplied as environment variables only live on the machine that's running the container and are only visible to those with access to the machine. > A network-based service uses a long-running listener to process requests. Why shut it down? Because software is constantly changing. At my last job, we released many times per day. Trying to patch a running container is just a recipe for pain. It's much simpler to start new containers and kill the old ones. You can even do it without downtime if you've got a system to route to the correct container (something like a long-lived HAProxy process that watches etcd/consul for the container it should route to. More and more, the notion of a non-distributed system is becoming obsolete. And the one lesson I've learned about distributed systems is that state is what makes them hard and you have to be incredibly intentional about how you manage your state. This also means that any time you can avoid adding state, be it in code or infrastructure, you should avoid doing so. Ephemeral, immutable containers follow that philosophy.