Linux-Container auf einem Cloud-Mac: iOS- und Backend-CI mit Colima verbinden

In eurem Repository liegen ein iOS-App-Projekt und der zugehörige Backend-Service gemeinsam: Das Backend startet über docker-compose eine Datenbank, eine Message Queue und mehrere Microservices, und die Integrationstests müssen sich real mit diesen Containern verbinden, um überhaupt laufen zu können. Für den iOS-Teil habt ihr bei HireVPS einen Cloud-Mac-mini für Xcode-Builds gemietet, und das läuft auch reibungslos – bis ihr die CI dazu bringen wollt, auf derselben Maschine gleich noch die Backend-Integrationstests mitlaufen zu lassen. Dann stellt sich heraus: Auf Apple Silicon gibt es keinen nativen Linux-Kernel, und docker run bricht sofort mit der Meldung ab, dass kein Daemon gefunden wurde. Das ist kein Konfigurationsproblem, sondern ein architektonisches: Docker läuft auf macOS von Anfang an nur "untergeschoben".

Szenario: Warum auch auf einem Cloud-Mac Linux-Container laufen müssen

Monorepos werden immer üblicher, und ein einzelner PR ändert oft gleichzeitig iOS-Client und Backend-Schnittstelle – wer nur die iOS-Seite testet, entdeckt Protokoll-Inkompatibilitäten schlicht nicht. Die ideale Pipeline sieht so aus: Auf demselben Runner wird zuerst mit Xcode gebaut und der Unit-Test-Lauf ausgeführt, danach werden die über docker-compose definierten Backend-Abhängigkeiten hochgefahren, eine Runde Ende-zu-Ende-Integrationstests durchlaufen und am Schluss ein einheitliches Ergebnis gemeldet. Der Vorteil liegt auf der Hand: Ihr müsst keine zwei getrennten CI-Umgebungen pflegen und auch keine Netzwerk-Policy-Löcher für maschinenübergreifende Kommunikation öffnen. Voraussetzung ist nur, dass dieser Cloud-Mac Linux-Container ausführen kann.

Auf Apple Silicon gibt es keinen nativen Linux-Kernel – jede Lösung, die "Docker ausführt", startet im Kern zunächst eine versteckte Linux-VM. Wie gut das performt, hängt praktisch vollständig davon ab, wie viel CPU und Arbeitsspeicher dieser VM zugewiesen werden.

Vorbereitung: eine leichtgewichtige Virtualisierungslösung wählen

Auf macOS führen im Wesentlichen zwei Wege zu containerisierten Workloads: Docker Desktop und Colima (in Kombination mit der nativen docker-CLI). Beide setzen im Hintergrund auf Apples Virtualization.framework und starten eine schlanke Linux-VM – der Unterschied liegt in der Erscheinungsform und im passenden Einsatzszenario.

Docker Desktop vs. Colima im Vergleich

Für CI, die auf einem unbeaufsichtigten Runner läuft, ist Colima klar die passendere Wahl: Es benötigt keine grafische Session, lässt sich per Shell-Skript mit einem einzigen Befehl hochfahren und nach dem Lauf wieder beenden – so bleiben keine verwaisten Prozesse im Speicher hängen.

Installation und Ressourcenzuteilung

Auf dem Cloud-Mac-mini installiert ihr die Toolchain zunächst per Homebrew:

brew install colima docker docker-compose docker-buildx

colima start \
  --cpu 4 \
  --memory 12 \
  --disk 60 \
  --vm-type=vz \
  --mount-type=virtiofs

docker context use colima
docker compose -f docker-compose.ci.yml up -d --wait

--vm-type=vz nutzt Apples natives Virtualisierungs-Backend (deutlich schneller als der ältere QEMU-Modus), und --mount-type=virtiofs bringt die Lese-/Schreibgeschwindigkeit des in Container gemounteten Projektverzeichnisses nahe an lokale Festplattenleistung heran. Lässt man diese beiden Parameter weg, büßt man merklich an Build-Geschwindigkeit und Datei-I/O ein.

Für die Ressourcenzuteilung gibt es keine Universalformel, aber einen brauchbaren Ausgangspunkt: Reserviert der Colima-VM 50–70 % des Host-Arbeitsspeichers und etwa die Hälfte der CPU-Kerne für Xcode-Builds. Als Orientierung nach Gerätespeicher lässt sich grob so starten (die tatsächlich verfügbaren Konfigurationen prüft ihr am besten im Control Panel):

Laufen Xcode-Build und Colima gleichzeitig, führt eine zu großzügige Speicherzuteilung dazu, dass sich beide gegenseitig ins Swapping treiben – die Build-Zeit verlängert sich dann sogar. Diesen Sweet Spot solltet ihr vor der eigentlichen CI-Einbindung durch mehrere komplette Pipeline-Läufe kalibrieren.

