Terraform для гибридной инфраструктуры 1С: как избежать дрейфа конфигурации

Terraform для гибридной инфраструктуры 1С — инструмент, который описывает сервер на своей площадке и арендованные облачные мощности одним конфигурационным файлом и разворачивает их одной командой. Без него локальный сервер 1С и облачная часть настраиваются вручную, и рано или поздно их реальное состояние расходится с тем, что записано в документации или в голове у админа.

что такое terraform в связке с сервером 1С

Terraform — декларативный инструмент инфраструктуры как кода от HashiCorp: администратор описывает серверы, сети и диски в .tf-файлах, а Terraform сравнивает это описание с текущим состоянием (state) и доводит инфраструктуру до нужного вида через API провайдеров. Для гибридной схемы — часть серверов 1С стоит в своей серверной, часть арендована в дата-центре — это снимает ручную рассинхронизацию: один и тот же код описывает и локальный контур через provider для vSphere или Proxmox, и облачную часть через provider хостера.

На практике так строят инфраструктуру компании, у которых основная база 1С:Бухгалтерия или 1С:ERP годами живёт на своём сервере, но для отчётного периода, тестового контура или резервной копии докупают мощности отдельно — например, аренда сервера 1С на месяц без покупки железа. Если в базе хранятся персональные данные сотрудников или клиентов, требование 152-ФЗ о размещении таких данных на серверах в РФ тоже проще соблюдать, когда регион дата-центра прописан в .tf-файле как параметр, а не держится в памяти у одного администратора. Заодно код читается как документация: новый инженер за полчаса видит, из каких серверов состоит инфраструктура, а не выясняет это по обрывкам переписки с предыдущим админом.

почему возникает рассинхронизация terraform и реального сервера 1С

Пятница, 19:40. У клиента на арендованном сервере зависает 1С:Бухгалтерия — не хватает оперативной памяти при закрытии месяца, сеансы бухгалтерии виснут один за другим. Дежурный администратор заходит по SSH напрямую, добавляет своп-раздел и вручную поднимает лимит памяти для rphost, чтобы снять симптом до понедельника. База отвечает, но правка сделана мимо Terraform — в .tf-файлах её нет.

Через две недели другой инженер запускает terraform apply, чтобы расширить кластер под новый филиал. Terraform сверяет state с реальным сервером, видит незнакомый своп-раздел и параметр rphost, которых нет в коде, и — как ему и положено — приводит сервер к описанному состоянию. То есть откатывает пятничное исправление. Сервер снова захлёбывается, на этот раз в разгар закрытия квартала, когда бухгалтерия сдаёт НДС.

Ставка тут не абстрактная: два-три часа простоя базы в день закрытия периода — это менеджеры, которые не могут провести заказы и выставить счета, бухгалтерия, которая рискует не уложиться в срок сдачи отчётности, штраф от налоговой за просрочку, если отчёт всё-таки не ушёл вовремя, и упущенные заявки от клиентов, которые в этот момент не могут получить счёт или отгрузку. Причина всегда одна и та же: кто-то правит прод руками в момент аврала, а конфигурация в коде остаётся прежней. На гибридной схеме это усугубляется тем, что локальный провайдер Terraform и облачный работают по-разному, и синхронизировать ручные правки на обоих контурах физически некому — обычно этим не занимается никто, пока не грянет следующий apply.

как исправить дрейф конфигурации в гибридной инфраструктуре 1С

Первый шаг — не чинить сервер руками, а сначала посмотреть на диф. terraform plan показывает расхождение между кодом и реальностью ещё до apply — если запускать его регулярно на каждом контуре отдельно, сначала on-prem, потом облако, пятничная правка со своп-разделом обнаружится в понедельник утром, а не превратится в аварию в разгар квартала.

Второй шаг — решить судьбу найденной правки: если она оказалась нужной, её вносят в .tf-код через terraform import или ручное обновление state, а не оставляют висеть только на сервере. Если правка была временным костылём, её убирают с сервера тем же apply, но осознанно, а не случайно, когда никто не помнит, зачем она вообще появилась.

Третий шаг — развести state по контурам: отдельный state для прод-сервера 1С, отдельный для тестового окружения, отдельный для облачной части. Тогда plan для расширения облака физически не может задеть локальный сервер бухгалтерии, и наоборот — авария на одном контуре не тянет за собой другой.

Четвёртый — при описании ресурсов сервера в .tf-модуле сверяться с официальными системными требованиями 1С, а не с тем, что «вроде хватало раньше»: заниженные лимиты CPU и RAM в коде — частая причина, по которой администратор вообще вынужден лезть править прод руками посреди ночи.

И пятый — если рассинхронизация раз за разом происходит именно на стыке своего железа и облака, часть нагрузки логичнее вынести на выделенный сервер в аренду, которым Terraform управляет через API провайдера напрямую, без SSH-скриптов и ручных правок по живому серверу.

Отдельно стоит развести зоны ответственности инструментов: Terraform хорошо описывает серверы, диски и сеть, но не заменяет систему конфигурации внутри ОС — для установки пакетов, настройки rphost и служб 1С поверх готового сервера логичнее добавить Ansible или аналог, а не пытаться засунуть всё в provisioner. Смешение слоёв — ещё одна частая причина, по которой terraform apply внезапно перезаписывает то, что администратор считал «настройкой сервера», а не инфраструктурой.

