7 / 8

Deploy на VPS

До сих пор всё происходило на одной машине. Но реальные проекты живут на серверах — а туда нужен и бинарник Athanor, и зашифрованный файл, и, что важнее всего, ключ, которым его расшифровывать.

Что делает athanor deploy

athanor deploy user@my-vps

Шаг за шагом:

1. получить linux/amd64-бинарник athanor
   (если текущая машина уже linux/amd64 — просто копия работающего
    бинарника; иначе нужна пересборка из исходников, см. ниже)
        │
        ▼
2. проверить локальные файлы; подготовить <remote_path>.athanor-staging
        │
        ▼
3. scp: бинарник, нормализованный athanor.yaml, secrets, identity → staging
        │
        ▼
4. chmod 700 <staging> && chmod 600 <манифест/секреты/identity>
                        && chmod 755 <бинарник>
        │
        ▼
5. smoke-test в staging; затем активация с резервной копией и откатом
        │
        ▼
6. повторный smoke-test уже в <remote_path>

remote_path берётся не из флага командной строки, а из deploy.remote_path в athanor.yaml — это деталь конфигурации проекта, а не разовый параметр команды.

SSH и SCP запускаются неинтерактивно (BatchMode=yes) с тайм-аутом подключения. До активации текущая рабочая копия не меняется. При сбое финального smoke-теста прежние файлы восстанавливаются автоматически. Развёрнутый манифест получает локальный ./<имя secrets_file>, поэтому абсолютный или внешний путь с машины разработчика не протекает на VPS.

Важно: на сервер уезжает сам приватный ключ

Об этом стоит сказать прямо, а не прятать в списке шагов выше: deploy копирует на VPS сам файл identity — приватный ключ, которым расшифровывается secrets.enc.yaml, защищённый только правами файла (chmod 600), без дополнительного шифрования. Это принципиально другая граница доверия, чем просто "секреты зашифрованы": стоит identity оказаться на сервере — и этот сервер полностью способен расшифровать всё, что этим ключом защищено. Компромисс осознанный: без ключа на сервере команда athanor run там попросту не заработает. Именно поэтому на действительно менее доверенном VPS имеет смысл завести отдельный ключ (athanor init --own-key для этого конкретного проекта) вместо общего на всего разработчика.

Deploy не управляет SSH-доступом

deploy не хранит и не запрашивает пароль или ключ для входа на сервер — он буквально вызывает системные ssh/scp с тем хостом, что вы передали (алиас из ~/.ssh/config или user@host), используя то, что уже настроено: ключ в ssh-agent или в конфиге. Если для входа нужен пароль, а не ключ, команда просто упадёт с ошибкой на первом же ssh-вызове — вместо того чтобы пытаться этот пароль у вас как-то выцарапать. Секреты приложения и доступ к самому серверу — два разных контура доверия, и deploy их не смешивает.

Кросс-компиляция и ATHANOR_SRC_DIR

deploy запускается из каталога вашего проекта — например, веб-приложения, — а не из репозитория Athanor: там просто нет исходников Athanor для сборки. Поэтому:

• если машина, с которой вы деплоите, уже linux/amd64 (тот же Linux, что и VPS) — используется копия уже запущенного бинарника, пересборка не нужна;
• если архитектуры расходятся — скажем, деплой с Mac на linux/amd64-VPS — понадобится переменная окружения ATHANOR_SRC_DIR, указывающая на чекаут исходников самого Athanor, чтобы кросс-компилировать GOOS=linux GOARCH=amd64 прямо оттуда.

Несколько проектов на одном VPS

Как уживаются несколько проектов на одном сервере — вопрос уже не deploy, а манифеста (глава 3):

• разные секреты — просто разные remote_path у разных проектов, deploy их никак не пересекает;
• общие секреты локально — оба манифеста могут указывать на один secrets_file, но каждый deploy копирует его снимок в свой remote_path. Автоматической синхронизации между разными каталогами на VPS нет.