Coder Social home page Coder Social logo

containers / youki Goto Github PK

View Code? Open in Web Editor NEW
5.9K 5.9K 323.0 22.9 MB

A container runtime written in Rust

Home Page: https://containers.github.io/youki/

License: Apache License 2.0

Shell 1.33% Rust 97.59% Ruby 0.43% Dockerfile 0.17% Just 0.45% Gnuplot 0.04%
containers docker kubernetes oci rust

youki's Introduction

youki: A container runtime in Rust

Discord GitHub contributors Github CI codecov

youki is an implementation of the OCI runtime-spec in Rust, similar to runc.
Your ideas are welcome here.

Quick Start

Tip

You can immediately set up your environment with youki on GitHub Codespaces and try it out.

Open in GitHub Codespaces

$ just build
$ docker run --runtime youki hello-world
$ sudo podman run --cgroup-manager=cgroupfs --runtime /workspaces/youki/youki hello-world

User Documentation

About the name

youki is pronounced as /joʊki/ or yoh-key. youki is named after the Japanese word 'youki', which means 'a container'. In Japanese language, youki also means 'cheerful', 'merry', or 'hilarious'.

Motivation

Here is why we are writing a new container runtime in Rust.

  • Rust is one of the best languages to implement the oci-runtime spec. Many very nice container tools are currently written in Go. However, the container runtime requires the use of system calls, which requires a bit of special handling when implemented in Go. This is too tricky (e.g. namespaces(7), fork(2)); with Rust, it's not that tricky. And, unlike in C, Rust provides the benefit of memory safety. While Rust is not yet a major player in the container field, it has the potential to contribute a lot: something this project attempts to exemplify.

  • youki has the potential to be faster and use less memory than runc, and therefore work in environments with tight memory usage requirements. Here is a simple benchmark of a container from creation to deletion.

    Runtime Time (mean ± σ) Range (min … max)
    youki 198.4 ms ± 52.1 ms 97.2 ms … 296.1 ms
    runc 352.3 ms ± 53.3 ms 248.3 ms … 772.2 ms
    crun 153.5 ms ± 21.6 ms 80.9 ms … 196.6 ms
    Details about the benchmark
    • A command used for the benchmark

      hyperfine --prepare 'sudo sync; echo 3 | sudo tee /proc/sys/vm/drop_caches' --warmup 10 --min-runs 100 'sudo ./youki create -b tutorial a && sudo ./youki start a && sudo ./youki delete -f a'
    • Environment

      $ ./youki info
      Version           0.0.1
      Kernel-Release    5.11.0-41-generic
      Kernel-Version    #45-Ubuntu SMP Fri Nov 5 11:37:01 UTC 2021
      Architecture      x86_64
      Operating System  Ubuntu 21.04
      Cores             12
      Total Memory      32025
      Cgroup setup      hybrid
      Cgroup mounts
        blkio           /sys/fs/cgroup/blkio
        cpu             /sys/fs/cgroup/cpu,cpuacct
        cpuacct         /sys/fs/cgroup/cpu,cpuacct
        cpuset          /sys/fs/cgroup/cpuset
        devices         /sys/fs/cgroup/devices
        freezer         /sys/fs/cgroup/freezer
        hugetlb         /sys/fs/cgroup/hugetlb
        memory          /sys/fs/cgroup/memory
        net_cls         /sys/fs/cgroup/net_cls,net_prio
        net_prio        /sys/fs/cgroup/net_cls,net_prio
        perf_event      /sys/fs/cgroup/perf_event
        pids            /sys/fs/cgroup/pids
        unified         /sys/fs/cgroup/unified
      CGroup v2 controllers
        cpu             detached
        cpuset          detached
        hugetlb         detached
        io              detached
        memory          detached
        pids            detached
        device          attached
      Namespaces        enabled
        mount           enabled
        uts             enabled
        ipc             enabled
        user            enabled
        pid             enabled
        network         enabled
        cgroup          enabled
      $ ./youki --version
      youki version 0.0.1
      commit: 0.0.1-0-0be33bf
      $ runc -v
      runc version 1.0.0-rc93
      commit: 12644e614e25b05da6fd08a38ffa0cfe1903fdec
      spec: 1.0.2-dev
      go: go1.13.15
      libseccomp: 2.5.1
      $ crun --version
      crun version 0.19.1.45-4cc7
      commit: 4cc7fa1124cce75dc26e12186d9cbeabded2b710
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  • I have fun implementing this. In fact, this may be the most important.

