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

131–140 of 177 posts

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

#131

Post by chubot »

dkarapetyan wrote: post #98
wmf wrote: post #92

Earlier quoted context omitted.

Because either there is no RPM or the RPM conflicts with other RPMs on the machine.

Sounds like then you should learn what a chroot is. All the existing linux platforms already provide the solution to your exact problem with much less overhead than docker.

I agree this is possible, but the tools are somewhat obscure and slow. You can debootstrap in a chroot and then install packages, but it takes a long time, and likely re-downloads hundreds of megabytes packages you already have on the system.

I don't like Docker, but I think it does some differential compression with the layers when you are modifying the image. So you don't have to re-do this install from scratch.

You may also run into issues with user IDs and various system config files in the chroot. Configuring the service with flags, env vars, and config files is a bit of a pain.

Docker is essentially a glorified chroot... I've essentially tried to rebuild it, and it is unfortunately a lot of work.

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

#132

Post by unscaled »

bubo_bubo wrote: post #109
lobster_johnson wrote: post #96

Earlier 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.

That's one of the main touted benefits of containers (a.k.a build reproducibility). You can view containers as a an overly complicated way to make software with complicated deployment brain-dead easy to deploy.

We're at the point in the hype cycle where it starts getting fashionable to dismiss that as an overkill, but the reality for most of us out there is that most software is way more complicated than a single executable and containers make it easier to deploy complicated software.

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

#133

Post by runeks »

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.

Problem is it's sometimes more annoying than helpful, e.g. having to copy files into the ~/.mozilla directory in order to be able to upload them to Dropbox via Firefox, or attach to an email.

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

#134

Post by hueving »

numbsafari wrote: post #65
user5994461 wrote: post #42

Earlier quoted context omitted.

There is an advantage in layering components, or building new software on top of existing components. However, a minor improvement or bugfix should be done in the component that is responsible for it. Creating another layer instead of fixing the problem is just creating more problems.

You can go whole hog with "containers" by just adopting unikernels. But, unless you are willing to abandon Linux/Unix, this is kinda where you are left.

How would that work when containers make kernel calls?

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

#135

Post by rwmj »

lostmsu wrote: post #26
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.

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'm not saying this is a good thing but ...) Containers are often used where you want to run several programs, but each depends on a mutually incompatible set of libraries. Two programs need python-somelib-1.0 and python-somelib-2.5, but both versions can't be installed at the same time. Or you need to upgrade the programs at different times and during the upgrade window they'd depend on different versions of python-somelib.

Now of course the correct way to solve this would be (a) to make both programs use the same version of python-somelib, (b) make upgrades happen atomically, (c) for Python modules to actually have some API backwards compatibility. But in the absence of doing the right thing you can use a container to effectively static-link everything instead. And worry about the security/bloat/management another time.

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

#136

Post by grey-area »

cookiecaper wrote: post #10

CoreOS works the same way. All containers. You can run `toolbox` to get into a systemd-namespace'd Fedora container (any other container can be specified; it's just Fedora by default), from which you're supposed to do all your troubleshooting/analysis (caveat: systemd-namespace does not seem to support `auditd` well). I still strongly dislike "containers". It's not worth the complexity or instability. Two thumbs way…

CoreOS works the same way. All containers.

Does it though? I use CoreOS without containers (for the nice auto-updates/reboots), and it works really well with just systemd services. I'm aware the branding sells it this way (esp. the marketing rebrand as Container Linux or whatever), but does it run any containers as part of the base system? I've found CoreOS with containers not very reliable, and CoreOS without containers extremely reliable.

Since I use Go on servers which has pretty much zero dependencies, what I'd really like to see is the operating system reduced to a reliable set of device drivers (apologies to Andreessen), cloud config, auto-update and a process supervisor. That's it.

Even CoreOS comes with far too much junk - lots of binary utils that I don't need, and I'd prefer a much simpler supervisor than systemd. Nothing else required, not even containers - I can isolate on the server level instead when I need multiple instances, virtual servers are cheap.

CoreOS is the closest I've seen to this goal, the containers stuff I just ignored after a few tests with docker because unless you are running hundreds of processes, the tradeoff is not worth it IMO. Docker (the company) is not trustworthy enough to own this ecosystem, and Docker (the technology) is simply not reliable enough.

The OS for servers (and maybe even desktops) should be an essential but reliable component at the bottom of the chain, instead of constantly bundling more stuff and trying to move up the stack. Unfortunately there's no money in that.

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

#137

Post by justincormack »

dkarapetyan wrote: post #62
ChuckMcM wrote: post #61

Earlier quoted context omitted.

I don't think so. Consider that computers are generally so powerful these days that when running a single application stack their seriously under utilized. The first way people went about getting this going was Virtual Machines (made popular by IBM with its VM/370 OS :-) and that works well but when all of your clients are running the exact same OS down to the same version, it is kind of waste to have 'n' copies of t…

What exactly is the problem with process sandboxing and language level VMs? The industry is tackling all the wrong problems. So have we given up on process sandboxing with capabilities? The whole containerization movement is one giant hammer to kill a fly kinda business these days. While you guys are figuring all this out I'm gonna stick with BEAM, JVM, and other tried and true methods. I'll check back in another 5 y…

Because process sandboxing turned out to be insufficient, and we need layered sandboxing with several levels for protection for security.

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

#138

Post by JdeBP »

rwmj wrote: post #135
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'm not saying this is a good thing but ...) Containers are often used where you want to run several programs, but each depends on a mutually incompatible set of libraries. Two programs need python-somelib-1.0 and python-somelib-2.5, but both versions can't be installed at the same time. Or you need to upgrade the programs at different times and during the upgrade window they'd depend on different versions of python…

You forgot possibility (d) allow multiple library versions to be present simultaneously.

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

#139

Post by JdeBP »

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…

Linux's control groups are a resource management system, an attempt to do resource management better than the POSIX rlimit mechanism. They are not job objects, and do not do all of the things that jobs do (on operating systems that have them). However, a job object is the kind of mechanism that people want for this sort of thing.

* http://jdebp.eu./FGA/linux-control-groups-are-not-jobs.html

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

#140

Post by JdeBP »

yebyen wrote: post #113
throwaway2048 wrote: post #67

Earlier quoted context omitted.

Great job proving the second part of what he said

Put up a sentence or two of informative discussion, or links or any kind, this is not any kind of way to advance the state of a thread. "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…

You do not know an operating system that has systemd? Given https://news.ycombinator.com/item?id=13715574 that seems very improbable.
Post reply on HN