Containerization Best Practices

6 min readJan 10, 2021

Container technology now getting used by Developers, DevOps Professions, Data Scientists, and other tech professionals, especially it helped developers to develop and deploy applications a lot faster than before, it brings us application portability and a lot of other features, that we will through one by one and we will learn which best practices we can follow to optimize it further!

Ok, but for those the word container/containerization still an alien word, below is a brief about containerization:

What is Containerization?

I like this definition from Citrix:

Containerization is defined as a form of operating system virtualization, through which applications are run in isolated user spaces called containers, all using the same shared operating system (OS). A container is essentially a fully packaged and portable computing environment that already has all the necessary packages to run the application inside.

In a more simple way: Containerization is the process of packaging an application along with its required libraries, frameworks, and configuration files together so that it can be run in various computing environments efficiently

In one line: Containerization is the encapsulation of an application and its required environment.

The below diagram Explain it well 👍

Add alt text

Popular Container Engines:

Docker:

The first and still most popular container technology, Docker’s open-source containerization engine works with most of the commercial/enterprise products, as well as many open-source tools.

CRI-O:

CRI-O, a lightweight alternative to using Docker, allows you to run containers directly from Kubernetes, without any unnecessary code or tooling.

Rktlet

The aforementioned rkt, redesigned and retooled to use the CRI as rktlet, now has a set of supported tools and community to rival Docker.

runC

runC, a lightweight universal container runtime, is a command-line tool for spawning and running containers according to the Open Container Initiative (OCI) specification.

Containerd

A project of the Cloud Native Computing Foundation, containerd was an early container format. More recently the developers of containerd built a CRI plugin that lets Kubernetes run containerd in the same way it runs rktlet or CRI-O.

Microsoft Containers

Positioned as an alternative to Linux, Microsoft Containers can support Windows containers under very specific circumstances. They generally run in a true virtual machine and not in a cluster manager like Kubernetes.

Kata Containers:

Kata Containers is an open-source container runtime, building lightweight virtual machines that seamlessly plug into the containers ecosystem.

But Again Why Use Containers?

Consistent Environment

Containers give developers the ability to create predictable environments that are isolated from other applications. Containers can also include software dependencies needed by the application, such as specific versions of programming language runtimes and other software libraries. From the developer’s perspective, all this is guaranteed to be consistent no matter where the application is ultimately deployed. All this translates to productivity: developers and IT Ops teams spend less time debugging and diagnosing differences in environments, and more time shipping new functionality for users. And it means fewer bugs since developers can now make assumptions in dev and test environments they can be sure will hold true in production.

Run Anywhere

Containers are able to run virtually anywhere, greatly easing development and deployment: on Linux, Windows, and Mac operating systems; on virtual machines or bare metal; on a developer’s machine or in data centers on-premises; and of course, in the public cloud. The widespread popularity of the Docker image format for containers further helps with portability. Wherever you want to run your software, you can use containers.

Isolation

Containers virtualize CPU, memory, storage, and network resources at the OS-level, providing developers with a sandboxed view of the OS logically isolated from other applications.

From Code to Applications

Containers allow you to package your application and its dependencies together into one succinct manifest that can be version controlled, allowing for easy replication of your application across developers on your team and machines in your cluster.

Less overhead

Containers require fewer system resources than traditional or hardware virtual machine environments because they don’t include operating system images.

Greater efficiency

Containers allow applications to be more rapidly deployed, patched, or scaled.

Containerization Best Practices:

Choose Container Engine Properly:

Based on the project and use cases, select the right container engine for your application, in case not sure about what would be the right container engine for your application, then good to go with the most popular one i.e. Docker but don’t just select it because someone telling it, do your own research and then select the right one for your project.

Keep images as small as possible:

To Keep images smaller:

-> Use multi-stage builds (e.g. docker multi-stage build)

-> Use smaller base image

-> While building image make sure only include packages what is necessary, should remove what’s not needed and always tag the images.

Store Persistent Data Outside Container:

Avoid storing application data in your container’s writable layer. This increases the size of your container and is less efficient from an I/O perspective than using volumes or bind mounts, instead of store data in external data storage e.g volumes in docker

Don’t store secrets in simple text:

Never store secrets / sensitive files which have contents like DB username/passwords, or any other sensitive credentials in plain text, instead use native secret management tools available in container engine or use efficient external plugins.

Dev, Test, Staging, Production:

Make sure to separately and dynamically manage environments in containerization, use environments variable accordingly, can use a script to automate this and optimize further.

Utilize CI/CD Tools for Testing & Deployment:

When you check in a change to source control or create a pull request, use any CI/CD pipeline to automatically build, tag images and test it and deploy automatically.

Pay attention to Container Security:

Security matters and considering the current situation it matters a lot! , so make sure to sign images, scan any external images before using them, search for vulnerability in images/packages/dependencies, and fix the root cause and of course audit those regularly. Try to use trusted/secure images

Single App per Container:

Of course you can run multiple, but it’s a good practice to run a single app per container. Because a container is designed to have the same lifecycle as the app it hosts, each of your containers should contain only one app. When a container starts, so should the app, and when the app stops, so should the container.

Never Run Container as Root:

Out of security concerns, never run any container as root as it will get root access to the host system, any security flow in any installed packages/dependencies will affect the original host system.

Don’t Run Many Processed in Single Container:

Running many processes inside a single process will affect the performance of the actual application, so instead make multiple containers as services that can interact with each other.

Monitor Your Containers:

It’s best practice to monitor your containers, check how it’s performing, collect CPU, RAM, I/O usage and other resource data periodically and automatically, also collect and analyze the logs time to time. It will be very helpful at the time of debugging or reporting purposes.

There are many tools available e.g. container insight by AWS, newrelic, App Dynamics, App Optics, Prometheus, cAdvisor, Dynatrace, DataDog, and many more.

Thanks for reading this article 🙏

Did I miss any point? let me know in the comments!

About the Author: