Date: Thu, 15 Apr 2021 05:02:07 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 254645] Build and publish official OCI images for FreeBSD releases Message-ID: <bug-254645-227-YvxrLuLyKt@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-254645-227@https.bugs.freebsd.org/bugzilla/> References: <bug-254645-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254645 --- Comment #5 from Samuel Karp <freebsd@samuelkarp.com> --- (In reply to Mateusz Kwiatkowski from comment #0) Hi Mateusz! > I wanted to start discussion about providing official OCI images by FreeB= SD project and publishing them in one of public registries (eg. Docker HUB). I think this is a great idea! While runj (which you referenced) is a perso= nal project, my day job is very container-centric and I have a few suggestions here. Docker, Inc. sponsors an "Official Images" program that publishes images to Docker Hub. The program is managed on GitHub [1] and would enable a FreeBSD developer to be in control of the images. The advantage of going through t= he "Official Images" program is the use of a short name that most of the conta= iner ecosystem will recognize (for example, "docker pull debian" implicitly pulls the "Official Image" of Debian located at docker.io/library/debian [2]; Fre= eBSD could have the "freebsd" short name). Docker Hub also supports "organizations" (similar to GitHub organizations);= the FreeBSD project could potentially get the "freebsd" organization, though it appears to be already taken by an inactive account [3]. In my day job at Amazon I work alongside the Amazon ECR team, who maintains= a public registry [4]. Like Docker Hub, Amazon ECR Public allows for friendly names associated with an AWS account and for verified publishers. I use a friendly alias with the image I published [5] and the FreeBSD project could have the "freebsd" alias. (In reply to Luca Pizzamiglio from comment #2) > AFAIK, zfs is supported (it would be ideal) Hi Luca! containerd has a zfs snapshotter [6] which works on Linux, but I h= ave not yet tried it on FreeBSD. > one important information that FreeBSD OCI images should have is the os.v= ersion, to enforce proper check on jails and host messages. I'm still new to FreeBSD, so my apologies for asking a stupid question. Is there a requirement that a FreeBSD userland program is built to run on a particular version of FreeBSD? Do the kernel or syscall interfaces change between versions? The Windows container images use os.version to indicate compatibility as Windows does require the container images to correspond with the underlying host. (In reply to Mateusz Kwiatkowski from comment #3) > Yes, we can put whatever is needed for runtime to validate images. I crea= ted minimal draft of runtime spec for FreeBSD for my needs I believe Luca was referring to the image spec [7], which already includes os.version in the index platform object. I'm generating OCI images [8], but not currently including os.version. > FreeBSD specific subtree of schema For the runtime config, agreed! I'd be happy to collaborate on this with y= ou. Thanks! Sam [1] https://github.com/docker-library/official-images/ [2] https://hub.docker.com/_/debian [3] https://hub.docker.com/u/freebsd [4] https://docs.aws.amazon.com/AmazonECR/latest/public/public-repositories.html [5] https://gallery.ecr.aws/samuelkarp/freebsd [6] https://github.com/containerd/zfs [7] https://github.com/opencontainers/image-spec [8] https://github.com/samuelkarp/runj/blob/main/demo/rootfs.go#L102-L152 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-254645-227-YvxrLuLyKt>