Docker best practices: lint your Dockerfile!
Tags: docker, devops, tutorial, codequality
Published: 2020-11-09 16:06:36

In software development, **best practices are the way to go.**
You must do the same while developing the infrastructure code!
In this post, we’ll go through how a linter can increase your productivity, how to use it with a Dockerfile, and how to implement it in a CI pipeline.

## What is a linter? Why we need it?

According to Wikipedia, a [linter](https://en.wikipedia.org/wiki/Lint_%28software%29) is *a static code analysis tool used to flag programming errors, bugs, stylistic errors, and suspicious constructs*.
As a static code analysis tool, linters can’t be used to detect compiling time errors but are very useful in finding typos and syntax errors. Using a linter will allow you to detect errors early, fixing them faster, and reduce bugs before execution.

## Hadolint

![image](https://dev-to-uploads.s3.amazonaws.com/i/4f0hytkjoarn76yng7sd.png)

The tool we will use is called [Hadolint](https://github.com/hadolint/hadolint) and as you can recall from the name is a linter. It’s built to help you follow the [docker best practices](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/), and it also uses [ShellCheck](https://github.com/koalaman/shellcheck) to inspect your `RUN` instructions.

### How to set it up

It very easy to use both in a local environment and CI, you can find the [integration docs here](https://github.com/hadolint/hadolint/blob/master/docs/INTEGRATION.md).

If you are a VS Code user, there is the  [Hadolint extension](https://marketplace.visualstudio.com/items?itemName=exiasr.hadolint). If you want to use it directly in Github, there is the [Hadolint Github action](https://github.com/marketplace/actions/hadolint-action).

## Define custom rules

If you don’t want to follow all the rules defined by Hadolint, you can easily deactivate some of them. You only need to create a file called  `~/.config/hadolint.yaml`, a full [list of rules here](https://github.com/hadolint/hadolint#rules). An example of a custom rule file is:

```yaml
ignored:
  - DL3000
  - SC1010
```

## How to run it in CI

To enforce this best practice, you can add a test in your Docker deployment pipeline. We can implement it in the [Ansible pipeline](https://www.ansible.com/) we used to execute [unit tests for Docker](/posts/docker-unit-test-dockerfile-image/).

Let’s add a new role called “Run hadolint on Dockerfile”:

```yaml
- name: Run hadolint on Dockerfile
  shell: |
    docker run --rm -i \
      -v "{{ role_path }}/files/hadolint.yaml":/root/.config/hadolint.yaml hadolint/hadolint \
      < {{ dockerfile_name }}
```

In this example, we directly run the official hadolint docker image against the Dockerfile. I’m mounting the `hadolint.yaml` file to use my custom rules configuration.

## This is it!

Now you should know all you need to use Hadolint for your Dockerfile.

Reach me on Twitter [@gasparevitta](https://twitter.com/gasparevitta) and **let me know your thoughts!**

You can find the code snippets on [Github](https://github.com/gasparev/blog-code-snippets/tree/master/docker-unit-test/roles/dockerfile-linter).
*This article was originally published on [my blog](https://www.gasparevitta.com/posts/docker-best-practices-dockerfile-hadolint/). Head over there if you like this post and want to read others like it!*