Yes agreed, as someone who had basically no understanding of what docker does, this was very helpful (I'm pretty sure I saw it because docker used it as an introduction to itself on their site)
Really this is more interesting as a great tutorial on the way Linux container tools work (and especially their fundamental simplicity -- the docs make them seem scary when they really aren't) more than it is as a docker replacement (docker is obviously much larger than this one script, but not really "large" as a software stack).
But reading this makes clear that, yes, containers are just filesystem trees, network namespaces are just like internal networks maintained by straightforward commands underneath an "ip netns" command, etc...
Woah! Don't know if it can be used as a proper Docker replacement (probably not), but I sure do appreciate the project as an example of how to use all the tools to implement an isolated environment. And the fact that it actually works with Docker containers (well, why wouldn' it, but still) is just a cheery on top!
Under EXCLUSION OF WARRANTIES and LIMITATION OF LIABILITY.
Here, Bocker is also a replacement for Docker in exactly the same sense: Bocker's simple statement "I can't guarantee it won't trash your system" is a concise alterantive to a wall of legalese.
To be fair one is for demonstration purposes and the other is intended to be used. They seek the same protections regardless. It's kind of like how a $1,000 water filtration system wants the same legal protection that a $15 Brita does or heck, I'd assume if you got scammed with a fraudulent water filter that used orgone energy and crystals, it too would also want those legal protections.
You'd probably want to tread cautiously if someone doesn't use disclaimers - that's probably a more dangerous product.
Isn't the argument presented here that just because two things have the same "no responsibility in event of failure"-clause does not mean likelihood of failure, robustness, battletesting, etc, are comparable? Or am I missing something
Well, I didn't read the legalese but read this short sentence. That makes it 1000% better for me right now, you can't abstract away the message channel. Maybe the best would be to have a short 10-line summary then the legally bounding legalese. (Edit: nonsense spelling error)
And now I'm curious whether this would work inside a container or not. I know dind is a thing, but I don't recall whether it needs special hacks that bocker lacks.
My team is being hit with really extreme pricing changes for Docker Desktop. I have never been clear on why we even wanted DD (I guess right now it’s the easiest path to getting x86 containers running on M1 Macs?). Alternatives like Podman or even a more extreme solution like this one are becoming more and more attractive.
I actually replaced Docker Desktop on my M1 Mac, because even after quitting the app (properly), the qemu VM kept runing, and running my battery. I like that I have more control over the processes with podman. `podman machine stop` and the vm is gone.
On an M1 Mac I believe that rancher desktop (mentioned in a sibling thread) is the way to go if you are going the kubernetes route. Because I only have a really simple usecase and want something just like docker I've been using lima[1] which you can just install with homebrew and set up an alias and then pretend you're using docker. I have had some problems where in long-running processes with a lot of network usage in the container after a while I get some network timeouts. I'm not sure whether that's a problem with lima or qemu or what else might actually be causing it. But basically as a dev experience it works fine even on a pretty underpowered laptop (which is what I'm using it on in this case).
The basic license is 5 dollars a month. I think that's a low price, if you consider the time cost of exploring alternatives.
Additionally, it's a shame that the docker company struggles to profit from their revolutionary technology: operations, devops and infra looks completely different than 10 years ago and they played a big role in it.
We were on the "Docker Teams" plan, paying $7/user/month. With this pricing change, since we are over 100 users, we bump to "Docker Business" paying $24/user/month, more than a 3x price increase!
At that price point, it's definitely worth looking at what other choices there are.
I think the issue is mainly with the principle of asking someone to run a shell script to do an installation. People who are security-minded, will check the script first. Those same people know that most won't do that.
Every piece of software relies to some degree on other software. Similarly, every person relies to some degree on other people. As long as you don't find yourselves in a race to the bottom of the barrel, things should be okay.
It's like 100 lines of bash, I suggest just checking out the source code. Very easy to understand once you know the basics of containerization being basically just cgroups, namespaces, and filesystem level isolation. I link it to people who are trying to learn about what containerization actually does.
With overlays, you'd need some kind of registry of all the images in the underlying filesystem. Btrfs subvolumes give that to you for free, essentially. No need for deciding where to put them, just give them a name.
Or you could treat the final image for the container as the read only base for the overlay. That's what I do. I "flatten" the image from buildkit, and untar it to a directory. Then make an overlay mount for the container and chroot inside. :)
Right, but the point is a btrfs snapshot does that for you. No need for a "flattening" step, just make a copy-on-write snapshot of your layer at whatever state it exists in and go. Delete the original later, etc... Doesn't matter.
I was part of this, it was a fun project. I have a final pull request that never made it though, and that's too bad as it addressed some hardcoding issues and added a few helpful commands: https://github.com/p8952/bocker/pull/23
Revisiting the project, it looks like more people tried submitting PRs for the following couple years. Funny, for a project that was definitely an exercise in "do X in 100 lines of code"
Simple doesn't mean overhyped or over used. Both 'ls' and 'cd' are simple to implement. The script is more of a tutorial than it is making fun of anything. You'd need to give better reasons for why Docker is overhyped than "look at this simple script which does some Docker-like stuff".
For many cases, you don't need it. For example, deploying a Go binary. Some people have the habit of dockerizing everything at any cost and complexity.
You can still stick a single binary in a container. (Putting a whole Linux in the container as well, that's probably overkill. And alas, it's also what docker does by default.)
Only a few lines later we have the first paragraph of the GNU GPL, which includes the sentence "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed."
IANAL, but I would guess that that implies that the author is in violation of the GPL for adding that restriction?
Then a level 79 Unix beard reimplements it in 40 inscrutable lines of Perl in the shape of an ascii whale... But can't figure out how it works an hour later.
The same reason why people care about likes on Facebook or karma on HN.
Internet points mean very little, until you get enough that you start floating to the top of popularity rankings, at which point they suddenly become indirectly monetizable.
Stars have some value in they at least let you see that (the potential for funny business aside) many people have looked at the repo and upvoted it for whatever reason. I'm sure there are buggy or otherwise sketchy repos with many stars, and various gems with few stars (I have some :p ), though overall it's a signal
Incidentally karma on HN is similar to the extent that it lets you how active a participant someone is, and that they're not a troll or throwaway. Again, it can certainly be gamed, and throwaway accounts often add valuable comments, but its still a signal
I’ve been contacted more than once by recruiters who’ve been attracted by stars of my profile. It’s always a little challenging to explain to them that my profile is just my hobbies.
Because people have hobbies and wish other people are enjoying them. Or it does help people tell if code is helpful if more people are using it. Or its some guy with 8,800 throw away android phones.
Except, docker has the same prerequisites. That's kind of the point of this excercise, to show that docker is primarily glue between existing tools, not necessarily new technology.
Dockerfile format is essential because it allows for a single code to build container. This code could be used by docker build, docker buildkit, podman, kaniko and other tools. It's not ideal but it's good enough.
Container image format is essential because it allows for a shared ecosystem of containers. There are plenty of container registries and you can just pull any image, build your image using those other images, etc.
Basically docker introduced some standards and everyone accepted those standards. And that's a good thing. They're far from ideal, but they're kind of shared among implementations and good enough I guess.
Now with those standards you can innovate on implementations. Some people replaced docker with podman, having access to the same vast repository of containers. Some people replaced docker build with kaniko, which allows to build containers in a different way using the same source Dockerfile.
> Do you really consider this an endless stream of new JS frameworks popping up every day?
“Everyday” in the case of js frameworks has always been hyperbolic to me, but I think something that perhaps isn’t unfair is “once you’ve mastered a given framework, there’s a new one you have to learn.”
It certainly seems to be more development than in other languages. Seems. Seems. Seems. I could be wrong about that though.
You shouldn't replace Docker with a shell script but you should understand (at some level) how Docker works. Unfortunately this code is pretty dense so it would probably take a while to untangle it.
I see such suggestions here and there, but after quick redditing I've got impression podman brings more chores being rootless and daemonless. I couldn't justify usage of it for myself.
Had short discussion with couple of friends more familiar with podman vs docker, they highlighted the case when you need to give access to docker socket (say for building images) or for other needs to someone who is not in infrastructure admins (devops) team. As we know, having access to docker effectively meant root access on host, so such untrusted parties access implies severe risk of your host belongs to someone else now.
For such cases, when you cannot guarantee the one who operates docker is the root on host anyways, podman starts to make sense.
What drives me insane about Docker is the user interface it exposes. There are atleast 3 or 4 ways to do something. API is terrible (ports - 127.0.0.1:5000:5000 is confusing as fuck design). Volumes is a total mess, networking is worse and as a veteran user of docker for over 4 years on a daily basis, I still get confused about everything Docker is and is not. It is one tool that makes me feel like a moron.
While some parts of Docker are far from elegance, I find the isolation of containers from the host by default a beneficial feature, and part of the very point of containers.
The syntax of port mapping is unfortunate and unergonomic, but I suppose it just follows the syntax of port forwarding in OpenSSH :-/
For a number of improvements / different trade-offs, see Podman. But does it have a neat client for macOS, which many developers unfortunately run? (I don't.)
> I find the isolation of containers from the host by default a beneficial feature, and part of the very point of containers.
There are some valid usecases during development - run some services on the host, while running the rest in containers. Containers doesn't need to know if it's connecting to the host or other containers. Just pass a proper URL, and services must blindly connect to it.
Bocker – Docker implemented in around 100 lines of Bash (2015) - https://news.ycombinator.com/item?id=22244706 - Feb 2020 (196 comments)
Docker implemented in around 100 lines of bash - https://news.ycombinator.com/item?id=16453610 - Feb 2018 (9 comments)
Show HN: Bocker – Docker implemented in 100 lines of bash - https://news.ycombinator.com/item?id=9925896 - July 2015 (87 comments)