Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tiny Linux distro that runs the entire OS as Docker containers

github.com

Post reply on HN
Print view View original

71–80 of 177 posts

Re: Tiny Linux distro that runs the entire OS as Docker containers

#71

Post by dboreham »

frik wrote: post #20
gtrevorjay wrote: post #15

This is clearly a trend, though it remains to see if it will garner enough acceptance to actually be "the future". systemd supports launching container-based services via nspawn and already namespaces "legacy" services very heavily. In fact, systemd et al were among the heaviest early drivers of cgroup technology for cleaner starting and stopping of groups of processes.

I am starting to wonder, why not just execute processes directly with cgroups commands? $ cgcreate -g memory,cpu:groupname/foo $ cgexec -g memory,cpu:groupname/foo bash https://wiki.archlinux.org/index.php/cgroups It's the bare basic that libvirt and Docker et al are based anyway. So if you want to run just one process per "container" it seems rather logical to keep it simple and use cgroups commands directly. (Simil…

Because you can't make billions of $ doing that?

Re: Tiny Linux distro that runs the entire OS as Docker containers

#73

Post by nekohacker »

hobarrera wrote: post #52

I'd really love to see some of this stuff transition to the desktop too. Like, for example, containerize Skype, so that it can't read my home. Or contain Firefox to just read `~/.mozilla` and `~/downloads`. For binary blobs I don't trust that much, I'd really value this. For FLOSS stuff, it still provides protection from bugs.

