3 ms·

I don't get the differentiation between "rkt" and "docker". What complexity does Docker add? Separate networking? Difficulty communicating between processes? J

I don't get the differentiation between "rkt" and "docker". What complexity does Docker add? Separate networking? Difficulty communicating between processes? Just trying to understand why rkt is less overhead...

schmichael 10y ago
One large difference is that docker has a daemon that exposes an HTTP API and acts more or less like an init for containers. The docker daemon has historically had some stability issues as well as some security implications. Running a command line tool like rkt is a vastly smaller attack surface and less complex stack overall.
- orthecreedence 10y ago
  Also, not sure if this is still the case, but Docker's daemon ran as root on the host. Any vulnerability has the potential to give root on the host machine to an attacker. I don't think this has ever happened, but rkt's approach of using a process per container just makes much more sense in a security context (and for containerization in general).
  - fapjacks 10y ago
    The daemon needs superuser privileges to do its business, but your containers are not running as root. That lives behind the --privileged option and has ample guidance in the documentation against using it.
    - TheDong 10y ago
      Wrong. Without usernamespacing your containers do run as root. If you type `docker run busybox id` it will print uid=0, and that uid is 0 in the container and out of it. You are namespaced, so the linux kernel promises that even though you're root, you're not dangerous, and there is syscall filtering and shit going on.... but that historically has not really fared that well! But your statement is false. You're root with and without privileged. Privileged gives you back CAPABILITIES which are different than USER, so your claim is bullshit.
      - tmzt 10y ago
        Where in the kernel is 0==uid still privileged? Are there still places where the uid is checked instead of caps?
        TheDong 10y ago
        He said "but your containers are not running as root". That is objectively false. uid = 0 is "privileged" basically everywhere in the kernel, from filesystem management (reading a file bindmounted in that's owned by root e.g.) to binding to low ports (like 80).
        fapjacks 10y ago
        Whatever dude. You keep spreading your FUD. You clearly do not understand what Docker is and what Docker does.
        TheDong 10y ago
        Why does anyone care about usernamespacing then? https://docs.docker.com/engine/reference/commandline/dockerd/#/daemon-user-namespace-options https://docs.docker.com/engine/reference/commandline/dockerd... As you can see from the docs, it says "the most important security improvement is that, by default, container processes running as the root user will have expected administrative privilege (with some restrictions) inside the container but will effectively be mapped to an unprivileged uid on the host." This implies the reverse, that if you don't use userns then your process as root in the container will be mapped to a privilege uid on the host. This is all I'm saying is true. You clearly don't understand what I'm saying.
- indexerror 10y ago
  > docker has a daemon that exposes an HTTP API This API has to enabled explicitly. Docker daemon works by using a unix socket instead ( "/var/run/docker.sock" ). > acts more or less like an init for containers There is Docker daemon and there is Docker CLI. Both have separate scopes.
  - TheDong 10y ago
    The unix socket actually serves an HTTP api (just not over tcp) as well, so the statement was true either way.
  - gnosek 10y ago
    > There is Docker daemon and there is Docker CLI. Both have separate scopes. Docker CLI is glorified curl, everything happens in the daemon (containerd being logically -- but finally not physically -- part of the daemon).
- simstein 10y ago
  Could you please give a hint on what kind of stability issues you experienced? Do they still exist? My team is thinking about using Docker for high loaded system in production, and stability is one of our priorities here.
  - schmichael 10y ago
    I don't personally operate docker in production, but googling "docker stability" or perusing their github issues should lead to the same anecdotes I'm referring to. If you'll indulge me putting on my corporate hat for a minute: we've had some customers very happy scheduling a high volume of containers at a high rate on nomad: - https://www.hashicorp.com/c1m.html https://www.hashicorp.com/c1m.html (mentions a docker bug even) - https://www.youtube.com/watch?v=MRtRwhL5lwM https://www.youtube.com/watch?v=MRtRwhL5lwM If at all possible I'd recommend using our Java or exec drivers as they use builtin containerization and avoid the overhead of docker or rkt.
vidarh 10y ago
A lot of it is historical. What rkt added conceptually when it was introduced was 1) a spec and test suite, 2) signed/content-addressable images and first class third party repos, 3) not running everything under a single daemon. Since then, Docker has improved quite a bit on these so the most in your face practical differences are smaller, but there are still philosophical differences that affects it. E.g. rkt comes out of CoreOS. CoreOS does a lot around embracing systemd to its full extent. Systemd can provide a lot of the capabilities that Docker did itself, and parts of rkt's design flows from that. E.g. restarting, querying status, capturing the logs, so in a systemd based system, Docker integrated fairly poorly in that systemd would be starting and keeping track of a Docker client rather than the process actually controlling the container, while rkt fits right in. Again, the difference is getting smaller, and various tools like runc etc. from Docker now allows you narrow the gap even more (if you put in extra effort). Try both, basically - they're similar enough that it's worth figuring out which "flavor" you like best.

