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

81–89 of 89 posts

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

#81

Post by dsmithatx »

Gigablah wrote: post #55
SFjulie1 wrote: post #50

I thought puppet/chef were the pit of the devops ridicule. Then I not only saw this, but also positive reactions to a readable code in which you have : echo 'nameserver 8.8.8.8' > "$btrfs_path/$uuid"/etc/resolv.conf This is wrong on so many level that I don't know where to begin with.

Can you share why you think puppet/chef are the "pit of the devops ridicule"?

Having implemented it across 10k+ servers in 12 datacenters I'd say he means Puppet is overly complex for what provides. Kind of like Docker. I think people equate Chef to the same over-complexity.

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.

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

#82

Post by XorNot »

Spakman wrote: post #72
XorNot wrote: post #66

Earlier quoted context omitted.

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.

What do you mean that "The security story is unfinished though."?

It's openly pointed out in the docs that it's intended to prevent unintentional system alterations, not stop an actively hostile program - i.e. there's not a lot of confidence from the devs in it's isolation levels yet.

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

#83

Post by juliangregorian »

vidarh wrote: post #67
Spivak wrote: post #57

Earlier quoted context omitted.

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.

No, they are isolation, a much stronger proposition.

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

#84

Post by tlrobinson »

p8952 wrote: post #12
tlrobinson wrote: post #5

Here's a proof-of-concept implementation of "docker pull" in bash (YMMV, I think it has broken since I wrote it): https://gist.github.com/tlrobinson/c85dca269f4405ad4201

Looks good! 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.

The only hard bit is parsing the JSON, which I use jq for (http://stedolan.github.io/jq/)

I think the v2 API requires hitting an auth endpoint too.

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

#85

Post by [deleted] »

tobbyb wrote: post #19

Just playing with this in a VM with an attached btrfs volume, a complete revelation. 96 lines! And it's actually pretty functional. This takes keeping it simple to a whole new level. 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…

[deleted]

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

#86

Post by cyansmoker »

tobbyb wrote: post #19

Just playing with this in a VM with an attached btrfs volume, a complete revelation. 96 lines! And it's actually pretty functional. This takes keeping it simple to a whole new level. 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…

Yes they do. Nice to learn about even more projects than I thought existed.

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

#88

Post by collyw »

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

bash is quite a neat language (for what it does) but has horrendous syntax.

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

#89

Post by hueving »

vidarh wrote: post #65
hueving wrote: post #58

Earlier quoted context omitted.

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 peopl…

One of the touted benefits of containers is shipping images to people with your software. That means as a customer you cant rebuild the image yourself.

It's exactly like statically linked binaries.

Post reply on HN