containers / containrs

General purpose container library

containrs - General purpose container library

This repository is a hacking space for a new general purpose container library written in Rust.

containrs's Issues

Unable to connect to 'criserver' using 'crictl'

1. I am able to build the project successfully after running cargo build with latest stable rust (rustc - v1.47.0)

2. Then I run

$ ./target/debug/criserver -l trace
[2020-10-30T08:02:18.484Z TRACE cri::storage::default_key_value_storage src/storage/default_key_value_storage.rs:22] Opening storage /var/run/user/1000/cri/storage/cri-service
[2020-10-30T08:02:18.605Z DEBUG cri::network::cni src/network/cni/mod.rs:126] Configuration paths: /etc/cni/net.d
[2020-10-30T08:02:18.605Z DEBUG cri::network::cni src/network/cni/mod.rs:135] Plugin paths: <some-bin-paths>
[2020-10-30T08:02:18.605Z INFO  cri::network::cni src/network/cni/mod.rs:139] Initializing CNI network
[2020-10-30T08:02:18.605Z INFO  cri::network::cni src/network/cni/mod.rs:141] No default CNI network name, choosing first one
[2020-10-30T08:02:18.605Z DEBUG cri::network::cni src/network/cni/mod.rs:264] Got network files: []
[2020-10-30T08:02:18.605Z INFO  cri::network::cni src/network/cni/mod.rs:291] No loaded networks
[2020-10-30T08:02:18.606Z TRACE cri::network::cni src/network/cni/mod.rs:150] Setup CNI storage in /var/run/user/1000/cri/storage/cni
[2020-10-30T08:02:18.606Z TRACE cri::storage::default_key_value_storage src/storage/default_key_value_storage.rs:22] Opening storage /var/run/user/1000/cri/storage/cni
[2020-10-30T08:02:18.608Z INFO  cri::kubernetes::server src/kubernetes/server/mod.rs:65] Runtime server listening on /var/run/user/1000/cri/cri.sock

3. Trying to connect to it using 'crictl' ( version 1.17.0)

$ crictl -D -r "unix:///var/run/user/1000/cri/cri.sock.orig" version
DEBU[0000] VersionRequest: &VersionRequest{Version:v1alpha2,} 
DEBU[0000] VersionResponse: nil                         
FATA[0000] getting the runtime version failed: rpc error: code = Internal desc = stream terminated by RST_STREAM with error code: PROTOCOL_ERROR 

Not sure if I am missing something?

Make unix domain socket work with crictl

Looks like we're facing those issues with the default implementation as well:

• hyperium/tonic#243
• hyperium/h2#442

I was able to connect via grpccurl, which does not have to seem the issue when specifying the socket:

> sudo ./grpcurl -plaintext -unix -protoset cri.protoset cri.sock criapi.RuntimeService.Version

Make RPC interception work

The current log interception does only provide the headers of the request, which does not give us any useful information at all:

https://github.com/cri-o/cri/blob/29f6f7fce7bbc752052d1b70e897b785c02f38c0/src/server.rs#L73-L74

https://github.com/cri-o/cri/blob/29f6f7fce7bbc752052d1b70e897b785c02f38c0/src/server.rs#L101-L107

Target is to make the interception work and print the request as well as the response, probably via a tower wrapper service like this:
https://github.com/hyperium/tonic/blob/master/examples/src/tower/server.rs

Xref: hyperium/tonic#333

Setup cgroups handling

The details of the implementation have to be defined.

containers storage implementation

we should stub out the container storage, possibly using the containers-storage binary in github.com/containers/storage, to allow forward progress on creating actual containers. The methods can match the api listed here for now

Add seccomp support

We basically have to unmarshal the seccomp profile path from the CRI and put it in the container runtime spec. We also have to provide the default profile runtime/default.

Add basic CI

We can run basic CI checks, like running:

• cargo clippy
• cargo fmt and check the diff
• cargo test

We could either utilize GitHub actions, CircleCI or prow. Which one would you prefer?

fix the repository name `containrs` -> `containers`

Is it typo?

Split project in first lib and binary

The lib should not expose any public type (for now). This way we can decide when and how to provide and API.

Decide on a name

cri was just a place holder, because naming things is hard. cri doesn't really uniquely identify this project (cri implementation in rust).

A couple of ideas floated around so far:

• Crustacean puns:

  • https://en.wikipedia.org/wiki/Krill
    • crill
  • https://en.wikipedia.org/wiki/Amphipoda
    • This is the phyllum of crustaceans (and has pods in the name)

• Rust pun

  • Crrust (container runtime-rust)?

• Container pun

  • Casket

• Oxidation pun

  • Ctrized (like container-dized)
  • Containerized

• Runc pun

  • rustc

bringing this up in an issue for discussion. I personally am leaning towards crrust (easy to say, clear about what it is)

Add help for using rust nightly

The default toolchain on a developer machine many be different from the nightly (eg. on my machine it's stable)

$ rustup toolchain list
stable-x86_64-unknown-linux-gnu (default)
nightly-x86_64-unknown-linux-gnu

The build fails. It will be a good idea to have some documentation about it.

Add logging facade

There are multiple good logging mechanisms available in Rust. I’d say we could stick to env_logger for now.

Switch to oci-spec-rs

We should switch to the oci-spec crate rather than having our own implementation of the runtime spec.

Implement Pod creation

The pod run functionality would be the first thing to implement as well as necessary surrounding infrastructure (like a key/value storage).

Add basic CLI interface

With the clap (from version 3, currently in beta) crate we can directly map cli parameters to configuration structures. This reduces the overhead and avoids unnecessary type conversions.

The first config options could be the log level and the GRPC socket path/server address.

Example: https://github.com/saschagrunert/kubernix/blob/master/src/config.rs

Implement / add container storage

The idea is to support only overlay for now to keep the implementation simple.

Consider OCI runtime plugin mechanism

The idea is not only to support CLI based OCI runtimes but also provide an easy-to-use middle layer (maybe based on C bindings to be mostly language Independent). WDYT?

Support loading/writing and customizing OCI runtime spec

We need to write the code that supports:

• Reading OCI runtime config.json
• Writing OCI runtime config.json
• Converting k8s CRI types to config.json

FATA[0000] getting the runtime version: rpc error: code = Internal desc = stream terminated by RST_STREAM with error code: PROTOCOL_ERROR

Add image pull capability

Add the image pull capability using https://github.com/hyperium/hyper/ client.

Implement Container creation

A container should be attached to a Pod Sandbox as defined by the CRI.

CNI integration

Support CNI plugins for networking

Make grpc server listen to a socket

This should be another good first issue to pick. :)

The server currently listens on an address. I think a socket path would be necessary to run with the kubelet.

Setup unit and integration tests

We should integrate some unit tests (live side by side with the source code) and integration tests (live in ./test) for this project.

Create cargo workspace

I would like to create a cargo workspace for this project and divide up the code into several crates

• common
• container
• ffi
• image
• network
• sandbox
• server
• services
• storage

Implement image spec

runtime spec has already been written by kata, https://github.com/kata-containers/kata-containers/blob/2.0-dev/src/agent/oci/src/lib.rs#L31 (kata agent 2.0) , but there is no image spec yet.

This issue is to track the progress of writing an image spec in rust.