Adult Containers (Part 03): 10 Things You Should Not Do with Containers
You finally surrendered to the mercy of containers and found that they solve a lot of problems and have a lot of advantages:
However, many still believe that containers are virtual machines, and forget about their most important feature ...
Disposability is why you need to change your approach to how to handle containers.
And here’s what you shouldn’t do in any case, so as not to lose the advantages of containers:
1. No need to store data inside the container. During the life cycle of containers can be suspended, destroyed, replaced. If the application runs in a container, then version 1.0 of this application should be easily changed to version 1.1 without data loss and other troubles. Therefore, if you want to save data, you need to write them on that. However, then you need to take care that the two containers are not written in the same place, so as not to damage the data. So, check that applications correctly write data to the shared storage.
2. Do not crush the delivery of applications.Some people think that the container is the same virtual machine. And most of them believe that applications should be deployed in existing existing containers. In fact, this is also possible, especially in the development phase, when there is a constant debugging and deployment. However, applications should only arrive on the CD conveyor for continuous delivery to the QA department or in production as part of their own image. Remember: containers are immutable.
3. Do not create large images. Large image is more difficult to distribute. Therefore, only those files and libraries that are really needed to start the application process should be included in the image. No need to install unnecessary packages or run updates (yum update), which create a new layer in the image and write a lot of files to it.
4. Do not use single-layer containers. To effectively use multi-layer (multi-level) file systems, always create separate layers for the OS, for username definition, for configuration, and finally, for the application itself. So it will be easier to recreate, accompany and distribute images.
5. No need to create images from running containers. In other words, do not use the docker commit command to create an image, since such images will not be reproducible. Instead, always use Dockerfile or other S2I tools (source-to-image) that provide reproducibility. In addition, you can easily track changes in the Dockerfile by storing it in the source repository (git).
6. Do not use only the latest tag.This tag is something like SNAPSHOT for Maven users. Due to the multi-layered file system of containers, tags are very useful. However, you may be in for an unpleasant surprise when, for example, after a break of many months, you decide to build an image and suddenly find that the application does not start anymore, because the parental layer (FROM in Dockerfile) has been replaced by a new version that does not support backward compatibility. Or because the latest version that you were waiting for was removed from the build cache. In addition, the latest tag should also be avoided when deploying containers in production, since you cannot track which version of the image is running.
7. Do not run more than one process in a container.Containers are ideally suited to perform one process (http daemon daemon, application server, DBMS). Otherwise, you may encounter all sorts of troubles, such as digging into logs or updating processes separately.
8. No need to store credentials in the image - use for this environment variables. Do not write in the image of any usernames and passwords. Instead, use environment variables to pull relevant data from sources external to the container. The Postgres image is a great example of how to do this correctly.
9. No need to run processes as root.“By default, docker containers run as root. (...) However, as technology evolves, other, safer default launch options may appear. In modern conditions, the requirement of root rights can be regarded as a threat and not available in all environments. To specify a user other than root, on behalf of which the container will be launched, the USER directive is used. (Excerpt from Guidance for Docker Image Authors)
10. Do not rely on IP addresses. Each container has its own internal IP address, which may change after the container is restarted. If an application or microservice needs to communicate with another container, use environment variables to transfer the desired host name to the port number from one container to another.
Remember? Now you can safely use. And practical advice on the use of containers can be found in our blog.
- Containers are unshakeable: OS, libraries, folders and applications - since everything is stored directly in the container, you are 100% sure that production will always be exactly the image that was tested in QA. And it will work at the same time absolutely similarly.
- Containers are lightweight: The container does not eat wasted memory. Instead of hundreds of megabytes and gigabytes, the container only needs memory for the main process.
- Containers are fast: The container runs as fast as a regular Linux process. Not minutes, but literally seconds.
However, many still believe that containers are virtual machines, and forget about their most important feature ...
Containers are ephemeral
Disposability is why you need to change your approach to how to handle containers.
And here’s what you shouldn’t do in any case, so as not to lose the advantages of containers:
1. No need to store data inside the container. During the life cycle of containers can be suspended, destroyed, replaced. If the application runs in a container, then version 1.0 of this application should be easily changed to version 1.1 without data loss and other troubles. Therefore, if you want to save data, you need to write them on that. However, then you need to take care that the two containers are not written in the same place, so as not to damage the data. So, check that applications correctly write data to the shared storage.
2. Do not crush the delivery of applications.Some people think that the container is the same virtual machine. And most of them believe that applications should be deployed in existing existing containers. In fact, this is also possible, especially in the development phase, when there is a constant debugging and deployment. However, applications should only arrive on the CD conveyor for continuous delivery to the QA department or in production as part of their own image. Remember: containers are immutable.
3. Do not create large images. Large image is more difficult to distribute. Therefore, only those files and libraries that are really needed to start the application process should be included in the image. No need to install unnecessary packages or run updates (yum update), which create a new layer in the image and write a lot of files to it.
4. Do not use single-layer containers. To effectively use multi-layer (multi-level) file systems, always create separate layers for the OS, for username definition, for configuration, and finally, for the application itself. So it will be easier to recreate, accompany and distribute images.
5. No need to create images from running containers. In other words, do not use the docker commit command to create an image, since such images will not be reproducible. Instead, always use Dockerfile or other S2I tools (source-to-image) that provide reproducibility. In addition, you can easily track changes in the Dockerfile by storing it in the source repository (git).
6. Do not use only the latest tag.This tag is something like SNAPSHOT for Maven users. Due to the multi-layered file system of containers, tags are very useful. However, you may be in for an unpleasant surprise when, for example, after a break of many months, you decide to build an image and suddenly find that the application does not start anymore, because the parental layer (FROM in Dockerfile) has been replaced by a new version that does not support backward compatibility. Or because the latest version that you were waiting for was removed from the build cache. In addition, the latest tag should also be avoided when deploying containers in production, since you cannot track which version of the image is running.
7. Do not run more than one process in a container.Containers are ideally suited to perform one process (http daemon daemon, application server, DBMS). Otherwise, you may encounter all sorts of troubles, such as digging into logs or updating processes separately.
8. No need to store credentials in the image - use for this environment variables. Do not write in the image of any usernames and passwords. Instead, use environment variables to pull relevant data from sources external to the container. The Postgres image is a great example of how to do this correctly.
9. No need to run processes as root.“By default, docker containers run as root. (...) However, as technology evolves, other, safer default launch options may appear. In modern conditions, the requirement of root rights can be regarded as a threat and not available in all environments. To specify a user other than root, on behalf of which the container will be launched, the USER directive is used. (Excerpt from Guidance for Docker Image Authors)
10. Do not rely on IP addresses. Each container has its own internal IP address, which may change after the container is restarted. If an application or microservice needs to communicate with another container, use environment variables to transfer the desired host name to the port number from one container to another.
Remember? Now you can safely use. And practical advice on the use of containers can be found in our blog.