Hacker News new | past | comments | ask | show | jobs | submit login

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(<=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.




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.


In my experience, not using docker to build docker images is a good idea. E.g. buildah[0] with chroot isolation can build images in a GitLab pipeline, where docker would fail. It can still use the same Dockerfile though.

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...


> 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 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.


That works, but it also means maintaining a Dockerfile that does the COPYs, when all you're really doing is assembling image layers. This is more or less exactly what ko does, without using the Dockerfile language to describe it.

Not having to run a Docker daemon is just a nice bonus! :)


I thought that go doesn't work in Alpine because of shared libs?


Build with `CGO_ENABLED=0`, perhaps?


> i can see ko being good alternative if you for some reason do not want to install docker on your computer

The already established good alternative to Docker desktop is Rancher Desktop[1].

[1] https://rancherdesktop.io/


This is not talking so much about the Docker GUI things but rather this doesn't require a Docker daemon at all.

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.




From my experience, podman desktop is pretty good at containers, but horrible for Kubernetes (it uses KIND but you can't configure basic things, like exposing NodePort IIRC).

Given that SUSE uses Podman, I hope they'll modify Rancher Desktop to use Podman, in which case it'd supersede Podman Desktop.


Sadly, Rancher Desktop still uses Docker, right?




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: