3 ms·

> [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 co

by 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!
  - chimeracoder 11y ago
    > I guess you lose all of the Docker metadata, links and volumes though? You only need links at runtime, so they're not part of the frozen image per se; they exist as part of a running container. Put another way, systemd handles container networking, so you don't need the environment variables that Docker injects when making links, because the containers can talk to each other already[0]. Volumes - if you mount external volumes with -v /foo:/bar, you can do the same with systemd. I'm actually not too sure about named volumes in Docker, since I almost never use them (it's way easier to reason about volumes when I control where they are located on the host). > You should turn this into blog post if you have time - I'd upvote it anyway! Thanks - I'm actually working on that! Consider these slides a preview. :)

by amouat 11y ago

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!
- chimeracoder 11y ago
  > I guess you lose all of the Docker metadata, links and volumes though? You only need links at runtime, so they're not part of the frozen image per se; they exist as part of a running container. Put another way, systemd handles container networking, so you don't need the environment variables that Docker injects when making links, because the containers can talk to each other already[0]. Volumes - if you mount external volumes with -v /foo:/bar, you can do the same with systemd. I'm actually not too sure about named volumes in Docker, since I almost never use them (it's way easier to reason about volumes when I control where they are located on the host). > You should turn this into blog post if you have time - I'd upvote it anyway! Thanks - I'm actually working on that! Consider these slides a preview. :)