Up and running with Rancher Desktop and Testcontainers on Apple M3

At Bitso, we are passionate about great open-source software, such as Rancher Desktop and Testcontainers.

We are also committed to giving our engineers the best tools possible, so we are currently rolling out new high-spec M3 laptops across the engineering organisation.

This post covers some interesting issues we encountered testing Bitso’s primary development stack with Rancher Desktop on Apple M3 Silicon.

Summary

• The current Rancher Desktop version (1.12.3) does not work out of the box on Apple M3 due to a bug in QEMU, so you must use VZ emulation
• Using VZ emulation causes a conflict with Cloudflare WARP and other DNS-related tools that expect to bind mDNSResponder on port 53, so needs a workaround
• Testcontainers does not currently work out of the box with Rancher Desktop on any Apple Silicon variants (eg M1, M2, etc.) and requires specific environment variables to be set

Rancher Desktop on M3

Rancher Desktop is an open-source container management application for macOS, Linux, and Windows. It provides a Docker-compatible interface, including support for Docker Compose, so is a viable, free alternative to Docker Desktop for commercial use.

Rancher Desktop is supported on macOS running on either Intel chips with VT-x instructions or Apple Silicon (M1) and has dedicated x64 and ARM64 builds.

Installation and overview

See here for a quick overview of installation, or if you have Homebrew installed, you can just use the rancher cask:

❯ brew install --cask rancher

Note: you will need to uninstall Docker Desktop if you installed it using Homebrew as the casks conflict. Currently Rancher Desktop does not detect other container management applications running.

Rancher Desktop’s basic architecture is an Electron GUI wrapped around several other tools to provide a simplified user experience for container management.

Under the hood, Rancher Desktop uses Lima (LInux MAchines) to provide a Linux virtual machine to run the required software, such as the container daemon (containerd or dockerd) and Kubernetes, if enabled.

Lima, in turn, depends on emulation software to provide the actual hardware virtualisation and offers different VM types depending on the host OS. On macOS, those options are either QEMU or experimental support for VZ, Apple’s native macOS Virtualisation Framework.

Now to the issue…

If you install Rancher Desktop on M3 with the default settings, it will just appear to hang saying “Starting virtual machine”, without the Docker daemon starting:

❯ docker ps
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

The issue with running Rancher Desktop on M3 is caused by an issue in Lima, which in turn is caused by a problem in the bottom layer of these dependencies, QEMU, on M3.

You can see the exception in the logs:

❯ head -5 ~/Library/Logs/rancher-desktop/lima.serial.log

UEFI firmware (version edk2-stable202302-for-qemu built at 17:14:55 on Mar 15 2023)
Error: Image at 0043FD41000 start failed: Not Found


Synchronous Exception at 0x000000043FD37E08

If you’re interested in more detail, the issue threads have a lot more information. Still, until the underlying fix to QEMU makes its way up the chain of dependencies, the workaround for now is not to use QEMU and use the (experimental) VZ emulation instead.

Open the Rancher Desktop Preferences dialog, click Virtual Machine, then Emulation, and click VZ under Virtual Machine Type. You can also select Enable Rosetta support if you want to be able to run Intel images in Rancher Desktop.

Click Apply, which should restart Rancher Desktop with the new settings.

Note: We found that this restart process can be unreliable, and rogue Rancher Desktop processes can be left running, so if things appear to be still not working, quit out of Rancher Desktop completely, then in your terminal, make sure there are no Rancher Desktop processes still running:

❯ ps auxww | grep -i rancher

# kill -9 any rogue Rancher Desktop process IDs

Simply kill — 9 any Rancher Desktop processes still running, then restart Racher Desktop.

Further gotcha with Cloudflare WARP

If you use Cloudflare WARP or any other DNS-related tools that expect to be able to run mDNSResponder on port 53, you may also encounter this issue, where Rancher Desktop causes a conflict by taking over port 53.

The workaround suggested in the issue thread only works when using QEMU emulation, so for M3, where you must use VZ for now, the workaround does not work.

There is no official workaround for this issue currently. Still, you can manually get things working by ensuring that Cloudflare WARP is running and connected first before running Rancher Desktop, which will then pick another port.

Test containers on Apple Silicon

Testcontainers is a powerful open source framework for bootstrapping infrastructure dependencies, such as Postgres databases and Redis caches, for integration tests using containers.

If you try and use Rancher Desktop as a drop-in replacement for Docker Desktop with Testcontainers on Apple Silicon, you may run into this issue and find that Testcontainers can’t connect, giving an error like the Java example below:

Can not connect to Ryuk at localhost:32768
java.net.ConnectException: Connection refused

There is currently no fix for this issue; the exact cause is unknown. However, you can work around it by setting some environment variables mentioned in the issue thread by @jandubois of the Rancher team and documented in the Rancher guides.

The environment variables you must export in your shell vary depending on whether you are running Rancher Desktop with administrative access or not:

With Administrative Access

export TESTCONTAINERS_HOST_OVERRIDE=$(rdctl shell ip a show vznat | awk '/inet / {sub("/.*",""); print $2}')

Without Administrative Access

export DOCKER_HOST=unix://$HOME/.rd/docker.sock
export TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE=/var/run/docker.sock
export TESTCONTAINERS_HOST_OVERRIDE=$(rdctl shell ip a show vznat | awk '/inet / {sub("/.*",""); print $2}')

These environment variables must be exported in your shell before running any builds that use Testcontainers.

That’s it — we hope you found this post useful!