Technological advantages over Linux

Tim Preston tim at timpreston.net
Wed Feb 19 16:02:09 UTC 2020


I apologize for the slow reply. Responses inline:

On Mon, 17 Feb 2020, at 8:42 PM, Ihor Antonov wrote:
> On 2020-02-17 09:47, Tim Preston wrote:
> > 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.
> 
> Yes, this is a known problem. For reasons unknow to me (could be
> technical limitation back when docker started) docker daemon was not
> performing UID mapping, so that root
> UID inside container (0) was also same UID outside containers, which
> created all sorts of problems. Docker now allow to do that, but the
> feature is not default
> 
> https://docs.docker.com/engine/security/userns-remap/
> 
> Newer tool - podman - offers rootless containers feature and perform this
> by default. Podman got rit of privileged daemon process, so that now
> entire container tooling runs in user namespace. And so it has to do
> UID/GID mapping between parent/child namespaces,
> 
> This is a step in right direction since now joes don't need root
> privileges to work with container tooling. 
> 
> Can you create jails in FreeBSD as non-root user and have root inside
> jail?
> 

That’s a good question. I haven’t looked into it, maybe someone else knows?

> 
>  Initial design of docker has a flaw, that
> was necessary back then, but not anymore - it has a privileged daemon
> running, listening on a socket for commands from CLI tool.
> 
> 
> > 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.
> 
> While this is probably true, I never encountered this issue myslef. And
> if software requires specific kernel settings - does jail solve this
> problem better? (I don't know if there are per-jail sysctl configs..)
> 

I don’t think this is a container problem, but rather a problem of running images created on a different host.

> > 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.
> 
> Pre-build images can emerge as inevitable need to speed up build
> process. If your recepie(dockerfile) relies on another recipie and that
> one relies on another - it could take A LOT of time to build all the
> layers you rely on. 
> 
> Basically docker "image" is just collection of layers. 
> When you work on the dockerfile and
> rebuild it regularly - you don't want to rebuild parts that have not
> changed. And so docker came up with the idea of image layers. Each
> command in Dockerfile creates a layer. And if you did not touch that
> specific line in dockerfile - layer will be re-used
> When you are finished - your "image" is just a resulting set of layers.
> (overly simplified, but the gist of it) 
> 
> And since linux folks did not have proper COW file system(ZFS) they had 
> to
> invent things like overlayfs to quickly take snapshots of the image - 
> because simply
> gziping the image every time somethig chages there was VERY SLOW.
> 
> Dockerhub also stores all the layers, because it appers to be
> storage-efficient, since many images can have shared layers.
> 
> So as much as I am with you on 
> > hope that an 'image' model isn't implemented 
> I see it as inevitable result of ecosystem development... unless a
> radically different approach is taken towards solving "long build times"
> problem.
> 

I wonder how much of the long build time problem was created by introducing images and layers? I’ve only just started using jails but I haven’t seen this problem in FreeBSD. As far as I know the longest step is downloading a release to base your containers on. 

In ezjail, for example, you can update all dependent jails by updating the base jail once. In Docker, updating the base image would mean rebuilding all dependent images, since a change in one layer means rebuilding all higher layers.

Docker was important because it paved the way for wide scale kubernetes adoption. But to answer the original question, no I don’t think Linux has any technological advantages over FreeBSD in regard to containerization. Outside of the ephemeral, horizontally scalable container use-case I think that jails are more useful.


More information about the freebsd-questions mailing list