Dockerfile: Best practices for building an image

Hi there,

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

I read this article on best practices for building a docker image. A Docker image serves as a template to build Docker containers. It also acts as a starting point when using Docker.

Link to the full article👇
Dockerfile: Best practices for building an image

Summary of best practices for building Docker images

Below is the list of best practices to follow while building Docker images:

1. OS base image

OS base image size can have a lot of impact on image sizes and security vulnerabilities. You should choose minimal Docker images like Alpine(~5 MB) compared to the most downloaded base image like ubuntu(~188 MB)

2. Base images

Each base image should have a specific goal and should be as generic as possible to ensure re-usability.

3. Docker users with minimal privileges

Docker users should only have the privileges that they need. For e.g. the ROOT user should not be used for starting the container.

4. Leverage Dockerignore

Dockerignore can be used for keeping your Docker images as lean as possible. You can create a file named .dockerignore in your root folder and use it to exclude files and directories that are not needed to run the app.

5. Be specific with AND or COPY

While using AND or COPY, be specific with the folder or files you want. It is an easy way to optimize image size.

6. Specific tag instead of fixed tag

Docker tags convey useful information about specific image versions/variants. Avoid using fixed tags like 'latest' as it makes it hard to track which version of the image is running and hard to roll back.

7. Image life cycle management

A security breach can happen in case you are running a deprecated version of an image. Hence, it's necessary to put in place a proper image life cycle management.

8. Sensitive information

Environment variables are not a good way to manage secrets as they are not encrypted. Solutions like Hashicorp vault can be used for managing secrets.

9. Multi-stage builds

With multi-stage builds, you use multiple FROM statements in your Dockerfile. Using multi-stage builds, you can selectively copy artifacts from one stage to another, leaving behind everything you don’t want in the final image.

10. Combine commands

As each command in a Dockerfile adds one layer to the image, one way to reduce image size is by combining commands. For example, multiple RUN commands can be combined into a single RUN statement.

I hope you enjoyed this summary and learned something new. I will be coming up with more such notes soon.

Please give me a follow if you liked it 🙌

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…



14