Git Product home page Git Product logo

nestybox / sysbox-ee Goto Github PK

View Code? Open in Web Editor NEW
47.0 9.0 7.0 12.78 MB

Sysbox Enterprise-Edition repository. The enterprise version of the open-source Sysbox "runc" runtime (empowers rootless containers to run workloads such as Systemd, Docker, Kubernetes, just like VMs).

Shell 100.00%
containers rootless-containers docker kubernetes devops container-runtimes container-runtime-security

sysbox-ee's Introduction

sysbox


Sysbox-EE End-of-Life Announcement (01/2023)

Prior to the acquisition by Docker on 05/2022, Nestybox offered Sysbox Enterprise as an enhanced version of Sysbox (e.g., more security, more workloads, and official support), via a paid license agreement.

After the acquisition however, Sysbox Enterprise will no longer be offered as a standalone product. Instead, Docker plans to port some (TBD) Sysbox-EE features to Sysbox-CE so users can replace the former with the latter.

At this time, no new licenses of Sysbox-EE are sold and no license renewals are offered. This repo will remain open for existing customers as a way to download Sysbox-EE binaries, but will be phased out in mid 2023 (after all existing license agreements expire).


Contents

Introduction

Sysbox Enterprise Edition (Sysbox-EE) is the enterprise version of the open-source Sysbox container runtime, developed by Nestybox (acquired by Docker on 05/2022).

Sysbox-EE uses Sysbox at its core, but adds enterprise-level features such as:

  • Improved container isolation / security

  • Running more types of system-level workloads inside containers

  • Scalability (running more containers per host)

  • Significant performance and efficiency optimizations (for faster container deployment with reduced disk utilization)

  • Lifecycle (higher release cadence, critical bug fixes ASAP)

  • Nestybox professional support with a guaranteed SLA (rather than best effort on Sysbox)

  • Feature prioritization (Sysbox-EE feature requests are prioritized)

Sysbox-EE is a drop-in replacement for Sysbox. It installs and it's used in the exact same way, but includes the additional features listed above. On a given host however, either Sysbox or Sysbox-EE must be installed, never both.

See the next section for a comparison between Sysbox-EE and Sysbox (aka Sysbox Community Edition or Sysbox-CE).

Features

Features are shown below.

sysbox

If you have questions, you can reach us here.

Supported Distros

Sysbox-EE relies on functionality available only in relatively recent Linux kernel releases.

See the distro compatibility doc for information about the supported Linux distributions and the required kernel releases.

We plan to add support for more distros in the near future.

Host Requirements

The Sysbox-EE host must meet the following requirements:

  • It must be running one of the supported Linux distros.

  • We recommend a minimum of 4 CPUs (e.g., 2 cores with 2 hyperthreads) and 4GB of RAM. Though this is not a hard requirement, smaller configurations may slow down Sysbox-EE.

Installation

Sysbox-EE is a drop-in replacement for Sysbox, meaning that it's installed and used in the same way.

For this reason, the documents in the Sysbox repo apply equally to both Sysbox and Sysbox-EE.

Here are the links to the docs showing how to install Sysbox-EE:

Using Sysbox-EE

Once Sysbox-EE is installed, you create a container using your container manager or orchestrator (e.g., Docker or Kubernetes) and an image of your choice.

Docker command example:

$ docker run --runtime=sysbox-runc --rm -it --hostname my_cont registry.nestybox.com/nestybox/ubuntu-bionic-systemd-docker
root@my_cont:/#

Kubernetes pod spec example:

apiVersion: v1
kind: Pod
metadata:
  name: ubu-bio-systemd-docker
  annotations:
    io.kubernetes.cri-o.userns-mode: "auto:size=65536"
spec:
  runtimeClassName: sysbox-runc
  containers:
  - name: ubu-bio-systemd-docker
    image: registry.nestybox.com/nestybox/ubuntu-bionic-systemd-docker
    command: ["/sbin/init"]
  restartPolicy: Never

You can choose whatever container image you want, Sysbox-EE places no requirements on the image.

Refer to the Documentation section below for further examples on how to use Sysbox-EE.

Documentation

The following documents in the Sysbox repo show how to use Docker and Kubernetes to deploy containers with Sysbox.

These docs apply equally to both Sysbox and Sysbox-EE.

Features that are specific to Sysbox-EE are tagged with "Sysbox-EE Feature Highlight" in the docs.

  • Sysbox Quick Start Guide

    • Provides many examples for using Sysbox to deploy enhanced containers. New users should start here.
  • Sysbox User Guide

    • Provides more detailed information on Sysbox features and troubleshooting.

In addition, the Nestybox blog site has articles on how to use Sysbox to deploy containers.

Filing Issues

We apologize for any problems in the product or documentation, and we appreciate users filing issues that help us improve Sysbox-EE.

To file issues with Sysbox-EE (e.g., bugs, feature requests, documentation changes, etc.), please refer to the issue guidelines document.

Security

If you find bugs or issues that may expose a Sysbox-EE vulnerability, please report these by sending an email to [email protected]. Please do not open security issues in this repo. Thanks!

In addition, a few vulnerabilities have recently been found in the Linux kernel that in some cases reduce or negate the enhanced isolation provided by Sysbox containers. Fortunately they are all fixed in recent Linux kernels. See the Sysbox User Guide's Vulnerabilities & CVEs chapter for more info, and reach out on the Sysbox Slack channel for further questions.

Support

Reach us at our slack channel or at [email protected] for any questions. See our contact info below for more options.

Contact

We are happy to help. You can reach us at:

Email: [email protected]

Slack: Nestybox Slack Workspace

sysbox-ee's People

Contributors

ctalledo avatar rodnymolina 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

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

sysbox-ee's Issues

Shiftfs module not present in Ubuntu Cloud Images

I'm unsure what I'm doing wrong here, but missing a shiftfs module.

