Crun: Fully featured OCI runtime and C library for running containers | Hacker News Reader

Crun: Fully featured OCI runtime and C library for running containers

github.com

126 pointsharporoeder45 comments

In case anyone is wondering if this signals a shift away from Go in container infrastructure, I don't think so. Docker, Kubernetes, Buildah and Podman are mostly Go code and I don't think there's much intent to change that.

I suspect the conclusion (that Go is not ideal for this kind of low level component) is accurate. OTOH, I wish it could be a memory-safe language instead of C. I can only assume there is some decent reason why Rust isn't used here, though personally I wouldn't know.

krunvm is written in Rust, although it's not a simple container runtime -- it starts the container in a VM for isolation.

Personally I'd prefer people didn't use golang not because of speed but because it's a terrible programming language.

Maybe it's a little off topic here, but why would you consider Golang a terrible language?

Go seems to reliably trigger language wars every time it's mentioned.

It's a surprisingly divisive language. Go users seem to mostly be happy cranking stuff out but a lot of people hate it.

No generics, a culture of "if err != nil", type system not powerful enough, libraries not pure enough, too verbose, etc.

Because it basically has a culture of driving to the bottom in language features.

Sure I can code full applications in GW-BASIC or whatever programming language of similar age, and did, almost 40 years ago.

It doesn't mean I enjoy doing them today, beyond some nostalgic weekend hobby.

Then again, assuming that generics proposal doesn't end the same way as the error one, it won't be that bad.

Go will finally feel like using CLU (from 1975).

I think of it as the new PHP.

Early PHP was a terrible language that people nonetheless built a ton of cool things with, for a variety of ergonomic and social reasons that are not that easy to pin down exactly.

One reason is that people with ideas and a drive to implement them are often not experienced developers. They have a product mentality, and see the need to implement things in code as a nuisance that stands between them and their idea. So they pick the easiest, lowest-hanging tool, not the sharpest or cleanest.

I'd like to say it's similar to old day's Java. PHP introduced random features early days but Java and Go doesn't.

Golang is great for small code bases, in a UNIX world where each program do only one thing, this is perfectly fine.

But once the code base grows, it easily becomes a tangled mess.

My biggest con for Go would be the project directory structure. At the toplevel of a project, I like to have only "src", "tests", "docs", "examples" and eventually "containers" if I provide Docker images. With go, it seems that everything should be at the toplevel (or maybe I haven't seen nicely structured projects yet?).

Could this be an issue with Go's built in build system rather than go the language ? At work I use go with Bazel and found it okay with regard to source layout, similar to my experience with c++. I don't have experience with go outside of Bazel though.

When I try to decide if i want to use a language, I look at its ecosystem.

It may have the best features in the world, but if the ecosystem is not there, it will be a pain to use it.

On the opposite, a language can have the worst features and a great ecosystem, for example Python is slow but as great scientific tools, or Javascript has a weird "typing system" but has tons of tools in every domain to make the best of it.

I don't know Bazel though, I'll take a look at it, thanks!

You can store Go files in src/ if you really want, nothing really stopping you, but it's not the usual approach, no. Tests are usually stored next to the actual implementations rather than a tests/ directory.

In which directory to store files is an incredibly small and minor detail though.

> nothing really stopping you, but it's not the usual approach

In my experience, if you open-source a project, it better have to follow conventions. Following conventions makes sure someone else can read your code easily.

> In which directory to store files is an incredibly small and minor detail though.

Yeah it's a small detail, but it is important to me to not get lost in a directory tree.

Random example taken from a github search: https://github.com/gofiber/fiber

Is it really ok to have that much source code at the toplevel? Is the code architecture clear at a glance?

For me, it is not, and I'll have to put in extra work (I'm lazy) to understand the code and how it works.

I don't mind doing that for other projects, but for my projects as I work on them daily, it becomes a pain very quickly.

This pattern or close variants or subsets are fairly common:

https://github.com/golang-standards/project-layout

In the container context, the Go runtime gets in the way of namespace control; 'Docker' as in RunC uses C to work around this (last time I looked) and so is compiled with cgo. I'm not sure that the direct creation/control of a container is possible using just Go. I would love to be out of date and wrong!?

At some level one needs to provide bindings to the underlying OS APIs.

Naturally C doesn't need bindings, when the OS APIs are written in C.

The particular implementation detail I was referring to: https://github.com/opencontainers/runc/tree/master/libcontai...

The distinction I was attempting to make is whether or not C source code is required in your Go project to fully implement a container runtime.

How do you propose to implement bindings to Linux APIs, written in C?

From Go? There is the syscall package.

More generally C is just adding some conventions, like 'calling' that can be interacted with by following the rules from e.g assembly or a higher level language that can compile to compatible calls.

Fair enough, I forgot about that one.

Another Rust option is Firecracker, it manages micro VM but can be used for Docker, ala Fargate and https://github.com/weaveworks/ignite

Despite my usual C bashing, I am fine with using C, provided that the project.

- Uses all the static analysers it can get hold of

- Pursues a policy of zero warnings

- Has fuzzing as part of the CI/CD process

I just opened a ticket requesting clarification.

There is a lot of "logical" errors possible in a container runtime that no language will save you from. See CVE-2019-18837 https://github.com/containers/crun/pull/173

Eliminating memory safety bugs won't prevent other kinds of bugs (of course), but it would still be a net win for security and reliability.

Sure, but we are talking about a single threaded program that is not doing crazy data processing at all. I'm all for Rust but there is a fairly steep learning curve.

I'm not sure I understand. Lots of single threaded programs that don't do crazy data processing have serious security vulnerabilities that memory safety would have prevented.

It's dangerous to treat rust like a panacea. _safe_ rust is memory safe. The problem is that for most nontrivial programs (especially very low level ones), you are forced to use unsafe rust. Just look at how many times the unsafe keyword is used in the rust stdlib.

It’s not treating rust as a panacea, it’s that the ambient level of expectations for software is getting higher. Although C is going to be more ubiquitous than Rust for the foreseeable future, adding new code in memory unsafe languages will eventually require some justification as to why it’s worth the risk. We’re not there yet, but it’s coming.

And yes. Low level code requires unsafety sometimes, or at least code that is not provably safe (digression: save for maybe using actual proofs a la seL4?) The important bit about Rust and other memory safe languages is that in Rust, memory unsafeness can be minimized and accounted for. That’s a whole class of bugs that is traditionally basically unmanageable in most non-trivial projects.

Go is also memory safe by default, but the runtime is too heavy, and thus we’re here.

This is pretty great. Ideally, whoever maintains the OCI specs would have a way of allowing implementations to be “certified compliant” by an open process (maybe a suite of automated tests that the implementation must pass).

crun runs the OCI validations tests on each PR.

The tests are maintained here: https://github.com/opencontainers/runtime-tools/tree/master/...

I guess this is the closest to be "certified compliant", but that is not enough for working with existing container engines as everyone just assumes runc is used

Henry Crun?

https://en.wikipedia.org/wiki/Henry_Crun_and_Minnie_Banniste...

Reply on news.ycombinator.com