I recently tried out to run tljh in a docker container. At a very early stage the process was aborted because of a missing systemd. On the other hand, podman comes with systemd supported. I thought it could be a chance I need to try. Is there any reason why it shouldn’t be done?
Why I plan to do this? TLJH couldn’t easily be uninstalled. The manual suggests to just discard the whole VM. Depending on the IT department, obtaining a VM is cumbersome and related with processes. On a VM, I can easily run a second layer of isolation. If I run a VM inside a VM, I expect a quite low performance so that I want to avoid that. This is why for me some kind of slim containerization and isolation is important.
Would love for you to try it out!
We actually do have a Dockerfile that builds an image that works, but I don’t think it’s a good idea
Sure, I will give it a shot. Could you quickly explain what problems you see with the tljh dockerfile? Why wouldn’t you use it in production? Thank you very much for the insights!
https://developers.redhat.com/blog/2016/09/13/running-systemd-in-a-non-privileged-container/ has some information. Mostly just parroting upstream warnings - I haven’t actually investigated specific reasons here.
The question here is really why does one want to use docker. If one believes that because of docker they can keep any kind of secrets on the host machine - no, not a good idea! There is more than one article in the internet about how docker is not good to isolate processes from each other and from the host in terms of security in case of a malicious attack.
If, however, the docker host’s purpose is only to make the setup and configuration of a JupyterHub more flexible, then I believe we are on another page. I only want to easily discard old settings and old user data, try out plugins, etc. So I think your report is helpful, even though during 5 years I hope some of those things have changed.
https://developers.redhat.com/blog/2019/04/24/how-to-run-systemd-in-a-container/ is another blog article that also mentions the shortcomings of the combination of docker and systemd. However, they say podman has that solved. I will try that soon.
For the records: I created a podman container as described at Setting up Development Environment — The Littlest JupyterHub v0.1 documentation . While bootstrapping inside the podman container, an error popped up after the traefik installation was reported on the shell. The error message was
System has not been booted with systemd as init system (PID 1). Can't operate. and it was related with the systemctl daemon-reload. A very similar and more detailled report can be found at podman build fails to emulate systemd (daemon-reload) while setting up postgresql · Issue #4909 · containers/podman · GitHub . Therefore, currently podman can not replace docker and solve all issues witht that. There are some solutions which might be applicable (more examination necessary) but it seems like they all would require changes to the Dockerfile.