My previous blog article was about some findings and learnings I got with podman, a daemonless container engine. With podman we are able to run commands like: podman pull|push|tag|run|images|ps and many others (podman help) without any Docker Daemon installed. And again, at the end of the day, if you are comfortable with that, you could uninstall Docker and do this: alias docker=podman.

Now what about building your own OCI Container images? If you would like to successfully run the command podman build, you will need to install buildah too.

Logo of buildah.

Image taken from here

Installing buildah

You could follow those instructions to see how to install buildah. In my case below I will install buildah on Ubuntu 18.04. Since I already setup the Release.key part by previously installing podman, I just need to run:

sudo apt-get update -qq 
sudo apt-get -qq -y install buildah

Note: if you are using the RUN command in your Dockerfile, you will need to install runc too: sudo apt-get -qq -y install runc.

Building and running an OCI Container Image with buildah

Now let’s build our first OCI container image, first of all we need a Containerfile (we will keep the notion of Dockerfile since it works with buildah/podman too):

Let’s have this Dockerfile:

FROM busybox:latest
CMD ["date"]

And then run this command:

podman build -t date .

If you run podman images, you should see:

REPOSITORY     TAG    IMAGE ID     CREATED     SIZE
localhost/date latest 022bdd32ce0e 8 hours ago 1.44 MB

Now let’s run this Container Image by running this command: podman run date, you should get this kind of output:

Sun Feb  2 02:01:34 UTC 2020

Reminder: if you are running this in WSL2, you should use:

  • podman --cgroup-manager=cgroupfs --events-backend=file build instead of podman build
  • podman --cgroup-manager=cgroupfs --events-backend=file run instead of podman run

To go further, I also gave a try to building “more complex” Container images with NodeJS, PHP, Golang and .NET Core containerized app, for this I leveraged this Azure/phippyandfriends repository. The command podman build has worked like a charm with them! ;)

Note: when I built the .NET Core app (parrot), I got these warnings:

STEP 6: RUN dotnet publish -c Release -o out
ERRO\[0234\] Can't add file /var/lib/containers/storage/overlay/5dba96836efb5e2cfe45ae7c9a711a8db5e0805bd88ba7af5b83b044fe184d65/diff/tmp/CoreFxPipe\_root.b5he0\_wwfcD\_lH7g471Brpw4X to tar: archive/tar: sockets not supported
ERRO\[0235\] Can't add file /var/lib/containers/storage/overlay/5dba96836efb5e2cfe45ae7c9a711a8db5e0805bd88ba7af5b83b044fe184d65/diff/tmp/dotnet-diagnostic-52-766545-socket to tar: archive/tar: sockets not supported
ERRO\[0235\] Can't add file /var/lib/containers/storage/overlay/5dba96836efb5e2cfe45ae7c9a711a8db5e0805bd88ba7af5b83b044fe184d65/diff/tmp/dotnet-diagnostic-76-766850-socket to tar: archive/tar: sockets not supported
ERRO\[0235\] Can't add file /var/lib/containers/storage/overlay/5dba96836efb5e2cfe45ae7c9a711a8db5e0805bd88ba7af5b83b044fe184d65/diff/tmp/hn2K8eq8bHUcTVSgvuckPlSK9tw9\_ORiMDm\_Vn4ylfI to tar: archive/tar: sockets not supported

The Container image is built successfully and we are even able to successfully run this Container. So not sure what’s the impact of this. Maybe that’s related to this open buildah’s issue.

With that said, here are some differences in term of Container Images size:

  • parrot (.NET Core)
    • With Docker: 117 MB
    • With podman/buildah: 117 MB (same size)
  • captainkube (Golang)
    • With Docker: 43.7 MB
    • With podman/buildah: 43.6 MB (-0.1 MB)
  • phippy (PHP)
    • With Docker: 427 MB
    • With podman/buildah: 388 MB (-39 MB)
  • nodebrady (NodeJS)
    • With Docker: 92.8 MB
    • With podman/buildah: 101 MB (+8.2 MB)

Interesting…

Pushing an OCI Container Image in Container Registry

I won’t go through the commands pull|push I presented in my previous blog article with podman, but I was able to successfully push the date image in my DockerHub as well as in an Azure Container Registry (ACR).

In ACR, the icon of your Container image type will differ like you could see on the image below, on your left an image built with Docker and on your right an image built with podman/buildah:

Docker container image icon versus Buildah container image icon on the Azure portal.]

Since I’m using Azure Security Center (ASC) to scan my Container images in ACR, I found out that for now there is an issue (“Scan error” without any details information) meaning that is not yet supported (I reached out to the Product Group Team, will see what they’ll say):

Container images built with buildah appear as “Scan error” on the Azure portal.

Deploying an OCI Container Image on AKS

Now what about running an OCI Container Image on Kubernetes, let’s try this out on Azure Kubernetes Service (AKS). Let’s run kubectl run date --image mabenoit/date. If you do kubectl get pod then, you will see that your pod has the status ImagePullBackoff. By doing a kubectl describe of this pod, you will find in the Events section this error:

Failed to pull image "mabenoit/date": rpc error: code = Unknown desc = Error response from daemon: mediaType in manifest should be 'application/vnd.docker.distribution.manifest.v2+json' not ''.

Depending on which version of Docker/Moby your are running as the CRI of your Kubernetes cluster you may get this issue. AKS is using its own Moby version based on the upstream version, currently the Azure Moby version is 3.0.8 corresponding to Docker 19.03.4. You could find out with the mentioned issue that’s fixed in Docker 19.03.5, which corresponds to Azure Moby version 3.0.9. Before getting this version in AKS, we will need to have this recent AKS-Engine’s PR packaged in a new version/release of AKS-Engine, which then will be integrated in AKS. Looking forward to it!

Further considerations and resources

Hope you enjoyed those findings and learnings about podman and buildah, really promising!

Cheers!