Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

Examples:
ARG ARTIFACT_SERVER=https://repository.its.yale.edu/artifactory/libs-releases-local
ARG YaleArtifactVersion=1.0.48

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

Code Block
{
    "new_image_tag": "iiq:8.1p1-yale-1.0.48",
    "build_arg": {
      "YaleArtifactVersion": "1.0.48-SNAPSHOT",
      "SailpointVersion": "8.1p1"
    }
}

The smallest build.json file contains only the “new_image_tag” because the tag is generated from the Jenkins job parameters and is not in the Dockerfile, so this is the only place it can come from on the developer’s desktop.

Note that the ARG YaleArtifactVersion default is a “production” version number (after a Perform Release has been done), while the override value in the JSON is the -SNAPSHOT version number used while developing before you generate a Release.

A best practice is that when an image contains a Yale Artifact, the Artifact Version number is in the image tag, so it is easy to tell what version of the application was put into the image.

The ARG ARTIFACT_SERVER would typically not be in the build.json file because it is a permanent part of the developer desktop configuration. If the user provides a local artifact server URL, it will be set in the user’s $HOME\sandboxProfile.ps1 file:
$SANDBOX_ARTIFACT_SERVER="http://repository.yale.sandbox/artifactory"

The the profile will add it to the list of --build-arg parameters passed to the “docker build” command:

Code Block
$build_args=[System.Collections.ArrayList]@( `
    "--build-arg ARTIFACT_SERVER=$SANDBOX_ARTIFACT_SERVER", `
    "--build-arg IMAGE_REGISTRY=$SANDBOX_IMAGE_REGISTRY" `
    )

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.

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 methodsare 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

--no-cache causes the build to execute each step in the Dockerfile even if that line has not changed and there is a cached result from the previous execution of that line. Generally our Dockerfiles are not that big and complicated, and allowing Docker to reuse the cached results of executing a previous Dockerfile produces unfortunate results. For example, a “RUN apt update && apt upgrade -Y” is probably intended to install all the very latest fixes and not the fixes that were cached from running these commands a few months ago. Dockerfile line caching produces unexpected results and should not be the default for unsuspecting users.

--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.