This is a companion page to a Yale git repository with the files to do the build.
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:
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.
The general approach is:
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.
Overrides for ARG values and other properties are stored in a build.json file in the project that is only used on the developer desktop. Minimally it contains values that are coded into the Jenkins job when someone builds it. Minimally this includes the image tags which are not part of the Dockerfile but must be provided as parameters of the “docker build” command itself and which are different for each project.
In cases where the developer is building an artifact on the desktop and then including it into the image, the developer will want to replace the URL for the Artifactory server with a URL that fetches the newly built artifact from the local Maven repository. Since this will be the same for all projects, it is part of the profile.
While the user can do a “docker.exe build” on the desktop, 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). There are lots of ways to build an image. The profile provides a generic command which can be rewritten to actually use any of the above methods.