On Wed, Nov 04, 2020 at 04:40:20PM +0200, Tiran Efrat wrote: > thanks for the replies. > Still, it's not clear to me whether there's a container solution (although > i assume you'd mention if there was.). What about VM solution? > thanks, > Tiran.
Let's firstly clarify what we are talking about and then let's look at the problem you are trying to solve by installing Docker. A "container" is just a term people use to describe a combination of Linux namespaces and cgroups. First off, "Docker" is really a misnomer. Nowadays Linux world has a whole bunch of container tools: moby (former Docker), podman, kata containers, cri-o etc. Not all of them are equal, some of them are complete user ecosystems, and some are just "bare" runtimes. There was a tool named "Docker" once with that name and the name really stuck, so people call things "Docker" left and right. Second, there is no such thing as "Linux containers" per se. There are 2 kernel mechanisms: namespaces (allow isolating a process from a the rest of the system, like network namespace, user namespace, pid namespace etc) and cgroups (allow limit resource usage, like cpu, ram, bandwitdh). Combing various combinations of namespaces and cgroups you get "containers". On a low level tools like Docker et al do is manipulate namespaces and cgroups. The design of namespaces is really the opposite to the well known implementations of operating system-level virtualization technologies like FreeBSD/DragonFly Jails and Solaris Zones. For example with jails you start with a completely isolated environment and then you can add different capabilities if necessary. With namespaces you start with non-isolated process (process that shares namespaces with rest of the system) and you unshare namespaces one by one. It does not mean that namespaces are less secure than Jails, it is a different design, more involved, probably harder to get right, but also more flexible. Before Docker it was very hard to use namespaces and cgroups for a regular Linux user. There was no one "Jail" command. There were only some system calls and scattered docs.(Well there was LXC, but not the point) What Docker did(and was first to do it) is provided a very convenient and pretty complete ecosystem to manage namespaces and cgroups, including features like: - scripting container creation (aka Dockerfile) and sharing it as code - sharing compiled images - Dockerhub is a centralized location for sharing images( it is just glorified file server that hosts a lot of tar.gz plus some indexing ) - sharing/re-using images ( FROM clause in Dockerfile ) - nice CLI tool to manage containers and images And it hid deeply notion of namespaces and cgroups, so regular Joes were able to use it without learning what kernel mechanisms make it possible. Writing a dockerfile is not very different from writing a shell script really. It helped widespread adoption of the tool, but with this also created a lot of misconceptions too. One can argue that "Docker" is too bloated and is not really secure. Yes, it is partially true: - it makes some choices about how namespaces and cgroups are used, maybe not the way YOU want. - It is also a pretty big codebase in Go, that YOU did not audit and which is not really necessary if you want to manage things manually and customize to you needs. - Yes, re-using images from the Internet also introduces lots of risks. - And yes, big army of regular Joes who don't know how the tool works allows misuse, miscofiguration etc. Now let's see what problem were you trying to solve by using the Docker? Ah, you were trying to install complicated suite without really understanding how all pipes fit together. Bad idea! Or are you trying to run software requiring specific Ubuntu libraries on DragonFly BSD or even on on Red Hat? Guess what? Your Docker image had to be build of the Red Hat image or even better starting with Alpine Linux image which uses musl instead of glibc. No, those Ubuntu libraries will never run on Red Hat let alone on DragonFly BSD. Cheers, Predrag
