-
Notifications
You must be signed in to change notification settings - Fork 459
Docker app implementation
Docker and Podman provide similar capabilities: they can build images from Dockerfiles, and run containers, through a CLI interface. They differ in architecture:
-
Docker uses a daemon, which typically runs as root. The CLI program is typically run by a non-root user, and communicates with the daemon over a pipe.
-
Podman doesn't use a daemon. The CLI program works directly. However, the Linux 'control group' mechanism is available only to root. The container pause/unpause mechanism relies on this. So if you want to pause containers (needed for BOINC) you have to run the CLI program as root.
Docker must be installed and configured so that
- the service is always running.
- the user under which the BOINC client runs can run the DOCKER CLI programs. There are various ways to do this: see https://docs.docker.com/engine/install/ubuntu/
We can't use Podman on Unix because the BOINC client can't run apps as root (see above).
WSL and Hyper-V must be enabled. There must be either
- A WSL distro with Podman installed. To do this, you can install a recent Linux distro (e.g. Ubuntu 22.04) from the Windows store, and install Podman on it:
sudo apt update
sudo apt -y install podman
Our plan is to create a WSL with Podman installed, put it on the Windows store, recommend that to volunteers.
- A WSL distro with Docker installed and configured to always run. It suffices to install Docker Desktop.
If both are present, a WSL distro with Podman is used.
We prefer Podman over Docker on Windows because it's simpler (for us and for volunteers who want to do it themselves) to install Podman.
Here's what happens when the BOINC client runs a Docker app:
The BOINC client runs docker_wrapper
(the app version's main program)
and communicates with it (pause/resume etc.)
through shared memory, as with all BOINC apps.
docker_wrapper interacts with Docker
by running the Docker CLI program (using popen()).
It issues commands to list images, build an image,
and start a container, and monitor the container.
docker_wrapper is responsible for getting
input files into the container, and output files out of the container.
It does this by either
- using the 'docker cp' command.
- mounting the slot and project directories in the container, in which case the logic in the container is responsible for finding the files (e.g. parsing the link files in the slot directory to get the physical names in the project directory).
This is controlled by the job config file, job.toml.
Based on info in init_data.xml,
docker_wrapper picks a WSL distro.
Using CreateProcess(), it runs wsl -d distro -u root,
which runs a shell (as root) in WSL,
connected to docker_wrapper by pipes.
Using these pipes, docker_wrapper issues Podman commands,
which run in the WSL container.
These commands build images, run Docker containers, etc.
The WSL container shares the host filesystem. The shell's current directory is that of docker_wrapper, namely the job's slot directory. Moving files in/out of the Docker container is done the same as in the Unix case.