Redhat发布的10 things to avoid in docker containers对于构建基于Container的服务非常有意义。摘录如下：
- Don’t store data in containers – A container can be stopped, destroyed, or replaced. An application version 1.0 running in container should be easily replaced by the version 1.1 without any impact or loss of data. For that reason, if you need to store data, store it in a volume, but take care if two containers write data on the same volume because it could cause corruption. Make sure your applications are designed to write to shared data stores.
- Don’t ship your application in two pieces – As some people see containers as a virtual machine. Most of them tend to think that they should deploy their application in existing running containers. That can be true during the development phase where you need to deploy and debug continuously; but for a continuous deployment (cd) pipeline in QA and production, your application should be part of the image. Remember: Containers should be immutable.
- Don’t create large images – A large image will only make it hard to distribute. Make sure that you have only the required files and libraries to run your application/process. Don’t install unnecessary packages or run “updates” (yum update) during builds.
- Don’t use a single layer image – To have a more rational use of the layered filesystem, always create your own base image layer for your OS, another layer for the security and user definition, another layer for the lib installation, another layer for the configuration, and finally another layer for the application. It will be easy to recreate and manage an image, and easy to distribute.
- Don’t create images from running containers – In other terms, don’t use “docker commit” to create an image. This way to build an image is not reproducible and it’s not versionable, and should be completely avoided. Always use a Dockerfile or any other S2I (source-to-image) approach that is totally reproducible.
- Don’t use only the “latest” tag – The latest tag is just like the “SNAPSHOT” for Maven users. Tags are encouraged to be used specially when you have a layered filesytem. You don’t want to have surprises when you build your image 2 months later and figure out that your application can’t run because a top layer was replaced by a new version that it’s not backward compatible or because a wrong “latest” version is in the build cache. The latest should also be avoided when deploying containers in production.
- Don’t run more than one process in a single container – Containers are perfect to run a single process (http daemon, application server, database), but if you have more than a single process, you will have troubles to manage, get logs, and update them individually.
- Don’t store credentials in the image. Use environment variables – You don’t want to hardcode any username/password in you image. Use the environment variables to get that information from outside the container. A great example for it is the postgres image.
- Run processes with a non-root user – “By default docker containers run as root. (…) As docker matures, more secure default options may become available. For now, requiring root is dangerous for others and may not be available in all environments. Your image should use the USER instruction to specify a non-root user for containers to run as”. (From Guidance for Docker Image Authors)
- Don’t rely on IP addresses – Each container have their own internal IP address and it could change if you start and stop it. If your application or microservices needs to communicate to another container, use any names and/or environment variables to pass the proper information from one container to another.