You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

It is possible to use the Buildah tool to build OCI container images directly on Eiger and Piz Daint. Buildah can only run in rootless mode: rootless mode relies on Linux user namespaces, which are enabled on the compute nodes. The command buildah on Eiger is available directly on /usr/bin, while on Piz Daint you need to load the module Buildah as shown below, after you have accessed a compute node: 

module load daint-gpu  # or daint-mc for multicore nodes
module load Buildah

Limitations

It is not possible to use the gpfs or lustre file systems to store the image layers. In order to circumvent this problem, an ext4 partition is mounted on the compute node allocated using the contbuild Slurm constraint.

Buildah service disruption on Eiger

The intervention planned on February 28th will affect the buildah and stackinator tools on Eiger, which won't be available until further notice

Using Buildah

The first step in order to use Buildah is to create a valid storage configuration file $HOME/.config/containers/storage.conf, following the minimal template provided below:

[storage]
  runroot = "/scratch/local/<username>/runroot"
  graphroot = "/scratch/local/<username>/root"

In the example above, /scratch/local refers to the external ext4 file system mounted on the allocated compute node. Please use the following commands to create an allocation suitable for building container images:

salloc -N1 -C "gpu&contbuild" -A <project> # or -C "mc&contbuild" to allocate a multicore node
ssh $SLURM_NODELIST                        # Use ssh to connect to the compute node

Note that the option -N1 is necessary to specify that only one node is requested, since building container images is not supported with multiple nodes. After making sure that you are logged on the compute node, you can load the default module Buildah available:

module load daint-gpu  # or daint-mc for multicore nodes
module load Buildah

Then it is pretty straightforward to build an image from a Dockerfile using the following commands:

# Change to the directory containing Dockerfile
cd <context_dir>

# Build using Dockerfile
buildah bud --tag <image_tag> .

# Build an image using Dockerfile and the docker format
buildah bud --format=docker --tag <image_tag> .

# Build an image using the docker format and a custom name for the Dockerfile
buildah bud --format=docker -f <custom_dockerfile> -t <image_tag> .

For large container images, tmp might not be adequate as a temporary storage. To use an alternative temporary storage location:

# Use an alternative temporary storage location of the ext4 partition
export TMPDIR=/scratch/local/<tmpdir>

If XDG_DATA_HOME is not defined, the Blob Info Cache is stored under $HOME/.local/share. This, leads to unlock errors for the dvs mount on the compute nodes, similar to: bolt.Close(): funlock error: errno 524. To avoid the above errors, set XDG_DATA_HOME to a path relative to the /scratch/local ext4 mount

Spawning Containers from Images

With Buildah it's possible to spawn a container from a container image using the command buildah from:

# Create container from a given image
buildah from --name <container_name> <image_name>

It is then possible to run interactively inside the spawned container:

buildah run -t <container_name> bash

Commiting a container as a new image

To commit a container (including any changes that may have been made in it) as a container image you can use the command buildah commit:

buildah commit <container_name> <image_tag

Exporting Container Images

Buildah allows exporting container images to a number of different formats. You can export the image with tag <image_tag> using the following command:

buildah push <image_tag> docker-archive:/<my_path>/<archive_name.tar>

The docker-archive format of the example above can be used to import the image using either Sarus or Singularity.

Interacting with Container Registries

Interacting with container registries using Buildah for pulling or pushing container images is straightforward. Buildah uses a registries.conf configuration file which controls the interaction with container registries as well as a policy.json defining the trust policy for container images. Default registries.conf and policy.json files are provided on Piz Daint allowing interaction with DockerHub. Custom configuration files can always be used via the --registries-conf and --signature-policy command line options.

Pulling images

In order to pull container images, use the command buildah pull, which takes one of the following forms:

buildah pull imagename:imagetag

OR

buildah pull myregistry/myrepository/imagename:imagetag

You might have to login to your container registry before being able to pull images. This is performed with one of the following options:

buildah login <registry_url>   # Login by passing the username/password interactively

OR 

buildah login -u <username> -p <password> <registry_url>   # Login by passing username/password as cli options

For instance, in order to login interactively on your personal DockerHub registry where you are registered with <username>, you should run the command below: 

buildah login docker.io/<username> 

Please have a look at the additional options available for buildah login.

Pushing images

In order to push an image to a container registry, you first need to login to it. Afterwards, you should tag the image you want to push according to the name of your container registry and the corresponding repository. This is performed using the command buildah tag and the procedure is similar to docker tag. Then you should use the command buildah push to push the image to the container registry, similarly to docker push.

Once the job allocation has completed, the contents of the /scratch/local ext4 partition are deleted. Therefore, make sure to either push your images to a container registry or export them to an archive


  • No labels