Related project

Status of youki

youki is not at the practical stage yet. However, it is getting closer to practical use, running with docker and passing all the default tests provided by opencontainers/runtime-tools. youki demo

Feature Description State
Containerd Running via Containerd
Docker Running via Docker
Podman Running via Podman
pivot_root Change the root directory
Mounts Mount files and directories to container
Namespaces Isolation of various resources
Capabilities Limiting root privileges
Cgroups v1 Resource limitations, etc
Cgroups v2 Improved version of v1 Support is complete except for devices. WIP on #230
Systemd cgroup driver Setting up a cgroup using systemd
Seccomp Filtering system calls
Hooks Add custom processing during container creation
Rootless Running a container without root privileges
OCI Compliance Compliance with OCI Runtime Spec ✅ 50 out of 50 test cases passing
CRIU Integration Functionality to checkpoint/restore containers Initial checkpoint support as described in #641

Design and implementation of youki

The User and Developer Documentation for youki is hosted at https://containers.github.io/youki/

Architecture

Getting Started

Local build is only supported on Linux. For other platforms, please use the Vagrantfile that we have prepared. You can also spin up a fully preconfigured development environment in the cloud with GitHub Codespaces.

Requires

  • Rust(See here), edition 2021
  • linux kernel ≥ 5.3

Dependencies

To install just, follow the instruction here.

Debian, Ubuntu and related distributions

$ sudo apt-get install    \
      pkg-config          \
      libsystemd-dev      \
      build-essential     \
      libelf-dev          \
      libseccomp-dev      \
      libclang-dev        \
      glibc-static        \
      libssl-dev

Fedora, CentOS, RHEL and related distributions

$ sudo dnf install          \
      pkg-config            \
      systemd-devel         \
      elfutils-libelf-devel \
      libseccomp-devel      \
      clang-devel           \
      openssl-devel

Build

git clone [email protected]:containers/youki.git
cd youki
just youki-dev # or youki-release
./youki -h # you can get information about youki command

Tutorial

Requires

Create and run a container

Let's try to run a container that executes sleep 30 with youki. This tutorial may need root permission.

git clone [email protected]:containers/youki.git
cd youki
just youki-dev # or youki-release

mkdir -p tutorial/rootfs
cd tutorial
# use docker to export busybox into the rootfs directory
docker export $(docker create busybox) | tar -C rootfs -xvf -

Then, we need to prepare a configuration file. This file contains metadata and specs for a container, such as the process to run, environment variables to inject, sandboxing features to use, etc.

../youki spec  # will generate a spec file named config.json

We can edit the config.json to add customized behaviors for container. Here, we modify the process field to run sleep 30.

  "process": {
    ...
    "args": [
      "sleep", "30"
    ],

  ...
  }

Then we can explore the lifecycle of a container:

cd ..                                                # go back to the repository root
sudo ./youki create -b tutorial tutorial_container   # create a container with name `tutorial_container`
sudo ./youki state tutorial_container                # you can see the state the container is `created`
sudo ./youki start tutorial_container                # start the container
sudo ./youki list                                    # will show the list of containers, the container is `running`
sudo ./youki delete tutorial_container               # delete the container

Change the command to be executed in config.json and try something other than sleep 30.

Rootless container

youki provides the ability to run containers as non-root user(rootless mode). To run a container in rootless mode, we need to add some extra options in config.json, other steps are same with above:

$ mkdir -p tutorial/rootfs
$ cd tutorial
# use docker to export busybox into the rootfs directory
$ docker export $(docker create busybox) | tar -C rootfs -xvf -

$ ../youki spec --rootless          # will generate a spec file named config.json with rootless mode
## Modify the `args` field as you like

$ ../youki run rootless-container   # will create and run a container with rootless mode

Usage

Start the docker daemon.

dockerd --experimental --add-runtime="youki=$(pwd)/youki"

If you get an error like the below, that means your normal Docker daemon is running, and it needs to be stopped. Do that with your init system (i.e., with systemd, run systemctl stop docker, as root if necessary).

failed to start daemon: pid file found, ensure docker is not running or delete /var/run/docker.pid

Now repeat the command, which should start the docker daemon.

You can use youki in a different terminal to start the container.

docker run -it --rm --runtime youki busybox

Afterwards, you can close the docker daemon process in other the other terminal. To restart normal docker daemon (if you had stopped it before), run:

systemctl start docker # might need root permission

Integration Tests

Go and node-tap are required to run integration tests. See the opencontainers/runtime-tools README for details.

git submodule update --init --recursive
just test-oci

Setting up Vagrant

You can try youki on platforms other than Linux by using the Vagrantfile we have prepared. We have prepared two environments for vagrant, namely rootless mode and rootful mode

git clone [email protected]:containers/youki.git
cd youki

# If you want to develop in rootless mode, and this is the default mode
vagrant up
vagrant ssh

# or if you want to develop in rootful mode
VAGRANT_VAGRANTFILE=Vagrantfile.root vagrant up
VAGRANT_VAGRANTFILE=Vagrantfile.root vagrant ssh

# in virtual machine
cd youki
just youki-dev # or youki-release

Community

We also have an active Discord if you'd like to come and chat with us.

Contribution

This project welcomes your PR and issues. For example, refactoring, adding features, correcting English, etc. If you need any help, you can contact me on Twitter.

Thanks to all the people who already contributed!

youki's People

Contributors

128f avatar adrianreber avatar anti-entropy123 avatar apepkuss avatar chenyukang avatar dependabot[bot] avatar dgibson avatar em- avatar furisto avatar github-actions[bot] avatar guni1192 avatar higuruchi avatar ipuustin avatar jprendes avatar knight42 avatar lengrongfu avatar mostlyamiable avatar nimrodshn avatar niwatoliver avatar peteryordanov avatar saschagrunert avatar silcet avatar szymongib avatar tommady avatar tsturzl avatar udzura avatar utam0k avatar xiaoyang-sde avatar yihuaf avatar yjdoc2 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

youki's Issues

Support for systemd cgroup driver

I'm considering supporting podman, but I don't know the details of podman, so I'm looking for opinions.
I don't know what features youki lacks to support podman yet.
I'm also looking for people to support this issue.

impl: exec sub command

The exec command is not listed in the runtime-spec, but I consider it one of the required features. For example, when I run docker exec -it [container id] bash, I currently get the following error.

Screenshot from 2021-05-22 19-39-11

Using clone(2) to create the init container process segfault when build with release version of the youki binary

When building the released version of youki binary, the clone(2) used to create the container process will fail with the following error from dmesg:

[176643.245728] youki[340675]: segfault at 529 ip 00005581f9b434a0 sp 00007fff14905090 error 4 in youki[5581f9a20000+157000]
[176643.245741] Code: 00 00 ff d5 4c 89 bc 24 00 1c 00 00 48 89 9c 24 08 1c 00 00 4c 89 b4 24 10 1c 00 00 48 8b 84 24 18 03 00 00 48 8b 00 48 8b 00 <4c> 8b b8 28 05 00 00 48 8b 98 38 05 00 00 41 be 01 00 00 00 bd 01

Preliminary investigation points to the child stack pointer passed to clone(2) call. The debug version of the binary is not affected. Changing the allocated child stack size to 1MB or 2MB seems to make the issue go away, but I'd like a proper fix. Using this issue to track.

Does youki require Huge TLB Pages ( hugetlb ) support ?

I've built youki from here : -

apt-get install -y pkg-config

apt-get install -y libsystemd-dev

apt-get install -y libdbus-glib-1-dev

cargo install cargo-when

git clone [email protected]:containers/youki.git

cd youki

./build.sh

resulting in: -

file youki

youki: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=885bc1c85a5d7739537de235aadeabc94294ced5, for GNU/Linux 3.2.0, with debug_info, not stripped

./youki --version

youki 1.0

I'm then packaging the binary into a Fedora 30 VM that forms the so-called pod sandbox component of Kata Containers so that I can run youki inside the pod sandbox ( aka guest VM ) rather than on the box that hosts the Kubernetes 1.21 Compute Node.

I'm also using two other tools - skopeo to pull images from public registries and copy them to the local file-system and umoci to unpack the pulled image and make it available as a bundle.

From a console on this VM, I pull an image using skopeo: -

skopeo copy docker://registry.fedoraproject.org/fedora:latest oci://tmp/fedora:latest

and unpack it to a bundle using umoci : -

umoci.amd64 unpack --image /tmp/fedora:latest /tmp/fedora_bundle

and then attempt to create a container using youki : -

youki create davehay --bundle /tmp/fedora_bundle

This fails with: -

Error: could not find mountpoint for hugetlb

