3 ms·

Over the last 15 years I've built and maintained Linux distros using apt, with custom debs and pressed files which handle configuration, automatic upgrades for

Over the last 15 years I've built and maintained Linux distros using apt, with custom debs and pressed files which handle configuration, automatic upgrades for most systems, and a small shell script and ssh for the rest. Now it's all docker rather than packages, ansible (which leaves no trace of what it's doing on the target machine) rather than a for I in 'cat hosts'. Fine, but where's the benefit?

JdeBP 10y ago
I encountered TUTTLE the other week. * https://lists.debian.org/debian-user/2017/04/msg00151.html https://lists.debian.org/debian-user/2017/04/msg00151.html * http://www.panix.com/~rst/tuttle.html http://www.panix.com/~rst/tuttle.html * https://lists.debian.org/debian-user/2017/04/msg00437.html https://lists.debian.org/debian-user/2017/04/msg00437.html * https://github.com/rst/Tuttle https://github.com/rst/Tuttle
btschaegg 10y ago
Note that I didn't make any value statement towards Docker - I don't have that much experience with it and found their infrastructure to be rather clunky, when I tried it. So, I'm not sure I'm qualified enough to make definitive statements about its usefulness. I can see, however, a benefit in encapsulating different services in different containers, as this potentially gives you some control over them (available disk space, network usage etc.) * . On top of that, I imagine starting out on a "machine agnostic" approach can be rather useful if you have to change your network landscape further down the line: If your database already is configured as if it were running on its own server, there's certainly a bunch of unintended coupling effects you can avoid. That said, I can't see Docker being the silver bullet it gets hyped up to be sometimes. But that goes for most new and shiny things in the tech space... * And yes, that's already feasible without containers. Docker's approach to this seems to provide a way to do it in a much more automated way than most alternatives though.

JdeBP 10y ago

I encountered TUTTLE the other week. * https://lists.debian.org/debian-user/2017/04/msg00151.html https://lists.debian.org/debian-user/2017/04/msg00151.html * http://www.panix.com/~rst/tuttle.html http://www.panix.com/~rst/tuttle.html * https://lists.debian.org/debian-user/2017/04/msg00437.html https://lists.debian.org/debian-user/2017/04/msg00437.html * https://github.com/rst/Tuttle https://github.com/rst/Tuttle

btschaegg 10y ago

Note that I didn't make any value statement towards Docker - I don't have that much experience with it and found their infrastructure to be rather clunky, when I tried it. So, I'm not sure I'm qualified enough to make definitive statements about its usefulness. I can see, however, a benefit in encapsulating different services in different containers, as this potentially gives you some control over them (available disk space, network usage etc.) * . On top of that, I imagine starting out on a "machine agnostic" approach can be rather useful if you have to change your network landscape further down the line: If your database already is configured as if it were running on its own server, there's certainly a bunch of unintended coupling effects you can avoid. That said, I can't see Docker being the silver bullet it gets hyped up to be sometimes. But that goes for most new and shiny things in the tech space... * And yes, that's already feasible without containers. Docker's approach to this seems to provide a way to do it in a much more automated way than most alternatives though.