The Wheezy image I use with LXC worked well enough, the minimal alpine image not so well, apk complaining about its database.
User name spaces support would be nice, then we can play with unprivileged containers.
And Overlayfs would be a nifty alternative to btrfs, it's in kernel 3.18, and 4.04 adds support for multiple lower layers. But this btrfs implementation is cool too. Cgroups support will be somewhere on that list too.
Cgroups and namespaces is in the kernel. General Linux ecosystem for networking, storage and distributed systems is already extensive. The possibilities are endless.
So now LXC, Docker, Rkt and Nspawn have Bocker for company.
The network, PID and mount namespaces are the ones unshared, plus a private /proc.
I like tools like this because they're reality checks on how the basics of Linux containers are just a few essential system calls, and particularly that they're limited.
One of the things I found really interesting here is how much could be done with just basic userland tools, and how old some of those tools are.
Docker was released in 2013, but support for kernel namespacing has been around since ~2007. That's quite a long time for such a great feature to go mainstream.
However, I've stated this in other threads: Docker isn't about containment. It's really about the packaging system. I don't think this technology demo gets that.
Cgroups was initially added by some folks from Google in 2007. A lot of the early work on Linux containers was done by Daniel Lezcano and Serge Hallyn of the LXC project, supported by IBM. It was initially a kernel patch and userland tools. You can still see it on the IBM website. It was merged in 2.6.32.
Then around 2012 the LXC project started being supported by Ubuntu and Stephane Graber of Ubuntu continued the work with Serge Hallyn. LXC was of course focused on OS containers and they didn't really market themselves.
Around 2013 when LXC was finally becoming usable by end users, Docker who were probably using it in their previous avatar in dotcloud as a PAAS platform, took it as a base, modified the container OS's init to run single apps, removed storage persistence, and built it with aufs layers, and took it to market aggressively.
But if you look beyond the PAAS centric use case, OS containers are simpler to use, offer near seamless migration of VM workloads, more flexibility in storage and networking scenarios and are more easily used with the ecosystem of apps and tools with a normal multi-process OS environment.
The ability to gain the advantages of containers without needing to re engineer how you deploy applications is an incredible value proposition.
LXC is mature, pretty advanced and simpler to use than Docker, but a lot of users and media have got the impression that its 'low level' or difficult to use.
The Docker, PAAS and micro services folks are the only ones really messaging and going out there to gain adoption and there is an unfortunate conflation of containers to Docker and monoculture developing. The 'Open Container Standard' is an example. Shouldn't that be 'Open App Container Standard'?
App containers are a constrained OS environment and add complexity, and the various Docker specific solutions being developed for everything from networking to storage is evidence of the additional complexity. There is obviously a huge devops PAAS case here that people see value in. And the sheer amount of money and engineering deployed means something good has to come out of it. But containers cannot be just about PAAS.
I run Flockport that provides an app store [1] based on OS containers that are as easy to use as Docker hub and extensive documentation [2] on using containers so do give it a look.
it feels like most of them build large products around things to justify making money, while i like the simple, elegant, easy to verify little pieces of software (some call it "the unix way")
unshare and iproute are pretty decent for ex.
I'd marked 'docker pull' as out of scope because I thought it would be fairly hard to interface with their API from bash, looks like I was wrong.
I think the v2 API requires hitting an auth endpoint too.
The author of "bocker" (not my bocker) has a great idea. I would learn from the script. Docker is not magic anymore.!!
(I am one the maintainers of dokku, which is written in bash).
it might be interesting to see a version of your script using overlayfs
I'll have to look info CoreOS's reasons for going with Ext4.
https://github.com/gdestuynder/mctl/ See also this terrible draft https://www.insecure.ws/linux/systemd_nspawn.html
systemd-nspawn is nice because I run systemd in all my containers and thus allows me to easily do logging etc.
I don't really dig the docker-microservices mantra that much. I just use them as glorified VMs I guess.
(And yes, you should run an init system in your containers [0])
[0] - https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb...
Is something watching for .cmd? Is this some behavior of util-linux (for which, my few seconds couldn't find solid documentation on)?
The run command itself is executed next, inside of ip netns exec.
Is there a certain process that goes into developing something like this, and why is this a popular thing to do? (writing an existing software in lesser lines)
2) It's fun
People give bash a hard time, but things like this really give me that warm, fuzzy feeling.
esac4lyfe
Surely that is better than a convoluted, 1,000,000,000 LoC application that no one outside a handful of core developers understands? Right?
Something that one smart developer can do in 100 lines on any interpretter is never worth billions of dollars.
Someone who can do it, on the other hand, is certainly worth hundreds of thousands of dollars, annually.
Meanwhile, so many people continue to marvel at what can be done with an interpretter and a turing-complete language. Yet, the last thing we need is yet another turing complete language.
Unfortunately, the problem with turing machines, virtual or otherwise, is that they're so good at faihfully reduplicating themselves...
100 lines maybe not, but docker is pretty lightweight glue riding on existing technology that did most of the heavy lifting. The valuation IS lopsided because it sort of did a "name grab" around the underpinning technology (sort of like "AJAX" was "XMLHttpRequest") and packaged it in a way that made it a more useful (some) and more importantly, talked about in a way people could understand, mostly giving it a name and describing some common practices was what happened.
The original idea was definitely clever though, and it is getting people who didn't adopt immutable systems before to start to understand immutable systems, even if the future is not actually going to be Docker. Yet, Docker is getting the press versus the higher level software that needs to exist to drive Docker.
While this makes it very hard for other projects to get VC attention, I think that's maybe a good thing for them if they don't know it - you want to bootstrap if you can anyway, and I hope many of them do.
While this isn't a super robust implementation or anything, I think it's important to show that Docker is more or less glue around existing concepts, and that there's still room to make better things.
Don't get me wrong, immutable systems are GREAT. Docker deserves points for getting people to understand them, and the ideas of private registries and Dockerfiles (though also not original) are good parts. Microservices? Not really neccessary for most people, that's more of a human problem. It sort of conflates immutable with microservices and makes you hop out of the norm to do the basics, but ok, sure, that's somewhat like a celebrity actor advocating for environmental causes. Still a good thing.
But is it a giant leap forward? Not as much as people think, compared to AMI builds, and you see folks running Docker on top of EC2 in cases (yes, they boot faster - but AMIs gave you immutable and things like Packer allowed redistributable images; stacking images is kind of sketchy if you don't control them all). But it's enough to make people use them, and that's a win, and someday the management software for it may be smart enough to make it feel as easy and powerful as that (fingers crossed for ECS?).
The 100 liner at least has the advantage of reminding people when people say "Docker is great" they mostly mean "I like this immutable systems thing and describing systems in text", and the other properties of Docker, and reminds people that if they can do better and try to make a better thing, they should also still try.
echo 'nameserver 8.8.8.8' > "$btrfs_path/$uuid"/etc/resolv.conf
Having now used Salt and starting to play with Ansible I'm growing an extreme dislike for Puppet and the weeks of my life I can never recover dealing with things that Salt has made so much easier.
HN's standard middlebrow dismissal of Docker is to claim that it's nothing except LXC, which really misses the point entirely. But at least it lets people pretend they are smarter, which is what really counts.