A couple of years ago, we moved our VM solution for the TM351 data management and analysis course to a Docker based solution.
I had tried the Docker solution way back when, but at the time Docker was still immature, cross-platform running was incosistent, and the most promising UI way in was the third party (and not cross-platform?) Kitematic application.
Now we have Docker Dashboard on the desktop (though you still can’t easily pull an arbitrary image using it?) and a Faculty-based, academic-run (not me!) JupyterHub server, with a Docker image launcher for launching user environments, supporting several modules.
A central IT solution, a home-built container launcher, is also supporting at least one module, with k8s managaed third party GPU servers, but that has always seemed a ridiculous solution to me. [REDACTED BIT HERE]
Poking around the Docker Dashboard for the first time in a while, I noticed that you can now install extensions into the dashbaord. One such extension is portainer, which I’ve played with a bit before. Portainer is an open source GUI for managing docker images and containers that is rather more comprehensive than the Docker dashboard. It can be used to pull images, manage containers, manage Docker compose “stacks”, and a whole lot more.
Portainer also allows you to subscribe to a remote JSON file that publishes a list of custom images and stacks that you are curating for some purpose. For example, publishing a list of course or module related Docker images.
From a quick play with an old Portainer custom app feed I had laying around, it’s easy enough to push a curated list of containers into the Docker Dashboard Portainer extension, so they can be easily pulled by students.
Launching containers from the images is still easier in some respects using the Docker Dashboard. Containers can be launched in Portainer in two ways: a “quick start” route from the custom app list, or via a more comprehensive UI from the list of downloaded images. In the quick start route, when mounting a local directory into a container, Portainer requires you to manually type in the path, whereas the Docker Desktop gives you a directory browser. However, Portainer allows you to map additional ports, whereas Docker Desktop will only map ports that are mapped via the Dockerfile.
On the other hand, Docker Dashboard lets you pass in environment variables:
You can pass in environment variables using the comprehensive container launcher UI in Portainer, but not the quick start UI from the custom app list. However, the custom app feed [specification] can specify environment variables — and more — for each container to be launched from each listed image.
Biulding a custom Docker Dashboard extension doesn’t look too hard, though I wonder how you can distribute them if you don’t publish them in the public extensions marketplace? Which raises the interesting possibility of what a course/module related extension might look like, or a “open home computing lab” extension, that could perhaps match the offerings of the hosted Open Computing Lab UI in terms of launching and managaing course related containers locally. (I previously explored simplifying the open source portainer UI, so that might provide a hacky way of doing a POC. As well as the public portainer repo, there is also a repo for the portainer extension.)
I also notice that Docker Desktop is testing support for WASM containers [announcement post]. These containers can be launched as standalone containers, or as part of a combination launched via Docker Compose. I haven’t had a chance to play with any of these containers, let alone trying to build one, but things on my to-play-with list include working through an example of building a WASM app container, eg as per the example in WebAssembly: Docker without containers! and then trying to build a postgres-wasm container. Or maybe a Datasette-wasm container (eg drawing on whatever it took to get datasette-lite to work)?
The WASM support also makes me wonder whether a “Docker-lite” desktop app is possible that doesn’t need to hook into o/s virtualisation support (which is still one of the faff things that can raise issues when supporting distance edcuation students working on their own machines), but that can simply run WASM containers. This would have the advantage of both lighter containers in terms of download size (WASM containers can be much smaller than “traditional” containers) and fewer installation/configuration steps. There should also be fewer “side-effects” when installing such an application onto someone’s machine, and then removing it without leaving a trace.
The WASM approach also raises interesting possibilities for other deployment models. For example, WASM on the server, where a WASM container runs rather than a “traditional” container. Hmmm, JupyterLite runs via Pyodide WASM; so: is there a demo of a JupyterLite WASM Docker container anywhere? Or publishing of WASM applications via a simple http webserver so that the user can run the application “browser locally”. A big question for the WASM on the server and WASM in the browser approach is how to deal with file persistence, for example, in browser storage, or by mapping onto a local filesystem. (Are there approaches yet that demo mounting browser storage on the local filesystem?) At which point, I suspect you also start to get security concerns.
PS To check: does Docker Dashboard and the dashboard extensions run on a Raspberry Pi? How about the WASM support?
PPS via David Wiliey/@opencontent, WordPress in the browser via WASM: demo / about.
OUseful.Info, the blog... 