As someone who came to Go without prior work experience in web technology, I struggle to understand the value-added from building a tiny container that is barely larger than a single binary, instead on just working with that binary. I'm sure there's a reason for it, but I've yet to learn what it is.
Yes with a single statically compiled binary there's not much point in containers, and frankly I don't think docker is reliable enough unless you're running at large scale, in which case it might become useful for deploying. I think the usage of containers is more just to ease local testing and deployment of heterogenous environments (which might not include just go, might include tools in other languages).
If you're just running one go binary there's no point. This website for example is just a single service managed by systemd running on a tiny DO box running CoreOS. No need for containers. The deploy script is a few lines long (rsync up and restart service).
I actually prefer the approach taken in https://medium.com/travis-on-docker/multi-stage-docker-builds-for-creating-tiny-go-images-e0e1867efe5a with the explicit FROM ... AS instead to create an alias over the --from=0 which is rather opaque.
As someone who came to Go without prior work experience in web technology, I struggle to understand the value-added from building a tiny container that is barely larger than a single binary, instead on just working with that binary. I'm sure there's a reason for it, but I've yet to learn what it is.
Yes with a single statically compiled binary there's not much point in containers, and frankly I don't think docker is reliable enough unless you're running at large scale, in which case it might become useful for deploying. I think the usage of containers is more just to ease local testing and deployment of heterogenous environments (which might not include just go, might include tools in other languages).