5 ms·

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

126 points by harporoeder 6y ago

jchw 6y ago
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.
- rwmj 6y ago
  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.
  - Lucasoato 6y ago
    Maybe it's a little off topic here, but why would you consider Golang a terrible language?
    - xyzzy123 6y ago
      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.
      - pjmlp 6y ago
        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).
        xyzzy123 6y ago
        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.
        nine_k 6y ago
        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.
        fomine3 6y ago
        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.
    - linkdd 6y ago
      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?).
      - antoinealb 6y ago
        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.
        linkdd 6y ago
        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!
      - arp242 6y ago
        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.
        linkdd 6y ago
        > 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 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.
    - richardjennings 6y ago
      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!?
      - pjmlp 6y ago
        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.
        richardjennings 6y ago
        The particular implementation detail I was referring to: https://github.com/opencontainers/runc/tree/master/libcontainer/nsenter 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.
        pjmlp 6y ago
        How do you propose to implement bindings to Linux APIs, written in C?
        richardjennings 6y ago
        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.
        pjmlp 6y ago
        Fair enough, I forgot about that one.
- tybit 6y ago
  Another Rust option is Firecracker, it manages micro VM but can be used for Docker, ala Fargate and https://github.com/weaveworks/ignite https://github.com/weaveworks/ignite
- pjmlp 6y ago
  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.
- champtar 6y ago
  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 https://github.com/containers/crun/pull/173
  - jjnoakes 6y ago
    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.
    - champtar 6y ago
      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.
      - jjnoakes 6y ago
        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.
- dahfizz 6y ago
  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.
  - jchw 6y ago
    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.
deathgrips 6y ago
Every day I wake up full of hope thinking, "coders couldn't possibly come up with a project name any worse than what I've already seen." Today I was yet again disappointed. Is there a wikipedia article about this? The phenomena where coders come up with the worst names ever? I actually parodied it by naming my compiler C-, alternatively written as cmin, and pronounced "semen". I challenge my fellow coders to come up with a worse sounding project name.
- jchw 6y ago
  I would assume Crun is straightforwardly "Container run" with a slight bit of play on Runc (which presumably means "Run container") to emphasize that it is instead, written in C. Given that this is an internal program name and not a product name, and that it is actually a pretty descriptive name terseness aside, I really don't see how it is so bad. Even many advanced users may never see this project name, and if they do, it will probably be in the context of being the process that actually runs their containers, in which case it should be pretty obvious.
  - deathgrips 6y ago
    I would assume that whoever wrote "crun" had fat-fingered "cron".
  - gscrivano 6y ago
    I am the author of Crun and the name was chosen to emphasize it is in C, compete with runc and still read like "container run". In retrospect, I could have chosen a better one.
    - pm90 6y ago
      FWIW I really liked the name and think it’s creative yet terse and easy to search.
    - jeswin 6y ago
      The name is quite memorable and the points you made are valid; so please don't change it unless you have a very good reason to.
pm90 6y ago
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).
- gscrivano 6y ago
  crun runs the OCI validations tests on each PR. The tests are maintained here: https://github.com/opencontainers/runtime-tools/tree/master/validation 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
SideburnsOfDoom 6y ago
Henry Crun? https://en.wikipedia.org/wiki/Henry_Crun_and_Minnie_Bannister https://en.wikipedia.org/wiki/Henry_Crun_and_Minnie_Banniste...

126 points by harporoeder 6y ago

jchw 6y ago

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.

rwmj 6y ago
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.
- Lucasoato 6y ago
  Maybe it's a little off topic here, but why would you consider Golang a terrible language?
  - xyzzy123 6y ago
    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.
    - pjmlp 6y ago
      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).
      - xyzzy123 6y ago
        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.
        nine_k 6y ago
        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.
        fomine3 6y ago
        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.
  - linkdd 6y ago
    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?).
    - antoinealb 6y ago
      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.
      - linkdd 6y ago
        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!
    - arp242 6y ago
      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.
      - linkdd 6y ago
        > 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 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.
  - richardjennings 6y ago
    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!?
    - pjmlp 6y ago
      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.
      - richardjennings 6y ago
        The particular implementation detail I was referring to: https://github.com/opencontainers/runc/tree/master/libcontainer/nsenter 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.
        pjmlp 6y ago
        How do you propose to implement bindings to Linux APIs, written in C?
        richardjennings 6y ago
        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.
        pjmlp 6y ago
        Fair enough, I forgot about that one.
tybit 6y ago
Another Rust option is Firecracker, it manages micro VM but can be used for Docker, ala Fargate and https://github.com/weaveworks/ignite https://github.com/weaveworks/ignite
pjmlp 6y ago
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.
champtar 6y ago
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 https://github.com/containers/crun/pull/173
- jjnoakes 6y ago
  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.
  - champtar 6y ago
    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.
    - jjnoakes 6y ago
      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.
dahfizz 6y ago
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.
- jchw 6y ago
  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.

deathgrips 6y ago

Every day I wake up full of hope thinking, "coders couldn't possibly come up with a project name any worse than what I've already seen." Today I was yet again disappointed. Is there a wikipedia article about this? The phenomena where coders come up with the worst names ever? I actually parodied it by naming my compiler C-, alternatively written as cmin, and pronounced "semen". I challenge my fellow coders to come up with a worse sounding project name.

jchw 6y ago
I would assume Crun is straightforwardly "Container run" with a slight bit of play on Runc (which presumably means "Run container") to emphasize that it is instead, written in C. Given that this is an internal program name and not a product name, and that it is actually a pretty descriptive name terseness aside, I really don't see how it is so bad. Even many advanced users may never see this project name, and if they do, it will probably be in the context of being the process that actually runs their containers, in which case it should be pretty obvious.
- deathgrips 6y ago
  I would assume that whoever wrote "crun" had fat-fingered "cron".
- gscrivano 6y ago
  I am the author of Crun and the name was chosen to emphasize it is in C, compete with runc and still read like "container run". In retrospect, I could have chosen a better one.
  - pm90 6y ago
    FWIW I really liked the name and think it’s creative yet terse and easy to search.
  - jeswin 6y ago
    The name is quite memorable and the points you made are valid; so please don't change it unless you have a very good reason to.

pm90 6y ago

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

gscrivano 6y ago
crun runs the OCI validations tests on each PR. The tests are maintained here: https://github.com/opencontainers/runtime-tools/tree/master/validation 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

SideburnsOfDoom 6y ago

Henry Crun? https://en.wikipedia.org/wiki/Henry_Crun_and_Minnie_Bannister https://en.wikipedia.org/wiki/Henry_Crun_and_Minnie_Banniste...