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

Terraform — инструмент инфраструктуры как код: сервер для 1С (виртуальная машина, диски, сеть, права доступа) описывается текстовым файлом вместо ручных кликов в панели хостинга. Команда terraform apply разворачивает сервер за 5-10 минут, история изменений хранится в git, а один и тот же код разворачивает как локальный сервер в офисе, так и арендованную машину в дата-центре — в этом суть гибридной инфраструктуры.

что такое инфраструктура как код для серверов 1С

Terraform читает конфигурационные файлы формата .tf и через провайдера — для VMware, Yandex Cloud, Proxmox, любого API-совместимого хостера — создаёт ресурсы: виртуальную машину под сервер 1С, диск под базу, сетевой интерфейс, правила файрвола для порта 1541 и сервиса RAS. Состояние всех ресурсов Terraform хранит в файле state — он знает, какой сервер уже создан, с какими параметрами, и что изменилось с прошлого запуска.

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

Выбор провайдера в коде — не разовое решение. Один и тот же модуль сервера 1С может смотреть то на VMware в серверной офиса, то на арендованную виртуальную машину — меняется только блок provider, остальной код диска, сети и прав остаётся прежним. Поэтому миграция базы с офисного железа на арендованный сервер занимает часы, а не недели переноса и повторной настройки с нуля.

почему возникает хаос в гибридной инфраструктуре 1С без Terraform

В пятницу вечером сисадмин компании из 60 человек поднимает третий сервер 1С — для нового филиала в Красногорске. Копирует настройки кластера с прошлого сервера по памяти, забывает открыть порт для сервиса RAS на новом файрволе. В понедельник в 9 утра бухгалтерия филиала пытается зайти в базу для сдачи отчёта — и не может: клиент не видит сервер. Пока сисадмин сравнивает конфиг вручную, восемь бухгалтеров сидят без 1С полтора часа.

Причина не в забывчивости сисадмина — настройка сервера 1С требует держать в голове десятки параметров: версию платформы, порты кластера 1540-1541, правила RAS, лимиты памяти, расписание бэкапа. На одном сервере это управляемо. Но на гибридной инфраструктуре из офисного железа, арендованного сервера под ERP и облачной резервной копии правила расходятся, а видно это только после сбоя.

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

как исправить ситуацию: перевод серверов 1С на Terraform-конфигурацию

Первый шаг — описать существующие серверы как код, а не переустанавливать их с нуля. Для каждой площадки заводится отдельный модуль:

• ✓ресурс сервера — тип виртуальной машины, число ядер, объём памяти (для базы на 40-50 пользователей обычно от 8 vCPU и 16 ГБ RAM)
• ✓ресурс диска — отдельный SSD-раздел под базу данных, вынесенный от системного диска
• ✓сетевые правила — порты 1540-1541 для кластера 1С, 1560 для RAS, ограничение доступа по IP для филиалов
• ✓переменные окружения — версия платформы 1С, имя базы, расписание регламентных заданий

Для нескольких похожих филиалов один модуль параметризуется переменными: имя филиала, диапазон IP, объём диска — вместо копирования файла конфигурации под каждую площадку. Terraform workspaces или отдельные .tfvars-файлы держат прод-контур, тестовый стенд и резервную копию в одном репозитории, но с разными значениями — тестовый сервер не получит продовые настройки сети по ошибке, потому что переменные физически разные файлы.

После первого terraform apply конфигурация филиала в Красногорске становится идентичной головному офису — не потому что сисадмин ничего не забыл, а потому что копировать нечего: код применяется один раз и одинаково. Ошибка из истории выше физически не могла бы произойти — правило про порт RAS прописано в модуле и применяется к каждому новому серверу автоматически.

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

что делать, если ошибка повторяется: state разошёлся с реальным сервером

Через полгода после внедрения Terraform ситуация может повториться в новой форме: сисадмин филиала во время ночного инцидента вручную поднимает лимит памяти на сервере через RDP — база зависла, разбираться некогда. Инцидент закрыт, но правку в код никто не внёс. При следующем terraform apply система пытается вернуть лимит к старому значению из конфигурации — сервер снова тормозит под нагрузкой.

Это классический дрейф состояния, state drift: реальность разошлась с тем, что Terraform считает правдой. Команда terraform plan перед каждым apply показывает разницу — если diff есть там, где никто ничего не менял через код, это сигнал ручного вмешательства.

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

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

запретить ручные правки на проде

Единственный источник правды — git-репозиторий с .tf файлами, а не память сисадмина или его RDP-сессия. Любое изменение параметров сервера проходит через pull request и terraform apply, даже если это добавить 2 ГБ памяти на один вечер.

хранить state удалённо и с блокировкой

Локальный state-файл на ноутбуке одного админа — риск: второй человек одновременно запускает apply и ломает конфигурацию. Remote state с блокировкой не даёт двум процессам применять изменения параллельно — критично, когда с гибридной инфраструктурой работает больше одного человека.

проверять план перед каждым apply

Автоматический прогон terraform plan в pull request — до того, как изменения попадут на реальный сервер — показывает точную разницу: что добавится, что удалится, что пересоздастся. Пересоздание диска с базой 1С в плане — повод остановиться и перечитать код, а не нажимать apply на автомате: ресурс, помеченный на пересоздание, удаляется и создаётся заново, а не просто обновляется.

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

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

Для гибридной схемы, где часть данных персональные — сотрудники, клиенты, — важно держать в конфигурации явный тег региона размещения: 152-ФЗ обязывает хранить персональные данные россиян на серверах внутри РФ, и Terraform-модуль удобно жёстко прописывает регион как переменную, а не оставляет выбор дата-центра на усмотрение того, кто в моменте разворачивал сервер.

сколько стоит перевести серверы 1С на Terraform

Сам Terraform бесплатный — платите за время инженера, который опишет текущую инфраструктуру кодом, и за серверы, на которых код разворачивается. Типовой сценарий для компании на 40-60 пользователей: почасовое сопровождение сисадмина от 3800 руб/час на составление и тестирование конфигурации, обычно 8-15 часов на первичное описание трёх-четырёх серверов, плюс аренда самих мощностей.

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

На практике весь путь — от текущих трёх серверов с ручными настройками до рабочей Terraform-конфигурации с remote state и pull request на каждое изменение — занимает 1-2 недели, включая тестовый прогон на копии базы, чтобы прод не трогать до полной уверенности в коде.

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

Чем Terraform отличается от обычных скриптов настройки сервера 1С?

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

Можно ли внедрить Terraform, если серверы 1С уже работают и настроены вручную?

Да, через terraform import: существующий сервер описывается кодом и подтягивается в state без пересоздания и без остановки базы. Настройки кластера 1С, RAS и расписание бэкапов при этом не трогаются — Terraform просто начинает управлять уже работающей машиной, а дальнейшие изменения вносятся через код, а не вручную.

Нужен ли DevOps-инженер в штате, чтобы использовать Terraform для 1С?

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

Как Terraform помогает с резервным контуром 1С, если основной сервер упал?

Резервный сервер описывается тем же кодом, что и основной, только с другим провайдером или регионом размещения. При аварии достаточно запустить terraform apply на резервной конфигурации — сервер поднимается с идентичными параметрами кластера 1С за минуты, а не восстанавливается вручную по памяти админа.

Сколько времени занимает переход гибридной инфраструктуры 1С на Terraform?

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