I ran youki info

Version           0.0.1
Kernel-Release    5.10.25
Kernel-Version    #1 SMP Fri Jun 11 20:36:25 UTC 2021
Architecture      x86_64
Operating System  Fedora 30 (Thirty)
Cores             1
Total Memory      1995
cgroup version    v1 and v2
cgroup mounts
  blkio           /sys/fs/cgroup/blkio
  cpu             /sys/fs/cgroup/cpu,cpuacct
  cpuacct         /sys/fs/cgroup/cpu,cpuacct
  cpuset          /sys/fs/cgroup/cpuset
  devices         /sys/fs/cgroup/devices
  freezer         /sys/fs/cgroup/freezer
  memory          /sys/fs/cgroup/memory
  net_cls         /sys/fs/cgroup/net_cls,net_prio
  net_prio        /sys/fs/cgroup/net_cls,net_prio
  pids            /sys/fs/cgroup/pids
  unified         /sys/fs/cgroup/unified

To the best of my knowledge, I don't have / want Huge TLB Pages enabled and, to the best of my knowledge, my environment, with Kata Containers 2.1.0-rc0 is using cgroups V1 as per this

In case it helps, here are the mount points inside the guest VM: -

mount

/dev/pmem0p1 on / type ext4 (ro,relatime,errors=remount-ro,data=ordered,dax=always)
devtmpfs on /dev type devtmpfs (rw,relatime,size=1019924k,nr_inodes=254981,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
nsfs on /run/sandbox-ns/ipc type nsfs (rw)
nsfs on /run/sandbox-ns/uts type nsfs (rw)
kataShared on /run/kata-containers/shared/containers type virtiofs (rw,relatime)
shm on /run/kata-containers/sandbox/shm type tmpfs (rw,relatime)
tmpfs on /etc/resolv.conf type tmpfs (rw,nosuid,nodev,mode=755)
kataShared on /run/kata-containers/1cd920f8ab4c440bed57e6c87c262fff09ca34c94f51d69fcb38f47eb6b97a7d/rootfs type virtiofs (rw,relatime)
kataShared on /run/kata-containers/27718022df79a99c1839534eb8f761231a7a04311c3d3a5955ac9bd2548a9798/rootfs type virtiofs (rw,relatime)

which does include: -

hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)

and here are the cgroups : -

ls -al /sys/fs/cgroup/

total 0
drwxr-xr-x 13 root root 340 Jun 24 10:37 .
drwxr-xr-x  8 root root   0 Jun 24 10:37 ..
dr-xr-xr-x  3 root root   0 Jun 24 10:37 blkio
lrwxrwxrwx  1 root root  11 Jun 24 10:37 cpu -> cpu,cpuacct
dr-xr-xr-x  3 root root   0 Jun 24 10:37 cpu,cpuacct
lrwxrwxrwx  1 root root  11 Jun 24 10:37 cpuacct -> cpu,cpuacct
dr-xr-xr-x  3 root root   0 Jun 24 10:37 cpuset
dr-xr-xr-x  4 root root   0 Jun 24 10:37 devices
dr-xr-xr-x  3 root root   0 Jun 24 10:37 freezer
dr-xr-xr-x  4 root root   0 Jun 24 10:37 memory
lrwxrwxrwx  1 root root  16 Jun 24 10:37 net_cls -> net_cls,net_prio
dr-xr-xr-x  3 root root   0 Jun 24 10:37 net_cls,net_prio
lrwxrwxrwx  1 root root  16 Jun 24 10:37 net_prio -> net_cls,net_prio
dr-xr-xr-x  3 root root   0 Jun 24 10:37 perf_event
dr-xr-xr-x  4 root root   0 Jun 24 10:37 pids
dr-xr-xr-x  5 root root   0 Jun 24 10:37 systemd
dr-xr-xr-x  4 root root   0 Jun 24 10:37 unified

Appreciating that this is a very non-standard configuration, but all advice gratefully received and appreciated 👍

spec.root.path is not correctly handled

Currently, the spec.root.fs is not correctly handled. When init_builder calls load_and_safeguard_spec, the copied version of the spec.json doesn't contain the change to canonicalize the rootfs path. As a result, when youki exec tries to load the safeguarded spec in tenent_builder, the spec.root.path can be incorrect missing the bundle path. As a result, currently, youki exec is also broken.

