4 ms·

Is there somewhere with a good walk though of the constructs that docker containers default to? Not these slim one the default docker one. As someone who works

Is there somewhere with a good walk though of the constructs that docker containers default to? Not these slim one the default docker one. As someone who works with docker containers on a somewhat daily basis I only have a vague idea of what they do under the hood and don’t have much of a reference point when comparing this slim impl to the default one.

timClicks 7y ago
Until you're more comfortable with the container model, I recommend sticking with Ubuntu LTS images, such as ubuntu:18.04. That way if something breaks, you have a familiar environment to work with. Once you have gathered a mental model, feel free to tune your images by basing them on something lighter.
core-questions 7y ago
Well, you're always coming FROM something, unless you're coming FROM scratch, which is literally empty. A popular base image is Debian Buster. What's in the Dockerfile? https://github.com/debuerreotype/docker-debian-artifacts/blob/17d8dadb220460bf153bf2de493c2bc873ef52de/buster/Dockerfile https://github.com/debuerreotype/docker-debian-artifacts/blo... Wow, simple, it just adds a "rootfs" archive. What's in there? https://github.com/debuerreotype/docker-debian-artifacts/blob/17d8dadb220460bf153bf2de493c2bc873ef52de/buster/rootfs.manifest https://github.com/debuerreotype/docker-debian-artifacts/blo... Aha. So what we have in rootfs.xz is essentially the output of a Debian system with all of those packages installed in it, and the minimal configuration needed to tie them together. No init system, no kernel, just a big filesystem full of the usual stuff an absolutely minimal Debian install would have. Now, when you run FROM debian:buster, what you get is a base layer with enough to be useful. `apt-get` is there with a default repository list that works fine, and you can install things to your hearts' content.
itamarst 7y ago
In general, the bottom layer is a small Linux distro (Ubuntu, Debian, Alpine), just enough to get you going. Ideally you choose a base image that is getting security updates on regular basis, and that doesn't have significant changes over time for the same tag. So e.g. `fedora` is bad base image, because one day you'll jump from Fedora 30 to Fedora 31. Likewise `ubuntu` isn't great. But `ubuntu:18.04` is the Long-Term Support release and so it'll be fairly stable. In the context of Python packaging I've written a more detailed guide to choosing a base image: https://pythonspeed.com/articles/base-image-python-docker-images/ https://pythonspeed.com/articles/base-image-python-docker-im...
jbotz 7y ago
I'm not completely sure what it is you want to know, but basically there are two pieces to linux container tech (Docker and others). The first is a set of Linux kernel features that lets us isolate various aspects of processes in separate namespaces. The second is layered images, using filesystem features like overlayfs and copy-on-write to avoid having to duplicated everything. These two features of the Linux kernel are the real "container technology", docker and others are basically just user interfaces for these. A link about namespaces: http://ifeanyi.co/posts/linux-namespaces-part-1/ http://ifeanyi.co/posts/linux-namespaces-part-1/ A nice little introduction to overlays/etc: https://jvns.ca/blog/2019/11/18/how-containers-work--overlayfs/ https://jvns.ca/blog/2019/11/18/how-containers-work--overlay... And if you really want to learn how it all works, write your own "rubber-docker" in Python: https://github.com/Fewbytes/rubber-docker https://github.com/Fewbytes/rubber-docker
kylequest 7y ago
docker-slim also gives you useful info about the original container image in addition to minifying your container (you can actually run it without the minification part if you want). It will "reverse engineer" the Dockerfile for your fat/original container image and it will produce a detailed report about the fat/original image layers and what's in them (diffing between the layers is an upcoming feature). I'll be happy to do an overview if you are interested. Please ping me offline.

timClicks 7y ago

Until you're more comfortable with the container model, I recommend sticking with Ubuntu LTS images, such as ubuntu:18.04. That way if something breaks, you have a familiar environment to work with. Once you have gathered a mental model, feel free to tune your images by basing them on something lighter.

core-questions 7y ago

Well, you're always coming FROM something, unless you're coming FROM scratch, which is literally empty. A popular base image is Debian Buster. What's in the Dockerfile? https://github.com/debuerreotype/docker-debian-artifacts/blob/17d8dadb220460bf153bf2de493c2bc873ef52de/buster/Dockerfile https://github.com/debuerreotype/docker-debian-artifacts/blo... Wow, simple, it just adds a "rootfs" archive. What's in there? https://github.com/debuerreotype/docker-debian-artifacts/blob/17d8dadb220460bf153bf2de493c2bc873ef52de/buster/rootfs.manifest https://github.com/debuerreotype/docker-debian-artifacts/blo... Aha. So what we have in rootfs.xz is essentially the output of a Debian system with all of those packages installed in it, and the minimal configuration needed to tie them together. No init system, no kernel, just a big filesystem full of the usual stuff an absolutely minimal Debian install would have. Now, when you run FROM debian:buster, what you get is a base layer with enough to be useful. `apt-get` is there with a default repository list that works fine, and you can install things to your hearts' content.

itamarst 7y ago

In general, the bottom layer is a small Linux distro (Ubuntu, Debian, Alpine), just enough to get you going. Ideally you choose a base image that is getting security updates on regular basis, and that doesn't have significant changes over time for the same tag. So e.g. `fedora` is bad base image, because one day you'll jump from Fedora 30 to Fedora 31. Likewise `ubuntu` isn't great. But `ubuntu:18.04` is the Long-Term Support release and so it'll be fairly stable. In the context of Python packaging I've written a more detailed guide to choosing a base image: https://pythonspeed.com/articles/base-image-python-docker-images/ https://pythonspeed.com/articles/base-image-python-docker-im...

jbotz 7y ago

I'm not completely sure what it is you want to know, but basically there are two pieces to linux container tech (Docker and others). The first is a set of Linux kernel features that lets us isolate various aspects of processes in separate namespaces. The second is layered images, using filesystem features like overlayfs and copy-on-write to avoid having to duplicated everything. These two features of the Linux kernel are the real "container technology", docker and others are basically just user interfaces for these. A link about namespaces: http://ifeanyi.co/posts/linux-namespaces-part-1/ http://ifeanyi.co/posts/linux-namespaces-part-1/ A nice little introduction to overlays/etc: https://jvns.ca/blog/2019/11/18/how-containers-work--overlayfs/ https://jvns.ca/blog/2019/11/18/how-containers-work--overlay... And if you really want to learn how it all works, write your own "rubber-docker" in Python: https://github.com/Fewbytes/rubber-docker https://github.com/Fewbytes/rubber-docker

kylequest 7y ago

docker-slim also gives you useful info about the original container image in addition to minifying your container (you can actually run it without the minification part if you want). It will "reverse engineer" the Dockerfile for your fat/original container image and it will produce a detailed report about the fat/original image layers and what's in them (diffing between the layers is an upcoming feature). I'll be happy to do an overview if you are interested. Please ping me offline.