16 ms·
Tiny Linux distro that runs the entire OS as Docker containers
- KaiserPro 9y agofor the ignorant, why would I want to wrap docker inside docker?
- y4mi 9y agothey actually mention it in their readme. > it seemed logical and also it would really be bad if somebody did docker rm -f $(docker ps -qa) and deleted the entire OS or are you asking why anyone would want a 'docker-os', which has everything but the docker daemon as a container?
- KaiserPro 9y agoNo no, I get the coreos idea, or providing libc, kernel docker service and nothing else. I saw that line, but since if you want to run docker at scale you'd have each execution node under the tight control of a scheduler, it seemed like a small edge case. As I said, for the ignorant such as myself why would I chose this over coreos?
- magoon 9y agono, it's the OS services that are dockerized. so your containers won't be docker inside docked.
- cookiecaper 9y agoThis is not Docker-in-Docker. This is an OS that acts like a "container hypervisor". It provides the bare minimum for hardware interfacing and hosting containers, just as conventional hypervisor provide the bare minimum for hardware interfacing and hosting virtual machines. The benefit is that more system resources are available for your clients (containers, in this case). I haven't used RancherOS but CoreOS works mostly-fine. However, I would avoid using these things altogether because containerization sucks.
- KaiserPro 9y agoI'd suggest that containerisation as a principle is fine, but its not what most people want. What people want is a mainframe where a lump of code is guaranteed to run the same everytime, regardless of the machine state, and if something goes wrong with the underlying layer is self heals(or automatically punts to a new machine, state intact). What we have currently is a guarantee that the container will run, and once running will be terminated at an unknown time. Mix in distributed systems(hard) atomic state handling (also hard) and scheduling(can be hard) its not all that fun to be productive for anything other than a basic website.
- tiff_seattle 9y agofor science
- hobarrera 9y agoTo separate all the OS-service containers, from the user-service containers. I guess this is mostly so you don't accidentally delete OS-containers (like ntpd) when trying to delete all your containers.
- codebeaker 9y agoDidn't Docker release this themselves (different project) just a week or so ago? I forget the name, and can't seem to find it on their site.
- y4mi 9y agothis project is pretty old though. i remember playing with an earlier version sometime around august 2015
- kordless 9y agoRancher has been around for a while now, at least a few years. http://rancher.com/getting-started-with-rancheros/ http://rancher.com/getting-started-with-rancheros/
- vkat 9y agolinuxkit -> https://github.com/linuxkit/linuxkit https://github.com/linuxkit/linuxkit
- joshwget 9y agoThere's definitely overlap in functionality between RancherOS and LinuxKit, but there are also a few pretty big differences. - LinuxKit seems designed to be a piece that can be used to build a Linux distro but isn't a full distro out of the box like RancherOS - As far as I know LinuxKit is still based on Alpine whereas RancherOS is custom and doesn't have much of a host filesystem - LinuxKit is based on containerd and RancherOS is still based on Docker (though this is likely to change soon) We're definitely interested in collaborating with LinuxKit since we do have similar goals. It's probably a good idea for us to write a more detailed blog post comparing the two since we've been getting this question pretty often lately.
- justincormack 9y agoLinuxKit is not based on Alpine - earlier versions before open sourcing were. We build our system containers from Alpine though, so there is still a connection. (I work on LinuxKit).
- thrill 9y agoI've been using RancherOS for a few weeks now and I'm quite delighted with it. A confusion that occurred at first for me was the distinction between Rancher (the project/company), Rancher (the application) which can be used for installation and distribution, and RancherOS, which is the concept of replacing the Init process with Docker. Docker is used in separate instances - one to manage the containers that make the OS, and one for the remaining containers that make your apps. I think the advent of Docker Swarm probably put a crimp on development and use of Rancher (the app). To me the way forward is Docker's own clustering tools, and the ease of standing up a cluster of Atom processors at www.packet.net where they install (as an option) RancherOS is very attractive.
- cookiecaper 9y agoCoreOS 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 down!
- gtirloni 9y agoCould you elaborate on the instability concerns? What kind of workload are you running on containers?
- cookiecaper 9y agoSure. Here's one example that I've dealt with in the last week. We have a server that receives the logs from our kubernetes cluster via fluentd and parses/transforms them before shipping them out to a hosted log search backend thingy. This host has 5 Docker containers running fluentd receivers. This works OK most of the time, but in some cases, particularly cases when the log volume is high and/or when a bug causes excessive writes to stdout/stderr (the container does have the appropriate log driver size setting configured at the Docker level), the container will cease to function. It cannot be accessed or controlled. docker-swarm will try but it cannot manipulate it. You can force kill the container in Docker, but then you can't bring the service/container back up because something doesn't get cleaned up right on Docker's insides. You have to restart the Docker daemon and then restart all of the containers with docker-swarm to get back to a good state. Due to https://github.com/moby/moby/issues/8795 https://github.com/moby/moby/issues/8795 , you also must manually run `conntrack -F` after restarting the Docker daemon (something that took some substantial debug/troubleshooting time to figure out). We've had this happen on that server 3 times over the last month. That's ONE example. There are many more! Containers are a VC-fueled fad. There are huge labor/complexity costs associated and relatively small gains. You're entering a sub-world with a bunch of layers to reimplement things for a containerized world, whereas the standard solutions have existed and worked well for many years, and the only reason not to use them is that the container platform doesn't accommodate them. And what's the benefit? You get to run every application as a 120MB Docker image? You get to pay for space in a Docker Registry? Ostensibly you can fit a lot more applications onto a single machine (and correspondingly cut the ridiculous cloud costs that many companies pay because it's too hard to hire a couple of hardware jockeys or rent a server from a local colo), but you can also do this just fine without Docker. Google is pushing containers hard because it's part of their strategy to challenge Amazon Cloud, not because it benefits the consumer.
- oneplane 9y agoThis 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.
- zerocrates 9y agoThis 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, then you're in a real pickle. So people will stack on more and more until it becomes more or less unbearable.
- user5994461 9y agoThere 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.
- numbsafari 9y agoYou 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.
- gtrevorjay 9y agoThis 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.
- pikzen 9y agoUnfortunately, systemd/nspawn does not benefit from the hype Docker garners, despite being infinitely better. This industry is becoming more and more hype and cargo-cult driven, instead of making sane technological choices
- wmf 9y agoBeing easier to try, having clear documentation/marketing, and having a bigger community are also forms of "better". If something is so infinitely technically better then winning is "just" a matter of creating on-ramps to ease its adoption.
- otterley 9y agosystemd's documentation is second to none: https://www.freedesktop.org/wiki/Software/systemd/ https://www.freedesktop.org/wiki/Software/systemd/
- JdeBP 9y agoOnly if one sets the bar quite low, and has very lax standards for doco. Unfortunately, people often do set the bar low in the Linux world. But to those from other worlds the descriptions that come to mind are "acceptable" and "mediocre". As people have pointed out passim over the years, the expected as the norm quality of doco for the worlds of the BSDs and the commercial Unices is noticeably a higher standard than in the Linux world. By those standards, "second to none" is most definitely an exaggeration. Sadly, "treated as an afterthought" is all too often still applicable, as well; this also being a disease of Linux doco that it hasn't wholly shaken off. The culture of updating the doco in lockstep when the software changes hasn't really taken a firm root, alas. Just one example of such doco problems is a systemd issue where the doco does not tell the the issue raiser that the entire basis for the issue is wrong. Users have to resort to finding commentary hidden in the source code. Raised as a documentation issue, it requests a documentation change to warn users of something that is not in fact the case at all. Ironically, the true doco issue is actually that it is deficient, and the correct doco change would be to move the commentary into the manual where users can easily see it. * https://github.com/systemd/systemd/issues/5735 https://github.com/systemd/systemd/issues/5735 * https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.html https://www.freedesktop.org/software/systemd/man/systemd-tim... * https://github.com/systemd/systemd/blob/5f36e3d30375cf04292bbc1bf3f4d7512cf80139/src/timesync/timesyncd-manager.c#L321 https://github.com/systemd/systemd/blob/5f36e3d30375cf04292b... * http://jdebp.eu./FGA/systemd-documentation-errata.html http://jdebp.eu./FGA/systemd-documentation-errata.html
- logronoide 9y agoI guess RancherOS is not something "new". First time I use it was in 2015... Anyway, it seems it's design has inspired some people recently.
- Walkman 9y agoI predicted this last year: https://twitter.com/kissgyorgy/status/783825879348744192 https://twitter.com/kissgyorgy/status/783825879348744192
- darren0 9y agoCreator of RancherOS here. Thanks for the interest in our tiny distro. RancherOS was created the beginning of 2015 and at the time was quite a novel concept. We strived to not just use container technologies in a Linux distro but actually package everything as standard Docker containers. Fast forward two years, what we were doing back then is now becoming the accepted practice. Most major distro are adopting more container packaging approaches in the form of flatpak, snap, and containerd. RancherOS 1.0 LTS was just released a couple weeks back and we have started development on 2.0. 1.0 was a bit ahead of the time and honestly had to employ a lot of technics to make it work that we didn't like. With 2.0 we will shift the focus from Docker to containerd, OCI, and LinuxKit which will allow a much cleaner design.
- hobarrera 9y agoI'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.
- wasted_intel 9y agoLook at http://flatpak.org http://flatpak.org for precisely that.
- hobarrera 9y agoNope, it does a lot more: it re-packages software, and basically shoves a second package manager down my throat; one that actually bundles dependencies within in package, carrying along all the issues that that flow brings with it. I want to isolate data, no libraries. Libraries are there to be shared.
- nekohacker 9y agoQubes (https://www.qubes-os.org/ https://www.qubes-os.org/) is a good fit for this.
- hobarrera 9y agoYeah, creating a new OS/distribution will never fix the problem. You can't tell people "Oh, just wipe everything clean and installing this other OS". It needs to build on top of what we have, otherwise adoption will never take place.
- viraptor 9y agoApparmor does that for you. Or selinux, depending on your distro.
- digi_owl 9y agoFirejail.
- mmrezaie 9y agoProbably it was not the vision of these types of projects, but this reminds me a lot of Qubes OS[1]. I actually have occasionally used docker (lxc) to run some applications that I was not trusting, and I was controlling them using cgroups. Right now my chrome browser is running like that. [1] https://www.qubes-os.org/ https://www.qubes-os.org/
- justAlittleCom 9y agoThat's ungodly.
- dkarapetyan 9y agoI have to say this enrages me. The system services are still privileged containers and we are now basically emulating a micro-kernel (very badly I might add with a monolithic kernel). If you want to use a micro-kernel then use a fucking micro-kernel. Hacking a micro-kernel with docker is not the right approach, especially given the stability track record of docker itself. It's a hack and aesthetically unpleasant on all sorts of levels. Not the least of which is that docker itself is one giant hack.
- DigitalJack 9y agoYou have serious problems if this enrages you. Let other people hack in peace. Go do your own "right" thing and leave the rest of us alone.
- B1tchard0 9y agoI don't understand why running software on bare metal is viewed as a problem to be solved. how many layers of abstraction are necessary, and why? Obviously virtualizing serves a valuable purpose. Making development more accessible is great. Simplistic dev services like this mean reliance on others infrastructure, and being bound to cloud. Doesn't seem forward thinking. Can you imagine if Google had decided to run their search app on Microsoft servers?
- digi_owl 9y agoThe basic thing is that we have ended up with a world of rock star code monkeys. And those rock stars can't be held back by some admin or exec saying no to using some hot new language or framework...