Things to avoid in Docker containers
&gt; Don’t store data in containers<p>You could manage your own data volumes or else let docker do it for you. I don&#x27;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.<p>&gt; Don’t ship your application in two pieces<p>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&#x27;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.<p>&gt; Don’t use only the “latest” tag<p>I use debian:latest. I don&#x27;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.<p>&gt; Don’t run more than one process in a single container<p>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.<p>You see, if I can reasonably split a container into two, I will. It&#x27;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.<p>&gt; Don’t store credentials in the image. Use environment variables<p>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.<p>&gt; Containers are ephemeral<p>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.<p>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.