honestly, it’s not worth it. hard drives are cheap, just plug one via USB 3 and make all the write operations there. that way your little SBC doesn’t suffer the performance overhead of using docker.
The point with an external drive is fine (I did that on my RPi as well), but the point with performance overhead due to containers is incorrect. The processes in the container run directly on the host. You even see the processes in ps. They are simply confined using cgroups to be isolated to different degrees.
docker images have a ton of extra processes from the OS they were built in. Normally a light distro is used to build images, like Alpine Linux. but still, you’re executing a lot more processes than if you were installing things natively.
Of course the images does not contain the kernel, but still they contain a lot of extra processes that would be unnecessary if executing natively.
To execute more than one process, you need to explicitly bring along some supervisor or use a more compicated entrypoint script that orchestrates this. But most container images have a simple entrypoint pointing to a single binary (or at most running a script to do some filesystem/permission setup and then run a single process).
Containers running multiple processes are possible, but hard to pull off and therefore rarely used.
What you likely think of are the files included in the images. Sure, some images bring more libs and executables along. But they are not started and/or running in the background (unless you explicitly start them as the entrypoint or using for example docker exec).
honestly, it’s not worth it. hard drives are cheap, just plug one via USB 3 and make all the write operations there. that way your little SBC doesn’t suffer the performance overhead of using docker.
The point with an external drive is fine (I did that on my RPi as well), but the point with performance overhead due to containers is incorrect. The processes in the container run directly on the host. You even see the processes in
ps. They are simply confined using cgroups to be isolated to different degrees.docker images have a ton of extra processes from the OS they were built in. Normally a light distro is used to build images, like Alpine Linux. but still, you’re executing a lot more processes than if you were installing things natively.
Of course the images does not contain the kernel, but still they contain a lot of extra processes that would be unnecessary if executing natively.
Containers don’t typically have inits, your process is the init - so no extra processes are started for things other than what you care about.
To execute more than one process, you need to explicitly bring along some supervisor or use a more compicated entrypoint script that orchestrates this. But most container images have a simple entrypoint pointing to a single binary (or at most running a script to do some filesystem/permission setup and then run a single process).
Containers running multiple processes are possible, but hard to pull off and therefore rarely used.
What you likely think of are the files included in the images. Sure, some images bring more libs and executables along. But they are not started and/or running in the background (unless you explicitly start them as the entrypoint or using for example
docker exec).