Live data from Hacker News

Show HN: Bocker – Docker implemented in 100 lines of bash

github.com

61–70 of 89 posts

Re: Show HN: Bocker – Docker implemented in 100 lines of bash

#61
post #11

Using btrfs subvolumes as the image format, that's a nice touch. On the same road as the hypothetical systemd packaging system (not that I'm very enthusiastic about that). 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 limi…

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

User namespaces actually weren't completely done until late 2013 (Ubuntu didn't have them enabled until 13.10 or 14.04 because it didn't work with XFS).

Re: Show HN: Bocker – Docker implemented in 100 lines of bash

#62
post #28

Earlier quoted context omitted.

Perhaps the parent poster was wryly indicating that he doesn't think that much of Docker. Certainly I think both of you are correct: Docker is about packaging, and it absolutely sucks at that. The only reason that that is not obvious is that Docker is piggybacking on the relatively excellent and well-developed package management of distributions like Debian and Fedora.

Debian and Fedora do packaging better than Docker, relatively speaking, but they still have major issues that have lead to "solutions" like Docker, Chef/Omnibus, etc. They install packages globally which doesn't allow for having multiple versions of the same software/library, they don't allow for unprivileged package management so users are at the mercy of the sysadmin, there's no transactional upgrades and rollbacks…

> Debian and Fedora do packaging better than Docker, relatively speaking, but they still have major issues that have lead to "solutions" like Docker, Chef/Omnibus, etc.

I get what you're saying, but the way you've phrased it makes it seem like it wasn't intentional when in fact before immutable git-style packages were discovered, you were forced to choose between packaging that works well for developers/ops and packaging that works well for end users.

Debian is the best example we have of the latter, but it's a mistake to say they did a bad job at making ops-friendly packaging. They are solving a different, mutually-exclusive (until recently) problem.

With a bunch more elbow grease and polish, the nix/guix approach allows us to have the best of both worlds, but this is a very new development; arguably it isn't even "there" yet.

Re: Show HN: Bocker – Docker implemented in 100 lines of bash

#63
Add support for GPG-signed `btrfs pull` and `btrfs push` and I'm totally sold! I've been working on something similar to this but on top of systemd-nspawn, which already does some stuff for you.

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

Re: Show HN: Bocker – Docker implemented in 100 lines of bash

#65
post #58

Earlier quoted context omitted.

It turns out that the kernel is smart enough to deduplicate (in memory) the same version of a shared library across VM boundaries, so I don't really see why we need to make packaging handle this, especially if this can be applied to containers (if it isn't already). Duplicates of the same file on disk is not a big deal, and can be solved by a good file system which handles deduplication. I don't see why we necessaril…

This means your security depends on the app maintainer, which is a terrible place to be in. I don't want to have to wait for the latest image of 100 apps and hope they didn't break anything else just to deal with an openssl vulnerability.

If your system consists of 100 apps, you have a bigger problem, and likely is a shop big enough to deal with it.

I'm working on a production deployment of a CoreOS+Docker system for a client now, and the entire system consists of about a dozen container-images, most of which have small, largely non-overlapping dependencies.

Only two have a substantial number of dependencies.

This is a large part of what excites people about Docker and the like: It gives us dependency isolation that often results in drastically reducing the actual dependencies.

None of this e.g. requires statically linked binaries, so no, you don't have to wait for the latest image of 100 apps. You need to wait for the latest package of whatever library is an issue, at which point you rebuild your images, if necessary overriding the package in question for them.

Re: Show HN: Bocker – Docker implemented in 100 lines of bash

#66
post #35
post #11

Earlier quoted context omitted.

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

A lot of the cgroups and namespaces functionality too time to mature and stabilize. User name spaces for instance was only available with 3.8. Cgroups and namespaces still don't play well with each other. 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…

Systemd-nspawn is way easier to use than LXC imo in that it replicates the simplicity of chroot with the power of cgroups. The security story is unfinished though.

Re: Show HN: Bocker – Docker implemented in 100 lines of bash

#67
post #57
post #54

Earlier quoted context omitted.

No, that's a dumb joke. Actually I don't really even use Docker personally. 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.

They are rightfully dismissive of Docker because it's just the current cycle of trendy abstractions. It's a barely passable solution to a bigger problem. "We're running many services on a single machine. But this is complicated and difficult to update and maintain." "We took our machine, ran a virtualization platform on it, and split each service into its own VM. But this comes at the cost of increased resource usage…

> and name-spacing rather than containers.

Containers are name-spacing.

Re: Show HN: Bocker – Docker implemented in 100 lines of bash

#69
post #28

Earlier quoted context omitted.

Perhaps the parent poster was wryly indicating that he doesn't think that much of Docker. Certainly I think both of you are correct: Docker is about packaging, and it absolutely sucks at that. The only reason that that is not obvious is that Docker is piggybacking on the relatively excellent and well-developed package management of distributions like Debian and Fedora.

Debian and Fedora do packaging better than Docker, relatively speaking, but they still have major issues that have lead to "solutions" like Docker, Chef/Omnibus, etc. They install packages globally which doesn't allow for having multiple versions of the same software/library, they don't allow for unprivileged package management so users are at the mercy of the sysadmin, there's no transactional upgrades and rollbacks…

Debian and Fedora do it better, yes. But it's not quite as easy to get started. However once you are at a certain size, both solutions are horrible. (Docker and RPM). Especially when you need to target more than one Fedora / CentOS / RHEL / etc... Also editing Spec files is quite horrible.

Re: Show HN: Bocker – Docker implemented in 100 lines of bash

#70
post #11

Using btrfs subvolumes as the image format, that's a nice touch. On the same road as the hypothetical systemd packaging system (not that I'm very enthusiastic about that). 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 limi…

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

When the abstractions are right, things fall out almost for free. Kudos for attempting this, made me smile from ear to ear.
Post reply on HN