macOS with Apple Silicon and x86-64-v3 support

I’m maintaining container images in the OpenNMS ecosystem. My local machine is a Mac with Apple Silicon. While I was upgrading some base images using RHEL UBI 10 / CentOS 10 images, I noticed the following error message.

0.112 Fatal glibc error: CPU does not support x86-64-v3

That happens if you try to run on an emulated x86 architecture running on ARM. After some investigation, I’ve found an article in the Red Hat developer forum talking about upgrading the Microarchitecture level from v2 to v3. The problem introduced is that v3 isn’t supported. I’m using Orbstack and you can reproduce this problem simply running the following docker command.

Mirroring a container registry

I was working on an article How to run an air gap installation of OpenNMS Horizon on Rocky Linux. I ran into a similar use case and it was not about RPMs or DEB packages, it was all about container images and registries. My question was, how can I get “all” container images into a private registry from DockerHub? Getting your hands dirty with a private registry is something I’ve described in Running a private container registry for testing. Here is a short how-to on how I did it for my future self or anyone else with a similar question.

Running a private container registry for testing

When I signed up for my DockerHub account in 2013, I never thought sooner than later everything ends up in a container image as it is today. DockerHub was the first public free as in free beer registry to distribute your container images. Containers are now everywhere, and DockerHub, a corporate entity running and funding DockerHub, introduced usage limits for the free tier and started commercializing its registry service. I need to play with software in a micro-service architecture on a platform like Kubernetes, and these limits can be daunting.

Containers and Capabilities

I have to work with container images from time to time, and sometimes I need to do networking stuff. Of course, you want to do this as an unprivileged user. Especially when you mix and match with Docker or Kubernetes, it gets sometimes a bit tricky and a lot of people in our community including myself struggled on this part. To document it for my future-self and the ones interested – here is my scenario. I need regularly two things when I run OpenNMS tools in containers:

A cookbook for a K8s playground

In my last weeks, I had to work with deployments of OpenNMS with Kubernetes. Instead of spending dollars on cloud providers for my lab, I’ve bought a beefy cheap box for my home network for less than 1.500,-€ about a year ago. It saved me probably already more than I would have spent on similar resources in the cloud for my playgrounds. It has an Intel(R) Core(TM) i9-10880H CPU, 64 GB RAM, and 2 TB SSD which has enough steam to run VMware ESXi on it. The main goal for this lab is, to have something you can quickly ditch into the bin and rebuild from scratch without worrying, and at the beginning of something new, you’ll break it a lot for sure :)

OpenNMS Horizon, Docker, Traefik and Let's Encrypt

I work from home for over 6 years now and especially when you like networking, want to get stuff up and running and breaking it - you start looking around :) You’ve heard about k8s, k{0,3}s or Microk8s but you don’t want to use it to run your private blog and you find yourself in a spot where the benefits running stuff in containers justify the pain - this article might be something for you :)

Docker build and cache invalidation

Right now I’m working with my work mates @opennms integrating the docker image building in our CI/CD environment. We build our container image based on CentOS and we noticed the caching doesn’t work for ${reasons}.

Running a docker build -t myimage . ended up always in installing packages from the official yum repositories even we haven’t changed anything in the Dockerfile.

To understand things better, I went back to drawing board and started with a simple example and rebuilding things step by step to understand when gets the docker build cache unnecessarily invalidated.

Docker, Java, Signals and Pid 1

Running a Java application in a container seems to be very easy. The devil is in the details and I want to shed some light on the PID 1 problem when you run Java applications in containers. Theoretical, processes in containers should not have state so you just don’t care, but reality is different.

Signals are used to message running process to behave in certain ways. A common case is to terminate a process nicely sending a SIGTERM to the process identified by the process id using the tool ps. People can implement logic shutting down an application gracefully. When you issue the command kill <pid> you send a SIGTERM to a process. We have other signals you can use, especially when application provide terminals. Hitting CTRL + C sends SIGINT to the terminal process. Some signals are quite out of time, the signal to hangup SIGHUP comes from terminal applications. It is often used nowadays telling a running process to re-read configurations.