DEV Community

loading...
Cover image for Best Practices for building containers

Best Practices for building containers

Ankit Anand ✨
Your friendly content curator on DevOps, open-source projects, application performance monitoring & cloud native technologies 👨🏽‍💻
Updated on ・2 min read

Hi there,

This is Ankit, your friendly DevOps content curator. I read a lot of articles about DevOps, distributed systems, performance monitoring, etc. I will be sharing some key takeaways from these articles with you so that you can stay updated and learn a few things quickly.🙂

This was a fantastic read from google's cloud architecture center.

Link to the full article👇
Best Practices for building containers

Summary of best practices for building containers

Package a single app per container

Containers are meant to be treated as a single app, and not as a virtual machine. The best practice is to have a parent process and all its child processes as a single container. If you have multiple apps in a single container, you might end up with a running container with an unresponsive core component.

Properly handle PID 1, signal handling, and zombie processes

Linux signals control the lifecycle of processes inside a container. And to tightly link the lifecycle of your app to its container, your app needs to handle Linux signals properly. One of the ways it can be done is by using a specialized init system like tini.

Optimize for the Docker build cache

Docker build cache can be used for accelerating the building of container images by skipping potentially costly steps. To take full advantage of Docker build cache, the build steps that change often should be positioned at the bottom of the Dockerfile. Docker could use its build cache only if all previous build steps used it.

Remove unnecessary tools

To protect your apps, try reducing the attack surface of your app by removing all unnecessary tools. For example, you can remove utilities like netcat.

Build the smallest image possible

Small images are suited for faster upload and download times. A few ways to ensure the small size of the image includes:

  • using the smallest base image possible
  • reducing the amount of clutter by installing only what is needed, and
  • creating images with common layers.

Scan images for vulnerabilities

In case of vulnerabilities, the best practice is to rebuild the image and its patches and redeploy it. You can choose a service to constantly scan your images for security vulnerabilities. Docker has partnered with Snyk to provide the vulnerability scanning service.

Properly tag your images

It is advised to properly link the tagging system on container images to the release policy of your software. A coherent and consistent tagging policy must be set in place and documented so that users can easily understand it.


I hope you enjoyed this TL;DR summary and learned something new. I will be coming up with more such notes soon. So, stay tuned! 🙂


Currently building SigNoz - an open-source APM & observability tool 💙

GitHub logo SigNoz / signoz

SigNoz helps developers monitor their applications & troubleshoot problems, an open-source alternative to DataDog, NewRelic, etc. 🔥 🖥

SigNoz-logo

Monitor your applications and troubleshoot problems in your deployed applications, an open-source alternative to DataDog, New Relic, etc.

License Downloads GitHub issues tweet

SigNoz helps developers monitor applications and troubleshoot problems in their deployed applications. SigNoz uses distributed tracing to gain visibility into your software stack.

👉 You can see metrics like p99 latency, error rates for your services, external API calls and individual end points.

👉 You can find the root cause of the problem by going to the exact traces which are causing the problem and see detailed flamegraphs of individual request traces.

SigNoz Feature

👇 Features:

  • Application overview metrics like RPS, 50th/90th/99th Percentile latencies, and Error Rate
  • Slowest endpoints in your application
  • See exact request trace to figure out issues in downstream services, slow DB queries, call to 3rd party services like payment gateways, etc
  • Filter traces by service name, operation, latency, error, tags/annotations.
  • Aggregate metrics on filtered traces. Eg, you can get error…




Discussion (0)