Qubes (https://www.qubes-os.org/) is a good fit for this.

Re: Tiny Linux distro that runs the entire OS as Docker containers

#74

Post by zenlikethat »

frik wrote: post #20
gtrevorjay wrote: post #15

This is clearly a trend, though it remains to see if it will garner enough acceptance to actually be "the future". systemd supports launching container-based services via nspawn and already namespaces "legacy" services very heavily. In fact, systemd et al were among the heaviest early drivers of cgroup technology for cleaner starting and stopping of groups of processes.

I am starting to wonder, why not just execute processes directly with cgroups commands? $ cgcreate -g memory,cpu:groupname/foo $ cgexec -g memory,cpu:groupname/foo bash https://wiki.archlinux.org/index.php/cgroups It's the bare basic that libvirt and Docker et al are based anyway. So if you want to run just one process per "container" it seems rather logical to keep it simple and use cgroups commands directly. (Simil…

A lot of different concepts got conflated into "containers", but a big value add of systems like Docker over this is the use of immutable FS images with built-in distribution mechanisms. Just like it's nice to have git remotes and porcelain around them vs. the limited utility of git if you couldn't push and pull.

Re: Tiny Linux distro that runs the entire OS as Docker containers

#75

Post by duncan_bayne »

zerocrates wrote: post #22
oneplane wrote: post #14

This is starting to smell like a system on top of a system to fix something that could be fixed in the system. Kind-of like implementing a filesystem on top op a filesystem... or putting a database on a filesystem to run another filesystem inside the database, or using a webbrowser as a runtime instead of an operating system.

This kind of thing happens when the base system is ubiquitous and therefore hard to change. It's easier to layer something on top of the base, where people can "opt in" and there's a large preexisting compatible audience. Changing the base layer itself at a minimum requires people to upgrade, and now you don't have that advantage of the preexisting audience anymore. If your improvement requires a breaking change, the…

Which is why highly flexible, powerful base systems are usually preferable to less flexible base systems optimised towards specific goals.

Common Lisp is my go to example of this. It's possible to extend the language to support entirely new paradigms without breaking it, because of the power of the macro system.

Re: Tiny Linux distro that runs the entire OS as Docker containers

#76

Post by gunnihinn »

gumby wrote: post #34
lostmsu wrote: post #26

Earlier quoted context omitted.

The whole notion of containers is basically this. That's why I am not sure why not just fix the OS. If there's anything to fix in the first place.

I always felt, perhaps uncharitably, that the point of containers was "those other programmers are idiots so we need to encapsulate everything for the sake of defense"

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.

Re: Tiny Linux distro that runs the entire OS as Docker containers

#77

Post by technofiend »

wmf wrote: post #43
frik wrote: post #20

Earlier quoted context omitted.

I am starting to wonder, why not just execute processes directly with cgroups commands? $ cgcreate -g memory,cpu:groupname/foo $ cgexec -g memory,cpu:groupname/foo bash https://wiki.archlinux.org/index.php/cgroups It's the bare basic that libvirt and Docker et al are based anyway. So if you want to run just one process per "container" it seems rather logical to keep it simple and use cgroups commands directly. (Simil…

systemd already puts each service in a separate cgroup AFAIK, so commands like cgexec aren't even needed. I suspect people are more interested in namespace separation, but recent versions of systemd can also do that [1]. I don't think systemd has image management so that's still a reason to use Docker. [1] https://www.freedesktop.org/software/systemd/man/systemd.exe...

Systemd creates three "slices": system, user and machine. Daemons started by systemd go in system, user processes in user and virtual machines go in machine.

Each process is placed in a hierarchy​ so you end up with system-httpd which makes it easy to assign or limit resources based on the slice.

Redhat covers it extensively in their performance​ and tuning class.

Re: Tiny Linux distro that runs the entire OS as Docker containers

#78

Post by cookiecaper »

gtirloni wrote: post #47
cookiecaper wrote: post #41

Earlier quoted context omitted.

Sure, I agree that both Docker and k8s (at some level, k8s probably had to have a lot of that complexity to interface with Docker) are overengineered, and that there are better containerization processes/runtimes. But I still don't think containers are what most people want. People need/want ultra-lightweight VMs with atomized state. NixOS looks promising but I haven't used it yet. It seems to give you a way to deter…

It seems deploying thousands of ultra-lightweight VMs with atomized state would still require an orchestration layer. I don't follow how that would remove complexity and/or improve stability.

It removes complexity because you can already use a lot of stuff that exists. Kubernetes has established itself as a black box.

Kubernetes has the concept of an "ingress" controller because it has established itself as the sole router for all traffic in the cluster. We already have systems to route traffic and determine "ingress" behind a single point (NAT). Kubernetes also manages all addressing internally, but we have technologies for that (DHCP et al). Kubernetes requires additional configuration to specify data persistence behavior, but we have many interfaces and technologies for that.

VMs would be able to plug into the existing infrastructure instead of demanding that everything be done the Kubernetes way. It reduces complexity because it allows you to reuse your existing infrastructure, and doesn't lock you in to a superstructure of redundant configuration.

kube is very ostentatious software in this way, and it makes sense that they'd throw compatibility and pluggability to the wind, because the strategic value is not in giving an orchestration platform to AWS users, but rather to encourage people to move to a platform where Kubernetes is a "native"-style experience.

As for orchestration, people were orchestrating highly-available components before Kubernetes and its ilk. Tools like Ansible were pretty successful at doing this. I have personally yet to find executing a `kubectl` command less painful than executing an Ansible playbook over an inventory file -- the only benefit would be faster response time for the individual commands, though you'd still need a scripting layer like Ansible if you wanted to chain them to be effective.

Re: Tiny Linux distro that runs the entire OS as Docker containers

#79

Post by developer2 »

oneplane wrote: post #14

This is starting to smell like a system on top of a system to fix something that could be fixed in the system. Kind-of like implementing a filesystem on top op a filesystem... or putting a database on a filesystem to run another filesystem inside the database, or using a webbrowser as a runtime instead of an operating system.

It's nothing like that at all. It's just a minimal operating system with a small install image. The only special thing it does is replace the init process with a system-docker process to reduce the overhead of resources used by the operating system.

The point isn't really to "run more Docker". It's to eliminate as much operating system overhead as possible, so that nearly every CPU cycle and byte of memory usage is dedicated to your containers.

Re: Tiny Linux distro that runs the entire OS as Docker containers

#80

Post by dozzie »

gunnihinn wrote: post #76
gumby wrote: post #34

Earlier quoted context omitted.

I always felt, perhaps uncharitably, that the point of containers was "those other programmers are idiots so we need to encapsulate everything for the sake of defense"

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.

You do realize that the scenario you have described could be carried out with chroot just as easily, right? The only way "containers" help (and not containers as is, but Docker specifically) is that they ship the whole chroot OS image with all the dependencies.
Post reply on HN