3 ms·

I like rkt’s focus on deployment issues that Docker currently still has — as an example, rkt verifies signatures by default. As another example, rkt intends to

by secure 11y ago

I like rkt’s focus on deployment issues that Docker currently still has — as an example, rkt verifies signatures by default. As another example, rkt intends to work better with systemd/kubernetes, but AIUI that’s still on the roadmap and not actually implemented. Looking forward to when CoreOS actually recommends running rkt in production :).

chimeracoder 11y ago
> As another example, rkt intends to work better [than Docker] with systemd/kubernetes, but AIUI that’s still on the roadmap and not actually implemented. Could you elaborate on this? Do you mean working better with systemd as a process supervisor or as a runtime? Many people don't know this, but it's already possible to use systemd as a runtime for Docker containers[0], which is about as integrated as I can imagine[1]. Though admittedly, the Docker daemon and runtime do not play well with process supervision (of any kind, including systemd)[2]. Last I checked, CoreOS had posted to the systemd mailing list announcing their plans to integrate with nspawn, though I don't think that's been released yet. [0] This is the best-kept secret of both Docker and systemd. I recently conducted a workshop on "Docker Without Docker" - in other words, how to run Docker containers without even having the Docker runtime installed (using pure systemd). [1] And, depending on your use case, I'd recommend giving it a shot - there are a number of things that systemd provides that Docker still does not. On the other hand, Docker has a large ecosystem, and the tools for building initial container images are very accessible. [2] At least as of recently, you can use 'exec mode' to specify the initial process (PID 1) inside a container running under Docker, but systemd still does not have access to the actual process on the host, which makes it cumbersome to monitor - the CoreOS documentation tells you to do something like this for Docker + systemd: https://github.com/ChimeraCoder/znc-kibana-playbooks/blob/master/znc.service https://github.com/ChimeraCoder/znc-kibana-playbooks/blob/ma...
- amouat 11y ago
  > [0] This is the best-kept secret of both Docker and systemd. I recently conducted a workshop on "Docker Without Docker" - in other words, how to run Docker containers without even having the Docker runtime installed (using pure systemd). Could you expand on this? I'm curious as to what you mean/how you did this.
  - chimeracoder 11y ago
    Sure. These are the slides for my talk, which includes some of the code examples that we walked through: https://chimeracoder.github.io/docker-without-docker/#1 https://chimeracoder.github.io/docker-without-docker/#1 Consider Git. Git exists solely on the filesystem. If you want, you can read git repos by inflating the ZLIB-compressed objects yourself, and create git repos by compressing objects, hashing them, and storing them in right locations the exact same way that Git does. It's a lot of work, and the Git toolchain exists so you don't have to type insanely long bash one-liners just to read your commit history. But it's kind of cool to know that >95% of Git is really just 'syntactic sugar' around functionality that's also provided by other command-line tools[0]. I'll wave my hands a bit, but in short: containerization uses features implemented at the kernel level, and in fact, until recently, Docker and systemd both built on top of LXC (Docker has switched created their own libcontainer). If you take a running Docker container and dump it, you'll get a root filesystem. You could chroot(8) inside this root filesystem, but as we know, containerization is more powerful than chroot. Once you've dumped the container, systemd doesn't need to know that it was once a Docker container - it'll just look for whatever binary is located at /sbin/init and run that (or run whatever command you tell it to run instead. Just like your actual OS - which is not a coincidence!). One advantage to using systemd instead of the Docker daemon/runtime is that systemd is capable of running itself inside a container, whereas running init systems inside Docker containers is tricky and not recommended[1]. Futhermore, systemd is smart enough to know when it's running inside a container and when it's not, so the container init system plays nicely with the host init system - things like integrated system logs and networking. Newer versions of systemd actually allow you to pull Docker images from the Docker hub directly, so you can even use systemd to replace `docker pull` as well as `docker run`. [0] There's a tiny, tiny portion of Git which is home-grown, but most of the features it builds on (SHA, zlib, diff) are easily replaced by other command-line tools. [1] While it's supported, the primary use case of Docker is for running application processes: https://github.com/docker/docker/issues/2170 https://github.com/docker/docker/issues/2170
    - amouat 11y ago
      Ah, that's a really great explanation - thanks. I guess you lose all of the Docker metadata, links and volumes though? You should turn this into blog post if you have time - I'd upvote it anyway!

