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

151–160 of 177 posts

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

#151

Post by thiht »

pikzen wrote: post #146
thiht wrote: post #143

Earlier quoted context omitted.

Well, between a good technology with a lot of hype and a better technology with no hype except for a few condescending people, how am I supposed to chose the latter? Tell me. I just read the ArchWiki page on systemd-nspawn[1] and I fail to see how it is any better by the way. It just looks way harder to use (Docker images vs packages, scripts and per distro instructions ; docker create, docker start, docker ps, docke…

Would you prefer if all those command were prefaced with `systemd`? Because that's all there is to it do docker in your example then. You're seeing condescension where there is none. I'm just pointing out facts. It's okay, Docker runs on hype, and apparently so do you. But then, I can't expect Red Hat to invest into advertising for a core system component, because developers ought to be aware of it. nspawn also offer…

>Would you prefer if all those command were prefaced with `systemd`?

Well, I'm fine with journalctl and machinectl as they're part of systemd. I'm not really fine with having to install respectively arch-install-script, deboostrap+debian-archive-keyring, debootstrap+ubuntu-archive-keyring to run an Arch, Debian or Ubuntu container. What if I want to run something like CentOS or Alpine?

>But then, I can't expect Red Hat to invest into advertising for a core system component, because developers ought to be aware of it.

That's why Docker has the market. systemd is huge and scary, developers see it as a sysadmin only component. You cannot expect developers to know systemd without explaining it to them in a way they can understand.

>nspawn also offers faster startup time

Is Docker slow? Starting a container is usually instantaneous. Maybe the engine? For me it's managed with systemd and its weird socket binding, it's pretty fast too.. Fast is good but I can't remember thinking "wow docker is slow"

>better integration with cgroups and chroot jails

How? Why do I need this better integration?

- - -

I'm convinced there are not a lot of things Docker cannot do in comparison to systemd-nspawn. On the contrary, with systemd-nspawn:

- how do I spawn a container remotely?

- how do I share my "images"? is there an easy way to bundle the app I want to isolate? something at least kinda portable between Linuxes, so no .deb/.rpm

- can I include a file to my source code and tell my users something like "run docker build, then docker run and you're good to go"?

- my sysadmins just gave me the rights to run the docker command (we configured the user namespace so that I'm not indirectly root on the host), would it be that easy for them with nspawn?

- say I want a specific dependency, redis for example. Can I do something as simple as `docker run -p6379:6379 -v/data/redis:/data --name redis redis` or would I have to manually install the redis in the nspawn?

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

#152

Post by dozzie »

hamburglar wrote: post #118
dozzie wrote: post #100

Earlier quoted context omitted.

> 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…

I disagree. Just google "doesn't work in chroot" and you'll be reminded of a litany of issues that come up when trying to build/run things in a chroot, and a container containing a linux distro makes a tidy little sandbox which generally avoids those issues. It's somewhere on a spectrum between a chroot and a VM, which I think a lot of people find value in. And I'm not confusing containers and Docker, I'm just speaki…

> Just google "doesn't work in chroot" and you'll be reminded of a litany of issues that come up when trying to build/run things in a chroot

Yeah, some newbie forgot to mount-bind a necessary directory like /proc or /dev, didn't provide sensible /etc/resolv.conf, or messed up host's and chroot's paths, either in request or in configuration. Nothing that would render chroot unviable. Is this what you meant?

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

#153

Post by JdeBP »

isostatic wrote: post #145
btschaegg wrote: post #141

Earlier quoted context omitted.

See: Virtualenv (for Python), Snappy, Flatpack The main advantage of docker, as far as my understanding goes, is more of a prebuilt system configuration thing. Need a database? Load the prebuilt PostgreSQL image onto the respective machine. One thing I think should get more use in general is that Dockerfiles are essentially completely reproducible scripts[1]. Too many companies I've seen still use Word documents full…

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?

I encountered TUTTLE the other week.

* https://lists.debian.org/debian-user/2017/04/msg00151.html

* http://www.panix.com/~rst/tuttle.html

* https://lists.debian.org/debian-user/2017/04/msg00437.html

* https://github.com/rst/Tuttle

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

#154

Post by digi_owl »

isostatic wrote: post #148
chainsaw10 wrote: post #117

Earlier quoted context omitted.

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

Patch a library and perhaps you end up breaking some programs that rely on that library. The benefit of that goes away with containers anyway, you don't share libraries, every instance gets its own install.

Could have sworn that _nix already had mechanisms for loading different lib versions side by side...

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

#155

Post by btschaegg »

isostatic wrote: post #145
btschaegg wrote: post #141

Earlier quoted context omitted.

See: Virtualenv (for Python), Snappy, Flatpack The main advantage of docker, as far as my understanding goes, is more of a prebuilt system configuration thing. Need a database? Load the prebuilt PostgreSQL image onto the respective machine. One thing I think should get more use in general is that Dockerfiles are essentially completely reproducible scripts[1]. Too many companies I've seen still use Word documents full…

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?

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.

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

#156

Post by skrebbel »

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.

Your comment made me more interested in this solution than I was at first glance. I tend to prefer pragmatism over elegance, which is why I like using a webbrowser as a runtime, for instance. It'll work everywhere.

If this idea has similar pragmatic advantages over the would-be best solution, then I'm game.

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

#157

Post by quigonjinn »

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…

There is a way to do this without the security/bloat/management issues. Take a look at the approach of GNU Guix. Both versions of a package can coexist in the system. Libraries are dynamically-linked and security updates can be applied fast (without building the world), using the "grafting" system.

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

#158

Post by rsync »

slackingoff2017 wrote: post #144
zerocrates wrote: post #22

Earlier quoted context omitted.

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…

The reason a new layer is being built is because people don't want vendor lock in and VM's aren't portable anymore. You can't take an AWS VM and fire it up on DigitalOcean without trial by fire. VM's should be portable but they're not because cloud providers don't want them to be. For a while everyone was locked into AWS but now that there's other options some companies want to hedge their bets, or even run parts of…

"You can't take an AWS VM and fire it up on DigitalOcean without trial by fire. VM's should be portable but they're not because cloud providers don't want them to be."

You can't ?

I have never used DO, but I have deployed linux and FreeBSD systems on EC2 and moving them to bare metal was just a tar command away ... you can even pipeline 'dd' over ssh if you want to be fancy ...

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

#159

Post by rsync »

ChuckMcM wrote: post #61
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 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…

"it is kind of waste to have 'n' copies of the OS loaded, so containers are a 'semantic' fractioning of the resources where the OS is common but the set of processes are unique to a client. You still need a way to allocate from the single set of resources so containers provide that abstraction."

Agreed. What I find so odd is that this problem was simply and elegantly solved in BSD with 'jail' and everyone went about their business.

I do not understand why (what appears to be) the linux answer to 'jail' is so complicated and fraught and the subject of so much discussion.

I am not sure that containers and their build scripts represent the $huge_profit_potential that people think they do ...

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

#160

Post by yebyen »

JdeBP wrote: post #140
yebyen wrote: post #113

Earlier quoted context omitted.

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.

I was fishing for an example of any OS or orchestrator that uses systemd-nspawn.

[1] shows me how to run systemd-nspawn by itself.

[2] shows me that it's basically just like chroot when it comes to a user experience.

When do I get to the part that's better than the entire ecosystem of schedulers and orchestration tools that has sprung up built on and around Docker? Are all of those companies wrong? (Are you trying to tell me it's all just hype and I should put everything into the hands of one competent sysadmin that manages nspawn and systemd?) I could be convinced of that, but I just don't see anyone doing that. I guess that's actually what was meant by cargo cult.

This all really just makes me want to go out and spend some more time looking at Rkt instead. We're all not even remotely convinced that this is better. Where is the mantl.io built on systemd-nspawn?

[1]: https://wiki.archlinux.org/index.php/Systemd-nspawn

[2]: https://rich0gentoo.wordpress.com/2014/07/14/quick-systemd-n...

Edit: I am still going to upvote you because you went to the trouble of going through my post history.

Post reply on HN