Like any other language, Dockerfiles can and should be linted for updated best practices and code quality checks. Docker is no exception to the rule, and good practices are always moving, getting updates, and might also be a little different between communities. In this section, we'll start with a basic Dockerfile found earlier and end up with a fully double-checked linted file.
To step through this recipe, you will need the following:
- A working Docker installation
- An AWS account
Many different linters exist for linting Dockerfiles: Hadolint (http://hadolint.lukasmartinelli.ch/) maybe the most used linter, while Project Atomic's dockerfile_lint project is perhaps the most complete one (https://github.com/projectatomic/dockerfile_lint).
Here's the working Dockerfile from earlier in this book:
FROM debian:stable-slim
RUN apt-get update -y
&& apt-get install -y apache2
&& rm -rf /var/lib/apt
ENTRYPOINT ["/usr/sbin/apache2ctl"]
CMD ["-D", "FOREGROUND"]Let's start working with Hadolint, as it's easy to install (prebuilt binaries and Docker images) and use. All rules are explained in Hadolint's wiki (https://github.com/lukasmartinelli/hadolint/wiki), and usage is really simple:
$ hadolint Dockerfile
Alternatively, use the Docker containerized version; it's probably good in CI scripts. Beware of the image size; at the time of writing, the image is 1.7 GB, while the hadolint binary is less than 20 MB:
$ docker run --rm -i lukasmartinelli/hadolint < Dockerfile
Linting Dockerfiles from this chapter, we'll notice different warnings. Maybe some are false positives, or maybe some rules are just not yet updated to the latest deprecation notices, such as the following:
$ hadolint Dockerfile Dockerfile DL4000 Specify a maintainer of the Dockerfile
In fact, this Dockerfile is following Docker 1.13 recommendations, which include to no more include a maintainer instruction. However, Hadolint is not yet up to date for this deprecation change, so execute the following to ignore one or more IDs, to still be cool:
$ hadolint --ignore DL4000 --ignore <another_ID> Dockerfile
This project lead by the Project Atomic team (http://www.projectatomic.io/) is also proposing different checks and strong opinions on how a Dockerfile should be written. These propositions are very often good advice, though.
Execute this to launch dockerfile_lint from the official Docker image:
$ docker run -it --rm -v $PWD:/root/ projectatomic/dockerfile-lint dockerfile_lint
A certain amount of suggestions will arise (errors, warnings, and info), each with a related reference URL to refer to.
When in doubt, it's often a good move to follow the suggestions and fix the code accordingly.
At the end of this double linting process, our Dockerfile changed a lot, as shown here:
FROM debian:stable-slim LABEL name="apache" LABEL maintainer="John Doe <[email protected]>" LABEL version=1.0 RUN apt-get update -y && apt-get install -y --no-install-recommends apache2=2.4.10-10+deb8u7 && apt-get clean && rm -rf /var/lib/apt/lists/* EXPOSE 80 ENTRYPOINT ["/usr/sbin/apache2ctl"] CMD ["-D", "FOREGROUND"]
We added labels to identify the image, versions, and maintainer, and we fixed a proper version of the apache2 package. So no bad surprise can happen with an untested update (updating the package will need a rebuild of the image), we're cleaning the apt cache more precisely, and we're explicitly exposing a port from the container.
Overall, those changes proposed by the linters helped us a lot in building a much better and stronger container. Their role in CI is crucial; include the linters in your Jenkins, Circle, or Travis CI jobs!