github.com/rkt/rkt@v1.30.1-0.20200224141603-171c416fac02/Documentation/rkt-vs-other-projects.md (about)

     1  # rkt vs other projects
     2  
     3  This document describes how rkt compares to various other projects in the container ecosystem.
     4  
     5  * [rkt vs Docker](#rkt-vs-docker)
     6    * [Process Model](#process-model)
     7    * [Privilege Separation](#privilege-separation)
     8  * [rkt vs runC](#rkt-vs-runc)
     9  * [rkt vs containerd](#rkt-vs-containerd)
    10  * [rkt vs LXC/LXD](#rkt-vs-lxclxd)
    11  * [rkt vs OpenVZ](#rkt-vs-openvz)
    12  * [rkt vs systemd-nspawn](#rkt-vs-systemd-nspawn)
    13  * [rkt vs machinectl](#rkt-vs-machinectl)
    14  * [rkt vs qemu-kvm, lkvm](#rkt-vs-qemu-kvm-lkvm)
    15  
    16  ## rkt vs Docker
    17  
    18  The Docker Engine is an application container runtime implemented as a central API daemon.
    19  Docker can resolve a "[Docker Image][docker-image-spec]" name, such as `quay.io/coreos/etcd`, and download, execute, and monitor the application container.
    20  Functionally, this is all similar to rkt; however, along with "Docker Images", rkt can also download and run "App Container Images" (ACIs) specified by the [App Container Specification][appc-spec] (appc).
    21  
    22  Besides also supporting ACIs, rkt has a substantially different architecture that is designed with composability and security in mind.
    23  
    24  #### Process Model
    25  
    26  Prior to Docker version 1.11, the Docker Engine daemon downloaded container images, launched container processes, exposed a remote API, and acted as a log collection daemon, all in a centralized process running as root.
    27  
    28  While such a centralized architecture is convenient for deployment, it does not follow best practices for Unix process and privilege separation; further, it makes Docker difficult to properly integrate with Linux init systems such as upstart and systemd.
    29  
    30  Since version 1.11, the Docker daemon no longer handles the execution of containers itself.
    31  Instead, this is now handled by [containerd][containerd].
    32  More precisely, the Docker daemon prepares the image as an [Open Container Image][oci] (OCI) bundle and makes an API call to containerd to start the OCI bundle.
    33  containerd then starts the container using [runC][runc-github].
    34  
    35  ![rkt-vs-docker-process-model](rkt-vs-docker-process-model.png)
    36  
    37  Since running a Docker container from the command line (i.e. using `docker run`) just talks to the Docker daemon API, which is in turn directly or indirectly — via containerd — responsible for creating the container, init systems are unable to directly track the life of the actual container process.
    38  
    39  rkt has no centralized "init" daemon, instead launching containers directly from client commands, making it compatible with init systems such as systemd, upstart, and others.
    40  
    41  A more detailed view to rkt's process model is shown in the [architecture documentation][architecture].
    42  
    43  #### Privilege Separation
    44  
    45  rkt uses standard Unix group permissions to allow privilege separation between different operations.
    46  Once the rkt data directory is correctly set up, container image downloads and signature verification can run as a non-privileged user.
    47  
    48  ![rkt-vs-docker-fetch](rkt-vs-docker-fetch.png)
    49  
    50  ## rkt vs runC
    51  
    52  [runC][runc-github] is a low-level container runtime and an implementation of the [Open Container Initiative specification][oci-spec-github].
    53  runC exposes and expects a user to understand low-level details of the host operating system and configuration.
    54  It requires the user to separately download or cryptographically verify container images, and for "higher level tools" to prepare the container filesystem.
    55  runC does not have a centralized daemon, and, given a properly configured "OCI bundle", can be integrated with init systems such as upstart and systemd.
    56  
    57  rkt includes the same functionality as runC but does not expect a user to understand low-level details of the operating system to use, and can be invoked as simply as `rkt run coreos.com/etcd,version=v2.2.0`.
    58  It can download both "[Docker Images][docker-image-spec]" and "[App Container Images][appc-spec]".
    59  As rkt does not have a centralized daemon it can also be easily integrated with init systems such as upstart and systemd.
    60  
    61  ## rkt vs containerd
    62  
    63  [containerd][containerd] is a daemon to control [runC][runc-github].
    64  It has a command-line tool called `ctr` which is used to interact with the containerd daemon.
    65  This makes the containerd process model similar to that of the Docker process model, illustrated above.
    66  
    67  Unlike the Docker daemon it has a reduced feature set; not supporting image download, for example.
    68  
    69  rkt has no centralized daemon to manage containers, instead launching containers directly from client commands, making it compatible with init systems such as systemd, upstart, and others.
    70  
    71  ## rkt vs LXC/LXD
    72  
    73  LXC is a system container runtime designed to execute "full system containers", which generally consist of a full operating system image.
    74  An LXC process, in most common use cases, will boot a full Linux distribution such as Debian, Fedora, Arch, etc, and a user will interact with it similarly to how they would with a Virtual Machine image.
    75  
    76  LXC may also be used to run (but not download) application containers, but this use requires more understanding of low-level operating system details and is a less common practice.
    77  LXC can download "full system container" images from various public mirrors and cryptographically verify them.
    78  LXC does not have a central daemon and can integrate with init systems such as upstart and systemd.
    79  
    80  LXD is similar to LXC but is a REST API on top of liblxc which forks a monitor and container process.
    81  This ensures the LXD daemon is not a central point of failure and containers continue running in case of LXD daemon failure.
    82  All other details are nearly identical to LXC.
    83  
    84  rkt can download, cryptographically verify, and run application container images.
    85  It is not designed to run "full system containers" but instead individual applications such as web apps, databases, or caches.
    86  As rkt does not have a centralized daemon it can be integrated with init systems such as upstart and systemd.
    87  
    88  ## rkt vs OpenVZ
    89  
    90  OpenVZ is a system container runtime designed to execute "full system containers" which are generally a full system image.
    91  An OpenVZ process, in most common use cases, will boot a full Linux Distro such as Debian, Fedora, Arch, etc and  a user will interact with it similarly to a Virtual Machine image.
    92  OpenVZ can download "full system container" images from various public mirrors and cryptographically verify them.
    93  OpenVZ does not have a central daemon and can integrate with init systems such as upstart and systemd.
    94  
    95  rkt can download, cryptographically verify, and run application container images.
    96  It is not designed to run "full system containers" but instead individual applications such as web apps, databases, or caches.
    97  As rkt does not have a centralized daemon it can be integrated with init systems such as upstart and systemd.
    98  
    99  ## rkt vs systemd-nspawn
   100  
   101  systemd-nspawn is a container runtime designed to execute a process inside of a Linux container.
   102  systemd-nspawn gets its name from "namespace spawn", which means it only handles process isolation and does not do resource isolation like memory, CPU, etc.
   103  systemd-nspawn can run an application container or system container but does not, by itself, download or verify images.
   104  systemd-nspawn does not have a centralized daemon and can be integrated with init systems such as upstart and systemd.
   105  
   106  rkt can download, cryptographically verify, and run application container images.
   107  It is not designed to run "full system containers", but instead individual applications such as web apps, databases, or caches.
   108  As rkt does not have a centralized daemon it can be integrated with init systems such as upstart and systemd.
   109  By default rkt uses systemd-nspawn to configure the namespaces for an application container.
   110  
   111  ## rkt vs machinectl
   112  
   113  machinectl is a system manager that can be used to query and control the state of registered systems on a systemd host.
   114  These systems may be registered Virtual Machines, systemd-nspawn containers, or other runtimes that register with the systemd registration manager, systemd-machined.
   115  Among many other things, machinectl can download, cryptographically verify, extract and trigger to run a systemd-nspawn container off the extracted image content.
   116  By default these images are expected to be "full system containers", as systemd-nspawn is passed the “--boot” argument.
   117  
   118  On systemd hosts, rkt will integrate with systemd-machined in much the same way that machinectl containers will: any pods created by rkt will be registered as machines on the host and can be interacted with using machinectl commands.
   119  However, in being more oriented towards applications, rkt abstracts the pod lifecycle away from the user.
   120  rkt also provides a more configurable and advanced workflow around discovering, downloading and verifying images, as well as supporting more image types.
   121  Unlike machinectl, rkt execs systemd-nspawn directly instead of creating a systemd service, allowing it to integrate cleanly with any supervisor system.
   122  Furthermore, in addition to namespace isolation, rkt can set up various other kinds of isolation (e.g. resources) defined in the appc specification.
   123  
   124  ## rkt vs qemu-kvm, lkvm
   125  
   126  qemu-kvm and lkvm are userspace tools that execute a full system image inside of a Virtual Machine using the [Linux KVM infrastructure][kvm-wiki].
   127  A system image will commonly include a boot loader, kernel, root filesystem and be pre-installed with applications to run on boot.
   128  Most commonly qemu-kvm is used for IaaS systems such as OpenStack, Eucalyptus, etc.
   129  The Linux KVM infrastructure is trusted for running multi-tenanted virtual machine infrastructures and is generally accepted as being secure enough to run untrusted system images.
   130  qemu-kvm and lkvm do not have a centralized daemon and can be integrated with init systems such as upstart and systemd.
   131  
   132  rkt can download, cryptographically verify, and run application container images.
   133  It is not designed to run "full system images" but instead individual applications such as web apps, databases, or caches.
   134  As rkt does not have a centralized daemon it can be integrated with init systems such as upstart and systemd.
   135  rkt can optionally use lkvm or qemu-kvm as an additional security measure over a Linux container, at a slight cost to performance and flexibility; this feature can be configured using the [kvm (aka Clear Containers) stage1][kvm-stage1].
   136  
   137  
   138  [appc-spec]: https://github.com/appc/spec
   139  [containerd]: https://containerd.tools
   140  [docker-image-spec]: https://github.com/docker/docker/blob/master/image/spec/v1.md
   141  [kvm-wiki]: https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine
   142  [kvm-stage1]: running-kvm-stage1.md
   143  [oci]: https://www.opencontainers.org/
   144  [oci-spec-github]: https://github.com/opencontainers/specs
   145  [runc-github]: https://github.com/opencontainers/runc
   146  [architecture]: devel/architecture.md