21–30 of 41 posts
Dammit, why didn't I know about this? In general, I always have the feeling I'm not aware of great applications out there, and I confirm this sensation every time I find them, like now! How do you all stay tune of the great apps out there?
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…
Dammit, why didn't I know about this? In general, I always have the feeling I'm not aware of great applications out there, and I confirm this sensation every time I find them, like now! How do you all stay tune of the great apps out there?
I am building an app right now and looked into this. Unfortunately the support for including static assets is limited for my case.
If that's not enough or not desirable I completely understand, there's probably something we could do to improve it.
`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.
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…
Or, if you don't want to install it in your CI/CD. Which could be extremely valuable; some CI/CD providers make "building a docker image" a weirdly hard (and sometimes, even much more expensive) step due to docker-in-docker madness.
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...
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…
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.
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…