Docker et Swift : conteneurisation d'applications de A à Z

Introduction : Pourquoi Docker et Swift forment le duo idéal pour le développement moderne

Le monde du développement iOS et macOS a longtemps été associé exclusivement à Xcode et aux builds locales. Cependant, avec l'arrivée de Swift côté serveur (notamment le framework Vapor) et la popularité croissante de l'architecture microservices, la conteneurisation est devenue non plus une simple tendance, mais une nécessité. Docker pour un développeur Swift, ce n'est pas seulement une question d'isolation de l'environnement, mais aussi d'uniformité des builds, de simplicité du CI/CD et de déploiement facile sur n'importe quel serveur.

Dans cet article, nous allons parcourir le cycle complet de travail avec Docker et Swift : de la rédaction d'un simple Dockerfile pour macOS/Linux jusqu'au déploiement d'une application web complète sur Vapor. Vous apprendrez à éviter les erreurs courantes et à rendre vos conteneurs légers et sécurisés.

Partie principale : Guide étape par étape pour la conteneurisation de Swift

1. Les bases : Dockerfile pour une application Swift (macOS vs Linux)

La première chose à comprendre : Swift est un langage multiplateforme, mais Docker fonctionne traditionnellement avec des conteneurs Linux. Pour le développement macOS, vous pouvez utiliser des images avec une build Linux de Swift (par exemple, swift:5.9-focal) ou, si l'environnement macOS est critique, utiliser la virtualisation (Docker Desktop for Mac). Cependant, pour les applications serveur (Vapor, Kitura), les images Linux sont la norme.

Un Dockerfile de base pour une application Swift serveur (Vapor) :

# Utilisation de l'image officielle SwiftFROM swift:5.9-focal AS build

# Définition du répertoire de travailWORKDIR /app

# Copie des fichiers Package.swift et Package.resolved pour la mise en cache des dépendancesCOPY Package.swift Package.resolved ./RUN swift package resolve

# Copie du code sourceCOPY Sources ./SourcesRUN swift build -c release

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

Cette approche utilise une construction multi-étapes (multi-stage build) : la première étape compile l'application, la seconde crée une image minimale contenant uniquement le binaire et les bibliothèques nécessaires. L'image finale pèse environ 60-80 Mo au lieu de 2 Go.

2. Optimisation des images : mise en cache et dépendances

Swift est un langage compilé, et chaque build peut prendre plusieurs minutes. Pour accélérer le processus, utilisez la mise en cache des couches Docker. L'astuce clé : copiez d'abord Package.swift et Package.resolved, puis exécutez swift package resolve, et seulement ensuite copiez les sources. Cela garantit que les dépendances ne sont reconstruites que lorsque Package.swift change, et non à chaque modification du code.

Optimisation supplémentaire : l'utilisation de .dockerignore :

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

Cela empêche les fichiers inutiles (tests, git, projets Xcode) de pénétrer dans le contexte de build, ce qui accélère le transfert du contexte et réduit la taille de l'image.

3. Docker Compose : lier Swift à une base de données et un cache

Les applications réelles vivent rarement de manière isolée. Pour un backend typique sur Vapor, vous aurez besoin de PostgreSQL (ou Fluent), de Redis pour le cache et éventuellement de Nginx. docker-compose.yml permet de tout lancer avec une seule commande.

Exemple de docker-compose.yml pour une application Swift avec PostgreSQL et 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: