This adds three OCI archive format files to the release containing
FreeBSD base images suitable for static linked, dynamic linked and shell
workloads. The shell image also contains pkg-bootstrap and can be easily
extended by installing packages (including pkgbase packages).
Details
Details
- Reviewers
dch cperciva - Group Reviewers
releng - Commits
- rG6686056ca354: release: add optional OCI images
rGd03c82c28da8: release: add optional OCI images
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
This needs buildah and skopeo to be installed into the release chroot. Currently, its setup to build from the /usr/ports if that is present, similar to other tools such as git - this might not be a great idea since buildah and slopeo will pull in go, llvm and openjdk as build dependencies. When testing, I mostly used NOPORTS so that they would be installed using pkg.
Comment Actions
I have a small concern that is under release there are two different concepts using the same name OCI, Oracle Cloud Image/Infrastructure and Open Container Initiative. I am not sure if this really makes people confusing but it seems better if we can avoid this conflict.
| share/man/man7/release.7 | ||
|---|---|---|
| 25 | Don't forget bump the date. :-) | |
Comment Actions
I agree there is the potential for confusion but I do believe that Open Container Initiative pre-dates Oracle Cloud Image. Since there are two common formats for container images, Docker and OCI, it makes sense to keep using OCI in manpage and comments but perhaps the build artifacts could be renamed from oci-foo.txz to container-image-foo.txz?
Comment Actions
Agreed, OCI has become a widespread industry term for "container thingies" like ethernet and xerox... I will rename the Oracle-flavoured OCI_ stuff to ORACLE_ in my diffs/patches.
Comment Actions
Clarify the language around OCI, making clear that this change adds
container images rather than anything Oracle related and renaming the
build artifacts from oci-*.tgz to container-image-*.tgz. Also set the
default command for the minimal shell image to /bin/sh similar to many
Linux distribution base images.
| release/Makefile | ||
|---|---|---|
| 89 | Move this down to line 166 and make it DISTRIBUTIONS+= container-image-${_IMG}.txz. | |
| release/release.sh | ||
| 296 | How much do these packages do? We use bits from the ports tree to build and upload cloudware but I'd prefer to avoid external dependencies as much as possible in the base system build. | |
| release/scripts/make-oci-images.sh | ||
| 1 ↗ | (On Diff #143755) | Can this be split into three scripts, or possibly one script with three configuration files? I prefer "one tool builds one thing" (and that might make the Makefile logic cleaner too). |
| release/release.sh | ||
|---|---|---|
| 392 | I think this can be included in RELEASE_RMAKEFLAGS? | |
| release/release.sh | ||
|---|---|---|
| 296 | The buildah tool is used to build the container images and keeps track of image metadata as well as calculating differences between an image and the one it is derived from. The skopeo tool is used to copy these images to oci-archive format tarballs. Neither tool is used at all in the build process itself, only in creating the container images from pkgbase packages. In theory, it would be possible to create the oci-archive tarballs manually but it would be a lot of work for very little gain (IMO). | |
Comment Actions
I think this looks good
| release/release.sh | ||
|---|---|---|
| 201–203 | Extremely minor nit but I would put WITH_OCIIMAGES after WITH_CLOUDWARE, leaving XZ_THREADS last, seems logical to keep the WITH_ variables together | |
Comment Actions
Thank you, this looks good.
FYI, I was able to replicate it using a custom poudriere image (-t oci not yet submitted) and verify that the size for minimal is OK:
# podman images REPOSITORY TAG IMAGE ID CREATED SIZE ghcr.io/jlduran/freebsd15-minimal latest 55371f41b739 17 minutes ago 42.6 MB docker.io/library/ubuntu latest c22ec0081bf1 3 weeks ago 103 MB docker.io/library/alpine latest c157a85ed455 4 weeks ago 9.11 MB
Comment Actions
Sorry, forgot to actually include my doubts in the discussion.
| release/scripts/make-oci-static.sh | ||
|---|---|---|
| 25 ↗ | (On Diff #144592) | I wonder if these mtree files should be based on ${curdir} instead of the host root? |
| release/scripts/make-oci-static.sh | ||
|---|---|---|
| 25 ↗ | (On Diff #144592) | This is a good question. In the past, I installed FreeBSD-mtree into a temp directory and built the container directory tree from that. For this iteration, since release.sh will typically do a buildworld+installworld first it seemed reasonable to use mtree and other files from the chroot. |
Comment Actions
A few (almost) irrelevant suggestions.
I have tested a bit more with the minimal image. For the use case described here, it works quite well. However, when compiling something from source, I ran into a few issues:
- Missing /usr/lib/libprocstat.so.1 from FreeBSD-utilities (this package pulls in a few dependencies).
- Missing /usr/lib/crt1.o from FreeBSD-clibs-dev (this package is in the top 20 sorted by size).
- Missing /sys symbolic link from pkgbase (irrelevant for this revision).
Overall, the minimal image is good and a welcomed addition towards delivering jails containers straight from the FreeBSD project (hopefully from a fully-owned registry as well as containerized ports packages).
Thanks again!
| release/Makefile | ||
|---|---|---|
| 173 | I do not understand the naming convention? freebsd:latest <-> freebsd:<short-commit-id> <-> freebsd:15 (different tags, same image) freebsd-minimal:latest freebsd-slim:latest freebsd:14.2-RELEASE <-> freebsd:14.2 That is, having the version number after the colon. | |
| release/scripts/make-oci-dynamic.sh | ||
| 4 ↗ | (On Diff #144592) | |
| share/examples/oci/Containerfile.pkg | ||
| 3 | ||
| 19 | ||
| share/examples/oci/Containerfile.pkg | ||
|---|---|---|
| 19 | Sorry, please ignore this suggestion, as it will leave ASSUME_ALWAYS_YES=yes in the environment of the final image. This may not always be desired. | |
Comment Actions
I think what we really want here is a Makefile.oci and oci-release/oci-install targets which get run from the release and install targets in release/Makefile.
| release/Makefile | ||
|---|---|---|
| 169 | Now that I think about it, I don't think we really want these to end up in e.g. https://download.freebsd.org/releases/amd64/14.2-RELEASE/. They should land in https://download.freebsd.org/releases/OCI-IMAGES/14.2-RELEASE/amd64/Latest/ like we do for CI-IMAGES and VM-IMAGES. So putting them into the list of "distributions" doesn't seem quite right. | |
| release/scripts/make-manifest.sh | ||
| 17 ↗ | (On Diff #144592) | Thinking about this a bit more... these aren't really "distributions" in the sense of things users select to include or exclude from the installer. So I'm not sure we need them in this file at all. |
| release/scripts/make-oci-dynamic.sh | ||
| 1 ↗ | (On Diff #144592) | I would prefer to see these as one release/scripts/make-oci.sh file and three release/tools/oci-*.conf files, just for consistency with how we do the VM builds. Would that be possible? |
| release/Makefile | ||
|---|---|---|
| 173 | This is mainly to allow e.g. both freebsd14-minimal:latest and freebsd15-minimal:latest to exist without conflict. | |
Comment Actions
I'll refactor the Makefile changes along these lines.
| release/Makefile | ||
|---|---|---|
| 169 | That makes sense - I'll take a look at how this is done for VM images and try to match that. | |
Comment Actions
Move the OCI image bits to Makefile.oci and don't treat them as distribution artifacts. If enabled, the OCI images are written to ${DESTDIR}/ociimages.
| release/Makefile | ||
|---|---|---|
| 173 | Precisely, isn't the "convention" something like: freebsd-minimal:15, freebsd-minimal:<short-commit-id>, freebsd-minimal:{edge,rolling} It looks like you want to ship a "latest" version for every FreeBSD version? But, this can be revisited post-commit. The main objective is to start producing these images. | |
| release/Makefile | ||
|---|---|---|
| 173 |
The naming is hard, but I'd like to have it more precise. What about freebsd:14.1-p2 freebsd:14.2 freebsd:14 freebsd-minimal:14.1-p2 freebsd-minimal:14.2 freebsd-minimal:14 freebsd:13.4-p5 freebsd:13.4 freebsd:13 for RELEASE versions, and freebsd-stable:14-<short-commit-id> freebsd-stable:14 freebsd-stable-minimal:14-<short-commit-id> freebsd-stable-minimal:14 freebsd-stable:13-<short-commit-id> freebsd-stable:13 for STABLE versions, and freebsd-current:<short-commit-id> freebsd-current:latest freebsd-current-minimal:<short-commit-id> freebsd-current-minimal:latest for CURRENT dev versions ? | |
| release/Makefile | ||
|---|---|---|
| 173 | We typically support two major versions, sometimes three, so having a latest tag for each seems useful. Longer term, we could mark the images with suitable OS version but since this feature is only currently used for Windows, it would require changes to the various container engines - in particular Podman and CRI-O currently ignore this field. | |
Comment Actions
LGTM. We'll need some changes in Makefile.mirrors but I'll take care of that after this goes into the tree.