Slashdot Mirror
New RancherOS Offers Lean Linux Functionality Within Docker Containers (rancher.com)
RancherOS is a lean Linux distribution aiming to offer "the minimum necessary to get Docker up and running," and tucking many actual Linux services into Docker containers.
An anonymous Slashdot reader quotes Distrowatch:
Josh Curl has announced the release of a new version of RancherOS [which] moves the project out of its alpha status and introduces new features, including an official Raspberry Pi image... "We're especially excited about this since it offers users a cheap method of getting started with Docker and RancherOS."
Try it again!
Will be the year of Linux on the Open Range.
Best are here.
ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/11.0/
Not interested in Dockers.
Thanks to Microsoft, nobody uses the word "daemons" to refer to non-interactive background processes. Even the Linux hipsters call them "services" now.
Docker. Nice pants, you use to cover your asshole.
You linux guys used to make fun of "DLL hell"
No, they didn't. These Linux guys are all under the age of 25. They don't know what DLL Hell means, and Linux is older than they are.
I must be dense, but how could you possibly have an official image for an ARM based computer when Docker is only for x86 and x86_64? If everything has to be run on an emulator like QEMU, then this hardly seems like a real solution.
By 2011, Docker had ARM support.
https://github.com/docker/dock...
Docker is basically the fastest, lightest type of virtualization. Mainly it gets you a reasonably secure jail. The container contains the entire userland, the whole OS other than the kernel. Some people use this to run both Debian Linux and Android at the same time. Yeah dependencies are handled too, but that's not normally the point.
"Muh jargon! Muh metaphor! Muh hacker culture!"
So they put their program on pid 1, on bare BIOS^Wkernel? Ah booters of the old times...
And this line made me smile:
System Docker replaces traditional init systems like systemd
So CADTs are moving away from systemd as fast as they flocked to it, while the rest of us are smirking.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Sometimes shared libraries get only one copy in memory. In other cases, you can end up using more memory. Sometimes it's worth a few extra MBs of RAM.
Personally, I've developed some expertise with kvm/qemu, so I tend to use full virtualization more often. Yes, it uses even more RAM. 512 MB of RAM costs me what, $3? I bill at $100/hour, so given the choice between using $3 of RAM or 30 minutes of my time, I'll spend the $3.
Nice to see legacy inits like System D being deprecated in favor of more modern approaches, there will be some resistances from system d grey beards who refuse to learn new things but they should be grateful someone is developing code code for them for free. If they don't like new shiny they should fork and go away, after all the code is available.
Extended golf clap.
Very nicely done.
they need to drop the OS gimmicry and focus on delivering an interface. The biggest major drawback is their system container hack, which equates to no value given that swarm can run across multiple operating systems.
If it's hundreds of *different* images, that's a tradeoff to consider. If it's many copies of the same image, most memory can be shared. Every approach has advantages and disadvantages.
Until you thousands of instances, the most expensive resource is probably people. RAM, CPU, and storage are cheaper than people, and you don't have to buy health insurance and other benefits for your RAM.
So basically... back to LXC containers? Or am I missing something. Time to RTFA
Docker is a freeze dried VM with mappable ports and filesystem. It runs on several OSs on various platforms. I'm not sure what its killer feature is. It isn't just the ability to include libs with your program - it's a way to include the entire OS with your program - with all the libs and whatever else you need.
Things I do with docker:
* get rid of RVM/rbenv, NVM, and all those other version managers. Just fire up a docker container with the version of ruby/node/whaterver you want
* package up services for deployment (web apps in my case) and toss the image to devops/IT to deploy
* test tools/software I'm not familiar with - not sure if you want to install latest? fire up a docker container and take it for a spin. And when you're done testing, maybe just continue using the container.
* run things on platforms that don't support them. Want to run redis on windows? docker container. Want to run git hubflow on windows without installing extra stuff? docker container.
> isn't officially supported yet; it is in RC status. For now ... use a custom build, or build it yourself
Yes, you can either download an unofficial build or compile it yourself, like people have been doing for years now. Gmail and Google Maps were officially beta for years, not officially supported as millions of people used them. You seem to confuse "officially supported" vs "works".
So this is basically just Ubuntu Core using docker containers instead of snaps?
The deployment of services sounds interesting, but I have some questions.
Do you have a common system/platform guide that includes hardening etc. for all possible dev OS choices?
Do you have to have documentation for each type of possible dev teams preferred OS or is that all standardized on the dev side?
Does devops/IT apply what they want to the OS before deploying? What if it breaks?
Sorry I could be showing my age- most of my experience comes from the silo dev model (MGMT/DEV/QA/SEC). Everyone had tunnel vision and only cared that their part was minimally satisfied.
You may have guessed where I sat in my silo by myself as a team with a "say" in that process (I am no longer part of that process thankfully).
"Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway" -Andrew Tanenbaum
Some of your questions make more sense than others. In the context of deploying, docker looks a lot like a VM deployment - except instead of having to build up a VM using chef, and with all the luggage that usually entails, the docker image tends to only be running the service. Imagine a linux kernel with only one process running. So there aren't a lot of edges to harden. Usually the service image gets launched in something that looks like a DMZ behind a firewall with a loadbalancer in front of it.. In our case it's a little wild west.
But part of the joy/ease of docker is that you build on some particular image. It would be easy to imagine an organization that was more .. organized than ours specifying a few base image flavors that developers would have to build off of - then you could harden those images all you wanted. I don't know that I would be a big fan of that, however. You can see where redhat supplies a lot of images, for example (https://access.redhat.com/search/#/container-images).
Concrete (semi bogus) example: you want to run redis (maybe on windows - where it's not trivial). There is a redis docker image: https://hub.docker.com/_/redis...
"docker run -p 6379:6379 redis"
That will fire up a docker container running redis and will map the port on the image to the port on the docker host (usually localhost, these days). You can now connect to port 6379 and talk to redis. The container running redis is hard to describe - it's a full (stripped) linux system and it's only running that one process. You can fire up a shell on that container using another docker command and it has a bunch of the things you expect. Some shell (maybe bash or something lighter). Most of the filesystem stuff you expect. It's like a VM - if you built a VM to only run redis.
I don't know if any of this helps - it really is a weird concept - at least I had a really hard time wrapping my head around it. But I do love what I can do with it.