Earlier quoted context omitted.
You realize how you're not making any sense. Docker is another abstraction so it can not be better in terms of resource usage than running whatever process you are now running inside docker. You literally have more overhead with the docker approach in terms of all resource utilization. You now have all the overhead of an OS and then you are layering docker on top of it. The OS has not gone away. It is still managing…
Rather it's replacing systems like systemd and various other system daemons with the docker equivalents. For example why run a network supervision daemon if dockerd or equivalent handle all the important complex pieces of networking via container orchestration? Why have a local package manager, or system port mapper.
Tiny Linux distro that runs the entire OS as Docker containers
111–120 of 177 posts
Re: Tiny Linux distro that runs the entire OS as Docker containers
#112Earlier quoted context omitted.
Actually, Lennart proposed some years ago exactly how you could "fix" the OS to apply the ideas from containerisation. http://0pointer.net/blog/revisiting-how-we-put-together-linu...
This seems horribly complicated and ridiculous especially since when it was written btrfs which was a requirement was pretty terrible.
Re: Tiny Linux distro that runs the entire OS as Docker containers
#113Earlier quoted context omitted.
>despite being infinitely better How and why? You're being condescending. I like Docker and if anything you make me not want to try systemd-nspawn with this attitude.
Great job proving the second part of what he said
"Go on, try it" doesn't help me in any way. I believe that Docker has more attention, you might call it hype. I'd say "eyes" instead. We have here a way to shown to run everything in Docker, parent link of thread (RancherOS.) That's great, I already went ahead and tried it. I'm still waiting to be convinced that I should try nspawn instead.
Without your help, I won't even know what OS Distro I can download to try it, let alone why it's better.
Re: Tiny Linux distro that runs the entire OS as Docker containers
#114Earlier quoted context omitted.
I work in a big company. It's much easier for us to spin up a container to run whatever experimental program we've thought might be useful to help us do our job than to provision a real box for it to run on or fit it into the whole bureaucracy. If it's actually useful we'll find someplace for it to live (or just in containers if that's all that's needed). If not, finding that out was cheap.
This is a more charitable interpretation of what I meant: "we can quickly test the value of an idea via a prototype without the cost of making it super well behaved in other areas." Which is an excellent application of containers! I just sometimes wonder if the cart hasn't gotten in front of the horse on the whole container front. The fact that the term "bare iron" has been hijacked to mean "not under virtualization"…
Re: Tiny Linux distro that runs the entire OS as Docker containers
#115Earlier quoted context omitted.
One huge benefit of containers is that you can treat a program as something atomic: Delete the container and it's gone, as if it were never installed. Modern package management systems like APT spend a lot of effort installing and removing files, and they don't do it completely; any file created by a program after it is installed will not be tracked. You could accomplish the same thing in other ways (as Apple's sandb…
"Modern package management systems like APT spend a lot of effort installing and removing files, and they don't do it completely" Well, there /is/ another way to do it. STATIC LINK ALL THE THINGS Which would work if licenses and copyrights didn't exist.
Managing internal dependencies (like libraries) is another concern entirely. But containers are good for that, too.
Re: Tiny Linux distro that runs the entire OS as Docker containers
#116Earlier quoted context omitted.
Containers are just unifying the concepts of namespaces and cgroups in to environments -- I'm not sure that there's a better way to do that at the OS level, as I enjoy the primitives being separate and having the potential to remix them as my understanding of containerization evolves. (Okay, so there's a few other things mixed in like SELinux settings.) I think there's interesting ideas of environments in other opera…
One obvious tweak would be to make it so that every bit of isolation that containers now get by default, you instead get per POSIX process-group/session or somesuch, so you don't have to think in terms of containers to get the benefit of containers—they're just something the OS does transparently whenever you make it clear that a set of processes forms a distinct, separate cluster. Making existing programs compatible…
Re: Tiny Linux distro that runs the entire OS as Docker containers
#117Earlier quoted context omitted.
One huge benefit of containers is that you can treat a program as something atomic: Delete the container and it's gone, as if it were never installed. Modern package management systems like APT spend a lot of effort installing and removing files, and they don't do it completely; any file created by a program after it is installed will not be tracked. You could accomplish the same thing in other ways (as Apple's sandb…
"Modern package management systems like APT spend a lot of effort installing and removing files, and they don't do it completely" Well, there /is/ another way to do it. STATIC LINK ALL THE THINGS Which would work if licenses and copyrights didn't exist.
I don't think it would.
Dynamic linking allows a library to be patched once and have the patch apply to all the programs using it. If every program was statically linked, you would have to update each one individually.
Not to mention the waste of space.
I'm guessing much of that is moot these days, but IMHO it's still something to aim for.
Re: Tiny Linux distro that runs the entire OS as Docker containers
#118Earlier quoted context omitted.
I think the "just as easily" is highly debatable. I'm not a container evangelist by any stretch, but if you were going to take a "just chroot it" approach, the very first thing you'd want to do to ease the operational burden is define some kind of standard app packaging format that defines what's in the chroot and an entry point and an environment, and maybe some scheme for mapping external data and various other nic…
> I think the "just as easily" is highly debatable. Heads up, you're talking about a different thing. You want to run these things as normal operations, but gunnihinn was talking about deploying an application to check if it is of any value. Chroot is just enough to make a mess as the application's developer instructed in INSTALL.txt without the need to worry about cleaning up afterwards. And by the way, you seem to…
And I'm not confusing containers and Docker, I'm just speaking a bit imprecisely. In my experience, conversations about "containers" are rarely about raw containers, but rather some specific containerization scheme and tools (e.g. docker). I suspect everyone in this entire subthread means "docker containers" when they says "containers."
Re: Tiny Linux distro that runs the entire OS as Docker containers
#119Earlier quoted context omitted.
Actually, Lennart proposed some years ago exactly how you could "fix" the OS to apply the ideas from containerisation. http://0pointer.net/blog/revisiting-how-we-put-together-linu...
This seems horribly complicated and ridiculous especially since when it was written btrfs which was a requirement was pretty terrible.
Re: Tiny Linux distro that runs the entire OS as Docker containers
#120Earlier quoted context omitted.
"Modern package management systems like APT spend a lot of effort installing and removing files, and they don't do it completely" Well, there /is/ another way to do it. STATIC LINK ALL THE THINGS Which would work if licenses and copyrights didn't exist.
> Which would work if licenses and copyrights didn't exist. I don't think it would. Dynamic linking allows a library to be patched once and have the patch apply to all the programs using it. If every program was statically linked, you would have to update each one individually. Not to mention the waste of space. I'm guessing much of that is moot these days, but IMHO it's still something to aim for.