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.
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
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.
Saving a Container Image as an Archive
The following example shows how to save a locally available Container Image as a compressed tar archive.
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
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
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 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
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.
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
The following command line example will build the actual Container Image
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.
Last updated
Was this helpful?