13 ms·

it isnt and very few people actually think that. plenty of "from scratch" images. ergo any image that is a single go binary

silisili 3y ago
Never made a ton of sense to me. Go crosscompiles easily, ship a binary. Because the second you want to do anything involving https, you need certificates, and that's where having a minimal but existent base image starts shining, and mostly goes up from there...
- speedgoose 3y ago
  Once you have a hammer… One advantage of software containers is to have this unique interface that is the same whatever is inside the container. Like shipping containers. If it's one single golang binary, or a weird python container running only on specific version of Debian compiled during a blue moon, or some 8GB java enterprise bloatware, it's the same.
  - claytongulick 3y ago
    See, this is actually my problem with containers. "or a weird python container running only on specific version of Debian compiled during a blue moon" This. I guess I've been fortunate that I'm able to reject software like this from my stack. I know that everyone isn't so lucky. I mostly do nodejs, and have zero need for containers when a simple npm install gets all deps. Or if I need performance, a single go binary. I tried doing the container thing just to understand how it all works and what the hype is about. It seemed needlessly complex and hard to develop/debug. For more complex situations where you need a bunch of interacting programs and services, I prefer stuff like Ansible and VMs, or just manually setting up a base image. I guess it's a "get off my lawn" kind of thing. It seems like containers are used a lot by folks who don't want to learn ops, like how to install and configure postgres, redis, etc... I think that's a mistake, and just pushes the problem onto others who have to support the software in production.
- maccard 3y ago
  Containers are more than "just" running a binary now though. If your "deploy" script is: docker build -t my-app . && docker push my-app Then all of a sudden it's a reproducible, reusable deployment script that works for any language, any application, and that any other dev on your team can run (as opposed to playing "which flavor of coreutils did they use when they wrote this?"). It's provider agnostic - you can run it on DO, AWS, GCP, whatver. You get free rolling/blue green/canary/whatever you prefer deployments, a "basic" cross compilation out of the box. They're not magic, but they are an excellent abstraction, despite the warts.

silisili 3y ago

Never made a ton of sense to me. Go crosscompiles easily, ship a binary. Because the second you want to do anything involving https, you need certificates, and that's where having a minimal but existent base image starts shining, and mostly goes up from there...

speedgoose 3y ago
Once you have a hammer… One advantage of software containers is to have this unique interface that is the same whatever is inside the container. Like shipping containers. If it's one single golang binary, or a weird python container running only on specific version of Debian compiled during a blue moon, or some 8GB java enterprise bloatware, it's the same.
- claytongulick 3y ago
  See, this is actually my problem with containers. "or a weird python container running only on specific version of Debian compiled during a blue moon" This. I guess I've been fortunate that I'm able to reject software like this from my stack. I know that everyone isn't so lucky. I mostly do nodejs, and have zero need for containers when a simple npm install gets all deps. Or if I need performance, a single go binary. I tried doing the container thing just to understand how it all works and what the hype is about. It seemed needlessly complex and hard to develop/debug. For more complex situations where you need a bunch of interacting programs and services, I prefer stuff like Ansible and VMs, or just manually setting up a base image. I guess it's a "get off my lawn" kind of thing. It seems like containers are used a lot by folks who don't want to learn ops, like how to install and configure postgres, redis, etc... I think that's a mistake, and just pushes the problem onto others who have to support the software in production.
maccard 3y ago
Containers are more than "just" running a binary now though. If your "deploy" script is: docker build -t my-app . && docker push my-app Then all of a sudden it's a reproducible, reusable deployment script that works for any language, any application, and that any other dev on your team can run (as opposed to playing "which flavor of coreutils did they use when they wrote this?"). It's provider agnostic - you can run it on DO, AWS, GCP, whatver. You get free rolling/blue green/canary/whatever you prefer deployments, a "basic" cross compilation out of the box. They're not magic, but they are an excellent abstraction, despite the warts.