Date: Mon, 17 Feb 2020 09:47:11 +0100 From: "Tim Preston" <tim@timpreston.net> To: freebsd-questions@freebsd.org Subject: Re: Technological advantages over Linux Message-ID: <8a9a33b3-4eb1-419c-a9e3-fca4db430619@www.fastmail.com> In-Reply-To: <mailman.19796.1581888762.21075.freebsd-questions@freebsd.org> References: <mailman.19796.1581888762.21075.freebsd-questions@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thank you Ihor, this is a great summary. On thing I'd like to mention regarding Docker is the inherent abstraction leakage around pre-built images as they tend to be tied to the host they were built on. For example, I've seen quite a few images in Docker Hub with a hardcoded UID which causes file permissions issue when mounting a volume from the host. Or often authors just assume you'll run the container as root. Another is a mismatch of kernel versions or capabilities between image build host and your host, for example, Redis usually needs Transparent Huge Pages to be turned off in the kernel. It's for these reasons (and the previously mentioned security risks) I'd hope that an 'image' model isn't implemented for FreeBSD jails. Recipes to build jails are a much better idea, as per iocage and Bastille. On Sun, 16 Feb 2020 13:32:29 -0800, Ihor Antonov <ihor@antonovs.family> wrote: > > > I've been reading this tread for a while, and now I can't help but to > add my 2 cents: > > I am long-time Linux sysadmin/devops and I work with "docker" on a daily > basis. Reading this thread I got an impression that a lot of folks on > BSD side have vague/wrong/incomplete understanding of Linux containers > so I want to introduce more structure into this topic. > > 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 jails. With > jails you start with a completely isolated environment and then you can > add different capabilites 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. (I can't compare resource > limiiting part as I am not familiar with how it is done on FreeBSD) > > It does not mean that namespaces are less secure than jails, it is a different > design, more involved, probably harder to get righ, 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 fileserver that hosts a lot of tar.gz + some indexing ) > - sharing/re-using iamges ( FROM clasue 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 golang, 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. > > But if you understand how it kerlnel works and when you understand your > requirements it is becomes pretty easy to find a proper solutoin. > > > Now coming to jails. jail is pretty low level tool. It should not be > compared to "docker". It can be compared to namespaces though. > > I think it would be more productive to compare capabilities of ecosystems. > - Can you securely sandbox the process with jails or namespaces? > - Can you easily script sanbox creation? > - Can you share/re-use recepies or built images? > - What tools provides more control and what provides more productivity > insread? > - etc... > > Where FreeBSD can improve IMHO is building ecosystem tools around > jails. IOCage and > Bastile are good projects, doing the right thing. But there are still > little to none ways to re-use/share images and build recepies > (AFAIK BasitleBSD is working in that direction). Some might argue that > BSD community does not need those - could be. > > > I use docker for things that are not very important on machines that > > are (relatively) unimportant. I would never use it on something like a > > mail server or web server that has other people?s data on it. > > Yes, use bubblewrap instead - really inspired by jails, minimal, > oriented for maximum security. https://github.com/containers/bubblewrap > > > ------------ > Ihor Antonov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8a9a33b3-4eb1-419c-a9e3-fca4db430619>