Docker and WSL
Background
Windows:
A host can have several WSL images. Each one:
- has a name
- can use either WSL 1 or 2
- contains a particular OS and version.
- may or may not contain Docker and (if it contains Docker) Docker Compose. Each of these has a version.
If the user has installed Docker Desktop, there will be a WSL image named 'docker-desktop' containing Docker and Docker Compose
Mac/Linux:
The host may or may not contain Docker and (if it contains Docker) Docker Compose. Each of these has a version.
User configuration options
All platforms:
<dont_use_docker/>
Windows
<dont_use_wsl/>
if set, don't use WSL (and hence don't use Docker)
<allowed_wsl>name</allowed_wsl>
allow BOINC to use the given WSL image. BOINC is automatically allowed to use the docker-desktop image if it's present.
Apps that use WSL
The whole Windows filesystem is accessible from WSL, so the app can run in the slot directory, accessing only files there and in the project directory.
Apps use a wrapper, wsl_wrapper. This takes a cmdline arg saying which distro to use
On startup, the wrapper runs 'main token' in the container, in the slot dir. This is a shell script that prints its own PID, then prints 'EOM token', then runs the application
so the wrapper knows it's done.
Poll: ps x ; echo token the wrapper parses this to get CPU time and WSS
Suspend/resume: kill SIGSTOP PID ; echo token
Apps that use Docker
There are 2 variants:
regular: the app version includes a complete Docker image
composer: the app version includes a set of layers and a composer script
In both cases the app version includes an executable (generic Linux executable, no BOINC)
Apps use a wrapper, docker_wrapper.
Windows:
docker_wrapper is similar to wsl_wrapper. It picks a WSL image to use (docker-desktop if it exists). If needed it runs composer to build the Docker image (which lives in the slot directory). It runs a Docker command to run the executable. We need to figure out
- how to stop/start the process
- how to get its WSS
Linux/Mac:
docker_wrapper is pretty much like wrapper, except that
- it may need to use Docker composer to build the image
- we need to figure out how to start/stop and get WSS
Scheduler requests
The host_info part of a sched request includes
All hosts:
- whether WSL is allowed
- whether Docker is allowed
Windows:
- a list of WSL images
for each one:
whether we're allowed to us it
WSL 1 or 2
OS name/version
whether Docker and Composer are present, and versions
Note: we can potentially store this info in the DB, maybe the host.serialnum field
non-Windows:
whether Docker and Composer are present, and versions
client_state.xml:
we don't need to include any of this
Plan class names
WSL apps:
<plan_class>
<name>wsl_foo</name>
<wsl/>
<wsl_version>1|2</wsl_version>
[<os_name>regexp</os_name>]
[<min_os_version>N</min_os_version]
</plan_class>
We can have the convention that the name includes 'wsl', but I don't think this matters.
Docker apps:
<plan_class>
<name>docker_foo</name>
<docker/>
[<composer/>]
[<min_docker_version>n</min_docker_version>]
[<min_composer_version>n</min_composer_version>]
</plan_class>
We can have the convention that the name includes 'docker', but I don't think this matters.