Docker Container With VersionVault View-Extended Access

Introduction

This blog explains how to configure a Docker host installed with HCL VersionVault and Docker that provides Docker Container with View-Extended Access. In this method, the Docker host shares only its viewroot, view storage, and VOBs storage. The VersionVault binaries are not shared; hence, users can access VOB elements using view-extended access and cannot perform any VersionVault operations. A container is just configured to allow access to views and VOBs that are hosted on the Docker host and no VersionVault configuration files need to be copied or customized.

1. Prerequisites for the Integration of VersionVault and Docker Containers

We need the four things below to be installed, up and running on the Linux host.

1. HCL VersionVault version 2.0.1 or later
2. Docker
3. NFS service
4. Automounter service

2. Installing Docker and VersionVault on the Linux Host

2.1. VersionVault Installation

• The Docker host should minimally have VersionVault 2.0.1 configured to run as a VersionVault dynamic view client.
• On the Docker host, VersionVault minimal developer installation only is required, since it installs the smallest number of VersionVault components required for a command-line user’s software development workstation.
• The major components included and required to be shared with the Docker container are viewroot, view storage, and VOBs storage.
• IBM Installation Manager 1.8.6, 1.9.1, and its future fix packs are required to install HCL VV 2.0.1 on the Docker host.

• Below is the screenshot of the “cleartool -version” command after installation of VV 2.0.1.

2.2. Docker Installation

• Any latest version of Docker can be installed on the Linux host with VersionVault 2.0.1. Below is the Docker Engine installation overview link which shares installation steps for different Linux platforms.

https://docs.docker.com/engine/install/

3. Installing NFS Server and Linux Automounter on Docker Host

• VersionVault uses NFS and the Linux automounter to access view or VOB storage. The Docker host system must be configured for NFS and the Linux automounter.

3.1. Installing NFS Server

• In this blog post I used RedHat OS. The commands given below will vary depending on the specific Linux distribution used.

Step 1: Update server and set hostname.

Your server should have a static IP address and static hostname that persists reboots.

Step 2: Install NFS Server

Next is the installation of the NFS server packages on the Linux host.

After the installation, start and enable nfs-server service.

Status should show “running.”

3.2. Installing Linux Automounter

Step 1: Install autofs on the Linux host.

• When installing the AutoFS package, the installation process will:
• Create multiple configuration files in the /etc directory such as auto.master, auto.net, auto.misc, and so on.
• Create the AutoFS service in systemd.
• Add the “automount” entry to your “nsswitch.conf” file and link it to the “files” source.

Step 2: Right after the installation, make sure that the AutoFS service is running with the “systemctl status” command.

Step 3: You can also enable the AutoFS service for it to be run at startup.

4. VOB and View Creation on Docker Host

• When creating VOBs/Views on Docker host to be used within the containers, you should specify the options: -host, -hpath, and -gpath. Both hpath and gpath should be the global pathname of the VOB/View storage directory.

For example, suppose you would like to create a VOB/View residing on a machine whose hostname is build_host. Our Docker host and VOB/View server host build_host uses the automounter.

To create a VOB/View on the Docker host to be used within a container, you would do the following:

cleartool mkview -tag testview -host build_host-hpath /net/build_host/viewstg/testview.vws -gpath /net/build_host/viewstg/testview.vws /net/build_host/viewstg/testview.vws

cleartool mkvob -tag /vob/testvob -host build_host -hpath /net/build_host/vobstg/testvob.vbs – gpath /net/build_host/vobstg/testvob.vbs /net/build_host/vobstg/testvob.vbs

This is required if the VOB/View resides on the Docker host or Docker container.

It is recommended that Docker containers use VOBs/Views external to the Docker container, since both storage and hostname can be temporary depending on how the container is configured.

5. Sample Docker Container

5.1. Docker Container with View-Extended Access

• As mentioned in the intro of this blog post, in this method we will not be allowed to create a view inside a container and access the VOB to create a new file/directory element or allowed to modify existing file/directory elements. We can only access view root directory and view the VOB elements.
• The Docker build directory consists of Dockerfile, config_ssh.sh, config_dir, and docker_compose.yml.
• The Linux base image must be supported by the VersionVault release running on the Docker host, which should also support the init process. Both RedHat and SUSE provide base images within their registries.
• Linux base images might not contain all the packages required to run VersionVault. The user must update the container to install these packages. Refer to Technotes 535653, 887639, and 718343.
• For more information on the Docker build directory and sample Dockerfile, docker_compose.yml, config_ssh.sh, and config_dir related to Container with View-Extended Access, refer to the link below. In the Resources dropdown in the upper-right corner of the window, look for the link to the article “HCL VersionVault and Docker Containers.“

https://www.hcltechsw.com/versionvault

6. Final Integration in Action

• Once the Dockerfile and docker_compose.yml file are developed with all the required configuration details, you need to navigate into the Docker build directory and perform the command below to build and run the container. The “-d” argument is used to run the container in detachable mode. In this build directory “config_dir” is not available, since we are not sharing VersionVault binaries with container; hence no VersionVault configuration files are required.

• The command above builds, (re)creates, starts, and attaches to containers for a service. To see the running container, run the command below. From the output we can see the new container is up and running with container name “vvdocker_build2_vvault_vextended_1”.

• In order to ssh into the container we need to find out the container’s IP address. To achieve this, we need to run the command below.

At the end of the command output you will find the IP address. Below is the sample snippet for reference.

• Once the container’s IP address has been found, enter the container’s IP and hostname in the Docker host /etc/hosts file. Similarly, after ssh into the container using the account which we created during container creation as per the input provided in Dockerfile, add the Docker host IP address and hostname details in the container’s /etc/hosts file.
• In this blog post Dockerfile is customized to create a “root” account during container creation, hence using the same account for container login and activity. I am not creating any VOB owner account or normal user account within the container like Docker host since it’s not required, as we can’t perform any VersionVault operations in this method. So we will use the root account to navigate into view root directory and access the VOB to view the VOB elements.

• As mentioned earlier, only view root directory, view storage and VOB storage directory are shared with container and no VersionVault binaries.

Please see the snippet below from the docker-compose.yml file configured for container with view-extended access container in which only view root directory (/view) and view/VOB storage directory file system (/net) are shared as volume with the container.

• Below I listed view hosted in docker host and ssh into container.

• Once we log in to the container, we cd to view root directory (/view), then navigate to Docker host view. Once we are inside view now, we can access the VOB and see the elements under it; however, we can only read it and can’t modify it, since this container provides only view-extended access.