Date: Wed, 19 Feb 2020 17:00:58 +0100 From: "Tim Preston" <tim@timpreston.net> To: "Ihor Antonov" <ihor@antonovs.family> Cc: freebsd-questions@freebsd.org Subject: Re: Technological advantages over Linux Message-ID: <20aa26cd-4b39-4724-a444-30b902dfadd4@www.fastmail.com> In-Reply-To: <20200217194207.rxmcomsn4jvmoc7c@sea-ll-10936> References: <mailman.19796.1581888762.21075.freebsd-questions@freebsd.org> <8a9a33b3-4eb1-419c-a9e3-fca4db430619@www.fastmail.com> <20200217194207.rxmcomsn4jvmoc7c@sea-ll-10936>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > >=20 > > 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. >=20 > > 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. >=20 > 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 >=20 > https://docs.docker.com/engine/security/userns-remap/ >=20 > Newer tool - podman - offers rootless containers feature and perform t= his > 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, >=20 > This is a step in right direction since now joes don't need root > privileges to work with container tooling.=20 >=20 > Can you create jails in FreeBSD as non-root user and have root inside > jail? >=20 That=E2=80=99s a good question. I haven=E2=80=99t looked into it, maybe = someone else knows? >=20 > 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. >=20 >=20 > > Another is a mismatch of kernel versions or capabilities between ima= ge > > build host and your host, for example, Redis usually needs Transpare= nt > > Huge Pages to be turned off in the kernel. >=20 > While this is probably true, I never encountered this issue myslef. An= d > if software requires specific kernel settings - does jail solve this > problem better? (I don't know if there are per-jail sysctl configs..) >=20 I don=E2=80=99t 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. >=20 > Pre-build images can emerge as inevitable need to speed up build > process. If your recepie(dockerfile) relies on another recipie and tha= t > one relies on another - it could take A LOT of time to build all the > layers you rely on.=20 >=20 > Basically docker "image" is just collection of layers.=20 > 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)=20 >=20 > And since linux folks did not have proper COW file system(ZFS) they ha= d=20 > to > invent things like overlayfs to quickly take snapshots of the image -=20= > because simply > gziping the image every time somethig chages there was VERY SLOW. >=20 > Dockerhub also stores all the layers, because it appers to be > storage-efficient, since many images can have shared layers. >=20 > So as much as I am with you on=20 > > hope that an 'image' model isn't implemented=20 > I see it as inevitable result of ecosystem development... unless a > radically different approach is taken towards solving "long build time= s" > problem. >=20 I wonder how much of the long build time problem was created by introduc= ing images and layers? I=E2=80=99ve only just started using jails but I = haven=E2=80=99t seen this problem in FreeBSD. As far as I know the longe= st step is downloading a release to base your containers on.=20 In ezjail, for example, you can update all dependent jails by updating t= he base jail once. In Docker, updating the base image would mean rebuild= ing all dependent images, since a change in one layer means rebuilding a= ll higher layers. Docker was important because it paved the way for wide scale kubernetes = adoption. But to answer the original question, no I don=E2=80=99t think = Linux has any technological advantages over FreeBSD in regard to contain= erization. Outside of the ephemeral, horizontally scalable container use= -case I think that jails are more useful.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20aa26cd-4b39-4724-a444-30b902dfadd4>