Docker

Introduction

Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in.

www.docker.com/whatisdocker

See the docs for installation instructions (if you are on Windows we highly recommend the Docker Desktop WSL 2 backend).

Images

Docker images can be created by Dockerfiles which can be stacked and thus form a directed graph. OGS-6 image definitions are created with ufz/ogs-container-maker. Built images can be found at the GitLab Container Registry. You can also create images from your local source code.

To build an image by yourself create a Dockerfile:

FROM ubuntu:20.04

RUN ...

Run the build command:

docker build -t repo/image_name path/to/directory
  • -t specifies a name for the image, can be arbitrary chosen (but should match the corresponding image on Docker Hub if there is one)
  • The path should specify the directory where the Dockerfile is located

Now you can see your build image with $ docker images.

Run a container

To run commands inside a container:

docker run --rm image_name command_to_run
  • --rm Cleans up after exiting the container

To run an interactive shell add the -it-switch:

docker run --rm -it image_name

It is useful to mount folders from the host operating system in the Docker container, e.g. to edit source code on your host with your favorite editor:

docker run --rm -it -v /host/directory:/container/directory image_name

Prebuilt OGS-6 Docker images

There are docker images provided on the GitLab Container Registry which include everything necessary to build OGS-6 (e.g. registry.opengeosys.org/ogs/ogs/gcc). They are used by the CI but you can also use them for development. For running the images require CPU capabilities equivalent or better than the Intel Ivybridge1 architecture.

Even better for development is the usage of Singularity container because they offer a transparent mapping of the user to container space.


  1. From GCC docs: Intel Ivy Bridge CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND and F16C instruction set support. ↩︎


This article was written by Lars Bilke. If you are missing something or you find an error please let us know.
Generated with Hugo 0.122.0 in CI job 418530 | Last revision: February 1, 2024
Commit: [cmake] Set runtime parameter on larger benchmarks. 86f23e2  | Edit this page on