Personal Blog of Thomas Hampel - Creative Mythbusting in Development and Collaboration

Who am I?

Feeds

Previous Document Next Document

Domino on Docker Project Updates

Thomas Hampel
 23 July 2019

Domino on Docker Project Updates
Daniel and me are working on the Domino on Docker project which has been around for a while. We are constantly updating it with more functionality.
Beside the main functionality of providing an automated installation we have a management script that can help to build custom Domino docker images for (e.g.) including applications.
We are working on making the resulting image more flexible. The first version allowed only to automatically setup a first server in a new Domain, but customers already have an environment and either want to setup an additional server in an existing domain or at least have a cross certified environment.

Whats new:
1. Additional server setup
You can now specify an existing server.id and existing server to get the system databases from. You still need to register the second server.id manually in your Domino Directory, however the ID file does not need to be copied anymore.
Just specify the environment variable
ServerIDfile to point to a location (local or http/https) from where the server.id file can be downloaded and the container startup routine will take care of automatically setting up your second server.

2. Add your own data into a container at initial startup
The big challenge is how to bring in data into a new container automatically. Distributing server.id files, templates, or even full applications.
We looked at different approaches which included "Docker secrets", shared volumes and other options.
For improving flexibility we decided to use configurable http/https download links which can be used to download a server.id or an additional data-directory.zip which is automatically expanded at first server start.
This would be for example a way for business partners to deploy their software on top of the image. Or for a customer to deploy their applications or specific adoptions.
All you have to do is to specify an environment variable CustomNotesdataZip (attention, case sensitive!) pointing to a zip file that will be downloaded and extracted into the container at runtime.

3. Scriptable configuration
Now that you have provided your own templates - how do you turn them into an application, how do you change ACLs, or server settings at runtime?
We have added a method to automatically configure a server based on a config JSON file. This can be used to create databases, change groups, change server settings etc.
The configuration is applied before starting up the (new) Domino server for the first time and also allows to sign applications, change the ACL of databases.
...there is even more configuration options to come.


4. More flexible deployment options
In previews versions there was image specific data in the /local directory.
So we moved that data to a separate directory to optionally allow /local to be mapped to a volume instead of having multiple volumes for /local/notesdata, /local/translog and /local/daos.
Mounting /local to a single volume will work fine, but if you want to build a high performance Domino server we are recommending to have separate volumes for those different parts. We even added directories for nif and ft to allow separate volumes for those parts as well.
The Docker volume mapping is comparable to creating mount points. It's about providing most flexibility with best practices in mind.

5. Preparation for new binary location
The project now now includes a new start script version 3.3.0 which is already prepared for changing the program directory default location ( /opt/ibm/domino ) with Domino 11.
The start script and all docker image script files have been prepared to support a different binary location in future. All places in the scripts use standard variables. And we will keep the LOTUS variable to point to the binary location.

Feedback & Future planning
One of the next features will be to allow cross certification with existing IDs. The certifier.id is currently staying on the first installed machine. So the idea is to cross certify a provided safe.id.
This is specially helpful to create test environments. A small servertask will take care of creating cross certifying a safe.id and adding it to the LocalDomainAdmin group.
Another idea is to integrate this functionality into the toolchain which sets up the server, we have not decided yet.
We are looking for your feedback so leave a comment with your suggestions for improvement or create an issue in our domino-docker project
Tagged with: Administration Best Practice Domino Docker
Comments
No Comments Found
Go ElsewhereSubscribe to RSSAboutStay ConnectedAnd More
Thomas Hampel, All rights reserved.