Skip to main contentMerative SPM on Kubernetes

Building the Docker® images

Introduction

Universal Base Image (UBI) consists of enterprise-ready and OCI-compliant Linux containers that offer greater security with stricter defaults than general images.

For more information, see Red Hat’s Universal Base Image and Red Hat Universal base image how it works

Some of the base images require authentication with the RedHat Container Registry. You must be logged in to the following registries:

  • registry.redhat.io
    • For accessing registry.redhat.io/rhel8/httpd-24
    • Login using docker login registry.redhat.io
  • registry.connect.redhat.com
    • For accessing registry.connect.redhat.com/ibm/ibmjava8-sdk-ubi8-minimal
    • Login using docker login registry.connect.redhat.com

Note: As covered in building Base images, if you do not have an active RedHat subscription you will need to build your own base images from source following the steps there.

Should you opt to build your own base images, the BASE_REGISTRY argument in the following commands may be omitted, if the base images are built in the same environment.

If the images are stored in a private registry, set BASE_REGISTRY to the registry’s hostname.

For the docker commands that follow you must set a DOCKER_REGISTRY environment variable based on the container environment you are deploying:

The URL for this value can be retrieved using this command: oc registry info --public

For example:

export DOCKER_REGISTRY=default-route-openshift-image-registry.apps-crc.testing

Now that all the elements are in place, build the images as follows:

Building the images

The following sections provide steps for building the Docker images.

Set the PROJECT environment variable:

Note: In the following commands, the value of $PROJECT will change depending on deployment type:

  • For a Minikube deployment the value of $PROJECT is arbitrary.
  • For an AKS deployment the value of $PROJECT must equate to a valid namespace in the customer’s account.
  • For an OpenShift deployment the value of $PROJECT must equate to a valid project. For this runbook it is best to stick with the value chosen for $PROJECT in Creating a CRC project

XML server image

To build the XML server image, run the following commands:

cd $SPM_HOME/dockerfiles/Liberty/
docker build \
--tag $DOCKER_REGISTRY/$PROJECT/xmlserver:latest \
--build-arg "BASE_REGISTRY=registry.connect.redhat.com/" \
--file XMLServer.Dockerfile .

SPM 8.0.1.0 For information on building an XML server sidecar performance monitoring image see Monitoring XML servers.

Utilities image

The utilities image is used at various stages of the deployment to check the state of the deployment.

To build the utilities image, run the following commands:

cd $SPM_HOME/dockerfiles/Liberty/
docker build \
--tag $DOCKER_REGISTRY/$PROJECT/utilities:latest \
--build-arg "BASE_REGISTRY=registry.connect.redhat.com/" \
--file Utilities.Dockerfile .

Batch image

A .dockerignore file is used to omit the EAR files from the build context for batch.

To build the batch image, run the following commands:

cd $SPM_HOME/dockerfiles/Liberty/
echo -e 'content/release-stage/ear' > .dockerignore
docker build \
--tag $DOCKER_REGISTRY/$PROJECT/batch:latest \
--file Batch.Dockerfile .
rm -f .dockerignore

Server Code image

To build the Server Code image, run the following commands:

cd $SPM_HOME/dockerfiles/Liberty/
docker build \
--tag $DOCKER_REGISTRY/$PROJECT/servercode:latest \
--file ServerEAR.Dockerfile \
--build-arg "MQ_RA_LICENSE=--acceptLicense" .

Application images

Take note of the SERVERCODE_IMAGE build argument which references the server code image - this gives the images a common base.

To build the application images, run the following commands for each of the applications (EAR files) needed:

cd $SPM_HOME/dockerfiles/Liberty/
docker build \
--tag $DOCKER_REGISTRY/$PROJECT/curam:latest \
--file ClientEAR.Dockerfile \
--build-arg "SERVERCODE_IMAGE=$DOCKER_REGISTRY/$PROJECT/servercode:latest" \
--build-arg "EAR_NAME=Curam" .

Static Content image

To build the static content image, run the following commands:

cd $SPM_HOME/dockerfiles/HTTPServer/
docker build \
--tag $DOCKER_REGISTRY/$PROJECT/httpd:latest \
--file StaticContent.Dockerfile \
--build-arg "BASE_REGISTRY=registry.redhat.io/" \
--build-arg "CONTENT_DIR=/CuramStatic" .

Note: The CONTENT_DIR build argument must correspond to the value set in curam-config.xml when the webclient was built.

Universal Access image

To build an SPM Docker image for your built Universal Access application:

  • Copy the build directory from the React application to $SPM_HOME/dockerfiles/HTTPServer
  • Run the following commands:

This is applicable only if you are licensed for SPM Universal Access.

Note: The CONTENT_DIR build argument must correspond to the value of the PUBLIC_URL variable set when creating the production build of the React app (npm run build).

cd $SPM_HOME/dockerfiles/HTTPServer/
docker build \
--tag $DOCKER_REGISTRY/$PROJECT/uawebapp:latest \
--file UAWebApp.Dockerfile \
--build-arg "BASE_REGISTRY=registry.redhat.io/" \
--build-arg "CONTENT_DIR=/universal" .

Pushing the images to the registry

When you set up Minikube by following the steps in Minikube, a registry was also created to store the Docker images. To push the new images that you created to the registry, run the following commands:

docker push $DOCKER_REGISTRY/$PROJECT/xmlserver:latest
docker push $DOCKER_REGISTRY/$PROJECT/utilities:latest
docker push $DOCKER_REGISTRY/$PROJECT/batch:latest
docker push $DOCKER_REGISTRY/$PROJECT/servercode:latest
docker push $DOCKER_REGISTRY/$PROJECT/curam:latest
docker push $DOCKER_REGISTRY/$PROJECT/httpd:latest

If any additional images were built (for other SPM applications or for the React application), do not forget to push the images too. For example:

docker push $DOCKER_REGISTRY/$PROJECT/rest:latest
docker push $DOCKER_REGISTRY/$PROJECT/uawebapp:latest

Pushing the images to the a Container Registry

A Container Registry is the service to distribute the containers across a Kubernetes service In order to configure it, some preparation steps are required to obtain the credentials and a namespace, globally unique between all the tenants of your cloud of choice. Refer to Getting Started with Artifactory as a Docker Registry for more information on configuring the registry and obtaining the required credentials.

docker login ${server-name}.jfrog.io
docker push ${server-name}.jfrog.io/{repo-name}/xmlserver:latest
docker push ${server-name}.jfrog.io/{repo-name}/utilities:latest
docker push ${server-name}.jfrog.io/{repo-name}/batch:latest
docker push ${server-name}.jfrog.io/{repo-name}/curam:latest
docker push ${server-name}.jfrog.io/{repo-name}/httpd:latest

View the artifacts in the repository

Confirm that the pushes to the Docker registry succeeded. Run the following command:

curl http://$DOCKER_REGISTRY/v2/_catalog

The command returns the following result, depending on the images built and your tagging:

{"repositories":["batch","curam","xmlserver","httpd","utilities", "servercode"]}

Note: Due to an issue with Minikube you will need to repush the Docker images to the registry each time you shut down.

For more information about the Docker Registry HTTP API, see Docker Registry HTTP API V2.