lightweight virtualization

You don’t need any Dockerfiles to use Docker. So, perhaps Docker will meet your needs.

To create a container you can SSH into:

$ docker run --detach -p 127.0.0.1:2222:22 --name example debian:stable sh -c 'apt update && apt install -y openssh-server && /usr/sbin/sshd -D'

This takes a little while to complete, use ‘docker logs -f example’ to monitor it. The base container is very slimmed down so you may want to add other packages to the install command here.

Create a login:

$ docker container exec -it example bash root@0c09f6c2a5e5:/# userdel rjk root@0c09f6c2a5e5:/# adduser rjk New password: Retype new password: passwd: password updated successfully Changing the user information for rjk Enter the new value, or press ENTER for the default Full Name []: Room Number []: Work Phone []: Home Phone []: Other []: Is the information correct? [Y/n] y

...and then login:

$ ssh rjk@127.0.0.1 -p 2222 rjk@127.0.0.1's password: Linux 0c09f6c2a5e5 6.12.34+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.34-1+rpt1 (2025-06-26) aarch64

The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Sat Sep 6 13:35:59 2025 from 172.19.0.1 -bash: warning: setlocale: LC_ALL: cannot change locale (en_GB.UTF-8): No such file or directory rjk@0c09f6c2a5e5:~$

This all works on a Pi 5 running trixie. I don’t know of a reason it wouldn’t work on a 4B but I’ve not tested it.

Of course the userdel part is unnecessary; left over from experimentation to get the example right.

Thanks for the suggestion, I'll try docker, or maybe go for podman - a bit less amount of abstractions. The lxc/lxd/incus kindof solution would have been perfect for this, and I was even thinking about proxmox , but I think its a bit too heavy for a raspberry pi - but yes I know k8s is also possible, I just dont want the admin overhead when its not necessary. The other end of of the spectrum would be hand crafted chroot, there is a very good article about that

Isn't the problem that Docker isn't persistent? Next time the container is started it loses the state from the previous time - so any changes you make, starting with installing any packages and then on, have to be done again?

You can address that two ways. One is to map volumes into the container so that they will keep the data on the host filesystem and it'll be there again when the container restarts. Or you can make your changes then snapshot the container ('docker commit') and then launch the snapshot as a new container.

Snapshots may suffice for installing your software in the normal way and then making a new snapshot which will then contain the software every time the container is started, but any changes made to the snapshot will be lost. So you'd have to use volumes to ensure that eg a database persists from run to run.

When I want persistent containers I use incus; they do say they support aarch64 so I'm surprised it doesn't work. If it's not working in Raspberry Pi OS you could try another Linux distro like Ubuntu. (Before it was forked, Incus was originally called LXD and written by Canonical so Ubuntu was their primary supported platform)

Theo

Try LXC. Ubuntu also have some extension of that, which they call LXD. (Confusingly, the commands for managing LXC are all one word beginning with the “lxc-” prefix, while LXD is managed via a single command called “lxc”.)

For something even lower-level, try systemd-nspawn.

I have made a lot of use of LXC myself. It comes with templates so you can, for example, easily install an Ubuntu userland inside a container under Debian, or even a 32-bit container on a 64-bit OS.

chroot is useless for proper isolation.

You're right, chroot can never be considered a secure isolation, but for separating 'service packages' from 'host os packages', might be enough, I mean, service running in chroot would not be "less secure" than running it from the host, agree?

Docker containers are persistent. If you stop a container then when you restart it, it will have the same contents it did before.

richard@embelyon:~ $ docker container exec -it example bash root@0c09f6c2a5e5:/# ls /persistent ls: cannot access '/persistent': No such file or directory root@0c09f6c2a5e5:/# touch /persistent root@0c09f6c2a5e5:/# exit

richard@embelyon:~ $ docker container stop example example

richard@embelyon:~ $ docker container exec -it example bash Error response from daemon: container

richard@embelyon:~ $ docker container start example example

richard@embelyon:~ $ docker container exec -it example bash root@0c09f6c2a5e5:/# ls -l /persistent

-rw-r--r-- 1 root root 0 Sep 7 08:51 /persistent

If you remove the container and create a new from the same image, then you lose any changes. But the same is true if you destroy a VM or wipe and reinstall a physical computer.

Interesting - I've never come across the 'docker container' command before, only mainly using 'docker run' or 'docker exec'. (Unfortunately it's terrible to google for, since even "docker container" in quotes throws up a million hits about the generic concept)

What happens if you reboot, does the same container keep running including your changes?

Theo

The default behaviour is that a container persists after being stopped (including after reboot of the host), but that it is not restarted. For persistent containers I use ‘--restart unless-stopped’.

Containers would be more reliable.

As Richard says, containers are persistent.

The confusion might be that some people, or at least me, don't rely on this container persistence for standard application persistence. I like volumes, they make it clearer what needs to be backed up.

The tear-down, reproducibility of a non-persistent container was one of the things that appealed to me about Docker. But this was what I regarded as good practice rather than enforced. My perspective is almost certainly skewed by having been a software developer and the unit test way of working. Plus a bitter history of supporting systems that were problematic due to undocumented system changes to the host OS.

This view is ideal, I don't know about pragmatic real systems.

They can be, they need not be. It is entirely possible to mount an instance of tmpfs to hold any writable storage, which will disappear as soon as the container instance terminates.