4 ms·
> 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 flexibil
by bibabaloo 6y ago
> 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.
- tptacek 6y agoIf 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.
- gravypod 6y ago"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.
- sagichmal 6y ago> Anything that "runs a binary somewhere" will essentially become docker given enough time. Docker... doesn't do nearly any of those things?
- gravypod 6y agoDocker 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-machines https://docs.docker.com/storage/volumes/#share-data-among-ma... 5. Health checking: https://docs.docker.com/engine/reference/builder/#healthcheck https://docs.docker.com/engine/reference/builder/#healthchec... 6. binary placement: https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/ https://www.docker.com/blog/multi-arch-build-and-images-the-... 7. networking configs: https://docs.docker.com/network/ 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/ 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).
- sagichmal 6y agoDocker 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.
- deleted 6y ago[deleted]
- bennofs 6y agoWell, 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.