Building Containers Without Docker | Hacker News Reader

Building Containers Without Docker

blog.alexellis.io

115 pointskiyanwang23 comments

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

`ko publish` does a `go build` and stuffs it in a base image, it even supports multi-arch images with `--platform=all`.

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

Because thats how people use go applications in docker swarm, K8s etc??

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.

because you might want to deliver it in its "nest", i.e., a filesystem with resources the go binary wants to access at runtime

On proper desktop OS those resources are embedded in the binary.

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.

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.

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.

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.

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

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.

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 ;)

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.

For Java you can use jib from google

https://github.com/GoogleContainerTools/jib

Here's a related blog post that does a nice job of showing how dependencies and resources should be put in different layers.

https://phauer.com/2019/no-fat-jar-in-docker-image/

This is pretty interesting, thanks for sharing. I wonder if there's something similar in the Node.js ecosystem

EDIT: I guess the same happens if the package.json/lock file doesn't change.

I don't know of anything that does it automatically. I think there's a lot of room for improvement in image building. No one seems to care about how bad it is currently though.

And for .NET, tye.

https://github.com/dotnet/tye

systemd also has container support baked it. It's actually as simple as 'pacstrap/debootstrap' followed by 'machinectl start'.

systemd is literally a container runtime with a dependency system baked in. Anything you can do with nspawn you can do with normal service units from what I can tell.

I like umoci for image manipulation.

https://github.com/opencontainers/umoci

It is also possible to build docker images with Bazel and rules_docker [1], which doesn't require docker itself, and can run unprivileged. That said, it is not compatible with Dockerfile (obviously) but you can do some cool things such as compose layers individually into a final image.

1. https://github.com/bazelbuild/rules_docker

Reply on news.ycombinator.com