🆕Containers in Bench

Bench has the ability to handle containers inside a running workspace. This allows you to install and package software more easily as a container image and provides capabilities to pull and run containers inside a workspace.

Bench offers a container runtime as a service in your running workspace. This allows you to do standardized container operations such as pulling in images from public and private registries, build containers at runtime from a Dockerfile, run containers and eventually publish your container to a registry of choice to be used in different ICA products such as ICA Flow.

Setup

The Container Service is accessible from your Bench workspace environment by default.

The container service uses the workspace disk to store any container images you pulled in or created.

To interact with the Container Service, a container remote client CLI is exposed automatically in the /data/.local/bin folder. The Bench workspace environment is preconfigured to automatically detect where the Container Service is made available using environment variables. These environment variables are automatically injected into your environment and are not determined by the Bench Workspace Image.

Container Management

Use either docker or podman cli to interact with the Container Service. Both are interchangeable and support all the standardized operations commonly known.

Pulling a Container Image

To run a container, the first step is to either build a container from a source container or pull in a container from a registry

Public Registry

A public image registry does not require any form of authentication to pull the container layers.

The following command line example shows how to pull in a commonly known image.

The Container Service uses Dockerhub by default to pull images from if no registry hostname is defined in the container image URI.

# Pull Container image from Dockerhub 
/data $ docker pull alpine:latest  

Private Registry

To pull images from a private registry, the Container Service needs to authenticate to the Private Registry.

The following command line example shows how to instruct the Container Service to login into the Private registry.hub.docker.com registry

# Pull a Container Image from Dockerhub 
/data $ docker login -u <username> registry.hub.docker.com 
Password:  
Login Succeeded! 
/data $ docker pull registry.hub.docker.com/<privateContainerUri>:<tag> 

Depending on your authorisations in the private registry you will be able to pull and push images. These authorisations are managed outside of the scope of ICA.

Pushing a Container Image

Depending on the Registry setup you can publish Container Images with or without authentication. If Authentication is required, follow the login procedure described in Private Registry

The following command line example shows how to publish a locally available Container Image to a private registry in Dockerhub.

# Push a Container Image to a Private registry in Dockerhub 
/data $ docker pull alpine:latest 
/data $ docker tag alpine:latest registry.hub.docker.com/<privateContainerUri>:<tag> 
/data $ docker push registry.hub.docker.com/<privateContainerUri>:<tag> 

Saving a Container Image as an Archive

The following example shows how to save a locally available Container Image as a compressed tar archive.

# Save a Container Image as a compressed archive 
/data $ docker pull alpine:latest 
/data $ docker save alpine:latest | bzip2 > /data/alpine_latest.tar.bz2 

This lets you upload the container image into the Private ICA Docker Registry.

Listing Locally Available Container Images

The following example shows how to list all locally available Container Images

# List all local available images 
/data $ docker images 
REPOSITORY                TAG         IMAGE ID      CREATED      SIZE 
docker.io/library/alpine  latest      aded1e1a5b37  3 weeks ago  8.13 MB 

Deleting a Container Image

Container Images require storage capacity on the Bench Workspace disk. The capacity is shown when listing the locally available container images. The container Images are persisted on disk and remain available whenever a workspace stops and restarts.

The following example shows how to clean up a locally available Container Image

# Remove a locally available image 
/data $ docker rmi alpine:latest 

When a Container Image has multiple tags, all the tags need to be removed individually to free up disk capacity.

Running a Container

A Container Image can be instantiated in a Container running inside a Bench Workspace.

By default the workspace disk (/data) will be made available inside the running Container. This lets you to access data from the workspace environment.

When running a Container, the default user defined in the Container Image manifest will be used and mapped to the uid and the gid of the user in the running Bench Workspace (uid:1000, gid: 100). This will ensure files created inside the running container on the workspace disk will have the same file ownership permissions.

Run a Container as a normal user

The following command line example shows how to run an instance a locally available Container Image as a normal user

# Run a Container as a normal user 
/data $ docker run -it --rm alpine:latest 
~ $ id 
uid=1000(ica) gid=100(users) groups=100(users)  

Run a Container as root user

Running a Container as root user maps the uid and gid inside the running Container to the running non-root user in the Bench Workspace. This lets you act as user with uid 0 and gid 0 inside the context of the container.

By enabling this functionality, you can install system level packages inside the context of the Container. This can be leveraged to run tools that require additional system level packages at runtime.

The following command line example shows how to run an instance of a locally available Container as root user and install system level packages

# Run a Container as root user 
/data $ docker run -it --rm --userns keep-id:uid=0,gid=0 --user 0:0 alpine:latest 
/ # id 
uid=0(root) gid=0(root) groups=0(root) 
/ # apk add rsync 
... 
/ # rsync  
rsync  version 3.4.0  protocol version 32 
... 

When no specific mapping is defined using the --userns flag, the user in the running Container user will be mapped to an undefined uid and gid based on an offset of id 100000. Files created in your workspace disk from the running Container will also use this uid and gid to define the ownership of the file.

# Run a Container as a non-mapped root user 
/data $ docker run -it --rm --user 0:0 alpine:latest 
/ # id 
uid=0(root) gid=0(root) groups=100(users),0(root) 
/ # touch /data/myfile 
/ #  
# Exited the running Container back to the shell in the running Bench Workspace 
/data $ ls -al /data/myfile  
-rw-r--r-- 1 100000 100000 0 Mar 13 08:27 /data/myfile 

Building a Container

To build a Container Image, you need to describe the instructions in a Dockerfile.

This next example builds a local Container Image and tags it as myimage:1.0 The Dockerfile used in this example is

FROM alpine:latest 
RUN apk add rsync 
COPY myfile /root/myfile 

The following command line example will build the actual Container Image

# Build a Container image locally 
/data $ mkdir /tmp/buildContext 
/data $ touch /tmp/buildContext/myFile 
/data $ docker build -f /tmp/Dockerfile -t myimage:1.0 /tmp/buildContext 
... 
/data $ docker images 
REPOSITORY                TAG         IMAGE ID      CREATED             SIZE 
docker.io/library/alpine  latest      aded1e1a5b37  3 weeks ago         8.13 MB 
localhost/myimage         1.0         06ef92e7544f  About a minute ago  12.1 MB 

When defining the build context location, keep in mind that using the HOME folder (/data) will index all files available in /data, which can be a lot and will slow down the process of building. Hence the reason to use a minimal build context whenever possible.