Date: Mon, 17 Feb 2020 11:42:07 -0800 From: Ihor Antonov <ihor@antonovs.family> To: Tim Preston <tim@timpreston.net> Cc: freebsd-questions@freebsd.org Subject: Re: Technological advantages over Linux Message-ID: <20200217194207.rxmcomsn4jvmoc7c@sea-ll-10936> In-Reply-To: <8a9a33b3-4eb1-419c-a9e3-fca4db430619@www.fastmail.com> References: <mailman.19796.1581888762.21075.freebsd-questions@freebsd.org> <8a9a33b3-4eb1-419c-a9e3-fca4db430619@www.fastmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? 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..) > 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. ------------ Ihor Antonov > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200217194207.rxmcomsn4jvmoc7c>