6 ms·

> Don’t store data in containers You could manage your own data volumes or else let docker do it for you. I don't see the difference. In the end, you will stil

by gizi 11y ago

> Don’t store data in containers You could manage your own data volumes or else let docker do it for you. I don't see the difference. In the end, you will still need a backup policy. I snapshot all data every 30 minutes for storage on another device. Nothing would change to that policy when using external data containers. > Don’t ship your application in two pieces Internally -and externally provided software have different dynamics. Issues are different. I update my own software with bug fixes and new features quite frequently. I don't need to do that for externally provided software. If that happens, I will indeed rebuild the container. In all practical terms, my own software sits in a host folder where I can update it, without rebuilding the container. > Don’t use only the “latest” tag I use debian:latest. I don't see a problem with that. It may lead to trouble some day, but then I just change the tag to the latest but one version before rebuilding. The problem has not occurred up till now. > Don’t run more than one process in a single container I have containers that internally queue their tasks. The queue processor is then a second process, besides the main network listener process. There are many reasons why it could be meaningful for a program to use more than one process. A categorical imperative in this respect is misguided. Other engineering concerns will take precedence. You see, if I can reasonably split a container into two, I will. It's just like with a function. If it is possible to split it in two, I will most likely do so. But then again, such design recommendation should never be phrased as a categorical imperative. > Don’t store credentials in the image. Use environment variables 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. > Containers are ephemeral A network-based service uses a long-running listener to process requests. Why shut it down? That would just disrupt the service. Containers may very well be long-lived. They are not necessarily ephemeral. This subject is not part of a domain such as morality where categorical imperatives are the norm. There are pretty much no categorical imperatives in software engineering. Software is mostly subject to just an Aristotelian non-contradiction policy. If your choices are non-contradictory, feel free to go with them. Furthermore, unmotivated, categorical imperatives simply have no place in this field.

jarfil 11y ago
> Containers are ephemeral It doesn't matter how long they are up, it means you should expect them to go down at any moment and lose all data stored inside. Plan for it by storing your data and config somewhere else. * Custom volumes and system mounts are persistent. * Images are persistent-ish, they get replaced by updates. * Containers are ephemeral, intended to scale up, down, sideways or whatever. > Don't store data in containers As stated above, you should expect your containers to puff out and into thin air at any moment. Also remember that docker auto-created volumes get auto-deleted when no more containers are using them. Use custom created volumes or system mounts if you don't want to wake up to a nasty surprise. > Don’t use only the “latest” tag It will bite you in the ass if you do. It may not today, nor tomorrow, but it will some day, the exact day that a bigger version upgrade happens. It's not a "hasn't happened to me yet, so it may not happen" thing, it will happen to you if you keep using the "latest" tag, no doubts about that. So just plan accordingly and don't use the "latest" tag (for deployment). > Don’t run more than one process in a single container This could be more of a "really try not to" than a "don't", but the truth is the more stuff you put in a single container, the harder it becomes to manage and scale. It is much better to have self-contained containers (see what I did there?) that you can match and mix with stuff like docker-compose. > Don’t store credentials in the image. Use environment variables No, they are not the same problem, and it has nothing to do with security. When you want to scale and spin up a new container... now you can't because your credentials are baked into the image. Don't store credentials in the image, period. If you don't like environment variables, you could mount a per-container config dir, but it's usually much easier to manage config passed as environment variables to the container.
- mateuszf 11y ago
  > No, they are not the same problem, and it has nothing to do with security. When you want to scale and spin up a new container... now you can't because your credentials are baked into the image. Another reason - once image is built - why rebuilding it? There is always a chance that you will end up with different versions of os or your packages. Immutable image which doesn't store credentials can be used on multiple environments with different credentials / configurations without changing / rebuilding the image.
notatoad 11y ago
If you store data in containers, update your application inside the container, and treat them as long-running persistent entities, then what benefit are you getting out of a container? You're essentially treating a container like a vps, so why not just run your app directly on a vps?
- tonyarkles 11y ago
  Performance? You're now running on a non-virtualized platform that doesn't have virtualized hardware.
curun1r 11y ago
> 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.
- derFunk 11y ago
  Yet beside Docker's :latest tags also using "FROM xy:latest" is a very bad practice and should be avoided. Always stick to one certain version of the dependencies you're having and you should be safe that you're getting the reproducible behaviour you're expecting to get when creating your containers. (of course if the base image is yours then you might be knowing that using :latest is well tested and safe)

by gizi 11y ago

jarfil 11y ago

> Containers are ephemeral It doesn't matter how long they are up, it means you should expect them to go down at any moment and lose all data stored inside. Plan for it by storing your data and config somewhere else. * Custom volumes and system mounts are persistent. * Images are persistent-ish, they get replaced by updates. * Containers are ephemeral, intended to scale up, down, sideways or whatever. > Don't store data in containers As stated above, you should expect your containers to puff out and into thin air at any moment. Also remember that docker auto-created volumes get auto-deleted when no more containers are using them. Use custom created volumes or system mounts if you don't want to wake up to a nasty surprise. > Don’t use only the “latest” tag It will bite you in the ass if you do. It may not today, nor tomorrow, but it will some day, the exact day that a bigger version upgrade happens. It's not a "hasn't happened to me yet, so it may not happen" thing, it will happen to you if you keep using the "latest" tag, no doubts about that. So just plan accordingly and don't use the "latest" tag (for deployment). > Don’t run more than one process in a single container This could be more of a "really try not to" than a "don't", but the truth is the more stuff you put in a single container, the harder it becomes to manage and scale. It is much better to have self-contained containers (see what I did there?) that you can match and mix with stuff like docker-compose. > Don’t store credentials in the image. Use environment variables No, they are not the same problem, and it has nothing to do with security. When you want to scale and spin up a new container... now you can't because your credentials are baked into the image. Don't store credentials in the image, period. If you don't like environment variables, you could mount a per-container config dir, but it's usually much easier to manage config passed as environment variables to the container.

mateuszf 11y ago
> No, they are not the same problem, and it has nothing to do with security. When you want to scale and spin up a new container... now you can't because your credentials are baked into the image. Another reason - once image is built - why rebuilding it? There is always a chance that you will end up with different versions of os or your packages. Immutable image which doesn't store credentials can be used on multiple environments with different credentials / configurations without changing / rebuilding the image.

notatoad 11y ago

If you store data in containers, update your application inside the container, and treat them as long-running persistent entities, then what benefit are you getting out of a container? You're essentially treating a container like a vps, so why not just run your app directly on a vps?

tonyarkles 11y ago
Performance? You're now running on a non-virtualized platform that doesn't have virtualized hardware.

curun1r 11y ago

> 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.

derFunk 11y ago
Yet beside Docker's :latest tags also using "FROM xy:latest" is a very bad practice and should be avoided. Always stick to one certain version of the dependencies you're having and you should be safe that you're getting the reproducible behaviour you're expecting to get when creating your containers. (of course if the base image is yours then you might be knowing that using :latest is well tested and safe)