Re: Docker

On Wed, Apr 12, 2023, at 7:52 AM, Steve O'Hara-Smith wrote:
> 	Docker is many things - the UI the least important.
>
> 	Docker is a mechanism for creating container images from text
> descriptions in Dockerfiles each of which defines an overlay to be applied
> to a base image (either an OS image or one defined in a Dockerfile). 
>
> 	A common use for this mechanism is to assemble servers by picking an
> off-the-shelf image with the right service(s) and building a custom
> configuration/application layer on top of it. Rinse, repeat until every
> element of a stack is defined and get swarm or kubernetes to deploy and
> manage it. This use depends strongly on the rich public library of
> application layers. In order to have this in FreeBSD we'd either have to be
> able to use the Linux images directly or we'd need a similar library of
> FreeBSD images (OCI compliant if we want kubernetes) - which is an awful lot
> of playing catch up.

When people advocate for incorporating this aspect of Docker in to FreeBSD, I have to ask: why?

I believe the main points are:

- packaging and distribution
- layer caching
- third-party tool / vendor support.

Docker addresses the proliferation of Linux distros and package managers. Maintainers don’t want to try to build for every possible combination, so they decide the distro for users as part of the image. It’s pretty common to skip the package manager completely in that case, and just stuff the binary and config files wherever they feel like that day. It’s the one package format that (in theory) works the same across all Linux distros.

We, of course, have the ports tree. Install a package, and you can edit the config file with /usr/local/etc/pkg-name<tab> and there’s a > 80% chance you’ve got it right. Run `service start pkg-name` in the case of a service and it’s up-and-running. I love this consistency - it makes it a lot easier to understand what’s going on in a system. DHH popularized the term “convention over configuration.” Well, FreeBSD has extraordinarily strong conventions - including where to place configuration files!

What about distribution? Docker seems to have the upper hand here… until you realize that a FreeBSD jail is just a bunch of files on the file system, that the host kernel isolates. You want to distribute a jail? Zip it up, and extract it somewhere else. zfs send if you’re fancy. If you can do it with files, you can do it with jails.

Layer caching is a non-issue to me. I’ve spent as much time re-organizing Dockerfile so it doesn’t build more than I want, as it has saved me in build time. I don’t deploy to enough servers that caching makes an appreciable difference - and the over all complexity trade off is far worse.

As far as third-party support… yep, Docker is king here. I absolutely believe we can, should, and will apply many of the principles from the Docker ecosystem to FreeBSD. It’s only a matter of time before someone is sufficiently motivated to design an automated deployment and scaling system like what’s currently done with Docker. For all we know, there are orgs out there with killer jail deployments that just aren’t talking about it [1].

For me, FreeBSD wins big on operational simplicity. Yes, we don’t have some of the gadgetry that Docker has. We also don’t have anywhere near the same kind of financial investment as Docker has had. You think FreeBSD’s market share is small? Well I think it is remarkably high and packs a lot of bang for the buck compared to the enormous amounts of money that have been poured into Linux and Docker.

Everything I’ve seen of FreeBSD so far - and what strongly attracts me to it - is that its user base skews heavily pragmatic, which is reflected in its ongoing development and ecosystem. People will continue to experiment with jails, develop new conventions and techniques for working with them, and share their efforts with others. The useful stuff will stick around and evolve, same as it has done since the beginning of BSD.

We don’t need Docker’s tools. We can apply some of its principles. Perhaps most of all, we can see in it many shining examples of what NOT to do.

Pat

[1] Allan Jude has written about deploying system images with ZFS:  https://papers.freebsd.org/2019/asiabsdcon/jude-managing_system_images_with_zfs/