There are two solutions. One is to save the canonicalized rootfs path with bundle path as part of the spec when safeguard the spec into the /run/youki/<id>. The other option is to take care to canonicalize the path with bundle path again when loading the path in tenent_builder.

Support checkpoint and restore

Checkpoint and restore is supported by runc. We should also support these operations. There does not seem to be a crate that allows interacting with criu, so we probably have to write it ourselves. The go implementation would be a good starting point. If anyone has more information on this topic it would be appreciated.

Implement list command

It would be nice to have an overview of all the containers created by youki and their current state.

More comments and docs

Now, This project has too few comments and documentation.
I would like to improve the development experience by improving them.

Refactor Cond.rs

As discussed in #14 , we can rename cond to pipe as it is more understandable. If you won't mind, I would like to refactor it and its occurrences. Reason to open new issue is that it is more than just documentation, so didn't want to add it in #14. you're fine with it, assign me this issue.
Another good reason to do this, as the module comment for it indicates it is a

conditional variable performing busy waiting on lock

but it is actually related to unix pipes, and the name can cause more confusion later on.

Make failure message great again

Right now if we had a test failed when run cargo test, the failure message is missing and we can not locate the assert that failed directly.

And if comment the tests code in tty.rs, the failure message show up again. Just like the failure message is eaten by the tty.

Failure test without commenting tests in tty.rs.
image

Failure test with commenting tests in tty.rs.
image

It would be a little annoying for debugging when CI failed. So maybe we should find a way to make failure message come back.

cc @utam0k

Multisystem testing

The integration tests can pass or fail depending on the system it's actually running on, one example of this is the network cgroups. On some systems the network cgroups mount into 2 different directories "net_prio" and "net_cls", on others they mount into one directory "net_cls,net_prio" or "net_prio,net_cls". This means that on some systems integration tests will pass, and others they will fail and Youki will not run properly. I believe this is specific to how distributions are setup. So it might be worth while to setup some kind of testing in 3-4 of the most popular distributions. These tests would be setup locally only, since our current CI cannot handle it at the moment.

My thoughts on which systems to test is:

  • Redhat/Fedora
  • Ubuntu LTS
  • Latest stable Debian
  • Alpine Linux, this is a good candidate to also test a system that doesn't use systemd

This test tooling will likely use a VM, something like vagrant might be most useful here. I don't believe testing container runtimes in a container will work all that well. Another choice might be something like Amazon's Firecracker.

In addition to providing multiple test environments this could also allow Windows and Mac users to more easily test changes.

Investigate sporadic CI failures

The CI fails sporadically during the kill command test when calling the start command with " could not be started because it was Stopped". I have not yet been able to reproduce this behavior locally.

This is the output of youki (with additional traces) when running the test successfully.

