Date: Sat, 15 Apr 2023 02:13:53 -0700 From: "Pat Maddox" <pat@patmaddox.com> To: questions@freebsd.org Subject: Re: Docker Message-ID: <1d0a7ed1-9330-49df-9b66-9ee4387de511@app.fastmail.com> In-Reply-To: <20230412155252.5e38ea4728bd52dc798852fc@sohara.org> References: <20230329053443.6ADA6B6AFED5@dhcp-8e64.meeting.ietf.org> <8E16D624-2655-4A10-844A-93E4F63E9859@gromit.dlib.vt.edu> <078a1cf8-7ae2-c593-615b-f5f37fa2b3eb@timpreston.net> <CA%2B1FSij9j922Nvv1Vhn43HznwpyGT99UZsU674G9hHWzR=UhvQ@mail.gmail.com> <06be3a1e-9319-1a21-88b9-4f87328ee127@timpreston.net> <CA%2B1FSijc%2B-OLNsyFNdR=jP3VzMi4zUE92i5iv9Pfg6AryDy_KQ@mail.gmail.com> <34b4b76e-1c41-4cfb-9e86-856f01e8abc9@app.fastmail.com> <CA%2B1FSihVrJ8cZ4ZU6mMr0sKJsZ98V4fh2vpDLugw7MGj-%2BEBPg@mail.gmail.com> <CA%2B1FSijL50mQ-HveBA4HZeNkSoaORv=aty-15nNLzn9amzY_nw@mail.gmail.com> <6002f636-310b-a9fd-b82f-346618976983@timpreston.net> <CA%2B1FSigV_pPwVW%2BDd8WZYGcNQVt7%2BYOcsnJFoRhS6jL5A636pg@mail.gmail.com> <20230412150350.12f97eb2c9dd566b8c8702d2@sohara.org> <CA%2B1FSihVPCQ6tp8u=aqnLyyOPpCMrnhYGcC8bCUgRbFHTdY5sA@mail.gmail.com> <1535315680.2770963.1681309684072@mail.yahoo.com> <20230412155252.5e38ea4728bd52dc798852fc@sohara.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 app= lied > to a base image (either an OS image or one defined in a Dockerfile).=20 > > 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 awf= ul lot > of playing catch up. When people advocate for incorporating this aspect of Docker in to FreeB= SD, 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=E2=80=99t want to try to build for every possible comb= ination, so they decide the distro for users as part of the image. It=E2= =80=99s pretty common to skip the package manager completely in that cas= e, and just stuff the binary and config files wherever they feel like th= at day. It=E2=80=99s the one package format that (in theory) works the s= ame 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=E2=80=99s a = > 80% chance you=E2=80=99ve got it right. Run `service start pkg-name` i= n the case of a service and it=E2=80=99s up-and-running. I love this con= sistency - it makes it a lot easier to understand what=E2=80=99s going o= n in a system. DHH popularized the term =E2=80=9Cconvention over configu= ration.=E2=80=9D Well, FreeBSD has extraordinarily strong conventions - = including where to place configuration files! What about distribution? Docker seems to have the upper hand here=E2=80=A6= until you realize that a FreeBSD jail is just a bunch of files on the f= ile system, that the host kernel isolates. You want to distribute a jail= ? Zip it up, and extract it somewhere else. zfs send if you=E2=80=99re f= ancy. If you can do it with files, you can do it with jails. Layer caching is a non-issue to me. I=E2=80=99ve spent as much time re-o= rganizing Dockerfile so it doesn=E2=80=99t build more than I want, as it= has saved me in build time. I don=E2=80=99t deploy to enough servers th= at caching makes an appreciable difference - and the over all complexity= trade off is far worse. As far as third-party support=E2=80=A6 yep, Docker is king here. I absol= utely believe we can, should, and will apply many of the principles from= the Docker ecosystem to FreeBSD. It=E2=80=99s only a matter of time bef= ore someone is sufficiently motivated to design an automated deployment = and scaling system like what=E2=80=99s currently done with Docker. For a= ll we know, there are orgs out there with killer jail deployments that j= ust aren=E2=80=99t talking about it [1]. For me, FreeBSD wins big on operational simplicity. Yes, we don=E2=80=99= t have some of the gadgetry that Docker has. We also don=E2=80=99t have = anywhere near the same kind of financial investment as Docker has had. Y= ou think FreeBSD=E2=80=99s market share is small? Well I think it is rem= arkably high and packs a lot of bang for the buck compared to the enormo= us amounts of money that have been poured into Linux and Docker. Everything I=E2=80=99ve seen of FreeBSD so far - and what strongly attra= cts me to it - is that its user base skews heavily pragmatic, which is r= eflected in its ongoing development and ecosystem. People will continue = to experiment with jails, develop new conventions and techniques for wor= king with them, and share their efforts with others. The useful stuff wi= ll stick around and evolve, same as it has done since the beginning of B= SD. We don=E2=80=99t need Docker=E2=80=99s tools. We can apply some of its p= rinciples. Perhaps most of all, we can see in it many shining examples o= f what NOT to do. Pat [1] Allan Jude has written about deploying system images with ZFS: http= s://papers.freebsd.org/2019/asiabsdcon/jude-managing_system_images_with_= zfs/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1d0a7ed1-9330-49df-9b66-9ee4387de511>