The backstory: To bypass internet censorship and deep packet inspection, I had written a proxy chain solution masquerading itself as plain html traffic. I needed it constantly running everywhere I went, but I didn't want to port it to a native android app. I wanted to run it through termux and at the time termux had no jdk/jre. Proot could spawn a archlinux env and there indeed was a jdk available.
The arch env within termux turned out to be generally more suitable for all tasks. Creating and destroying ephemeral envs with different setups and prooting into them to just run a single command is easily automated with a script; I named it bag.sh, a drastically smaller form of a shipping container.
Funny bag.sh also has a roadmap/todo in there untouched for 5 years! It's written on mobile screen hence mostly formatted to 40 columns lines to fit on the display without scrolling.
More generally though, implementing a crude version of a larger application is one of the best ways of learning how things work inside it. I'm a big fan of the approach.
> mkdir -p $(dirname "$2")
Combine that with a ~10" bluetooth keyboard that fits comfortably in my leather jacket's inside pockets and I get to leave the house without carrying a bag and still sit and write code in the back corner of a handy beer garden.
Turns out to be surprisingly productive as well, probably because there's just enough extra friction to flipping to my usual distractions compared to a laptop that I tend to just take a sip of my beer while continuing to glare at the code instead.
I likely lost it, but I had a redundand and distributed reverse SSH tunnel based colo-to-cloud transfer tool.
Shell Fu and others have good collections of these https://www.shell-fu.org/
Where Docker adds real value is not (just) Docker Hub but Docker for Windows and Mac. The integrations offer a vastly superior experience than messing around with VirtualBox and Vagrant by hand (been there, done that) to achieve running Docker on one's development machine.
If there is always some next ideas then by definition you must always have todos that never get done. It should actually be the normal state of every single project.
It's a fairly full-featured Terminal UI that has the benefit of running over ssh:
Docker is just a combination of kernel tech that already exists. Namespaces, cgroups, and union file systems and probably few others.
But Linux containers[1] are actually fascinating stuff, really powerful, and (even for the Docker experts) poorly understood. The point of Bocker isn't "see how easy it is to rewrite Docker" it's "See how simple and powerful the container ecosystem is!".
[1] Also btrfs snapshots, which are used very cleverly in Bocker.
The reason people use docker over Podman and rolling their own is because of the ecosystem and ubiquity of docker.
Currently I'm going through a phase of building and managing jails with just the stuff in FreeBSD base, but that's entirely intended to only be a phase - it'll last until I have the way all of it fits together burned into my brain well enough to be confident debugging it, and then I'll stop banging rocks together and go back to using higher level tools like a sensible person :D
By the way it took me a while to get why it was named Bastille. As La Bastille was a castle built to defend Paris from English attacks during the Hundred Years' War, and then turned into a prison.
Careful. The default installation prefix is /usr/bin, and the install will happily clobber your mount command with one that requires a library that doesn't exist. Then next time you boot, the kernel will mount the file system read-only.
On Linux, docker is basically fancy chroot.
Also, in a 2013 docker meetup, someone wrote a docker clone in bash.
People want to learn! Hopefully things like this help them.
> Bocker runs as root and among other things needs to make changes to your network interfaces, routing table, and firewall rules. I can make no guarantees that it won't trash your system.
Linux makes it quite hard to run "containers" as an unprivileged user. Not impossible! https://github.com/rootless-containers/rootlesskit is one approach and demonstrates much of the difficulty involved. Networking is perhaps the most problematic. Your choices are either setuid binaries (so basically less-root as opposed to root-less) or usermode networking. slirp4netns is the state of the art here as far as I know, but not without security and performance tradeoffs.
I don't need a seperate network nor process isolation.
There are native macos containers, but they arent very popular
It’s an old version, and I think it isn’t supported by Docker Inc (for the reasons mentioned in the sibling comment), but it’s there.
IMO the real magic of Docker was the Docker/OCI image format. It's a brilliant way to perform caching and distribute container images, and it's really what still differentiates the workflow from "full" VM's.
I lived through a failed attempt to migrate from Docker Desktop for Mac to an open source alternative (minikube+portainer, IIRC). A lot of test scripts developers relied on – to run parts of the integration test suite on their laptops for debugging – broke, because Docker Desktop for Mac went to a lot of effort to make macOS look like you were running Docker on Linux, whereas the open source replacement wasn't as seamless. Some of these test scripts contained Java code directly talking to the Docker daemon over its Unix domain socket, so need the same API implemented. Many other scripts made heavy use of the Docker CLI. After spending a lot of time on it, it was decided to just go back to Docker Desktop for Mac. The failed migration had resulted in highly paid engineers spending time pulling their hair out trying to get test scripts to work instead of actually fixing bugs and delivering new features.
Now, that was 2+ years ago now, and maybe the open source alternatives have caught up since, or maybe we picked the wrong one or made some other mistake. But I'm not rushing to try it again.
Podman is in many aspects superior, while still being able to function as a drop in.
Docker's only real innovation was the OCI format, which it had to give away for it to become an industry standard, and now doesn't own.
(this is not intended to start a filesystem argument, I'm doing it with zfs because I already know zfs and it's available on both of the OSen I care about; if you already know btrfs and are only running things that support it, clearly you should use that for the exact same reasons ;)
So had I ended up in the same situation as you I would probably have done similar, but with an added undercurrent of "Matt, you idiot, how did you manage to forget to put the keyboard in your pocket before you left?!"
(still a neat hack on your part, mind, no question there, but I'm very much glad I've optimised by standard "leaving the house" loadout so inflicting the same thing on myself is at least *less* likely ;)
(this is in no way a comment about what the right decision would have been, only musing on an additional reason the decision might have gone the way it did)
I was surprised when they shut that down too.
Your situation sounds very similar to the company I work for. Orbstack has been a drop in replacement except one issue. Any dev using IPv6 assignment on their home network has issues where pods try to hit external dns because it tries to use IPv6 and I don’t think the Orbstack k8s instance is dual stack.
There are hacks to get around it but if I could get Orbstack to address this issue, I couldn’t find one other issue.
Orbstack is crazy fast and way better than docker desktop overall
Similar issues in our environment, and I managed to swap everything over to Rancher Desktop fairly seamlessly as it does the exact same thing. It runs a Linux VM and if you select the "dockerd (moby)" container engine it runs a copy of docker inside of it. So you get a socket with the same docker API implemented... because it's running actual docker. docker compose and everything else work as expected.
The reason we switched is that Rancher Desktop, along with providing a convenient way to run docker, also includes a full k3s install in that same VM. So we can work on unifying some of our stack/configs on kubernetes rather than docker for local and kubernetes for everywhere else. It also opens up using upstream helm charts and things when a developer wants to deploy and try something locally.
It's also free. Open source and backed by SUSE, who also develops and maintains the k3s distribution among other stuff in this space.
Yes, but that wasn't what I was talking about. Docker Desktop for Mac goes to a lot of trouble to hide the fact that there are two different virtual filesystems involved (Linux vs macOS) and two different networking stacks too. That means scripts which run on Docker for Linux and do stuff involving filesystem/network integration between the host and the container will often work without change on Docker Desktop for Mac. In my past experience, open source alternatives don't offer as seamless integration, they don't do as good a job of hiding the fact that there are two different virtual filesystems and networking stacks, so those kinds of scripts are less likely to work.
FS: Rancher mounts your `/Users/$USER` folder in the VM that Docker is running in. It supports virtiofs on macos (not sure if it's used by default though). As far as I can tell, this replicates the default Docker Desktop setup.
Networking Container -> Host: Connecting to `host.docker.internal` works as expected. On the host I can listen on a port on my host (`nc -l -p 1234`) and connect from a container (`docker run -it --rm alpine nc host.docker.internal 1234`).
Networking Host -> Container: Exposed ports work as I would expect. I can run a container with an exposed port (`docker run -it --rm -p 1234:1234 alpine nc -l -p 1234`) and connect from my host (`telnet localhost 1234`). I can't connect directly onto the docker network bridge (though I'm not sure if that was ever supported on OSX?).
No skin in the game either way here, just with a bunch of people suggesting buying OrbStack (which is OSX only), figured I'd throw Rancher Desktop out as a potentially viable cross-platform alternative that's also free and OSS.
