Containers have the opportunity for developers to build predictable environments isolated from other applications. The application’s software dependencies can also be bundled in containers, such as particular versions of programming language runtimes and other software libraries. Apart from these reasons, several other reasons make containers a preferable option when you think of your cloud-native strategy.
As we went around, Containerization makes our life more comfortable, and to make your dev life a bit easier, following the best practices is one way to start.
In this post, we will go around few best practices in the industry and reasons you should consider these practices when you start or are in the middle of your cloud-native journey.
The list is not in any order of priority. Feel free to experiment or adapt any/all!
Choose Container Engine Properly
Choose the right container engine for your application based on the project and use cases; if you are not sure what the right container engine for your application would be, then it is good to go with the most common and popular one, i.e., Docker.
But don’t just choose Docker because someone says it, do your own analysis, and then select the right one for your project. Careful consideration helps you to minimize technical debt.
Keep Container Image Small
It’s generally preferable to have a small Docker Image, everyone agrees. To Keep images smaller:
- Use multi-stage builds (e.g. docker multi-stage build)
- Use smaller base image
- Avoid storing application data in your container’s writable layer. This is less efficient from an I/O perspective than using volumes or bind mounts, instead of storing data in external data storage (e.g. volumes in docker.) Also, this increases the size of your container.
- When building images, make sure that image only contain the appropriate packages, delete what is not required and always tag the image. The actual application output would be affected by running several processes within a single container, so build multiple containers for an application that can communicate with each other instead.
Single App per Container
You can run several, but running a single app per container is a great practice. Each of your containers should contain just one app since a container is built to have the same lifecycle as the app it hosts. So when a container starts and stops so should the app start and stop.
Use Trusted/Secure Images
Try to use verified images while you deploy your container and if you need to use an unverified image scan it well, so any vulnerability doesn’t creep into your application. Scan for vulnerability in images/packages/dependencies and if found, fix it and also don’t forget to keep searching for newer vulnerabilities regularly.
Don’t store secrets in simple text
Never store in plain text secrets/sensitive files containing content such as DB username/passwords or any other sensitive credentials or tokens, use native secret management software in the container engine or use powerful external plugins instead.
Never Run Container as Root
Because of security issues, never run a container as root. As if the container will have root access, any security flow in any package/dependencies installed will affect the original host system.
Monitor Your Containers
It is best practice to regularly and automatically track your containers, check how they work, collect CPU, RAM, I/O usage and other resource data, and also collect and review logs from time to time. While debugging or monitoring this data would be very helpful.
Few tools that can help you to monitor:
I hope you went through all of these practices and are ready to create a better containerization environment for your organization.
One pro tip: Try using any CI/CD pipeline to automatically build, tag images, test and deploy containers when you check a change to the source control or create a pull request.
If you’d like to explore more best practices for your cloud-native journey, we have put an excellent blog discussing best practices for your CI/CD.