I recently purchased a MacBook Air (M1, 2020) with a broken screen for $150 AUD ($99.51 USD) to replace my home services. Currently, most of these services run inside Docker containers on my aging Netgear ReadyNAS 314.
It's not the first time I've purchased a MacBook Air (M1, 2020) with a broken screen, as my wife has been using one for the past few years as her desktop computer. Her MacBook Air is connected to a hub which also powers it, connects to an external keyboard and mouse, ethernet, and is even connected to a 44" 32:9 ultra wide-screen monitor.
The plan with the new MacBook Air is to have it take over the running the local services that are currently on the RN314, and let the RN314 just be a NAS. The RN314 has a dual core Intel Atom® Processor D2701 running at 2.13 GHz with just 2GB RAM, so it's never been great at handling any extra loads.
I started the process by upgrading the MacBook Air operating system with a clean install of macOS Sonoma, which is the most recent release of macOS at this time. I also installed homebrew, a package manager for macOS.
Homebrew can be installed with the following command:
$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
The MacBook Air contains Apple's M1 CPU which is an AArch64 processor, but most of my Docker containers require an AMD64 instruction set (the RN314's CPU is AMD64). Fortunately, Apple have created a great translator named Rosetta, which allows us to run AMD64 binaries on the M1 CPU at near native speeds.
To install Rosetta 2,
$ softwareupdate --install-rosetta --agree-to-license
I installed Colima, which is a free (as in freedom) replacement for Docker Desktop.
$ brew install colima
To configure Colima, I used the command:
$ colima template --editor nano
There are three variables in the configuration file that need to be modified for Colima to use Rosetta, and they are as follows:
vmType: vz
rosetta: true
mountType: virtiofs
Once I had configured Colima to use Rosetta, I created a LaunchDaemon plist file so that Colima would start on every boot before any users log in. I tested Colima and everything seemed to be running well, although it was a little slower than I had expected. After some probing around, I found that Colima was falling back to using QEMU, an powerful emulator that has been around for a long time, but is no where near as fast as Rosetta.
Why was it so slow? I quickly found a
bug in Colima. If Rosetta isn't running when Colima starts, Colima doesn't believe it's installed and continues loading using QEMU as the fallback.
Rosetta usually starts automatically when a user logs in to macOS via the graphical user interface. As I was using the MacBook Air as a headless device (no monitor), I wouldn't be logging into the computer on each boot, but still needed to be able to have Colima running to access the containers remotely.
I couldn't work out how to start Rosetta manually, but I did notice that when I logged in to the computer via SSH (a remote text based session), I was able to get Rosetta to start by (re-)installing it. This seemed like it might provide me with an easy workaround - I could just have a script re-install Rosetta on each boot. Unfortunately this workaround didn't work from the LaunchDaemon, as the same command provided an error showing that it was unable to install Rosetta.
I did manage to think of a simple workaround after a bit more thought; I created a new (non-admin) user, and set macOS to automatically log in as that user. Once the user logged in, It would run a simple script which would then log the user back out of the system.
That was the magic that was needed! Rosetta would start when our new user logged in, yet it wouldn't stop when they logged out. The logging in and back out happens before Colima starts, so Colima is able to use Rosetta when it starts up.
Now that I had everything working, I decided to hide the user account so that I could pretend it was never there to begin with.
The result is that I can now run AMD64 containers at near native speeds - way faster than I could on the RN314.
Comments
Post a Comment