Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

31–40 of 89 posts

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

#31

Post by davexunit »

catern wrote: post #28
davexunit wrote: post #27

Earlier quoted context omitted.

If Docker is about packaging, then it's one of the worst package management systems I've ever used. I use Docker for the abstraction over namespaces and cgroups mainly, and get frustrated with the layers of disk images, bad caching system, poor security story, and the weak Dockerfile DSL.

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 for package updates gone bad, and builds aren't reproducible (Debian is doing great work to fix this, though), to name the most important issues.

I work on the GNU Guix project, which can do all of these things. Additionally, with Guix, I have access to a configuration management system that can create disk images, VMs, and (in a future release) containers (replace Chef/Puppet/Docker), a tool for quickly creating isolated dev environments without polluting the rest of the system (replaces virtualenv and Vagrant when combined with a VM/container), and more.

I'm convinced that more featureful package managers can and will solve a lot of our software deployment problems, and I'm also convinced that simply layering more tools on top of a shaky foundation isn't going to work well in the long term.

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

#32

Post by ecnahc515 »

davexunit wrote: post #30
hosh wrote: post #25

Earlier quoted context omitted.

Two of the things I'd love to see is having the image format be: (1) Open standards (and I'm hearing things moving in that direction) (2) Content-addressability, so that images can be stored on IPFS. Point (2) really plays the "packaging" rather than the "containment" aspect. I'm not really thinking about Docker Hub or any proprietary services like that. There's a project put out by Chef (formerly Opscode) called Omn…

Omnibus is a step backwards. Every monolithic Omnibus package has its own copy of each dependency, so you end up with duplicated binaries. You can no longer patch a library system-wide, you have to figure out which Omnibus packages have the library and rebuild it with the patched version. Package management was invented to deduplicate files across the system, and people seem to have given up on that. You say that Doc…

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 necessarily want to do all of this in a package manager.

It's actually a good thing that we have these duplicates from a packaging perspective, because you completely remove the host requirements altogether, and can focus on what an app needs, and if you want to take advantage of deduplication (on disk, or in memory), then you can let another subsystem resolve that for you.

To resolve the patching something system-wide, you simply use a common base image, it's orthogonal to containers. Just because you can have different versions of a dependency, doesn't mean you need to. The main advantage of the container having it's own version is that you can independently upgrade components without worrying that a change will effect another application.

You might argue that this is a security concern, but I'd argue that it's more secure to have an easily updatable application than an easy way to update a particular library across all applications. In the latter case, we already know what happens, people don't update the library nearly as often as they should, because it could break other applications which might rely on that particular version. At least in the first case we can upgrade with confidence, meaning we actually do the upgrades.

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

#33

Post by pravka »

catern wrote: post #28
davexunit wrote: post #27

Earlier quoted context omitted.

If Docker is about packaging, then it's one of the worst package management systems I've ever used. I use Docker for the abstraction over namespaces and cgroups mainly, and get frustrated with the layers of disk images, bad caching system, poor security story, and the weak Dockerfile DSL.

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.

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

s/well-developed/widely-used

Just because a package manager has a broad user base does not make it excellent nor well-developed. pacman[1] user base is far smaller, but (IMHO) it's a much more refined package manager than apt or rpm.

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

#34

Post by chjj »

vezzy-fnord wrote: post #3

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…

Agreed. That was pretty good. A dash of bash with 3 teaspoons of butter: https://en.wikipedia.org/wiki/Btrfs#Subvolumes_and_snapshots

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

#35

Post by tobbyb »

p8952 wrote: post #11
vezzy-fnord wrote: post #3

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.

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

https://www/flockport.com/store

https://www.flockport.com/guides

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

#37

Post by pekk »

Wow, Docker in 100 lines! It runs as root? Oh. It is written in bash? Oh. It needs a ton of manual setup? Oh. It doesn't actually implement the package format which is most of the point of Docker? Oh. So is it that easy to reimplement Docker? Despite the obvious snarky intent, it appears not.

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

#38

Post by zobzu »

logicrime wrote: post #18

Holy crap! I've been keeping up with the hype, yet having never used Docker and never needed it yet I can't help but become more skeptical now that I know that it's features aren't more complex than a little bit of bash. People give bash a hard time, but things like this really give me that warm, fuzzy feeling. esac4lyfe

to be honest most of the work is done by iproute and unshare in this case. unshare basically calls clone() (syscall) with the correct namespace related paramters, iproute deals with veth.

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

#39

Post by yodasan »

josegonzalez wrote: post #22
eatitraw wrote: post #17

Now we need bokku: https://github.com/progrium/dokku

Dokku written in bash? (I am one the maintainers of dokku, which is written in bash).

I think he's suggesting creating a similar project to dokku, but instead of using Docker, use Bocker.

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

#40

Post by nitrogen »

vezzy-fnord wrote: post #29
hosh wrote: post #26

Earlier quoted context omitted.

There are several tech streams converging there. A bigger chunk is the space that Mesos and Kubernetes occupy. And to be fair, I suspect the Docker folks were thinking less about clustering and orchestration so much as: (1) clustering and orchestration still sucks; (2) people want as good of an experience using docker as they do when spanning across multiple nodes; (3) let's make clustering and orchestration less suc…

clustering and orchestration still sucks I don't see that changing until we get proper single-system imaging, location transparency, process and IPC migration, process checkpointing and RPC-based servers for representing network and local resources as objects (be they file-based or other) in our mainstream systems. These things only really caught on in the HPC and scientific computing spaces, where you've had distrib…

I ran an OpenMOSIX cluster as a hobby. The alternative was Beowulf (the meme of the day was "Imagine a Beowulf cluster of these things").

It seems the mainstream server industry has moved to more isolation rather than more interconnectedness, which is probably better for most public-facing systems.

Post reply on HN