Скил infra-automation — серверные операции без импровизации
Как скил infra-automation даёт агентам Datarim согласованные паттерны для SSH-пакетного выполнения, проверки работоспособности, инвентаризации перед миграцией и безопасного запуска compose.
Выполнить одну команду на четырёх серверах, проверить, отвечают ли все HTTP-сервисы, или перечислить все активные слушатели перед миграцией — это повторяющиеся задачи, где ситуативный подход накапливает небольшие ошибки, которые складываются в большие. Скил infra-automation даёт агентам фиксированный набор паттернов для таких операций, чтобы подход был согласованным и проверяемым.
Скил охватывает парк серверов Arcana: четыре машины (WWW, PROD, DB и Trading) — у каждой публичный IP и IP в сети Tailscale. До любой пакетной автоматизации ключи хостов добавляются в ~/.ssh/known_hosts через явный шаг инициализации. Это событие документируется; все последующие автоматические SSH-вызовы используют BatchMode=yes и пятисекундный таймаут подключения, чтобы неизвестный хост сразу давал ошибку, а не завис.
Пакетное выполнение и проверка работоспособности
Для команды, которая выполняется на всех серверах, паттерн — один цикл с явными заголовками по каждому хосту и ограничением объёма вывода. Это исключает ситуацию, когда один сервер выдаёт огромный лог и заглушает результаты остальных. Проверки HTTP-сервисов строятся аналогично: цикл по парам «порт — имя сервиса», каждая проверка возвращает HTTP-код или строку UNREACHABLE.
Правила безопасности прописаны явно. Деструктивные команды — удаление файлов, удаление таблиц — выполняются на одном сервере с подтверждением, никогда в цикле по всем. Любая команда сначала проверяется на одном сервере, и только потом запускается по всем. Операции пишутся в файл для аудита.
Инвентаризация перед миграцией
Перед переносом сервера скил определяет, что нужно переписать: конфигурации виртуальных хостов веб-сервера, активные TLS-сертификаты, DNS-записи, указывающие на IP сервера, все активные слушатели, задания cron и таймеры systemd, исходящие соединения — хуки и резервное копирование. Пропущенный сервис — самая распространённая причина неудачной миграции, поэтому список — отправная точка, а не послесловие.
При изменении конфига на живом сервере паттерн такой: резервная копия, правка, сравнение с оригиналом, проверка синтаксиса, перезагрузка конфига (не перезапуск сервиса), затем проверка через curl. Перезагрузка конфига сохраняет существующие соединения; перезапуск — нет.
Состояние гонки в compose и отслеживание артефактов
Один из паттернов скила устраняет состояние гонки в docker compose up -d --build: когда сервис использует restart: unless-stopped, предыдущий контейнер может всё ещё удерживать имя в тот момент, когда новый пытается его занять. Решение — явный docker compose down --remove-orphans перед сборкой. Операция идемпотентна при холодном старте (благодаря || true), а именованные тома остаются нетронутыми, так как down без флага -v их не удаляет.
Любой скрипт или конфиг, установленный на production-сервере и указанный в критерии приёмки, должен быть в репозитории до того, как этот критерий войдёт в работу. Неотслеживаемый артефакт не имеет истории изменений и незаметно отклоняется от задуманного поведения.
Общая картина — в посте что такое Datarim. О классификации сетевых привязок рассказывает пост о скиле network-exposure-baseline.