что делать, если ошибка синхронизации повторяется после исправления

Если дрейф вернулся через месяц после того, как его вроде бы устранили, дело не в Terraform, а в процессе вокруг него. Обычно это один из трёх сценариев: у нескольких человек есть SSH- или RDP-доступ к проду в обход code review; никто не запускает plan по расписанию, поэтому расхождение копится незаметно неделями; или изменения вносятся под давлением времени, и «внести правку в код завтра» на практике превращается в «забыли навсегда».

Рабочее решение — ночной CI-джоб, который гоняет terraform plan по всем контурам и присылает алерт при любом непустом дифе, плюс жёсткое правило: экстренная правка на проде разрешена, но обязана попасть в код в течение суток, иначе доступ у инженера временно отзывается. Для критичного сервера 1С имеет смысл назначить владельца каждого .tf-модуля — тогда за расхождение отвечает конкретный человек, а не безликая «дежурная смена».

Если своими силами выстроить такой процесс некому — обычная ситуация для компании с одним системным администратором на десяток задач сразу — быстрее отдать разбор на аутсорс: сопровождение 1С и работа системного администратора по ставке от 3800 руб/час обходится дешевле, чем повторный простой базы в день сдачи отчётности.

как предотвратить дрейф конфигурации и простои 1С на гибридной инфраструктуре

Профилактика дешевле лечения, и здесь работает не один приём, а сочетание нескольких. Весь .tf-код держат в git с обязательным ревью перед merge — правки мимо pull request на прод не проходят. Plan запускают по расписанию, а не когда кто-то о нём вспомнил. Для эластичных частей гибридной схемы — тестовых контуров, сезонного расширения мощностей под отчётный период — вместо разовой закупки VPS «на глазок» берут виртуальный сервер для 1С, который заводится в Terraform как ресурс с самого начала, а не постфактум задним числом.

Для компаний, где база выросла до 1С:ERP с несколькими сотнями пользователей, отдельная головная боль — масштабирование сервера приложений под пиковую нагрузку в закрытие периода. Держать это на своём железе и гибридных костылях сложнее, чем перенести контур на сервер под 1С:ERP, где масштабирование и мониторинг — задача провайдера по SLA, а не ночной звонок дежурному админу. Terraform от этого никуда не девается: конфигурация арендованного сервера точно так же описывается кодом, просто железо и часть эксплуатации перестают быть головной болью внутренней команды.

terraform своими силами или аренда готового сервера 1С: что выбрать

Оба подхода совместимы с Terraform — разница в том, кто отвечает за железо и кто первым замечает дрейф конфигурации.

Если гибридная схема существует больше года и ни разу не проходила plan без диффа, дешевле не чинить процесс с нуля, а забрать нестабильный контур под управление тех, кто такие дрейфы видит каждый день, и настроить прод один раз правильно: настройка сервера 1С обычно занимает меньше времени, чем очередной ночной инцидент. На практике это разовая работа на несколько часов по ставке системного администратора, а не постоянная статья расходов — дальше сервер обслуживается по регламенту провайдера, и дрейф конфигурации становится чужой проблемой, а не поводом для звонка в полночь.

❓ Частые вопросы

Нужно ли переписывать всю инфраструктуру 1С на Terraform, если раньше всё настраивали руками?

Нет, переход можно делать постепенно: сначала описать в Terraform новый или самый нестабильный контур — например, арендованный сервер под тестовую базу, а старые серверы подключать по мере необходимости через terraform import. Полная миграция сразу не требуется и не рекомендуется — риск ошибки выше пользы.

Чем дрейф конфигурации отличается от обычной ошибки сервера 1С?

Обычная ошибка сервера 1С — это конкретный сбой: не хватило памяти, зависла служба, кончилось место на диске. Дрейф конфигурации — расхождение между тем, что записано в .tf-коде, и тем, что реально настроено на сервере. Сам по себе он не роняет базу, но провоцирует сбой при следующем terraform apply, когда инструмент откатывает незафиксированные правки.

Можно ли использовать Terraform, если часть серверов 1С физически стоит в своей серверной?

Да, для локальных серверов Terraform работает через provider для своей платформы виртуализации — vSphere, Proxmox, oVirt — и управляет ими так же, как облачными ресурсами через API. Схема, где часть базы 1С на своём железе, а часть в аренде, описывается одним репозиторием с раздельными state для каждого контура.

Сколько стоит устранить рассинхронизацию, если своего DevOps-инженера в штате нет?

Разовый разбор рассинхронизации и настройка регулярного terraform plan обычно оценивается по часовой ставке системного администратора — от 3800 руб/час, конкретная сумма зависит от количества серверов и глубины дрейфа. Итоговую стоимость называют после диагностики, а не заранее по телефону.

Как понять, что в компании уже есть дрейф конфигурации, если Terraform никогда не запускали plan?

Верный признак — если никто не может сходу сказать, сколько правок на проде сделано в обход кода за последний месяц. Практический тест: запустить terraform plan на каждом контуре и посмотреть на диф. Пустой вывод — конфигурация чистая, любые изменения в выводе — это и есть дрейф, который рано или поздно приведёт к откату при apply.