Today I have a lot of good advice for people who are starting to work with containers and docker. The article is just part of a podcast in which I appeared as a guest.
○ For example, it's better not to use the latest tag we talked about earlier. The tags identify the version of the container image. When we create our image, we should use a specific base image tag, not latest, which gets us the latest available image. Do not get me wrong. There's nothing wrong with using the latest images, it's just a matter of controlling it. Otherwise, something may suddenly stop working for us. So we should update our images, but we should choose the specific version and time.
○ People often ask me how often they should update their containers. Well, I usually answer that as often as possible. Because new vulnerabilities are still being discovered and patched in new versions of containers on an ongoing basis. Therefore, if we want to take care of security, we should pay attention to newer versions of container images. Many companies automate updates on development environments or add a task in each sprint so that someone from the team takes care of updating the container or virtual machine image. Here you also have to remember to update the things that we add to our image. Often, private image repositories allow analysis of container images and automatically notify administrators when any vulnerabilities occur.
○ Another piece of advice is - it's worth looking for the smallest possible image so that it takes up as little space as possible and launches faster.
○ Surely you know git and you know what the .gitignore file is for, there is a file in the docker called .dockerignore and it allows the same, i.e. skipping files that we do not want to add to the image
○ Speaking of skipping files, of course, you shouldn't add any keys in the dockerfile, otherwise anyone who has access to the image will be able to read them.
○ Containers should also be monitored as we do with regular servers. Because we would like to know if our application is working properly or not? Well, at least I would :D
○ Container repositories often have the ability to scan images, but Docker itself also has this ability, we can use the docker scan command to find vulnerabilities
○ We should remember to open only necessary ports in containers.
○ We should remember about creating HealthChecks, so that when docker receives information about the bad state of the container, it should create a new one with the correct status
○ It's better not to store data in containers, it should be done on pinned volumes. Containers can be restarted, stopped or destroyed at any time and a newer version of the application should be able to run without any data loss.
○ In my opinion, it's best to create container images from Dockerfile, not using docker commit - i.e. from a working container. Creating an image from a Dockerfile enables easy tracking of changes and guarantees repeatability, which is not guaranteed by docker commit.
○ One main process should be running in one container, when you run more of them, they are harder to manage and you may have more problems because, for example, one process will stop working, the container will no longer work properly, but it will not detect it because the main process is still running correctly and the container does not know that it should restart.
○ Last but very important, remember to run your containers as a non-root user.
The article is just part of a podcast in which I appeared as a guest. More information can be found on my blog.
If you are interested in this article, please visit my blog lepczynski.it
You can also visit my YouTube channel Wojciech Lepczynski
Top comments (0)