Docker und Swift: Containerisierung von Anwendungen von A bis Z

Einleitung: Warum Docker und Swift das ideale Paar für die moderne Entwicklung sind

Die Welt der Entwicklung für iOS und macOS war lange Zeit ausschließlich mit Xcode und lokalen Builds verbunden. Mit dem Aufkommen von Server-Side Swift (insbesondere des Frameworks Vapor) und der wachsenden Beliebtheit der Microservice-Architektur ist die Containerisierung jedoch nicht nur ein Trend, sondern eine Notwendigkeit geworden. Docker für Swift-Entwickler bedeutet nicht nur Isolation der Umgebung, sondern auch Einheitlichkeit der Builds, einfache CI/CD und problemloses Deployment auf jedem Server.

In diesem Artikel behandeln wir den gesamten Arbeitszyklus mit Docker und Swift: vom Schreiben eines einfachen Dockerfile für macOS/Linux bis zum Deployment einer vollwertigen Webanwendung auf Vapor. Sie erfahren, wie Sie typische Fehler vermeiden und Ihre Container leicht und sicher machen.

Hauptteil: Schritt-für-Schritt-Anleitung zur Containerisierung von Swift

1. Grundlagen: Dockerfile für eine Swift-Anwendung (macOS vs. Linux)

Das erste, was man verstehen muss: Swift ist eine plattformübergreifende Sprache, aber Docker arbeitet traditionell mit Linux-Containern. Für die macOS-Entwicklung können Sie Images mit einem Linux-Build von Swift verwenden (z. B. swift:5.9-focal) oder, wenn die macOS-Umgebung kritisch ist, Virtualisierung nutzen (Docker Desktop for Mac). Für Serveranwendungen (Vapor, Kitura) sind Linux-Images jedoch der Standard.

Ein grundlegendes Dockerfile für eine serverseitige Swift-Anwendung (Vapor):

# Verwende das offizielle Swift-ImageFROM swift:5.9-focal AS build

# Arbeitsverzeichnis festlegenWORKDIR /app

# Kopiere Package.swift und Package.resolved zum Caching der AbhängigkeitenCOPY Package.swift Package.resolved ./RUN swift package resolve

# Kopiere den QuellcodeCOPY Sources ./SourcesRUN swift build -c release

# Finales Image (minimal)FROM ubuntu:focalWORKDIR /appCOPY --from=build /app/.build/release /appEXPOSE 8080CMD ["./Run"]

Dieser Ansatz verwendet einen mehrstufigen Build (multi-stage build): Die erste Stufe kompiliert die Anwendung, die zweite erstellt ein minimales Image, das nur die Binärdatei und die notwendigen Bibliotheken enthält. Das resultierende Image wiegt ~60-80 MB statt 2 GB.

2. Image-Optimierung: Caching und Abhängigkeiten

Swift ist eine kompilierte Sprache, und jeder Build kann Minuten dauern. Um den Prozess zu beschleunigen, nutzen Sie das Caching von Docker-Layern. Ein entscheidender Trick: Kopieren Sie zuerst Package.swift und Package.resolved, führen Sie dann swift package resolve aus, und kopieren Sie erst danach die Quellen. Dadurch wird sichergestellt, dass Abhängigkeiten nur neu gebaut werden, wenn sich Package.swift ändert, und nicht bei jeder Code-Änderung.

Eine zusätzliche Optimierung ist die Verwendung einer .dockerignore-Datei:

.git.gitignore.build*.xcworkspace*.xcodeprojDerivedDataPackagesREADME.mdTests

Dies verhindert, dass unnötige Dateien (Tests, Git, Xcode-Projekte) in den Build-Kontext gelangen, was die Übertragung des Kontexts beschleunigt und die Image-Größe reduziert.

3. Docker Compose: Swift mit Datenbank und Cache verbinden

Reale Anwendungen leben selten isoliert. Für ein typisches Backend mit Vapor benötigen Sie PostgreSQL (oder Fluent), Redis für den Cache und möglicherweise Nginx. docker-compose.yml ermöglicht es, alles mit einem Befehl zu starten.

Beispiel einer docker-compose.yml für eine Swift-Anwendung mit PostgreSQL und Redis:

version: '3.8'services:  app:    build: .    ports:      - "8080:8080"    environment:      - DATABASE_HOST=db      - DATABASE_PORT=5432      - REDIS_HOST=redis      - REDIS_PORT=6379    depends_on:      - db      - redis    restart: unless-stopped

  db:    image: postgres:15-alpine    environment:      POSTGRES_DB: myapp      POSTGRES_USER: user      POSTGRES_PASSWORD: password    volumes:      - postgres_data:/var/lib/postgresql/data    ports:      - "5432:5432"

  redis:    image: