Перейти к содержанию

Goss: проверка VPS после деплоя

Linux · Проверка конфигурации
Не изучено

Добавлено 2026-10-11. Пример для Linux с systemd, Nginx на хосте и сайтом на 127.0.0.1:18080.

Проблема

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

Решение

Описать ожидаемое состояние хоста в goss.yaml и запускать проверки после изменений. Автоматически созданный через goss add файл нужно сверять с требованиями: снимок текущего состояния может закрепить существующую ошибку.

Пример

Goss установлен на хосте; проверить и при необходимости изменить путь конфигурации Nginx. HTTPS-проверку добавлять после выпуска сертификата.

service:
  nginx:
    enabled: true
    running: true
file:
  /etc/nginx/sites-enabled/devops-kb.strangled.net:
    exists: true
addr:
  tcp://127.0.0.1:18080:
    reachable: true
    timeout: 1000
http:
  http://127.0.0.1:18080/:
    status: 200
    timeout: 3000
    body: ['devops-kb']
  https://devops-kb.strangled.net/:
    status: 200
    timeout: 5000
    allow-insecure: false
    body: ['devops-kb']
goss --gossfile goss.yaml validate --format documentation

Ненулевой код завершения должен останавливать дальнейшие шаги релиза. Наличие файла не проверяет синтаксис Nginx: перед reload по-прежнему нужен nginx -t. Проверка соединения с 18080 не доказывает, что порт закрыт снаружи; это отдельное требование к публикации Docker-порта и сетевой проверке.

Когда применять

После изменения конфигов, обновления образа или пересоздания VPS. Проверка с этого же хоста дополняется внешним мониторингом.

Источник

Как применить у себя

  1. Зафиксировать версию Goss и 5–10 требований к одному серверу.
  2. Получить успешный отчёт после деплоя.
  3. В копии тестового файла намеренно заменить ожидаемый текст страницы и убедиться, что проверка падает.
  4. Сохранять отчёт с релизом; после подключения к процессу деплоя отметить «Изучено».