MSGID: dont-email.me df294fc6
REPLY: news.chiark.greenend.org.uk 1caa0e02
TZUTC: 1000
CHRS: CP437 2
REPLYADDR: Pancho.Jones@protonmail.com
REPLYTO: 3:633/280.2@fidonet UUCP
PID: Mozilla Thunderbird
TID: MBSE-FIDO 1.1.2 (Linux-x86_64)
RFC-Message-ID: <109snd3$21u94$1@dont-email.me>
RFC-From: Pancho
RFC-References: <109h5bq$309ra$1@dont-email.me>
RFC-Organization: A noiseless patient Spider
RFC-Content-Type: text/plain;
RFC-Content-Transfer-Encoding: 8bit
RFC-Injection-Date: Wed, 10 Sep 2025 20:34:44 +0000 (UTC)
RFC-Cancel-Lock: sha1:YTp50QCzCHHXU/KOvfthWqlOqoY=
RFC-In-Reply-To:
RFC-Content-Language: en-GB
On 9/6/25 22:53, Theo wrote:
> Richard Kettlewell wrote:
>> Jimmy Logan writes:
>>> I'd like to create some kind of service container on rpi4b which I have,
>>> which would allow me to just install something in a normal way (not
>>> programming the whole installation process like dockerfiles), without
>>> changing anything on the current OS.
>>
>> You don’t need any Dockerfiles to use Docker. So, perhaps Docker will
>> meet your needs.
>
> 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.
>
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.
--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)
SEEN-BY: 19/38 105/81 106/201 128/187 129/14 305 153/7715 154/110
SEEN-BY: 218/700 226/30 227/114 229/110 111 200 206 275 300 317 400
SEEN-BY: 229/426 428 470 616 664 700 705 266/512 291/111 292/854 320/219
SEEN-BY: 322/757 342/200 396/45 460/58 633/280 281 418 420 509 2744
SEEN-BY: 712/848 770/1 902/26 2320/105 5020/400 5075/35
PATH: 633/280 229/426
|
