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.
> 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.
You can always add layer with new credentials. E.g.
FROM image:staging
COPY ./production-credentials/ /
When implemented in this way, staging image won't be able to run in production code until it will be tested and accepted (sealed) using formal process.
If you will use environment variables, you (or your deployment team) will be able to run staging images in production at any moment.
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.