Hacker News Reader

Comment by bibabaloo | Hacker News Reader

> One thing a Docker container gets you for a simple Go app is the ability to run it on any platform that runs container images (like ECS); that's more flexibility than you get with something that needs a proper VPS to run. Everything knows how to run a Docker image.

It is kind of bonkers that we've gotten to a stage where more things know how to run a container than know how to run a statically linked binary.

View on HN

"Running a binary" is still super easy. All you need to do is take account of log management, process isolation, networking configs (port forwarding), service discovery, health checking, data storage folders, fault-tolerant rollbacks, binary placement (putting the x86 binary on the x86 machine & arm on the arm machine), config files, environment variables, the working directory the process needs, etc.

Anything that "runs a binary somewhere" will essentially become docker given enough time. Docker is just "run this binary somewhere" everything above packaged into it.

> Anything that "runs a binary somewhere" will essentially become docker given enough time.

Docker... doesn't do nearly any of those things?

Docker attempts to do all of these things. It may not do them well but it provides a framework/opinion on how this should all be managed:

1. binary + configs (PWD, files, ENV): baked into the image's Dockerfile

2. Secrets: passed in via env vars at runtime

3. Service discovery: docker-compose exposes container name as a hostname and provides a DNS record for this available in all netns that are connected to the same network.

4. data storage folders: Volumes https://docs.docker.com/storage/volumes/#share-data-among-ma...

5. Health checking: https://docs.docker.com/engine/reference/builder/#healthchec...

6. binary placement: https://www.docker.com/blog/multi-arch-build-and-images-the-...

7. networking configs: https://docs.docker.com/network/

8. log management: to file or to syslog over TCP (super easy to ship to ELK) https://docs.docker.com/config/containers/logging/configure/

9. fault-tolerant rollbacks: if you tag images correctly and you are upgrading from v1 -> v2 you can just replace the tag with :v1 to rollback to the correct version which will also be cached on the machine. If your registry is down you can still rollback.

10. Process isolation: this is exactly what docker is. Process isolation implemented in the kernel (sometimes).

Docker doesn't have any infrastructure for managing configs. Nor secrets. It doesn't have log shippers or storage -- and "to file or syslog over TCP" are definitely not the recommended ways! The only thing it really "does" there is process isolation.

If everything compiled to a statically linked binary, sure. But most things don't compile to static binaries, and platforms are built to run things in all kinds of languages.

Meanwhile: Docker can be pretty insane as a runtime (we don't use it for that!) but it's not an insane packaging format.

Well, turning a static binary into a docker image is basically just adding some metadata on how to run it. Whereas turning an image into a static binary is much harder, so it makes sense the world standarized on the more flexible format.

Reply on news.ycombinator.com