[Hackathon 2024][Gadolinium][Docker] Execute instructions in a specific order

[MP-Aubay]

(Existing rule in draft : green-code-initiative/creedengo-common#42)

Not implementable : this rule can reduce energy cost, but is hardly implementable with static analysis,

Rule title

Execute instructions in a specific order

Language and platform

Docker

Rule description

When building an image, Docker steps through the instructions in your Dockerfile, executing each in the order specified. For each instruction, Docker checks whether it can reuse the instruction from the build cache.
(https://docs.docker.com/develop/develop-images/guidelines/)

The following example shows a small Dockerfile for a program written in C.

FROM ubuntu:latest

RUN apt-get update && apt-get install -y build-essentials

COPY main.c Makefile /src/

WORKDIR /src/

RUN make build

Each instruction in this Dockerfile translates to a layer in your final image. You can think of image layers as a stack, with each layer adding more content on top of the layers that came before it:

Whenever a layer changes, that layer will need to be re-built. For example, suppose you make a change to your program in the main.c file. After this change, the COPY command will have to run again in order for those changes to appear in the image. In other words, Docker will invalidate the cache for this layer.
If a layer changes, all other layers that come after it are also affected. When the layer with the COPYcommand gets invalidated, all layers that follow will need to run again, too:

https://docs.docker.com/build/cache/

In this example, we’ll prefer to run “WORKDIR” Before “COPY” because we don’t need to do the command another time when there is a modification in “main.c”:

Rule short description

Write instructions in a correct sequence to maximize cache usage when rebuilding after a modification.

Rule justification

Using Docker cache can reduce :

• Network connectivity, for example with RUN that pull informations from the web
• Ressources, avoiding recreating existing layer

We can wondering if this issue is relevant, because in real life example, Docker image are build with pipelines, and the Docker cache is not always keep between build.

Severity / Remediation Cost

Severity : Minor, energy will be consumed only at build time.

Remediation cost : Easy, users will need to reorganize Dockerfile instructions.

Implementation principle

Not implementable in Sonarqube, because it will depend for each Dockerfile, there is no common mistake to check.