Ci/Cd

Если ты до сих пор делаешь next build прямо на продакшен-сервере — твой сервер действительно страдает. CPU в полку, OOM-kill, 502-е ошибки и долгие простои — это классика, которой пора положить конец.

В 2026 году стандарт индустрии — это раздельная сборка:

1. Собираем минимальный standalone-образ в облаке GitHub Actions.
2. Пушим его в GHCR (GitHub Container Registry).
3. На сервере делаем только pull + атомарный перезапуск.

Глава 1. Идеальный Dockerfile (Multi-stage + Standalone)

Весь секрет маленького и быстрого образа — в режиме standalone. Next.js сам вычисляет, какие файлы и части node_modules реально нужны для работы сервера, и копирует только их.

Когда проект выходит за рамки локальной разработки и начинает использовать CI/CD, возникает фундаментальный вопрос: каким образом безопасно передавать конфигурационные параметры в пайплайны сборки и деплоя. Речь идет не только о паролях к базам данных, но и о токенах контейнерных реестров, SSH-ключах, ключах подписи JWT, строках подключения к очередям сообщений и любых других параметрах, которые нельзя хранить в открытом виде.

Попадание чувствительных данных в Git-репозиторий — это не просто плохая практика. История коммитов сохраняется навсегда. Даже если секрет был удален в следующем коммите, он уже стал частью истории и может быть извлечен через git log, git show или при клонировании форка. В корпоративной среде это превращается в реальный риск при аудитах, расширении команды или при утечке доступа к репозиторию.

Написать Dockerfile просто: FROM node, COPY ., CMD run. Это работает, и для локальных тестов этого часто достаточно. Но когда такой образ попадает в CI/CD или, не дай бог, в продакшн, начинаются проблемы: сборка длится вечность, образ весит гигабайты, а безопасники хватаются за голову.

Разница между «работает» и «работает правильно» колоссальна. Давайте разберем четыре уровня оптимизации, которые отделяют любительскую поделку от надежного инженерного решения.

1. Фундамент: Выбор образа и детерминизм

Всё начинается с инструкции FROM. Многие по привычке берут полные образы (например, стандартную ubuntu или python:3.9), не задумываясь о последствиях.

В последние десять лет индустрия развёртывания веб-приложений прошла путь от FTP-скриптов и rsync до сложнейших систем оркестрации. Сегодня разработчики и небольшие команды всё чаще оказываются перед непростым выбором:

• либо платить серьёзную наценку за удобство PaaS-платформ (Heroku, Render, Fly.io),
• либо погружаться в когнитивную и операционную сложность Kubernetes.

Kamal предлагает третий путь: удобство современных облачных сервисов — на вашем собственном сервере.

Что такое Kamal

Kamal — это open-source CLI-инструмент от компании 37signals (создателей Basecamp и Ruby on Rails), предназначенный для деплоя веб-приложений поверх Docker без Kubernetes.

Переезд в облако или смена провайдера — это всегда операция на открытом сердце. Инженеру нужно решить массу вопросов: как перенести терабайты данных с минимальным простоем? Как конвертировать схему? Как настроить CDC (Change Data Capture), чтобы не потерять ни одной транзакции во время переключения?

У каждого крупного облачного провайдера есть свой ответ. Подходы кардинально разные: кто-то даёт просто «трубу» для данных, кто-то — полноценный ETL-комбайн, кто-то делает миграцию serverless и максимально беспроблемной.