jails Using OCI container images with jails

I was curious to see if it is possible to use the new OCI container images with
standard jail tooling (not podman).

The following script downloads and untars the 14.2 image:

sh:
#!/bin/sh

set -eu -o pipefail

OCI_IMAGE_URL=${OCI_IMAGE_URL:-https://download.freebsd.org/releases/OCI-IMAGES/14.2-RELEASE/amd64/Latest/FreeBSD-14.2-RELEASE-amd64-container-image-minimal.txz}

if [ $# != 1 ]
then
  echo Usage:  ociimagextract.sh /path/to/output/directory
  echo         Default OCI image: $OCI_IMAGE_URL
  echo         To use a different image set OCI_IMAGE_URL:
  echo         OCI_IMAGE_URL=https://other-image-url ociimagextract.sh /path/to/output/directory
  exit 1
fi

TARGET=$1

which jq
if [ $? != 0 ]
then
  echo Could not find jq command
  echo You can install jq using "pkg install jq"
  exit 1
fi

mkdir -p $TARGET
DIR=`mktemp --directory`
fetch -q -o - $OCI_IMAGE_URL | tar -xzvpf - -C$DIR
TOPDIGEST=`cat $DIR/index.json | jq -r .manifests[0].digest | tr ':' '/'`
DIGESTS=`cat $DIR/blobs/$TOPDIGEST | jq -r '.layers[] | .digest' | tr ':' '/'`

for DIGEST in $DIGESTS
do
 cat $DIR/blobs/$DIGEST | tar -xzvpf - -C$TARGET
done

echo jail root filesystem directory created at $TARGET

If you create a minimal jail config in /etc/jails.conf.d/minimal.conf, eg

minimal {
exec.start += "/bin/echo \"while true; do sleep 1d; done\" | /bin/sh &";
host.hostname = "${name}";
path = "/usr/local/jails/${name}";
}


And create the related mountpoint

zfs create -o mountpoint=/usr/local/jails/minimal root/jails/minimal

you can run the above script to download and extract the OCI image contents into a directory

sh ociimageextract.sh /usr/local/jails/minimal

and create the jail with

# jail -c minimal

the jail is pretty small at 16M

# jexec minimal df -h
Filesystem Size Used Avail Capacity Mounted on
root/jails/minimal 55G 16M 55G 0% /


If you add networking to the jail's config you can then add pkg support from inside the jail by running

# /usr/bin/env PACKAGESITE=https://pkg.freebsd.org/FreeBSD:14:amd64/latest /usr/sbin/pkg bootstrap -y

Eg I then installed isc-cron (regular cron wasn't working) with

# pkg install -y isc-cron

(I changed the start to exec.start += "/usr/local/sbin/cron")

So it does seem possible on some level to use the OCI images with regular jails, though
it may only be useful for experimenting.
 
I was wondering the same thing. Very cool.

Warning (this next statement make make you dumber): Not directly down the same path, but possibly on the same track (I think?); I was also thinking about employing `tarfs` in a similar manner. The thought I had was ready made jail containers with preinstalled packages which could be (un)mounted and spun up with jail. i.e., setup, tar it, share it, jail it.

Also, I've been having a hard time "picking up shell script" (brain is probably at capacity) and your script taught me at least two things. So, thank you.
 
Appjail already does all this. It has prebuilt images that can be fetched.

Appjail is very very docker like.
I have to make a pretty big assumption here (because I'm not terribly familiar with all of the jail managers) but I don't think we're speaking about the same thing.

In the traditional sense, "images hosted at XYZ" ... you can already download (fetch) a "thick" tar, extract it, write a jail.conf entry (to /etc/jail.conf or /etc/jail.conf.d/) and run that fetched image with zero dependency on third party tools (because that's what you're doing if you follow the handbook). But that is for a full filesystem, libs, shell, etc..

My 'dumb thought' was that since TARFS is part of the kernel and would require zero dependency (of course, tarfs would be slower) and would mount the "read-only" images instead of "unpacking" them (podman, docker, whatever mange by calling other tools like unpackers, inspectors, copiers, and whatnot). So, my though was about the layers of the container.

static - Base
dynamic - libs and libc
minimal - shell and stuff

That is to say, if you have a statically compiled binary, you could make your own "dynamic" layer (blob) which should be able to run using only the offical static layer (blob) and the statically compiled binarie(s) and libs for the tool/service you create/assemble/package.

See here (the "listing the layers" part draws a nice picture):

Jail managers like AppJail and BSDPot aside; A thick jail is essentailly the "minimal" container (has the 'static', and 'dynamic' layers as well as the 'minimal'). But as I've said, we already have the ability to ship these types of containers around (with zero depencencies--third party tools--already) using nothing but the base install (no jail "manger" required). Tools (managers) like AppJail and BSDPot I believe may even read OCI images, like the 'minmal' I assume, and allow you to create a jail from it (like what speakeasy demonstrated plus the networking and other aspects) but I wasn't really thinking about that part with my 'dumb thought'.
 
I have to make a pretty big assumption here (because I'm not terribly familiar with all of the jail managers) but I don't think we're speaking about the same thing.

In the traditional sense, "images hosted at XYZ" ... you can already download (fetch) a "thick" tar, extract it, write a jail.conf entry (to /etc/jail.conf or /etc/jail.conf.d/) and run that fetched image with zero dependency on third party tools (because that's what you're doing if you follow the handbook). But that is for a full filesystem, libs, shell, etc..

My 'dumb thought' was that since TARFS is part of the kernel and would require zero dependency (of course, tarfs would be slower) and would mount the "read-only" images instead of "unpacking" them (podman, docker, whatever mange by calling other tools like unpackers, inspectors, copiers, and whatnot). So, my though was about the layers of the container.

static - Base
dynamic - libs and libc
minimal - shell and stuff

That is to say, if you have a statically compiled binary, you could make your own "dynamic" layer (blob) which should be able to run using only the offical static layer (blob) and the statically compiled binarie(s) and libs for the tool/service you create/assemble/package.

See here (the "listing the layers" part draws a nice picture):

Jail managers like AppJail and BSDPot aside; A thick jail is essentailly the "minimal" container (has the 'static', and 'dynamic' layers as well as the 'minimal'). But as I've said, we already have the ability to ship these types of containers around (with zero depencencies--third party tools--already) using nothing but the base install (no jail "manger" required). Tools (managers) like AppJail and BSDPot I believe may even read OCI images, like the 'minmal' I assume, and allow you to create a jail from it (like what speakeasy demonstrated plus the networking and other aspects) but I wasn't really thinking about that part with my 'dumb thought'.
Both CBSD and AppJail support OCI images, not just their own formats.
 
Notes from CBSD: thus, OCI are no longer a problem for at least three modern managers: AppJail, CBSD, Pot.

The problem, I think, is different - few people have demonstrated anything more than running `busybox` shell from OCI: we don't have a /large/ library of /native/ OCI images that distribute files in the traditional FreeBSD hierarchy ( described in the official FreeBSD handbook using nullfs ), in addition to full RW + layers. And this is where managers can combine their efforts, since now we have a universal format for exchanging images.
 
speakeasy, I just wanted to reiterate how cool this is. I was doing a bit of playing around with this and I started unrolling this by hand (after I got done creating, playing around, and destroying a jail as per your instructions, of course). Do you happen to know what the other two files are?

My ultimate goal with this play session is/was to create a layer myself and add it in and repack the whole thing up again to see if my container could be used.

At any rate. +1 to you again.

Code:
john[server:sha256]ll
total 11275
     18 Feb  5 19:15 3d7/
 846343 Nov 29 04:35 3d72902df1260817e18ac359deda9bc951af5632f9729ceb24d649fdb54a57fe
     13 Feb  5 19:17 6c3/
6357752 Nov 29 04:35 6c3cf2b1cc8a503f19224274c10fe7840a32f9625b688f9fd8ab7e05c03f1f33
      7 Feb  5 19:18 915/
4279043 Nov 29 04:35 9154eccec9cd47364487f3d87162f771d9946514712bcb27a5e62168fdf587db
    923 Nov 29 04:35 b98b8f5438a07e000a156ecb216529d8dfa191448ac3dc1f6add9848b4461d05
    714 Nov 29 04:35 c5f3e77557a916c124bfb74bdd982efe0a5749aaba9de0d282703d4634b28839
 
Back
Top