[HN Gopher] Crun: Fully featured OCI runtime and C library for r...
___________________________________________________________________
Crun: Fully featured OCI runtime and C library for running
containers
Author : harporoeder
Score : 123 points
Date : 2021-01-31 07:49 UTC (15 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| pm90 wrote:
| 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 wrote:
| 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
| SideburnsOfDoom wrote:
| Henry Crun?
|
| https://en.wikipedia.org/wiki/Henry_Crun_and_Minnie_Banniste...
| jchw wrote:
| 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.
| tybit wrote:
| Another Rust option is Firecracker, it manages micro VM but can
| be used for Docker, ala Fargate and
| https://github.com/weaveworks/ignite
| champtar wrote:
| 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
| jjnoakes wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| pjmlp wrote:
| 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.
| rwmj wrote:
| 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 wrote:
| Maybe it's a little off topic here, but why would you
| consider Golang a terrible language?
| xyzzy123 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| richardjennings wrote:
| 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 wrote:
| 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 wrote:
| The particular implementation detail I was referring to:
| https://github.com/opencontainers/runc/tree/master/libcon
| tai...
|
| 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 wrote:
| How do you propose to implement bindings to Linux APIs,
| written in C?
| linkdd wrote:
| 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?).
| arp242 wrote:
| 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 wrote:
| > 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.
| carwyn wrote:
| This pattern or close variants or subsets are fairly
| common:
|
| https://github.com/golang-standards/project-layout
| antoinealb wrote:
| 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 wrote:
| 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!
| deathgrips wrote:
| 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 wrote:
| 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 wrote:
| I would assume that whoever wrote "crun" had fat-fingered
| "cron".
| gscrivano wrote:
| 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 wrote:
| FWIW I really liked the name and think it's creative yet
| terse and easy to search.
| girvo wrote:
| I knew exactly what you were going for from nothing but the
| name, so I think you did a great job personally.
| jeswin wrote:
| 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.
| topspin wrote:
| The name is fine. Pay no attention to the bikeshedding.
| tomcam wrote:
| The name is quite descriptive and fits the target audience
| perfectly as far as I'm concerned.
| Der_Einzige wrote:
| I cannot believe that you are being downvoted! This comment
| made me literally laugh out loud!
|
| I thought the naming was bad because OCI is currently
| associated with Oracle cloud - but your critique was far
| better!!!
| detaro wrote:
| How is OCI associated with Oracle cloud?
| Der_Einzige wrote:
| https://www.oracle.com/cloud/
| detaro wrote:
| TIL, I had only heard about OCI in the meaning from the
| submission (which also appears to be older than Oracle's
| use of the label)
| jasonvorhe wrote:
| I don't get it. What do you think of when reading crun? See-
| run? See-unn? Sirrun? Is crun perhaps some kind of slur? It's
| not "semen", right?
| secondcoming wrote:
| krun?
___________________________________________________________________
(page generated 2021-01-31 23:02 UTC)