Docker и Swift: контейнеризация приложений продвинутого уровня

Введение: Почему контейнеризация Swift — это вызов и преимущество

Контейнеризация Swift-приложений для iOS и macOS долгое время считалась уделом энтузиастов. В отличие от Go или Node.js, Swift требует компиляции на целевой платформе, а официальные образы Docker долгое время оставались экзотикой. Однако с выходом Swift 5.x и появлением официальных образов swift:5.10 (и новее) ситуация кардинально изменилась. Сегодня Docker позволяет не только запускать серверные бэкенды на Vapor, но и автоматизировать сборку CLI-утилит, тестировать код в изолированной среде и даже подготавливать бинарные артефакты для деплоя на macOS.

В этой статье мы разберём продвинутые техники: многоэтапную сборку (multi-stage build), агрессивное кэширование зависимостей, оптимизацию размера образа и интеграцию с Swift Package Manager. Примеры ориентированы на реальные проекты — от простого HTTP-сервера до сложного микросервиса.

1. Многоэтапная сборка: разделяем компиляцию и рантайм

Классическая ошибка новичков — использовать один образ для сборки и запуска. В результате образ весит >2 ГБ из-за SDK, инструментов и исходников. Правильный подход — два этапа: builder и runner.

Пример Dockerfile для Vapor-приложения

# Этап 1: сборка
FROM swift:5.10 AS builder
WORKDIR /app
COPY Package.swift Package.resolved ./
RUN swift package resolve --cache-path .build/artifacts
COPY Sources Sources
COPY Tests Tests
RUN swift build -c release --static-swift-stdlib

# Этап 2: минимальный рантайм
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y libicu70 libxml2 ca-certificates && rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY --from=builder /app/.build/release/Run .
EXPOSE 8080
CMD ["./Run"]

Ключевые моменты:

• Кэширование зависимостей — копируем Package.swift и Package.resolved до копирования исходников. Docker кэширует слой, и при изменении только кода пересобираются только бинарники.
• Флаг --static-swift-stdlib — статическая линковка стандартной библиотеки Swift. Это снижает требования к рантайму, но увеличивает размер бинарника на ~30%.
• Минимальный образ — используем Ubuntu с необходимыми системными библиотеками (libicu, libxml2). Итоговый образ менее 150 МБ против 2 ГБ при одноэтапной сборке.

2. Агрессивное кэширование через BuildKit и SSH-агенты

При работе в CI/CD (GitHub Actions, GitLab CI) каждый запуск скачивает зависимости заново. Используйте Docker BuildKit для монтирования кэша Swift PM.

Dockerfile с кэшированием BuildKit

# syntax=docker/dockerfile:1
FROM swift:5.10 AS builder
WORKDIR /app
RUN --mount=type=cache,target=/app/.build/artifacts \
    --mount=type=bind,source=Package.swift,target=Package.swift \
    --mount=type=bind,source=Package.resolved,target=Package.resolved \
    swift package resolve
COPY Sources Sources
RUN --mount=type=cache,target=/app/.build/artifacts \
    swift build -c release --static-swift-stdlib

Преимущества:

• Персистентный кэш — артефакты зависимостей сохраняются между билдами на одном хосте.
• SSH-агенты — если ваш Package.swift ссылается на приватные репозитории, используйте --mount=type=ssh для аутентификации без хранения ключей в образе.

Для macOS-хостов (например, MacStadium) обязательно добавляйте --platform linux/amd64, так как Swift на ARM (M1/M2) требует эмуляции.

3. Продвинутая работа с Swift Package Manager

Swift PM — не просто менеджер зависимостей, но и мощный инструмент для тестирования и линтинга в контейнере.

Запуск тестов в контейнере с поддержкой Code Coverage

FROM swift:5.10 AS tester
WORKDIR /app
COPY . .
RUN swift test --enable-code-coverage --parallel
# Генерация отчёта в формате lcov
RUN llvm-cov export -format="lcov" \
    .build/debug/*PackageTests*.xctest \
    -instr-profile=.build/debug/codecov/default.profdata > coverage.lcov

Этот образ можно использовать в CI для генерации отчётов о покрытии. Для интеграции с SonarQube или Codecov просто скопируйте coverage.lcov из контейнера.

Сборка под разные платформы

Docker позволяет собирать Swift-приложения для Linux, даже если ваш хост — macOS:

docker buildx build --platform linux/amd64,linux/arm64 -t myapp:latest --push .

Однако для сборки под iOS (arm64-apple-ios) потребуется Xcode и macOS-хост. В этом случае используйте Docker Desktop с эмуляцией Rosetta и образ swift:5.10-slim.

4. Оптимизация размера образа: от 2 ГБ до 80 МБ

Минимальный размер образа критичен для быстрого деплоя в Kubernetes или AWS ECS. Вот несколько продвинутых техник:

• scratch-образ для статически слинкованных бинарников — если ваше приложение не использует системные библиотеки (например, CLI-утилита), можно собрать в FROM scratch. Пример для утилиты на Swift:

FROM swift:5.10 AS builder
WORKDIR /app
COPY . .
RUN swift build -c release --static-swift-stdlib -Xlinker -s
FROM scratch
COPY --from=builder /app/.build/release/mycli /mycli
ENTRYPOINT ["/mycli"]

Итоговый образ — менее 30 МБ.

• Удаление символов отладки — добавьте флаг -strip-debug-symbols или используйте strip:

RUN strip -s /app/.build/release/Run