Gocker: Docker implemented in 1.3k lines of Go

The problem is the implicit guarantee:

- Step 3: pip update && install X

- Step 4: run step-tool

- Step 5: pip update && install Y

To be clear, I'm sure all these things can be solved by a complex enough stream of shell commands, but I'm also forced to shove in updates at every step of my build, which is an artifact of the build-system

The biggest advantages though is having to explicitly define al the edges:

- You need persistent storage? You better define it or you'll lose it one the next (re)deploy. - You need to expose network services? Tell me which-ones or it won't work.

If we're talking on small scale single server deploys, it makes backup, upgrade/rollback and migration of applications a LOT easier.

As long as you're not talking about a k8s cluster - which you should avoid with application architectures that aren't "cloud native", I assume you'll have a local docker-compose file which you just start/stop to bring the entire application stack you need (database/app/proxy server/monitoring/...) with one command, which means all external service dependencies are also contained in one 'stack'.

What I also use it for on small-scale apps is having a test environment of the same software running on the same droplet. I just put a Traefik reverse proxy in front of it that autodetects the docker containers, handles HTTPS/ACME certificates and routes the test-url to the test-containers, the real URL to the "production" containers, and they're all isolated.

Or Rust, "rocker" would make a great name.

Pretty cool, and very educational for people not familiar with how these things work

That said (and I've said this before), this is not really Docker. It's running containers, not the same thing. If you want to compare it to anything, it's runc, but that's not a good headline :)

Not that the docker architecture is that clean, but it is the combination of ideas it brought to the table what made docker docker:

- have APIs to do everything, from launching workloads to building images. - combining layered filesystems with os-level namespaces - package format for "images" coupled with a distribution system

If it was just starting containers, that was already possible for a good while (and many shared hosting providers already did this).

I think many people underestimate the importance of the first point, having an API to do all this. It's having this combination of ideas that democratised cloud computing, it is what makes the bigger picture possible. While the Docker API is currently not very important anymore, it showed the possibilities, and made the limitations it had also very apparent, and at the beginning, nobody had solutions for this. It took things like Mesos and kubernetes to take it to the next level, with the latter having become the de-facto standard container API.

Must be country block due to copyright cause it works for me, it's a scene from Meet the Parents - Milking Cats.