An introduction to OCI Containers on FreeBSD

  • Thread starter Thread starter Mark Phillips
  • Start date Start date
M

Mark Phillips

Guest
Original article here.
Consider this when replying.

I doubt you’ve been living under a rock for at least the last decade, so I won’t explain containers for you. I will, however, mention what the Open Container Initiative (OCI) is, since FreeBSD has just become a part of it. Quoting from their own website:

“The Open Container Initiative (OCI) is a lightweight, open governance structure for the express purpose of creating open industry standards around container formats and runtimes.

Excellent. To work within this structure, we’re going to need a tool. Enter Podman:

Podman is a fully featured container engine that is a simple daemonless tool. Podman provides a Docker-CLI comparable command line that eases the transition from other container engines and allows the management of pods, containers and images

There’s our ground rules set. Let’s see if Podman’s use of the word ‘simple’ matches the promise.

Installation and setup​


I’m starting here from a fresh, clean, installation of FreeBSD 15.0-BETA3, but I’ve also tested this on the current stable release, 14.3, and it’s all the same. Let’s install the required packages:


# pkg install -y podman-suite

Podman will by default store containers in /var/db/containers, so you might like to create a dedicated ZFS filesystem for that:


# zfs create -o mountpoint=/var/db/containers zroot/containers

If we want to access any services running in a container, we’re going to need the pf firewall. The podman package contains an example configuration, which makes life easy for us:


Code:
# cp /usr/local/etc/containers/pf.conf.sample /etc/pf.conf
# sysctl net.pf.filter_local=1

Don’t forget to update the interface variables in that copied file, before you enable and start the pf service. Naturally, if you’re already running pf, and you already have a config file in place, don’t just copy this file over. Just pick the relevant bits from it and add to your existing config.


Code:
# service pf enable
# service pf start

If we want to make use of any Linux-based containers, we’ll also need to enable the Linux service:


Code:
# service linux enable
# service linux start

We’re ready to go. Let’s try a FreeBSD container (here we’re a normal user, so we’ll have to use privilege escalation as podman currently needs to be root — my preference is doas; it’s small and simple):


Code:
$ doas podman run ghcr.io/freebsd/freebsd-runtime:14.3 freebsd-version
14.3-RELEASE

That was easy! Let’s test a Linux container:


Code:
$ doas podman run --rm --os=linux docker.io/alpine cat /etc/os-release | head -1
NAME="Alpine Linux"

Again, that was really easy.


You can find FreeBSD OCI images on GitHub and Docker Hub. But we imagine many people will want to consume Linux images.

Testing something useful​


I heard about Caddy a while ago, whilst discussing a massive multiplayer online gaming service with a FreeBSD-based business (that’s a whole other interesting story, for another time). A cursory look tells me it’s probably a really easy way to serve a website, securely, in a container. So I tested this theory with a Hugo-generated static site — simply serving up the public folder.


$ doas podman run --os=linux -p 80:80 -v $PWD/website:/usr/share/caddy -v caddy_data:/data docker.io/caddy
running-caddy-1024x721.png


Wow, that was easy!

What’s in it for me?​


As well as enabling containers for existing FreeBSD users, Podman is about to introduce a whole raft of new users to FreeBSD. We’ve aslready been seeing a large uptick in new users visiting the YouTube channel and Subreddit, looking to build their digital worlds on the reknowned simplicity and reliability of FreeBSD. ZFS FTW
💪



So, it intrigued me to try a somewhat esoteric challenge. Many years ago, I put a container onto Docker Hub. Python Pandas, on a CentOS foundation. Could I run this container on my shiny new OCI FreeBSD server?


doas podman run -it --os=linux docker.io/phips/pandas:v3 /bin/bash
running-old-pandas-1024x721.png


Yes! Amazing! So there’s an answer for migrating old workloads to a new platform.

Quick and easy​


There we have it. It’s easy and fast to get containers up and running on FreeBSD. Also, it’s really simple to consume aging containers — a path to migrate an underlying platform to a well-engineered, rock-solid operating system.


The FreeBSD handbook will be updated soon with proper documentation for OCI containers, but in the meantime you can peruse current Core member Dave Cottlehuber’s working documentation here.


We’re dropping new posts — and videos — for technical topics regularly. So make sure you’re subscribed to the YouTube channel and following this feed in your favorite RSS reader. There’s also the newsletter, if you’d like to receive updates by email.


We’d like this content series to be interactive too — so what would you like to see us cover? What FreeBSD questions can we help you tackle? Get in touch with your ideas.


The post An introduction to OCI Containers on FreeBSD first appeared on FreeBSD Foundation.

Continue reading...
 
Does it mean that it is possible now to run any Linux docker container on FreeBSD without a bhyve? Are there any downsides? I have never used docker containers, but I see that many projects tend to provide docker container with missing or old documentation how to do without docker. So it may be needed in the future.


How does it fit together with jails?
 
Does it mean that it is possible now to run any Linux docker container on FreeBSD without a bhyve? Are there any downsides? I have never used docker containers, but I see that many projects tend to provide docker container with missing or old documentation how to do without docker. So it may be needed in the future.


How does it fit together with jails?
You can run Linux containers, yes. Not any. Just the ones that doesn't rely on exotic Linuxisms that aren't yet present in the Linuxulator.

And it's Jails all the way down.
 
This is cool. I created some test container images based on ghcr.io/freebsd/freebsd-runtime:14.3. Running Apache Tomcat inside container works great. But when trying put PostgreSQL into container things fail, because jail that is created by podman does not have sysvshm=new set:

Code:
 FATAL:  could not create shared memory segment: Function not implemented

Any ideas how that should be done ?
 
This is cool. I created some test container images based on ghcr.io/freebsd/freebsd-runtime:14.3. Running Apache Tomcat inside container works great. But when trying put PostgreSQL into container things fail, because jail that is created by podman does not have sysvshm=new set:

Code:
 FATAL:  could not create shared memory segment: Function not implemented

Any ideas how that should be done ?
Does it work with `--ipc=host` being passed to `podman run` ?
 
Nope.
Code:
Error: OCI runtime error: ocijail: filesystem error: in create_directory: Operation not supported ["/var/db/containers/storage/zfs/graph/9e7436cf3bc3a745320f1adf4c384a84b385884993e268982cc008d05964f157/dev/shm"
 
These are not linux containers, but native FreeBSD ones. My whole idea is to do this natively, without any linux compat stuff.
 
If anyone else is insterested in running *FreeBSD native* PostgreSQL in podman container, this issue describes how to do it (for now):

- create a hook configuration file to run script in createRuntime phase
- modify the script in issue so that sets sysvshm=new (instead of allow.mlock)
 
I noticed that many docker containers use s6-overlay thing which provides s6 as init replacement (and more).
Unfortunately, the silly thing insists on running as PID 1.
As I understand, Linux containers can / do have separate PID spaces while on FreeBSD we do not have that, jails share the global PID space.
So, nothing else besides the true init in the "jail zero" can have PID 1.
As a result, even simplest docker/Linux containers are broken if they use s6-overlay.

Maybe there is a solution to this but I couldn't find it.
Maybe we could compile our own version of patched s6-overlay-helpers and make it available as an additional overlay that could be applied to a container.

References:
 
Back
Top