CI-Integration: den self-hosted Runner mit Linux-Containern vertraut machen

Handelt es sich beim Runner um einen self-hosted GitHub-Actions-Runner, genügt es, im Job einen Schritt zum Starten von Colima einzufügen, die Tests laufen zu lassen und anschließend aufzuräumen – zusätzliche Service-Container-Deklarationen braucht es nicht:

jobs:
  hybrid-ci:
    runs-on: [self-hosted, macos, cloud-mac]
    steps:
      - uses: actions/checkout@v4
      - name: Xcode build & unit test
        run: |
          xcodebuild -scheme App -destination "platform=iOS Simulator,name=iPhone 15" test
      - name: Bring up backend containers
        run: |
          colima start --cpu 4 --memory 12 --vm-type=vz --mount-type=virtiofs
          docker compose -f docker-compose.ci.yml up -d --wait
      - name: Integration tests
        run: ./scripts/run-integration-tests.sh
      - name: Teardown
        if: always()
        run: |
          docker compose -f docker-compose.ci.yml down -v
          colima stop

Der Schritt if: always() ist entscheidend: Auch wenn Tests fehlschlagen, müssen Container und VM heruntergefahren werden – sonst sammeln sich auf einem dauerhaft gemieteten Cloud-Mac immer mehr verwaiste VMs an, die Speicher belegen und den nächsten Build ausbremsen.

Caching-Strategie: Image-Layer und Abhängigkeiten wiederverwenden

Wenn nach jedem Neustart der Colima-VM erneut Images gezogen und Abhängigkeiten neu installiert werden, zieht sich die CI-Laufzeit stark in die Länge. Zwei einfache, wirksame Ansätze:

1. Image-Layer-Cache persistieren: Nicht bei jedem Lauf colima delete ausführen, sondern nur colima stop/colima start – die VM-Disk (standardmäßig unter ~/.colima) behält bereits gezogene Image-Layer, sodass nach dem Neustart kein erneuter Download nötig ist.
2. Build-Cache über Volumes mounten: Deklariert im Backend-Dockerfile für Abhängigkeitsverzeichnisse wie node_modules, vendor oder .cargo benannte Volumes. In Kombination mit --wait bei docker compose ist der erste Build zwar etwas langsamer, aber inkrementelle Folge-Builds sparen dann einen Großteil der Zeit.

Zusammen mit dem oben erwähnten virtiofs-Mount wird das Lesen/Schreiben im Projektverzeichnis kaum noch zum Flaschenhals. Was wirklich im Blick bleiben sollte, ist die Netzwerkebene – greifen Integrationstests auf externe APIs zu, richtet unbedingt separate Mock- oder Sandbox-Adressen für die Testumgebung ein, damit die CI nicht heimlich gegen Produktions-Endpunkte läuft.

Fallstricke und Checkliste

Die Punkte, an denen man bei der praktischen Einbindung am ehesten stolpert, nach Priorität sortiert:

• Docker-Context vergessen zu wechseln: Wenn vor der Colima-Installation bereits Docker Desktop genutzt wurde, zeigt der docker-Befehl möglicherweise noch auf den alten Context – der Schritt docker context use colima darf nicht fehlen.
• Falscher VM-Typ: Ältere Colima-Versionen setzen unter Umständen standardmäßig auf qemu. Auf Apple Silicon müsst ihr --vm-type=vz explizit angeben, der Performance-Unterschied ist deutlich.
• Unbegrenztes Diskwachstum: Werden Image-Layer nicht aufgeräumt, füllen sie dauerhaft den über --disk reservierten Speicherplatz. Empfehlenswert ist, im CI-Ablauf regelmäßig docker system prune -af --volumes laufen zu lassen.
• Ressourcenkonkurrenz bei parallelen Jobs: Laufen auf derselben Maschine gleichzeitig weitere Xcode-Build-Jobs, muss die Speicherzuteilung von Colima entsprechend reduziert werden, um OOM-Situationen zu vermeiden.
• Architektur-inkompatible Images: Referenziert das Backend Basis-Images, die nur x86_64 unterstützen, greift auf Apple Silicon die QEMU-Emulationsschicht, was die Geschwindigkeit drastisch einbrechen lässt. Prüft möglichst, ob native arm64-Varianten der Images existieren.

Sobald dieser Ablauf einmal eingespielt ist, kann derselbe Cloud-Mac-mini gleichzeitig als iOS-Build-Maschine und als Backend-Integrationstestumgebung dienen. Ihr müsst euch nicht mehr um maschinenübergreifende Netzwerk- und Credential-Koordination kümmern – nach dem PR liefert eine einzige Pipeline ein vollständiges Bestanden/Fehlgeschlagen-Signal.

Häufig gestellte Fragen