...
This is a generic project to create Docker images to run Yale applications. It should be possible to build an image on the developer’s machine for testing, then check the project into git.yale.edu and run the Jenkins job to built the image for the Yale container runtime environment.The requirements are:
Requirements
The Jenkins job builds an image using just the Dockerfile with no custom parameters. Therefore, the Dockerfile all by itself must build and image for the Yale environment, while files in this project override build args and provide additional tags only on the developer’s desktop.
The exact method of doing the equivalent of a “docker build” on the desktop is defined by the developer in a profile. It is possible to use a local docker command, or a remote ssh docker command, or a substitute for Docker like Podman.
A script file is included in every project and is run only on the developer desktop to do that type of build. The project specific script file includes project specific parameters while the generic code shared by all projects built by this developer are in the developer’s profile script.
The developer may run a copy of Harbor on his machine, or may choose to scan images and share images across VMs using a different method. All images are tagged on the developer machine with the same prefixes they will have in the Yale Harbor server.
...
General Approach
The Dockerfile has ARG statements assigning default values appropriate for the Yale Jenkins build of the image to store it in the Yale Harbor server. The Jenkins job just does a plain “docker build” on the project directory with the plain Dockerfile with all its default values.
...
The convention is for the profile to expose a build-image command and to have the individual build.ps1 file in each project call that function to do the “docker build” or its equivalent. There are alternate approaches to do a “wsl docker build” (run it in WSL), or “ssh userid@vm docker build” (run it on a VM), or “multipass exec vm docker build” (special version of ssh for Multipass), or “wsl podman build” (run podman replacement for docker in WSL), or “nerdctl build” (Rancher desktop). By putting the actual command in the profile script, the user can choose which technology he prefers to use.
Parameters for the Build
There are a few parameters that the Jenkins job always puts on the “docker build”, and they are probably a good choice for you to add to your environment
...
--pull is a special version of --no-cache that applies to the image in the FROM statement. By default, Docker doesn’t check to see if there is a new version of the image in the source repository (DockerHub?) when you already have an image downloaded with the same tag. This is OK if the tag is specific to a particular unchanging version. However, when you are referencing a “latest” image, then you may want to replace an old base image with an updated version with bugs fixed and you need to suppress the unwelcome Docker optimization by forcing it to --pull a newer image if one is available.
Base Image Choice
The most common choice for Docker Hub images is Debian. When it became common to scan images for vulnerabilities, Debian was initially slow to respond. Today, however, they have a special package source URL for vulnerability fixes and make a fix available as soon as the vulnerability is announced. This is, therefore, the best choice when looking for a clean scan.