| 1 |
On Fri, Mar 9, 2018 at 3:11 PM, R0b0t1 <r030t1@×××××.com> wrote: |
| 2 |
> On Fri, Mar 9, 2018 at 10:17 AM, Alec Warner <antarus@g.o> wrote: |
| 3 |
>> The containers are nominally stateless, so there is less chance of 'gunk' |
| 4 |
>> building up and surprising me later. It also makes the lifecycle simpler. |
| 5 |
>> |
| 6 |
>> Obviously its somewhat harder for stateful services (databases, etc.) but I |
| 7 |
>> suspect things like SANs (or Ceph) can really provide the storage backing |
| 8 |
>> for the database. |
| 9 |
>> (database "schema" cleanliness is perhaps a separate issue that I'll defer |
| 10 |
>> for another time ;p) |
| 11 |
>> |
| 12 |
> |
| 13 |
> Containers are stateless, which prevents programs from munging state, |
| 14 |
> because there is none. This is okay except when one needs state, which |
| 15 |
> one does for most desktop activities. |
| 16 |
> |
| 17 |
|
| 18 |
Containers don't have to be stateless. However, if you want them to |
| 19 |
be completely disposable then they obviously need to be. |
| 20 |
|
| 21 |
Bind-mounting something into a container is a simple solution for many |
| 22 |
situations. If your desktop only stores state in /home then that is |
| 23 |
probably very practical. You still need to be able to rapidly build a |
| 24 |
suitable desktop container and easily deploy it in the context of |
| 25 |
something like a laptop. But, I don't think this was being proposed |
| 26 |
as a solution for desktops in the first place, which of course then |
| 27 |
raises the issue that until they do cover desktops containers aren't |
| 28 |
really a substitute for keeping your filesystem reasonably clean. |
| 29 |
|
| 30 |
-- |
| 31 |
Rich |
Archives