schmichael 10y ago

One large difference is that docker has a daemon that exposes an HTTP API and acts more or less like an init for containers. The docker daemon has historically had some stability issues as well as some security implications. Running a command line tool like rkt is a vastly smaller attack surface and less complex stack overall.

orthecreedence 10y ago
Also, not sure if this is still the case, but Docker's daemon ran as root on the host. Any vulnerability has the potential to give root on the host machine to an attacker. I don't think this has ever happened, but rkt's approach of using a process per container just makes much more sense in a security context (and for containerization in general).
- fapjacks 10y ago
  The daemon needs superuser privileges to do its business, but your containers are not running as root. That lives behind the --privileged option and has ample guidance in the documentation against using it.
  - TheDong 10y ago
    Wrong. Without usernamespacing your containers do run as root. If you type `docker run busybox id` it will print uid=0, and that uid is 0 in the container and out of it. You are namespaced, so the linux kernel promises that even though you're root, you're not dangerous, and there is syscall filtering and shit going on.... but that historically has not really fared that well! But your statement is false. You're root with and without privileged. Privileged gives you back CAPABILITIES which are different than USER, so your claim is bullshit.
    - tmzt 10y ago
      Where in the kernel is 0==uid still privileged? Are there still places where the uid is checked instead of caps?
      - TheDong 10y ago
        He said "but your containers are not running as root". That is objectively false. uid = 0 is "privileged" basically everywhere in the kernel, from filesystem management (reading a file bindmounted in that's owned by root e.g.) to binding to low ports (like 80).
        fapjacks 10y ago
        Whatever dude. You keep spreading your FUD. You clearly do not understand what Docker is and what Docker does.
        TheDong 10y ago
        Why does anyone care about usernamespacing then? https://docs.docker.com/engine/reference/commandline/dockerd/#/daemon-user-namespace-options https://docs.docker.com/engine/reference/commandline/dockerd... As you can see from the docs, it says "the most important security improvement is that, by default, container processes running as the root user will have expected administrative privilege (with some restrictions) inside the container but will effectively be mapped to an unprivileged uid on the host." This implies the reverse, that if you don't use userns then your process as root in the container will be mapped to a privilege uid on the host. This is all I'm saying is true. You clearly don't understand what I'm saying.
indexerror 10y ago
> docker has a daemon that exposes an HTTP API This API has to enabled explicitly. Docker daemon works by using a unix socket instead ( "/var/run/docker.sock" ). > acts more or less like an init for containers There is Docker daemon and there is Docker CLI. Both have separate scopes.
- TheDong 10y ago
  The unix socket actually serves an HTTP api (just not over tcp) as well, so the statement was true either way.
- gnosek 10y ago
  > There is Docker daemon and there is Docker CLI. Both have separate scopes. Docker CLI is glorified curl, everything happens in the daemon (containerd being logically -- but finally not physically -- part of the daemon).
simstein 10y ago
Could you please give a hint on what kind of stability issues you experienced? Do they still exist? My team is thinking about using Docker for high loaded system in production, and stability is one of our priorities here.
- schmichael 10y ago
  I don't personally operate docker in production, but googling "docker stability" or perusing their github issues should lead to the same anecdotes I'm referring to. If you'll indulge me putting on my corporate hat for a minute: we've had some customers very happy scheduling a high volume of containers at a high rate on nomad: - https://www.hashicorp.com/c1m.html https://www.hashicorp.com/c1m.html (mentions a docker bug even) - https://www.youtube.com/watch?v=MRtRwhL5lwM https://www.youtube.com/watch?v=MRtRwhL5lwM If at all possible I'd recommend using our Java or exec drivers as they use builtin containerization and avoid the overhead of docker or rkt.

vidarh 10y ago

A lot of it is historical. What rkt added conceptually when it was introduced was 1) a spec and test suite, 2) signed/content-addressable images and first class third party repos, 3) not running everything under a single daemon. Since then, Docker has improved quite a bit on these so the most in your face practical differences are smaller, but there are still philosophical differences that affects it. E.g. rkt comes out of CoreOS. CoreOS does a lot around embracing systemd to its full extent. Systemd can provide a lot of the capabilities that Docker did itself, and parts of rkt's design flows from that. E.g. restarting, querying status, capturing the logs, so in a systemd based system, Docker integrated fairly poorly in that systemd would be starting and keeping track of a Docker client rather than the process actually controlling the container, while rkt fits right in. Again, the difference is getting smaller, and various tools like runc etc. from Docker now allows you narrow the gap even more (if you put in extra effort). Try both, basically - they're similar enough that it's worth figuring out which "flavor" you like best.