A framework to simplify 'Dockerfile' and make it easier to build complex containers
Across the web, there are many examples of container Dockerfile configuration files. These range from very simple to complex, almost unreadable files. The general problem, seems to be that everyone attempts to use the Dockerfile as a kitchen sink and put every command related to the creation of the container, into the Dockerfile itself. The Dockerfile documentation only describes the directives which may be used. It does not talk about standards or best practices.
This always results in mixed mode programming, since the Dockerfile RUN command is used. It invokes some other command inside of the build container. Usually, this is a bash script, though it can be any script language. Including these script commands on the RUN command, end up with a lot of escaping and formatting because the Dockerfile is not a native file for the script. (Hence: "mixed-mode" program).
This framework takes a different approach. It minimizes the 'mixed mode' code, and moves it to a set of small scripts which are COPY'd to the build container from where they are run.
Downloading files is another common pattern which occurs. Sometimes developers verify a PGP signature, or a SHA to validate the downloaded file. I have even seen SHA's downloaded from the same site as a file and used to verify the download. Sometimes, a retry is performed. There is so much duplicated code.
Container security is always a concern, so it pays to be mindful of who owns the process which the container runs. Usually, default is ‘root’ unless you specify USER in Dockerfile. Also, just because USER is specified, that user may not have same uid on host system, as it does inside the container. This can lead to debugging issues, as well as access issues on the host system when VOLUMEs are also mounted.
A typical project has a Docker file. A project using the container_build_framework, contains a Dockerfile and a build folder. You can include a vols folder for any local mountpoints, as well as a .dockeringnore and the usual meta files for git. This results in a project folder which looks like:
The simplified project Dockerfile looks like this:
Depending on the project, there may also be other ENV, EXPOSE, ARG or ONBUILD directives, and possibily a USER directive.
As can be seen, all of the script code has been moved out of the Dockerfile, reducing the mixed-mode code, and resulting in simplification.
The build processes of all containers is always the same.
- Install needed OS Support
- Verify users and groups exist
- Download & verify external packages
- Install applications
- Add customizations and configuration
- Make sure that ownership & permissions are correct
- Clean up
Every container will perform one or more of these actions. Many container builds, perform these items multiple times with different targets. Also, in the Dockerfile examples, these items are seldom performed in any consistent manner. The result can make it not only difficult to debug your own Dockerfiles, but near impossible for someone else to understand, modify and debug your Dockerfiles.
This framework solves these problems by breaking the steps previously in the Dockerfile into small, well organized scripts. The scripts are placed into known locations making them easy to find and identify. A naming convention is used to control the order the scripts are executed. This gives you very precise control over the build process and makes the Docker application easier for you and others to modify or extend.