¶ Introduction
The Remote Container VSCode extension has been previously integrated to S.O.N.I.A's workflow by a different PFE team. Here, we take a look on how the Dockerfiles were written. We will give feedbacks on what has been done well and what can be improved.
¶ Recommendations
¶ Things we currently do well
- Include only the files we need to the build context.
- It is possible to pipe a Dockerfile through stdin. However, this is not necessary for our case, and it’s actually more convenient to save the Dockerfile persistently. Currently, the Dockerfile is saved inside the Github repository.
- We are currently adding the files to the container with the COPY instruction. Although it is also possible to use the command ADD to transfer files between the host and the Docker image, COPY makes the instruction more explicit.
- We are currently using the .dockerignore file to ignore two folders, which are build and devel. However, it might be possible to ignore other files to make the build even faster. Usually, the less files we include in the build context, the faster the build is. Also, the built images are usually smaller. In our situation, since we are copying all the files from the git repository to the Docker container, it might not be possible to ignore any of the files. In fact, it might actually create problems if files were not sent to the container, since committing to Github will create file conflict errors.
¶ Things that can be improved
- We can take a measure of how big the build context is. This information is shown to us when we build a Docker image. This information can be used to track the progression of the performance of the Dockerfile.
- If it was possible not to copy the files from the local directory to the container, these files and folders can be easily omitted:
- .git
- .vscode
- LICENSE
- README.md
- When the container was built, the container was identified as friendly_bouman. This can be difficult to differentiate between different images. A solution can be to add a image name and tag when building the image.
¶ Other points
- Usually, a rule of thumb for ordering the instructions is to put those that are most likely to change closer to the end of the Dockerfile. The reasoning behind this is that if these instructions change, only the layers that come after it are going to be rebuilt.
- If some commands do not change, it is a good practice to chain them together to form just one command. Since each instruction inside a Dockerfile is translated to a layer, multi-line instructions will just become one layer.
- This is the actual size that the container image takes. It gives us an idea about how slim the image is.
