I’m not sure why Docker would be a particularly good (or particularly bad) fit for the scenario you’re referring to.
If you’re suggesting that Docker could make it easy to transfer a system onto a new SD card if one fails, then yes that’s true … to a degree. You’d still need to have taken a backup of the system BEFORE the card failed, and if you’re making regular backups then to be honest it will make little difference if you’ve containerised the system or not, you’ll still need to restore it onto a new SD card / clean OS. That might be a simpler process with a Docker app but it very much depends on which app and how it’s been set up.
I think the idea is rather, that read only container - as the name implies - only read and drive write. Since SD cards aren’t exactly great at being written to often, that could increase the lifetime of the SD card.
I’m still struggling to understand what advantage Docker brings to the set-up.
Maybe the application doesn’t need to write anything to disk at all (which seems unlikely) but if so, then you’re not saving any disk-write cycles by using docker.
Or maybe you want it only to write to filesystems mounted from longer-life storage e.g. magnetic disk and mark the SD card filesystems as --read-only. In which case you could mount those filesystems directly in the host OS (indeed you have to do this to make them visible to docker) and configure the app to use those directly, no need for docker.
Docker has many great features, but at the end of the day it’s just software - it can’t magic away some of the foundational limitiations of system architecture.
I think you still don’t get the idea of read-only containers.
They’re set up in a way that prohibits any writes except some very well defined locations. That could mean piping logs directly to stdout and don’t write them to disk, or not caching on disk, etc.
That is standard practice in professional setup (though for security reasons).
No, it’s not magic, but software can get configured, you know? And if you do that properly, you might see a change in behavior.
I’m not sure why Docker would be a particularly good (or particularly bad) fit for the scenario you’re referring to.
If you’re suggesting that Docker could make it easy to transfer a system onto a new SD card if one fails, then yes that’s true … to a degree. You’d still need to have taken a backup of the system BEFORE the card failed, and if you’re making regular backups then to be honest it will make little difference if you’ve containerised the system or not, you’ll still need to restore it onto a new SD card / clean OS. That might be a simpler process with a Docker app but it very much depends on which app and how it’s been set up.
I think the idea is rather, that read only container - as the name implies - only read and drive write. Since SD cards aren’t exactly great at being written to often, that could increase the lifetime of the SD card.
I’m still struggling to understand what advantage Docker brings to the set-up.
Maybe the application doesn’t need to write anything to disk at all (which seems unlikely) but if so, then you’re not saving any disk-write cycles by using docker.
Or maybe you want it only to write to filesystems mounted from longer-life storage e.g. magnetic disk and mark the SD card filesystems as --read-only. In which case you could mount those filesystems directly in the host OS (indeed you have to do this to make them visible to docker) and configure the app to use those directly, no need for docker.
Docker has many great features, but at the end of the day it’s just software - it can’t magic away some of the foundational limitiations of system architecture.
I think you still don’t get the idea of read-only containers.
They’re set up in a way that prohibits any writes except some very well defined locations. That could mean piping logs directly to stdout and don’t write them to disk, or not caching on disk, etc.
That is standard practice in professional setup (though for security reasons).
No, it’s not magic, but software can get configured, you know? And if you do that properly, you might see a change in behavior.
If the application in question doesn’t need to write anything, it also doesn’t write outside of docker, so it also won’t wear down the SD card.
If the app has to write something, a fully read-only container will simply not work (the app will crash or fail otherwise).