d-utils

commit

b1fdd2107bbfcee8e36f192a3e25bf4e690f2baf

parent

ae66e0a67d0e63569d4896ead5ed1e1fd0f9165c

Author

Tobias Bengfort <tobias.bengfort@posteo.de>

Date

2022-06-24 06:52

README: expect less prior knowledge

Diffstat

1 files changed, 24 insertions, 18 deletions

diff --git a/README.md b/README.md

@@ -3,9 +3,8 @@
    3     3 `d-utils` is a set of simple utils to use docker images without docker.
    4     4 
    5     5 -	`d-pull NAME[@TAG] [DIR]` will download a docker image and save it to `DIR`.
    6    -1 	It is saved as a single `rootfs` folder along with `config.json`.
    7    -1 -	`d-run DIR [CMD]` will execute `CMD` in the container give by `DIR`. Volumes
    8    -1 	are created in `DIR/volumes/`.
   -1     6 	It is saved as a single `rootfs` folder along with a `config.json`.
   -1     7 -	`d-run DIR [CMD]` will execute `CMD` in the container give by `DIR`.
    9     8 
   10     9 # Config
   11    10 
@@ -40,32 +39,39 @@ system. If you need a new container based on the same image you can just run
   40    39 > -- [Christian Brauner](https://people.kernel.org/brauner/the-seccomp-notifier-new-frontiers-in-unprivileged-container-development)
   41    40 
   42    41 I (think I) can remember when cgroups and namespaces were added to linux. Back
   43    -1 then they were announced as low level features that were not supposed to be
   -1    42 then they were announced as low-level features that were not supposed to be
   44    43 used directly, but that could enable exciting new high-level tools.
   45    44 
   46    -1 And boy did that make waves. Nowadays flatpak and snap use these features to
   47    -1 containerize desktop applications, systemd uses them to isolate system
   48    -1 services, and docker seems to have thoroughly conquered deployment.
   -1    45 And boy did that make waves. Nowadays there are many tools that use these
   -1    46 low-level features: systemd uses them to isolate system services, flatpak and
   -1    47 snap do something similar for desktop applications, and docker has popularized
   -1    48 the idea of "containers" that have now spread far beyond docker itself.
   49    49 
   50    50 My trouble is: None of these tools feel like they have nailed the "high level"
   51    51 aspect of this. `systemd-analyze security` for example lists 80 (!) different
   52    -1 settings. The user experience is just not that great.
   -1    52 settings. What I expect from a high-level tool is a good mix between
   -1    53 flexibility and simplicity, and these tools seem to give me neither.
   53    54 
   54    -1 Docker is the worst offender in my opinion. I still have to check the docs
   55    -1 every time I want to start a container, but worse than that it hides the
   56    -1 images, containers, and volumes in some impenetrable folder structure. On top
   57    -1 of that, it executes all containers as root which is a massive security issue.
   -1    55 Docker is the worst offender in my opinion. In an attempt to make it easier for
   -1    56 users there is a lot of implicit behavior: When I start a container the
   -1    57 necessary files are implicitly downloaded and stored somewhere on my machine.
   -1    58 And the container is implicitly started with root permissions. In my opinion
   -1    59 this implicit behavior does more harm than good.
   -1    60 
   -1    61 And even with this behavior, docker is still far from simple to use. There is
   -1    62 an abundance of subcommands and options that are hard to understand without a
   -1    63 deep understanding of both docker and the underlying primitives.
   58    64 
   59    65 So let's start from scratch.
   60    66 
   61    67 As far as I understand, containerization has two goals: Bundle an application
   62    -1 with libraries and configuration so it becomes self-contained, and then isolate
   63    -1 the whole thing so it cannot mess up the host system.
   -1    68 with libraries and configuration so it can run anywhere, and then isolate the
   -1    69 whole thing so it cannot mess up the host system.
   64    70 
   65    -1 To run such a container you would basically just need a chroot, ideally
   66    -1 unprivileged. Namespaces can then help to further isolate the container, which
   67    -1 is good but not essential. `bwrap` (also used in flatpak) provides all of
   68    -1 that and actually has good UX, so we are up to a promising start.
   -1    71 To run such a container you would basically just need a chroot. Namespaces can
   -1    72 then help to further isolate the container, which is good but not essential.
   -1    73 `bwrap` (also used in flatpak) provides all of that and actually has good UX,
   -1    74 so we are up to a promising start.
   69    75 
   70    76 But then you also need the container itself. And this is where docker makes a
   71    77 comeback: The ideas of images, containers, layers, volumes as well as