Ko: Easy Go Containers(ko.build) |
Ko: Easy Go Containers(ko.build) |
Ko's simplicity comes from focusing on doing exactly one thing well -- it doesn't have to run containers to build code in any language, it just builds minimal Go containers, and that means it can focus on doing that as well as possible.
Another powerful benefit of focusing on Go (IMO) is that ko can be used to transform a Go importpath to a built image reference.
A common simple use: `docker run $(ko build ./cmd/app)`
This is also how Kubernetes YAML templating[1] works, and it's also how the Terraform provider[2] works -- you give it an importpath, and ko transforms it into a built image reference you can pass to the rest of your config. I don't even "use ko" day-to-day most days, I mostly just use terraform. :)
1: https://ko.build/features/k8s/ 2: https://ko.build/advanced/terraform/
Despite that it's probably still the best tool for building containers in Go, but it's not pleasant.
`ko builds images by executing go build on your local machine`
If you've done any sort of work with service or application development on a team, you will no doubt have encountered issues with relying on local machine build dependencies. Enforcing dependency versions across the team is basically impossible even in cases where the entire team is using the same OS and hardware, so you're going to run into problems where users are building the codebase with different versions of tools and dependencies. This is one of the core problems that containerization was intended to solve, so if you are using containerization in development and not building inside the container, you are missing out on one of the major advantages of the paradigm.
For the most part, for the most common simple Go applications, if you build the same code with the same version of Go installed, you'll get the same dependencies and the same artifact.
Building Go applications in containers is not necessary in general, and doing so makes it much more complicated to share a build cache. You can of course do it with enough additions to your Dockerfile, but why bother?
If your developer team and CI environment are all using a similar recent Go, they shouldn't have different behavior using ko together.
Now extrapolate this out to larger orgs, where months might pass between changes to repos, and commits might be coming from disparate teams. Trying to mandate specific Go versions AND versions of any developer tooling that you might need to run your Go application locally, and you are inviting chaos.
Always build in the container. Local system dependencies are the enemy. Docker configuration for Go is actually extraordinarily simple compared to most languages, and even something like build caching is easy to handle via volumes.
FROM alpine:latest AS base # Scratch does not have shell so we have to create non-root user in here and later copy it into scratch. RUN adduser -D -u 123456 appusr
FROM scratch # Copy the binary. COPY foo.bin /foo.bin # Copy the user and set is as active. COPY --from=base /etc/passwd /etc/passwd USER appusr # Non-root user cannot bind to "privileged" ports(<=1024). EXPOSE 1234 ENTRYPOINT ["/foo.bin"]
Simple. But i can see ko being good alternative if you for some reason do not want to install docker on your computer but still be able to build docker containers.
`docker run $(ko build -L main.go)`
I think Bazel can be a good fit for larger polyglot organizations that need to manage large codebases in many languages in a uniform way. Basically Google-circa-2010-sized organizations, coincidentally!
For smaller teams, adopting Bazel too early can be a real productivity drain, where you get all of the downsides of its constraints without as many of its benefits. Bazel is overkill for a project of ~10 Go apps, for example. Ko was actually created to help such a project (Knative) migrate off of Bazel's rules_docker to something better, and I think it achieved the goal!
I don't think building something like `ko` with it should be that much work. (I know, famous last words)
I'll have to check with $employer if it's ok to open source it.
Ko sound like a great idea but I have little interest in running go services!
How do you all stay tune of the great apps out there?
If that's not enough or not desirable I completely understand, there's probably something we could do to improve it.
If you want to get rid of your Dockerfiles anyway, nix can also build docker images[1] with all the added benefits of nix (reproducibility, efficient building and caching, automatic layering, etc.).
[0] https://buildah.io/ [1] https://nixos.org/manual/nixpkgs/stable/#ssec-pkgs-dockerToo...
Docker is a much bigger dependency than ko, involving a daemon and a socket you have to manage and secure. ko is a only a go program, and builds are straight-forward and lightning fast compared to Docker.
Importantly, ko also removes the need for a Dockerfile. Yes, as you point out a Dockerfile can be simple, but but the best part is no part. Dockerfile has plenty of foot guns and best practices to learn so if at the end of the day all you need is a go binary on a container ko will serve you much, much better.
Not having to run a Docker daemon is just a nice bonus! :)
The already established good alternative to Docker desktop is Rancher Desktop[1].
Similar tools are Google's Jib for JVM based applications, `rules_docker` and `rules_oci` for Bazel etc.
All of which allow you to build applications without needing a Docker runtime at all during the build process which is a huge plus for portability, performance and repeatability.
Given that SUSE uses Podman, I hope they'll modify Rancher Desktop to use Podman, in which case it'd supersede Podman Desktop.
To solve the issue fully you need a more comprehensive approach to packaging. nix or guix can provide that.
Containers are more useful as a software distribution mechanism.
If you mean containers as in the isolation features that are utilised by docker et al. to provide their flavor of compartmentalization then yes, those are pretty useful for reproducibility (although not 100% necessary, I think).
If you mean containers as in a bundled linux userland (so, e.g. a docker container running some image) then no, that is entirely orthogonal to reproducibility, as demonstrated by nix and guix which AFAIK use the low-level isolation features for their build sanboxes but do not have anything resembling a container image involved.