root@system:~# docker run --runtime=sysbox-runc --rm -it --hostname my_cont debian:latest
docker: Error response from daemon: OCI runtime create failed: container requires user-ID shifting but error was found: shiftfs module is not loaded in the kernel. Update your kernel to include shiftfs module or enable Docker with userns-remap. Refer to the Sysbox troubleshooting guide for more info: unknown.
ERRO[0000] error waiting for container: context canceled```

License

I'm not seeing any license in this repository.

connection refused after running docker with sysbox-runc

I'm on Ubuntu 19.10 and installed without issue the bionic .deb.
Now, when I run docker run --runtime=sysbox-runc ... I get the following:

docker: Error response from daemon: OCI runtime create failed: container_linux.go:364: starting container process caused "process_linux.go:474: container init caused \"process_linux.go:441: running prestart hook 0 caused \\\"error running hook: exit status 1, stdout: , stderr: time=\\\\\\\"2020-02-01T13:15:25+01:00\\\\\\\" level=fatal msg=\\\\\\\"dial unix /var/run/docker/libnetwork/b1aea14fa6b47a6f800f04a76d29b6fab16f9a9176a9c5a3a7a0259f801457ed.sock: connect: connection refused\\\\\\\"\\\\n\\\"\"": unknown.
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Then docker doesn't work anymore at all (even with the default runtime) and service command neither:

sudo service docker restart
Failed to connect to bus: Connection refused
sudo service apache2 restart
Failed to connect to bus: Connection refused

The only way to get things up is to restart the computer.

Btw, while installing the deb, a sudo service docker restart was required for docker to detect the new runtime. This is missing in your docs.

Issues running a Rancher container inside a Sysbox container

docker run --name=test -it nestybox/ubuntu-bionic-systemd-docker:latest
docker exec -it test bash

# Inside the Sysbox container
docker run --privileged rancher/rancher

ERROR: Rancher must be ran with the --privileged flag when running outside of Kubernetes

Error when pulling openjdk images

Hi, I encountered the following issue when attempting to pull the openjdk image within a container using the sysbox-runc runtime,

# docker pull openjdk
Using default tag: latest
latest: Pulling from library/openjdk
977461c90301: Pull complete 
38d4dba4c275: Extracting [==================================================>]   14.8MB/14.8MB
2b949418b5d5: Download complete 
failed to register layer: Error processing tar file(exit status 1): operation not permitted

This was run inside a container started as follows,

docker run --runtime=sysbox-runc --rm --name nestybox-docker -it nestybox/alpine-docker

dockerd was started from another window via docker exec nestybox-docker dockerd -D.

I was able to reproduce the same error message building this smaller Dockerfile,

FROM oraclelinux:7-slim
RUN rm -rf /var/cache/yum

How to limit resources on a system container?

Testing this out, I was trying to limit the resources on the system container and see the effect inside the system container.

I tried passing the docker run option flags like --cpus=1 on launching the system container, but once inside, I still see 2 CPUs.

Same trying to use -m or --memory: this seems to have no effect.

How I can define/limit the resources for the system container?

The 'command' section in docker-compose.yml do nothing

  1. cat docker-compose.yml

version: '3.7'
services:
test-node:
container_name: test
image: nestybox/ubuntu-bionic-systemd-docker:latest
restart: always
tty: true
stdin_open: true
runtime: sysbox-runc
command:
- /bin/bash
- -c
- >
touch /testfile

  1. run cd / && ls -a on the container:
    bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var

proc-sys-fs-binfmt_misc.automount: Failed to initialize automounter: Operation not permitted

docker run -it --runtime=sysbox-runc --privileged --restart=always -p 9200:9000 nestybox/ubuntu-bionic-systemd-docker:latest

  1. running log:
    [ OK ] Started Dispatch Password Requests to Console Directory Watch.
    [ OK ] Reached target Remote File Systems.
    [ OK ] Started Forward Password Requests to Wall Directory Watch.
    [ OK ] Created slice User and Session Slice.
    [ OK ] Reached target Paths.
    [ OK ] Reached target Swap.
    [ OK ] Created slice System Slice.
    [ OK ] Listening on udev Kernel Socket.
    [ OK ] Listening on udev Control Socket.
    [ OK ] Listening on /dev/initctl Compatibility Named Pipe.
    proc-sys-fs-binfmt_misc.automount: Failed to initialize automounter: Operation not permitted
    [FAILED] Failed to set up automount Arbitrary Executable File Formats File System Automount Point.
    See 'systemctl status proc-sys-fs-binfmt_misc.automount' for details.

  2. run systemctl status proc-sys-fs-binfmt_misc.automount on the container:
    โ— proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats File System Automount Point
    Loaded: loaded (/lib/systemd/system/proc-sys-fs-binfmt_misc.automount; static; vendor preset: enabled)
    Active: failed (Result: resources)
    Where: /proc/sys/fs/binfmt_misc
    Docs: https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html
    https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems

  3. run docker info on host machine :
    Client:
    Debug Mode: false
    Server:
    Containers: 2
    Running: 2
    Paused: 0
    Stopped: 0
    Images: 57
    Server Version: 19.03.4
    Storage Driver: overlay2
    Backing Filesystem: extfs
    Supports d_type: true
    Native Overlay Diff: true
    Logging Driver: json-file
    Cgroup Driver: cgroupfs
    Plugins:
    Volume: local
    Network: bridge host ipvlan macvlan null overlay
    Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
    Swarm: inactive
    Runtimes: runc sysbox-runc
    Default Runtime: runc
    Init Binary: docker-init
    containerd version: b34a5c8af56e510852c35414db4c1f4fa6172339
    runc version: 3e425f80a8c931f88e6d94a8c831b9d5aa481657
    init version: fec3683
    Security Options:
    apparmor
    seccomp
    Profile: default
    Kernel Version: 5.4.0-72-generic
    Operating System: Ubuntu 18.04.3 LTS
    OSType: linux
    Architecture: x86_64
    CPUs: 4
    Total Memory: 7.645GiB
    Name: sanzenwin
    ID: 2YUT:QA42:UWRF:X2M7:LTJY:TJN7:SCND:BY24:QRJZ:VJ5X:R4PC:Z5YY
    Docker Root Dir: /var/lib/docker
    Debug Mode: false
    Registry: https://index.docker.io/v1/
    Labels:
    Experimental: false
    Insecure Registries:
    127.0.0.0/8
    Registry Mirrors:
    https://ustc-edu-cn.mirror.aliyuncs.com/
    Live Restore Enabled: false
    WARNING: No swap limit support

  4. run uname -a on host machine:
    Linux ***** 5.4.0-72-generic #80~18.04.1-Ubuntu SMP Mon Apr 12 23:26:25 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Bind mount of `/run` or `/var/run` into container causes host network to become unresponsive

Hello

I tried to make the sysbox runtime work for our Jenkins setup but it ends up crashing (the whole Docker daemon).

System information

  • AWS EC2 Instance
  • Ubuntu 18.04 Server (ubuntu/images/hvm-ssd/ubuntu-bionic-18.04-amd64-server-20200112 (ami-0b418580298265d5c))
  • Upgraded kernel as documented via backports (uname -r = 5.3.0-40-generic)

Jenkins Volumes (run directly on host using regular Docker runtime)

  • /var/run/docker.sock:/var/run/docker.sock
  • jenkins-workspace:/var/jenkins_home

Jenkins Pipeline

pipeline {
    ...
    agent {
        docker {
            image 'censored:latest'
            args  '--runtime=sysbox-runc -v jenkins-maven-repository:/home/jenkins/.m2'
        }
    }
    ...
}

For completness, this is what Jenkins tries to run:

docker run -t -d -u 1000:1000 --runtime=sysbox-runc -v jenkins-maven-repository:/home/jenkins/.m2 -w /var/jenkins_home/jobs/maven-pipeline-ng/workspace --volumes-from 9f65cddc6f6cf5951e78cc7bbd67f64040b5877919c8860d0d550a1c6a3905cf -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** censored:latest cat

So basically the Jenkins container (which is a regular one) should start pipeline agents with sysbox runtime -> Agents will be siblings of Jenkins but be able to have isolated Docker inside


This leads to the following error however:

Failed to run image 'censored:latest'. Error: docker: Error response from daemon: OCI runtime create failed: container_linux.go:364: starting container process caused "process_linux.go:474: container init caused \"process_linux.go:441: running prestart hook 0 caused \\\"error running hook: exit status 1, stdout: , stderr: time=\\\\\\\"2020-03-06T13:50:22Z\\\\\\\" level=fatal msg=\\\\\\\"dial unix /var/run/docker/libnetwork/c0d26181f7af.sock: connect: connection refused\\\\\\\"\\\\n\\\"\"": unknown.

The whole server (not only Docker, literally everything) starts to behave strange afterwards and the only solution is to perform a reboot via AWS console (doesn't really work too). I.e. running reboot -h now results in:

Failed to connect to bus: Connection refused
Failed to open /dev/initctl: No such device or address
Failed to talk to init daemon.

Manually creating censored:latest containers within the Jenkins container works and Docker within such a container works as well when done without -v jenkins-maven-repository:/home/jenkins/.m2 -w /var/jenkins_home/jobs/maven-pipeline-ng/workspace --volumes-from 9f65cddc6f6cf5951e78cc7bbd67f64040b5877919c8860d0d550a1c6a3905cf -e flags - so the problem must be with these.

Currently access to the server is not possible (stuck and un-stoppable) so I cannot further break down which of the flags alone is a problem (maybe --volumes-from?). I will try once I regain access to the server, but hopefully the provided information is enough anyways.

Thanks.

ubuntu 19.04 server: runtime not found

FYI:

I installed on Ubuntu 19.04 server from the live CD on VirtualBox.
The installer gives an option to install Docker during installation of Ubuntu

Docker ends up under /var/snap/docker/384/run and the config is under /var/snap/docker/384/config

I am guessing this is why the daemon.json config file wasn't properly updated to include the runtime.

after updating the daemon.json config file with the path to the sysbox-runc runtime, the issue was resolved.

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.