by secure 11y ago

chimeracoder 11y ago

> As another example, rkt intends to work better [than Docker] with systemd/kubernetes, but AIUI that’s still on the roadmap and not actually implemented. Could you elaborate on this? Do you mean working better with systemd as a process supervisor or as a runtime? Many people don't know this, but it's already possible to use systemd as a runtime for Docker containers[0], which is about as integrated as I can imagine[1]. Though admittedly, the Docker daemon and runtime do not play well with process supervision (of any kind, including systemd)[2]. Last I checked, CoreOS had posted to the systemd mailing list announcing their plans to integrate with nspawn, though I don't think that's been released yet. [0] This is the best-kept secret of both Docker and systemd. I recently conducted a workshop on "Docker Without Docker" - in other words, how to run Docker containers without even having the Docker runtime installed (using pure systemd). [1] And, depending on your use case, I'd recommend giving it a shot - there are a number of things that systemd provides that Docker still does not. On the other hand, Docker has a large ecosystem, and the tools for building initial container images are very accessible. [2] At least as of recently, you can use 'exec mode' to specify the initial process (PID 1) inside a container running under Docker, but systemd still does not have access to the actual process on the host, which makes it cumbersome to monitor - the CoreOS documentation tells you to do something like this for Docker + systemd: https://github.com/ChimeraCoder/znc-kibana-playbooks/blob/master/znc.service https://github.com/ChimeraCoder/znc-kibana-playbooks/blob/ma...

amouat 11y ago
> [0] This is the best-kept secret of both Docker and systemd. I recently conducted a workshop on "Docker Without Docker" - in other words, how to run Docker containers without even having the Docker runtime installed (using pure systemd). Could you expand on this? I'm curious as to what you mean/how you did this.
- chimeracoder 11y ago
  Sure. These are the slides for my talk, which includes some of the code examples that we walked through: https://chimeracoder.github.io/docker-without-docker/#1 https://chimeracoder.github.io/docker-without-docker/#1 Consider Git. Git exists solely on the filesystem. If you want, you can read git repos by inflating the ZLIB-compressed objects yourself, and create git repos by compressing objects, hashing them, and storing them in right locations the exact same way that Git does. It's a lot of work, and the Git toolchain exists so you don't have to type insanely long bash one-liners just to read your commit history. But it's kind of cool to know that >95% of Git is really just 'syntactic sugar' around functionality that's also provided by other command-line tools[0]. I'll wave my hands a bit, but in short: containerization uses features implemented at the kernel level, and in fact, until recently, Docker and systemd both built on top of LXC (Docker has switched created their own libcontainer). If you take a running Docker container and dump it, you'll get a root filesystem. You could chroot(8) inside this root filesystem, but as we know, containerization is more powerful than chroot. Once you've dumped the container, systemd doesn't need to know that it was once a Docker container - it'll just look for whatever binary is located at /sbin/init and run that (or run whatever command you tell it to run instead. Just like your actual OS - which is not a coincidence!). One advantage to using systemd instead of the Docker daemon/runtime is that systemd is capable of running itself inside a container, whereas running init systems inside Docker containers is tricky and not recommended[1]. Futhermore, systemd is smart enough to know when it's running inside a container and when it's not, so the container init system plays nicely with the host init system - things like integrated system logs and networking. Newer versions of systemd actually allow you to pull Docker images from the Docker hub directly, so you can even use systemd to replace `docker pull` as well as `docker run`. [0] There's a tiny, tiny portion of Git which is home-grown, but most of the features it builds on (SHA, zlib, diff) are easily replaced by other command-line tools. [1] While it's supported, the primary use case of Docker is for running application processes: https://github.com/docker/docker/issues/2170 https://github.com/docker/docker/issues/2170
  - amouat 11y ago
    Ah, that's a really great explanation - thanks. I guess you lose all of the Docker metadata, links and volumes though? You should turn this into blog post if you have time - I'd upvote it anyway!