Domino-docker explained – Part 2 : Creating your first Domino image
In the previous part, I looked at reasons why you might want to run your Domino server inside a container. In this part, I’m going to show how to create your first Domino image. We have to take one step back though, as since a couple of years, HCL provides their own docker image for Domino. So why would you want to create your own image? My experience is that it leads to a better image and it gives options to add your own tooling to the image. Nevertheless, using HCL’s image is an option and the script also provides an option to build on top of the standard HCl image. My advice: create your own.
How to build your first Domino container image using the domino-docker scripts
I’m going to assume you have a Red Hat or Red Hat Clone (CentOS, Alma Linux etc) host OS. If you don’t have git installed yet, install it. You need it to download the latest version of the domino-docker scripts.
yum -y install git
Next create or enter a directory where you want to store the domino-docker scripts. This can be wherever you like, though for the sake of standardisation, I advise using /local/github. From this directory, clone the domino-docker git repo. Unless you participate in Domino beta programs, you can just clone the master branch.
mkdir -p /local/github cd /local/github git clone https://github.com/HCL-TECH-SOFTWARE/domino-container.git
This created a domino-docker directory in your current directory. In the future, to update the scripts to the latest version, enter the domino-docker directory and just type ‘git pull’.
Now that you have the scripts, it’s time to get the software and put it in the right place. If, from the domino-docker directory, you type
./build.sh -checkonly
you get an overview of the download paths for the software that the scripts looks for. If you only want to create an image for Domino V12, you of course only need to download the 12.0 packages. You can save the software wherever you want on your host machine or you can even download them on a different machine and make them available for the script through a webserver. Whatever option you choose, you have to configure them in the build.cfg file.
The build.cfg can, after creation, be found in a DominoDocker directory in your home dir.
cd /localgithub/domino-docker ./build.sh cfg
In this file, you can a couple of build options. If you use a webserver, you should configure:
DOWNLOAD_FROM=<url of your webserver>
If the packages are available locally on your build machine, you use:
SOFTWARE_DIR=<path to your directory with Domino packages>
In the end, the software will be downloaded from a webserver during the creation of the image. If you configure the DOWNLOAD_FROM link, it will download it from there. If you configure the SOFTWARE_DIR (or neither in which case you have to place the software in the domino-docker/software directory), the script will create an nginx container with the software directory as volume and download the software through that.
In both spots you can add the software.txt and current_version.txt files which you can find in the software/ directory and change them to your need. If you, for example, still consider Domino 11.0.1 the ‘current’ version, you can change that file and the scripts will use Domino 11.0.1 by default if you don’t pass along a different Domino version.
If the script knows where it can find the software, you have enough to create your first image. The easiest way to do this is to to type, from the domino-docker directory, this command:
./build.sh domino
This creates an Domino 12 image of 1,61 GB, based on CentOS 8, with tags ‘12.0.0’ and ‘latest’ and it did so in 5 minutes and 16 seconds on my machine. With this image, you could start a Domino 12 server, but there are many more options in the build command. Let’s have a look at a couple of them.
Creating an image for another Domino version than the currently latest
Let’s say we don’t want to create an image for Domino 12, but for Domino 11.0.1 FP3. The build.sh command gives some information on what the other options are and what options to use in this situation:
[root@ domino-docker]# ./build.sh
Usage: build.sh { domino | traveler | volt } version fp hf
-checkonly checks without build
-verifyonly checks download file checksum without build
-(no)check checks if files exist (default: yes)
-(no)verify checks downloaded file checksum (default: no)
-(no)url shows all download URLs, even if file is downloaded (default: no)
-(no)linuxupd updates container Linux while building image (default: yes)
cfg|config edits config file (either in current directory or if created in home dir)
cpcfg copies standard config file to config directory (default: /root/DominoDocker/build.cfg)
Add-On options
-git adds Git client to Domino image
-openssl adds OpenSSL to Domino image
-borg adds borg client and Domino Borg Backup integration to image
-verse adds the latest verse version to a Domino image
-nomad adds the latest nomad package to the server
Examples:
build.sh domino 11.0.1 fp3
build.sh traveler 11.0.1.1
So to create a Domino 11.0.1 FP3 image, we can use ‘build.sh domino 11.0.1 fp3’. If we just run this command, the new 11.0.1 FP3 image will get the tag ‘latest’ and the 12.0.0 image will lose this tag. If you want to keep images of multiple versions, that’s not what we want. Let’s say we want to give this Domino 11 image the tag ‘latest11’ instead of ‘latest’, so we do have a tag that will always refer to the Domino 11 version with the latest fix pack and possibly hotfixes. Then the full command is:
./build.sh domino 11.0.1 fp3 latest11
In 5 minutes and 46 seconds, this created an image of 1,67 GB with Domino 11.0.1 FP3 and tags ‘11.0.1FP3’ and ‘latest11’. There are other options though.
Basing your image on a different OS from CentOS 8
So by default, the Domino image is based on the latest CentOS image on docker hub. There are other options though and you can set those in 2 ways:
- In the build.cfg file set the parameter ‘DOCKER_FILE=’ with the right dockerfile_xxx
- Add the dockerfile_xxx parameter to the build.sh command
Currently you can choose between these dockerfiles:
| Dockerfile | Distribution |
| dockerfile_alma | Alma Linux (RHEL8 clone) |
| dockerfile_centos7 | Latest CentOS 7 (RHEL7 clone) |
| dockerfile_centos8 | Latest CentOS 8 (RHEL8 clone) |
| dockerfile_leap | openSUSE Leap (SUSE) |
| dockerfile_orel | Astra Linux Orel/Oryol (Russian distro. based on Debian) |
| dockerfile_photon | VMWare Photon OS (minimal Linux OS) |
| dockerfile_ubi | Red Hat Universal Base Image (based on RHEL8) |
Update: This was changed in a later release of the scripts. The syntax is now to add -from= to the build command. See https://blog.martdj.nl/2022/07/19/domino-containers-revisited/ for a recent list of tested base operating systems.
All of these options are tested and work, but it’s good to realise that only the RHEL clones are officially supported. HCL base their own image on Red Hat UBI. I must say though that in my experience HCL support is a lot easier on supporting installations on non-supported operating systems than IBM was. To give an idea of how much difference it makes when you base your image on a different OS. Compared to the Domino 11.0.1 FP3 image based on CentOS 8 (5:46 minutes, 1,67 GB), the same Domino version based on Photon OS took 4:20 minutes to build and uses only 1,28 GB.
Conclusion
Because of all the options, this became a long post after all, but I hope it became clear that with the Domino Docker scripts, it’s actually very simple to create your own image. In the next post, I’ll show you how to use this image.
