DevOps: от изменения к работающей системе

Оглавление · Docker и сеть

DevOps — подход к совместной работе над разработкой и эксплуатацией. Изменение считается полезным, когда его можно проверить, доставить пользователю и сопровождать после публикации. Разработчик должен понимать, как запускается его приложение; человек, обслуживающий сервер, должен понимать, как выпускаются его изменения. В маленьком учебном проекте обе роли может выполнять один человек.

Docker, GitHub Actions и Grafana помогают организовать этот процесс, но сами по себе не делают проект «DevOps». Важны воспроизводимые действия, короткая обратная связь и понятная ответственность за результат.

Путь изменения в Atmanki

flowchart LR
  Git[Изменение в Git] --> Check[Проверки CI]
  Check --> Image[Готовый образ]
  Image --> Registry[GHCR]
  Registry --> VPS[VPS: запуск образа]
  VPS --> Signals[Метрики и ошибки]
  Signals --> Git

CI, continuous integration, регулярно проверяет совместимость изменений: типизацию, серверные тесты и статическую генерацию с изолированной CMS. Continuous delivery означает, что проверенный результат готов к выпуску; continuous deployment добавляет автоматический выпуск после проверок. В нашем основном workflow push в main запускает проверки, сборку и деплой, если VPS подготовлен. Подробнее — порядок выпуска.

Образ — артефакт сборки. Контейнер — запущенный процесс из этого образа. Том базы — изменяемые данные, которые переживают замену контейнера. Поэтому возврат прежнего web-образа не возвращает вчерашний контент Strapi.

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

Compose, конфигурации Caddy и workflow находятся в Git. По diff видно, какие сервисы запускаются, как соединены и какие проверки выполняются. Это один из примеров Infrastructure as Code: описание инфраструктуры проходит тот же цикл обсуждения и проверки, что и приложение.

Пароль — не часть такого публичного описания. В Git хранится имя переменной, а значение передаётся отдельно. Digest образа фиксирует конкретный артефакт; плавающий тег может завтра указывать на другие байты.

Обратная связь после выпуска

Успешная сборка не доказывает, что сервер запущен. Успешный healthcheck не доказывает, что опубликованный контент читается из CMS. Поэтому мы разделяем проверки процесса, чтения данных и пользовательского сценария. Метрики помогают увидеть длительность и частоту проблем, ошибки — найти место сбоя, логи — восстановить контекст.

В Atmanki всё размещается на одном VPS. Это осознанное учебное упрощение: можно изучить полный цикл без кластеров и высокой доступности. Мониторинг на том же хосте не сообщает о полном отказе VPS. Отсутствие алертов не доказывает исправность.

Упражнение

Откройте .github/workflows/deploy.yaml, Dockerfile и scripts/deploy/release.sh. Найдите отдельно проверку, сборку, публикацию образа и запуск контейнера. Объясните, что останется на сервере после неудачного обновления web и почему это не является откатом базы. Сверьте ответ с эксплуатацией.

Что означает «выпуск воспроизводим»

pnpm-lock.yaml фиксирует зависимости приложения, digest — готовый образ, Git commit — исходники и конфигурацию релиза. Эти три указателя решают разные задачи. Сборка из того же Git commit с другим базовым Docker-образом не обязана давать те же байты. Поэтому VPS запускает уже собранный образ, а не устанавливает зависимости заново при каждом обновлении.

Развёртывание выполняется под общей блокировкой flock: два workflow могут работать параллельно в GitHub, но применять изменения на одном VPS должны последовательно. Healthcheck определяет, когда сервис готов к следующему шагу. Он не заменяет тест чтения CMS и проверку опубликованных изображений.

Как разбирать неудачный выпуск

Начните с наблюдаемого симптома. «Пользователь не видит новую новость» может означать отказ webhook, недоступность CMS или ещё не обновлённый кеш. Проверьте версии контейнеров, затем отдельные участки пути данных. Не меняйте несколько настроек одновременно: после такой правки трудно понять причину.

Зафиксируйте, что наблюдали, что проверили и какие выводы пока предположительны. Исправление завершено после повторения исходного сценария. Зелёная сборка проверяет код, а восстановившийся пользовательский сценарий — результат выпуска.

Скорость и надёжность

Для проекта можно определить цель, например «узнать об отказе чтения CMS». Наблюдаемый показатель — доля успешных проверок. SLO, service level objective, задаёт целевой уровень такого показателя на интервале времени; SLA добавляет обязательства перед другой стороной. Учебный Atmanki не имеет производственного SLA и независимого измерителя доступности. График нашего VPS не доказывает доступность из всех сетей и не учитывает время, когда сам измеритель не работал.

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