[INFO src/state.rs:16] 2021-07-08T12:12:31.874083870+02:00 CALLED STATE
[INFO src/delete.rs:26] 2021-07-08T12:12:31.876735623+02:00 CALLED DELETE
[INFO src/create.rs:34] 2021-07-08T12:12:31.880261860+02:00 CALLED CREATE
[INFO src/cgroups/common.rs:155] 2021-07-08T12:12:31.891048269+02:00 cgroup manager V1 will be used
[WARN src/capabilities.rs:27] 2021-07-08T12:12:31.916619716+02:00 CAP_CHECKPOINT_RESTORE doesn't support.
[WARN src/capabilities.rs:27] 2021-07-08T12:12:31.916699714+02:00 CAP_PERFMON doesn't support.
[WARN src/capabilities.rs:27] 2021-07-08T12:12:31.916721314+02:00 CAP_BPF doesn't support.
[INFO src/state.rs:16] 2021-07-08T12:12:31.984294516+02:00 CALLED STATE
[INFO src/kill.rs:20] 2021-07-08T12:12:31.994463136+02:00 CALLED KILL
[INFO src/state.rs:16] 2021-07-08T12:12:32.003495876+02:00 CALLED STATE
[INFO src/delete.rs:26] 2021-07-08T12:12:32.007922697+02:00 CALLED DELETE
[INFO src/cgroups/common.rs:155] 2021-07-08T12:12:32.020250779+02:00 cgroup manager V1 will be used
[INFO src/state.rs:16] 2021-07-08T12:12:32.051025233+02:00 CALLED STATE
[INFO src/create.rs:34] 2021-07-08T12:12:32.054227576+02:00 CALLED CREATE
[INFO src/cgroups/common.rs:155] 2021-07-08T12:12:32.063796607+02:00 cgroup manager V1 will be used
[WARN src/capabilities.rs:27] 2021-07-08T12:12:32.116028281+02:00 CAP_PERFMON doesn't support.
[WARN src/capabilities.rs:27] 2021-07-08T12:12:32.116231877+02:00 CAP_BPF doesn't support.
[WARN src/capabilities.rs:27] 2021-07-08T12:12:32.116306276+02:00 CAP_CHECKPOINT_RESTORE doesn't support.
[INFO src/start.rs:19] 2021-07-08T12:12:32.145331061+02:00 CALLED START
[INFO src/state.rs:16] 2021-07-08T12:12:32.148588804+02:00 CALLED STATE
[INFO src/kill.rs:20] 2021-07-08T12:12:32.151353455+02:00 CALLED KILL
[INFO src/state.rs:16] 2021-07-08T12:12:32.153879310+02:00 CALLED STATE
[INFO src/delete.rs:26] 2021-07-08T12:12:32.156782258+02:00 CALLED DELETE
[INFO src/cgroups/common.rs:155] 2021-07-08T12:12:32.165717500+02:00 cgroup manager V1 will be used
[INFO src/state.rs:16] 2021-07-08T12:12:32.190686057+02:00 CALLED STATE
[INFO src/create.rs:34] 2021-07-08T12:12:32.193853601+02:00 CALLED CREATE
[INFO src/cgroups/common.rs:155] 2021-07-08T12:12:32.203325533+02:00 cgroup manager V1 will be used
[WARN src/capabilities.rs:27] 2021-07-08T12:12:32.251435881+02:00 CAP_BPF doesn't support.
[WARN src/capabilities.rs:27] 2021-07-08T12:12:32.251517179+02:00 CAP_CHECKPOINT_RESTORE doesn't support.
[WARN src/capabilities.rs:27] 2021-07-08T12:12:32.251542679+02:00 CAP_PERFMON doesn't support.
[INFO src/start.rs:19] 2021-07-08T12:12:32.277765314+02:00 CALLED START
[INFO src/state.rs:16] 2021-07-08T12:12:32.280738961+02:00 CALLED STATE
[INFO src/kill.rs:20] 2021-07-08T12:12:32.283505912+02:00 CALLED KILL
[INFO src/state.rs:16] 2021-07-08T12:12:32.286962351+02:00 CALLED STATE
[INFO src/delete.rs:26] 2021-07-08T12:12:32.289950498+02:00 CALLED DELETE
[INFO src/cgroups/common.rs:155] 2021-07-08T12:12:32.299679825+02:00 cgroup manager V1 will be used
[INFO src/state.rs:16] 2021-07-08T12:12:32.347732274+02:00 CALLED STATE

This is where we are checking the state.

pub fn refresh_status(&mut self) -> Result<Self> {
        let new_status = match self.pid() {
            Some(pid) => {
                // Note that Process::new does not spawn a new process
                // but instead creates a new Process structure, and fill
                // it with information about the process with given pid
                if let Ok(proc) = Process::new(pid.as_raw()) {
                    use procfs::process::ProcState;
                    match proc.stat.state().unwrap() {
                        ProcState::Zombie | ProcState::Dead => ContainerStatus::Stopped,
                        _ => match self.status() {
                            ContainerStatus::Creating | ContainerStatus::Created => self.status(),
                            _ => ContainerStatus::Running,
                        },
                    }
                } else {
                    ContainerStatus::Stopped
                }
            }
            None => ContainerStatus::Stopped,
        };
        Ok(self.update_status(new_status))
    }

It appears like the container process doesn't exist anymore. The question is why do we see this behavior only in the kill tests?

impl: original integration test.

Youki is currently using the integration tests from rutime-tools, but there are some areas where this isn't sufficient (e.g. cgv2), so we will implement our own.

logo

The current logo is too confusing.
I'm not very good at drawing, so I'm looking for help.

implementation of run command

ref: https://github.com/opencontainers/runc/blob/master/man/runc-run.8.md

❯ ls
config.json  rootfs
❯ sudo ~/crun run mycontainer
❯ ~/youki run mycontainer
error: Found argument 'run' which wasn't expected, or isn't valid in this context

If you tried to supply `run` as a PATTERN use `-- run`

USAGE:
    youki [FLAGS] [OPTIONS] <SUBCOMMAND>

For more information try --help

