5 ms·

Shameless plug: if you just need to build a container that runs a Go program, you can't do it much simpler than with https://github.com/google/ko https://github

Shameless plug: if you just need to build a container that runs a Go program, you can't do it much simpler than with https://github.com/google/ko https://github.com/google/ko `ko publish` does a `go build` and stuffs it in a base image, it even supports multi-arch images with `--platform=all`.

darksaints 6y ago
You've got a statically compiled, fully contained executable. Why would you need to wrap that in the overhead of a container?
- anaganisk 6y ago
  Because thats how people use go applications in docker swarm, K8s etc??
- judge2020 6y ago
  You can say "I want to run image us-docker.pkg.dev/something:v1 in my cluster with these ports exposed" instead of having to spin up VMs, place the exe there (or attach a volume with it pre-placed), then configure the firewalls for those VMs.
- jjtheblunt 6y ago
  because you might want to deliver it in its "nest", i.e., a filesystem with resources the go binary wants to access at runtime
  - pjmlp 6y ago
    On proper desktop OS those resources are embedded in the binary.
    - jjtheblunt 6y ago
      agreeing with your comment, and a coffee epiphany resulted: it also made me realize that the container IS such a beast, as it's a binary file format that is handled by a different linker-loader, that which takes such a binary file, extracts the runnable content and runs it in a mounted bundled filesystem.
- weitzj 6y ago
  Because you want to run it on docker or Kubernetes. For example if you were to have a desktop program as a single binary but you could tweak its installation process. You would need some kind of configuration interface on what parameters to tweak like MSI. So Docker or even Kubernetes yaml files are the “installation files”, which otherwise your static Go binary would lack or would be provided as either a README.md or your own custom configuration format, which you have to document. Sure enough the single Go binary is nice and I use this often for some cli tools, but if you integrate your tooling with other people and have to communicate, it makes it easier to agree on a common language (not programming language), but “configuration/deployment “ language, so that when you talk about: “this is a port”, everybody in the team can look up what “a port” is.
- systemvoltage 6y ago
  It's a valid question and most responses here are missing the main point - saying that "Because it needs to run on Kubernetes" or whatever is valid, but that's like saying what's the point of a car? So that we can mount an engine in it. If you're not dependent on any externalities, you could just ship your executable over rsync to the server and you're all set.
- justincormack 6y ago
  Go binaries are not entirely self contained. Even when fully statically linked (and there are several options to still use libc features) they use the certificates from the filesystem and a fee other files. So if you want full control you should ship these too.
  - johannes1234321 6y ago
    > they use the certificates from the filesystem [...] if you want full control Bow the question is who that "you" is. As the the one running it I have less control and a harder time updating those and depend more on the developer providing those.
    - mikepurvis 6y ago
      Containers are more than just FS isolation— there's a convenience piece here where someone might like it in a lightweight container for the sake of sane integration with higher level orchestration, management of resources like ports, storage, etc. In your case, it may be that these aren't considerations, and you'd prefer to just run the binary directly against your bare system.
      - johannes1234321 6y ago
        Oh, I love containers and do most my work in them. However I also mind that that production needs are different than developer needs and have seen too many cases where containers made security audits (a new openssl update - where do I have to apply it?) hard ... and certificates triggered me ;)
  - ImJasonH 6y ago
    Yep! By default ko bases images on gcr.io/distroless/static:nonroot which provides certs and other necessary basics, all in a nice tidy package.

darksaints 6y ago

You've got a statically compiled, fully contained executable. Why would you need to wrap that in the overhead of a container?

anaganisk 6y ago
Because thats how people use go applications in docker swarm, K8s etc??
judge2020 6y ago
You can say "I want to run image us-docker.pkg.dev/something:v1 in my cluster with these ports exposed" instead of having to spin up VMs, place the exe there (or attach a volume with it pre-placed), then configure the firewalls for those VMs.
jjtheblunt 6y ago
because you might want to deliver it in its "nest", i.e., a filesystem with resources the go binary wants to access at runtime
- pjmlp 6y ago
  On proper desktop OS those resources are embedded in the binary.
  - jjtheblunt 6y ago
    agreeing with your comment, and a coffee epiphany resulted: it also made me realize that the container IS such a beast, as it's a binary file format that is handled by a different linker-loader, that which takes such a binary file, extracts the runnable content and runs it in a mounted bundled filesystem.
weitzj 6y ago
Because you want to run it on docker or Kubernetes. For example if you were to have a desktop program as a single binary but you could tweak its installation process. You would need some kind of configuration interface on what parameters to tweak like MSI. So Docker or even Kubernetes yaml files are the “installation files”, which otherwise your static Go binary would lack or would be provided as either a README.md or your own custom configuration format, which you have to document. Sure enough the single Go binary is nice and I use this often for some cli tools, but if you integrate your tooling with other people and have to communicate, it makes it easier to agree on a common language (not programming language), but “configuration/deployment “ language, so that when you talk about: “this is a port”, everybody in the team can look up what “a port” is.
systemvoltage 6y ago
It's a valid question and most responses here are missing the main point - saying that "Because it needs to run on Kubernetes" or whatever is valid, but that's like saying what's the point of a car? So that we can mount an engine in it. If you're not dependent on any externalities, you could just ship your executable over rsync to the server and you're all set.
justincormack 6y ago
Go binaries are not entirely self contained. Even when fully statically linked (and there are several options to still use libc features) they use the certificates from the filesystem and a fee other files. So if you want full control you should ship these too.
- johannes1234321 6y ago
  > they use the certificates from the filesystem [...] if you want full control Bow the question is who that "you" is. As the the one running it I have less control and a harder time updating those and depend more on the developer providing those.
  - mikepurvis 6y ago
    Containers are more than just FS isolation— there's a convenience piece here where someone might like it in a lightweight container for the sake of sane integration with higher level orchestration, management of resources like ports, storage, etc. In your case, it may be that these aren't considerations, and you'd prefer to just run the binary directly against your bare system.
    - johannes1234321 6y ago
      Oh, I love containers and do most my work in them. However I also mind that that production needs are different than developer needs and have seen too many cases where containers made security audits (a new openssl update - where do I have to apply it?) hard ... and certificates triggered me ;)
- ImJasonH 6y ago
  Yep! By default ko bases images on gcr.io/distroless/static:nonroot which provides certs and other necessary basics, all in a nice tidy package.