31–40 of 41 posts
I love `ko`. I wish there was something similar for rust but I haven't found it quite yet
I love `ko`. I wish there was something similar for rust but I haven't found it quite yet
Bazel has this functionality. https://github.com/bazelbuild/rules_docker#rust_image
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 am building an app right now and looked into this. Unfortunately the support for including static assets is limited for my case.
I love `ko`. I wish there was something similar for rust but I haven't found it quite yet
I have a very opinionated library that builds Docker images in pure Rust. 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!
I'll be honest, I just don't think this is a great way to do development in any language: `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 th…
I do agree with you in general. However, while containers were being invented to solve this problem, Go was also solving this problem. 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…
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.
Earlier quoted context omitted.
I do agree with you in general. However, while containers were being invented to solve this problem, Go was also solving this problem. 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…
See now that right there is the issue. _IF_ your developer team and CI environment are all using a similar recent Go. Maybe you can keep this going with a single application and a small team that is actively maintaining that application, but even then I've run into issues with people using different computer with different architectures. Just this past week I had to solve a problem with a Go repo that wasn't building…
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.
I have used something like this in the past: 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( Simple. But i c…
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.
Earlier quoted context omitted.
See now that right there is the issue. _IF_ your developer team and CI environment are all using a similar recent Go. Maybe you can keep this going with a single application and a small team that is actively maintaining that application, but even then I've run into issues with people using different computer with different architectures. Just this past week I had to solve a problem with a Go repo that wasn't building…
I agree with this being an issue, although certainly less pronounced with go compared to other languages. I don't think containers solve the issue though: none of the mainstream approaches to building containers actually make the builds (and by extension images) inherently reproducible. It just shifts the issue from differing host systems to differing base layers (granted, the issue is less pronounced with those). As…
Earlier quoted context omitted.
I agree with this being an issue, although certainly less pronounced with go compared to other languages. I don't think containers solve the issue though: none of the mainstream approaches to building containers actually make the builds (and by extension images) inherently reproducible. It just shifts the issue from differing host systems to differing base layers (granted, the issue is less pronounced with those). As…
I would say that containers are the foundation of the practice of reproducible builds. They don't solve the problem on their own, but containerization is a core element of the best practice of reproducible builds, along with utilization of lockfiles and infrastructure as configuration. It's certainly a hell of a lot easier to get a containerized application to a reproducible state than one run on a local machine with…
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.
I'll be honest, I just don't think this is a great way to do development in any language: `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 th…
I do agree with you in general. However, while containers were being invented to solve this problem, Go was also solving this problem. 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…