Платформы для деплоя: Часть 5 — Kamal: деплой Docker-приложений на свой сервер

Kamal — инструмент командной строки от компании 37signals (создателей Basecamp и Ruby on Rails) для развёртывания веб-приложений в Docker-контейнерах на собственных серверах. Он занимает место между платформами вроде Heroku или Vercel, где за удобство платят наценкой и привязкой к поставщику, и Kubernetes, который даёт гибкость ценой заметной сложности. Kamal подключается к серверам по SSH, запускает на них контейнеры и переключает трафик на новую версию без простоя.

Изначально Kamal делали для Rails, но сейчас он не зависит от языка: если приложение собирается в Docker-образ, его можно развернуть. Актуальная ветка — Kamal 2 (последний выпуск на момент написания — 2.12).

Как работает деплой

Команда kamal deploy выполняет последовательность шагов:

1. собирает Docker-образ приложения;
2. отправляет его в реестр контейнеров;
3. на каждом сервере скачивает новый образ и запускает контейнер;
4. дожидается, пока новый контейнер ответит на проверку работоспособности;
5. переключает трафик на новый контейнер и останавливает старый.

За переключение отвечает kamal-proxy — собственный прокси Kamal, который во второй версии заменил Traefik. Во время деплоя он раз в секунду обращается к пути проверки работоспособности (по умолчанию /up) и направляет запросы на новый контейнер только после успешного ответа. Если приложение не поднялось за отведённое время, трафик остаётся на старой версии.

Установка и подготовка серверов

Kamal ставится на машину разработчика или в CI как Ruby-гем (gem install kamal); если Ruby нет, его можно запускать из Docker-контейнера. На серверах нужен только SSH-доступ по ключу.

Первое развёртывание выполняется командой kamal setup. По документации она подключается к серверам по SSH (по умолчанию от root), устанавливает Docker там, где его нет, через скрипт get.docker.com, запускает kamal-proxy и выполняет первый деплой. Для установки Docker нужны права root.

Конфигурация

Вся конфигурация — один файл config/deploy.yml. Минимальный пример с одним сервером и автоматическим HTTPS:

service: my-app
image: my-user/my-app

servers:
  web:
    hosts:
      - 192.0.2.10

proxy:
  host: app.example.ru
  app_port: 3000
  ssl: true
  healthcheck:
    path: /up

registry:
  server: registry.example.ru
  username: my-user
  password:
    - KAMAL_REGISTRY_PASSWORD

env:
  clear:
    LOG_LEVEL: info
  secret:
    - DATABASE_URL

builder:
  arch: amd64

С параметром ssl: true kamal-proxy сам получает сертификат Let’s Encrypt. По документации это работает, когда приложение развёрнуто на одном сервере, домен указывает на него и открыт порт 443. Если серверов несколько, перед ними нужен балансировщик, а сертификат выпускается на нём.

Секреты

Значения секретов не хранятся в deploy.yml. Kamal читает их из файлов в каталоге .kamal/: сначала .kamal/secrets-common, затем .kamal/secrets (или файл для конкретного окружения). Формат — как у dotenv, при этом значение можно получить командой:

KAMAL_REGISTRY_PASSWORD=$KAMAL_REGISTRY_PASSWORD
DATABASE_URL=$(cat /secure/database_url)

Для менеджеров паролей есть команда kamal secrets, которая извлекает значения из хранилища при деплое. Сами файлы с секретами не должны попадать в репозиторий, а переменные из раздела secret доставляются на сервер в отдельном файле окружения, а не в параметрах запуска контейнера.

Вспомогательные сервисы

Базы данных, Redis и другие сервисы Kamal умеет запускать рядом с приложением как accessories — отдельные контейнеры на указанном сервере. Для небольших проектов это удобно. Для рабочих систем с ценными данными базу обычно выносят на отдельный сервер или в управляемый сервис: резервное копирование, обновления и отказоустойчивость базы Kamal не решает.

Когда Kamal подходит

• Несколько серверов или один, стабильная нагрузка, небольшая команда без выделенного инженера по инфраструктуре.
• Нужно уйти от облачной платформы с оплатой за каждый ресурс к своим серверам, не переходя на Kubernetes.
• Серверы в любом дата-центре — важно только SSH-доступ и Docker. Для российской компании это могут быть VPS у российских провайдеров.

Когда он не подходит:

• нужно автоматическое масштабирование под резкие пики нагрузки;
• десятки сервисов со сложной сетевой связностью, где уже нужны возможности оркестратора;
• команда уже живёт в Kubernetes и умеет его обслуживать.

Общее сравнение платформ для деплоя — в первой части цикла. Похожую задачу решает Dokploy, но у него есть веб-интерфейс и собственная панель, а Kamal — только командная строка и один конфигурационный файл в репозитории.

Типичные ошибки

• Нет пути проверки работоспособности. Если приложение не отвечает на /up (или на заданный путь), деплой не переключит трафик.
• Файл .kamal/secrets попал в репозиторий вместе с настоящими значениями.
• Автоматический HTTPS на нескольких серверах. Сертификат Let’s Encrypt через kamal-proxy выпускается только при развёртывании на одном сервере.
• Архитектура образа не совпадает с сервером. Образ, собранный на Mac с процессором ARM, не запустится на сервере x86-64 без указания builder.arch.
• База данных как accessory без резервного копирования.