What does HackerNews think of bocker?
Docker implemented in around 100 lines of bash
You don't even need a few hundred: https://github.com/p8952/bocker
And then there's 'dokku' which IIRC, started as a bash version of Heroku.
> Not all ideas have the same quality.
They really do. I've heard all kinds of things in my career, but almost none I would want to dedicate a portion of my life building. Not because they are bad ideas or won't work, but because of the person with the idea or it just didn't interest me. Those people went on to be moderately successful (like hundreds of millions worth) but I'm glad I wasn't on that ride.
Docker implemented in around 100 lines of bash: https://github.com/p8952/bocker
This is the most mindblowing example for enterprise security teams that think Docker is a new threat on a single tenant Linux host.
No, buddies, all this stuff is already there. If you were fine with your visibility before*, you're still fine. Go find a real problem while people play with their developer dopamine.
* NARRATOR: They shouldn't have been.
[1]: https://github.com/p8952/bocker/
[2]: https://news.ycombinator.com/item?id=33218094 (116 comments)
https://github.com/p8952/bocker? Last commit was 7 years ago, and even then this was more of an experiment / PoC - I really don't think this was ever meant as a viable replacement. (IMHO Bash is a horrible language as well.)
I agree with your sentiment on container/cloud tooling. It doesn't need to be this complicated, the needs of the 1% are dictating the experience for the 99%. However Docker (the basic CLI interface) and Dockerfile (the format) did a lot to bring containers to the mainstream, and you can still get quite a lot out of it by just sticking to the basics. For self-hosting simple services, or even just deploying your application, on plain old VPS/box-under-the-desk, it's still just plain brilliant; at least compared to loading files into a shotgun and aiming in the general direction of /opt, /usr/local, /home/app, /etc.
I'm in love! <3 :-D
Related: Bocker, Docker rewritten in 100 lines of Bash https://github.com/p8952/bocker
By and large, there’s no such thing as a container, there’s just sprinkles of housekeeping magic. To wit, Docker implemented in around 100 lines of bash:
https://github.com/p8952/bocker
Problems come when we think that today’s containers manage to actually contain anything, bring any security guarantees, or do much else than just slightly-more-successfully jump start a configurable bundle of dependencies.
It clarifies security thinking if you pretend you don’t have a container, but instead, you’ve got a new kind of tar file, some namespacing, some niceness, iptables, and some convenience aliases:
https://github.com/p8952/bocker
None of it’s magic, and none of it brings new security guarantees. There’s just the stuff hosts had, that’s what they still have, so however you secured a process under that stuff, you still must do it to a process under this stuff, just now against an extra pile of abstractions and duplicate OS cruft.
Devs are mad at the security team because they want to inexplicably pile another dubious OS into with apt-getted software of dubious third party libs somehow expecting the whole thing to be safer, and the security team reaction is to want to “scan” the pile of nonsense.
Both groups, and the vendors exploiting them, desperately do not want to grapple with the implications of your point 2.
This position is not popular.
As for point 1, it could be argued Google is continuing this experiment, and learning from it, as seen in more than one CVE last year addresses obtaining root on GKE:
https://cloud.google.com/kubernetes-engine/docs/security-bul...
That said, your point 1 can be found, if you already had a way of securing a public host with security boundaries asserted from outside the host.
For instance, one of the GKE CVEs mentions the GKE Sandbox relying on gVisor:
https://cloud.google.com/kubernetes-engine/docs/concepts/san...
(About that extra OS in the container, note Google’s plea for distroless and no shell. Are folks even listening?)
See also Firecracker:
https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir...
While gVisor and Firecracker are fantastic, I’d argue for a real “belt and suspenders” instead of just more belts. Most likely it’s better to get actually outside the host metal, stop counting on software.
Perhaps the best known commercialization of a custom hardware approach that’s readily available to end users is AWS Nitro, with an ok-if-markety backgrounder here:
https://www.allthingsdistributed.com/2020/09/reinventing-vir...
Google offers a good writeup on the isolation layers:
https://cloud.google.com/blog/products/gcp/exploring-contain...
Note their comments on the hypervisor, and consider what Nitro is doing.
I think I have a basic grasp of those things, but still don't get how Docker uses them.
> You should also study this https://github.com/p8952/bocker
Cool! That's very usefl!