Hello, I am very interested in the container runtime, but I don’t have much relevant experience. I noticed that the run command is not implemented.

And I can try to do it if you agree.

Cgroups v2 freezer test randomly fails

While running cargo test on main branch, cgroups v2 freezer test_set_freezer_state seems to fail randomly.
Curiously it seems some kind of race condition makes it fail? Because sometimes when running cargo test, it prints

test cgroups::v2::freezer::tests::test_set_freezer_state ... FAILED

and shows that test has failed, with a message

error: test failed, to rerun pass '--lib'

below result of all running tests,
sometimes it prints

test cgroups::v1::freezer::tests::test_set_freezer_state ... ok

but still stops running unit and doc tests, with error message

error: test failed, to rerun pass '--lib'

and sometimes this test passes, and all test are run and pass.

Another thing I have noted is that order of tests is changes, as in probably cargo runs tests in parallel, which might play a role in this?

The test uses Arc, and the order of tests in cargo test output changes each time, so I feel this might be some issue related to concurrency and race conditions, but could be something else as well.

Extract spec.rs as a crate

The spec.rs that reads the oci-spec specification is a general-purpose code that can be used not only in this project.
Therefore, I would like to extract and provide it as a separate crate from youki in this repository.
Ideally, the youki itself should use the crate.
If anyone is interested in this, I would like to challenge you.

[Tracking Issue] Pass command line interfaces tests

This issue is for tracking PR to pass the command line integration test.
If you are interested, you can comment on this issue and I will assign it to you. This issue is for tracking PR to pass the command line integration test. Some of them may already pass the tests.

Goal

Each of them will be targeted to pass integration tests. If possible, it is good to have unit tests as well.
It would be helpful to have a look at the GitHub Actions file to see how to run the integration tests.

[Tracking Issue] Support for cgroups v2

This issue is for tracking the implementation of cgroups v2.
Since cpu and cpuset of cgoups has already been implemented, you can implement it while referring to it.
If you are interested, you can comment on this issue and I will assign it to you.

Devices are special and will be handled separately from this issue.
#230

Goal

There isn't an integration test for cgv2, so please make sure that the results of the operation and unit tests are successful.

Reference

Add seccomp

Hi, thanks for the project, it's very intresting!
I would like to work on seccomp feature if possible.

[Tracking Issue] Improve the test coverage

The current youki has far too few unit tests.
We are planning to increase the test coverage for the following files.
Perhaps this is a very good opportunity to understand the code and how it works. If you are interested, please comment on the issue and declare the files you want to test.

  • src/spec.rs
  • src/namespaces
  • src/cgrpups/devices.rs(assigned @tsturzl) #75
  • src/cgroups/manage.rs
  • src/create.rs(assigned @TinySong)
  • src/capability.rs (assigned @sensaiankit)
  • src/rootfs.rs(assigned @constreference )
  • src/tty.rs(assigned @constreference ) #102

[Tracking Issue] Support for cgroups v1

This issue is for tracking the implementation of cgroups.
Since devices of cgoups has already been implemented, you can implement it while referring to it.
If you are interested, you can comment on this issue and I will assign it to you.

Goal

Each of them will be targeted to pass integration tests. If possible, it is good to have unit tests as well.
It would be helpful to have a look at the GitHub Actions file to see how to run the integration tests.

Reference

CNCF TAG-Runtime Discussion/Presentation?

Hello youki team,

I'm one of the co-chairs of the CNCF SIG-Runtime, I'm reaching out and think it would be great for you to present/discuss the project at one of our meetings. An overview of the project would be great.

Let me know if this something you'd be interested in doing. If yes, please feel free to add it to our agenda or reach out to me (raravena80 at gmail.com)

Thanks!

Sharing types with containrs

Hey folks, I think I do not have to mention that this is an interesting project. Great work so far! 👏

I'd like to point to our other side-project containrs, which targets to implement a higher level runtime like containerd and CRI-O: https://github.com/cri-o/containrs

Do you think it would make sense to share some types, for example integrating them into youki and then re-using later on in our project? I see some overlaps, for example:

Asynchronous cgroup controller configuration

We should be able to concurrently configure each of the cgroup subsystems to hopefully see some performance improvements. One thing to note is write order within a controller is important to keep track of since values can be validated against each other by the kernel. Initially it may be best to write configs in each controller in series and have each controller be executing concurrently with the next, and eventually move into more granular concurrency.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.