Привет, Хабр!
Мы — Игорь Старшинов, Евгений Ярош и Михаил Изюмов. Мы работаем в «Инфосистемы Джет» и если коротко, то мы тут построили «марсоход».
Если чуть длиннее — мы создали комплексную систему автоматического развертывания кластеров PostgreSQL, протестировали ее более 150 раз, внедрили у заказчика в изолированной инфраструктуре, и все заработало.
Написать скрипт для развертывания кластера PostgreSQL? Легко. Автоматизировать это под Ansible? Есть готовые гайдлайны. Но в этом проекте задача звучала иначе: каждое развертывание должно было не только запускать кластер, но и автоматически проверять его на соответствие стандартам архитектуры и информационной безопасности. Фактически заказчик (крупная российская компания с закрытым контуром) строил инструмент автоматизированного комплаенса для всех своих будущих проектов с PostgreSQL.
Теперь внимание. Никакого доступа к рабочей инфраструктуре, никакого интернета, никакого «скопировал — вставил». Даже буфер обмена отключен. Все тестируем у себя, воссоздав полностью среду заказчика. А это уже больше похоже на запуск марсохода.
Автоматизация PostgreSQL-кластеров в условиях максимальных ограничений
Итак, перед нами стояла задача не просто «запускать PostgreSQL по кнопке», а выстроить автоматизированный механизм развертывания отказоустойчивых кластеров — причем как для PostgreSQL, так и для Postgre Pro — прямо внутри инфраструктуры заказчика. Механизм должен был оставаться гибким, масштабируемым и стабильным даже в условиях жестких органиченикй закрытого контура.
Первым делом нужно было заложить сразу три варианта отказоустойчивой архитектуры — в зависимости от уровня критичности информационных систем компании.
Следующим слоем шла поддержка нескольких операционных систем: Red Hat, RedOS и Astra Linux, каждая со своими нюансами, ограничениями и особенностями настройки. Сверху добавлялась необходимость учитывать разные версии самих СУБД — как PostgreSQL, так и Postgre Pro, — поведение которых могло заметно меняться в зависимости от конфигурации и окружения.
Добавим к этому полное отсутствие доступа в интернет, что исключало установку привычных пакетов напрямую, и необходимость работы только с внутренними репозиториями. И, наконец, строгие требования информационной безопасности: от структуры каталогов и прав доступа до специфических параметров настройки, которые были зафиксированы в объемной таблице требований нашего заказчика.
Особое внимание уделялось автоматической настройке параметров СУБД в зависимости от характеристик среды — количество ядер, объем оперативной памяти, путь до логов и баз и прочее. Эти параметры не задавались жестко, а рассчитывались в процессе установки путем применения специальных формул, реализация которых легла в основу кода Ansible.
Решением стал комплекс скриптов на Ansible (YAML), который включал в себя не только развертывание кластера, но и автоконфигурацию под заданные параметры, автотестирование всех сценариев, автоматическую верификацию результата — по чеклисту из 100+ требований заказчика.
Проект длился около полугода и проходил через три этапа: обследование, разработку и приемо-сдаточные испытания (ПСИ). Над ним работал Центр компетенций СУБД «Инфосистемы Джет», который объединяет профильных специалистов инфраструктурного и сервисного центров.
Этап 1. Обследование: когда Марс пока только на картах
Первым делом мы пошли в разведку, то есть в обследование. Это тот самый этап, когда ничего не разворачивается, но становится понятно, где мы вообще находимся.
Мы узнали, что:
работать напрямую в контуре заказчика нельзя. Даже буфер обмена в Citrix — и тот заблокирован;
внешних источников пакетов нет, только внутренние репозитории;
требования к окружению расписаны на десятки параметров;
безопасность диктует не только конфигурации, но и способы установки ПО.
Мы воссоздали инфраструктуру заказчика у себя: подняли шаблон его среды, локальный репозиторий, смоделировали изоляцию. Получился полноценный «марсианский полигон» для тренировок до полета.
Этап 2. Разработка: проектируем скрипты, как «марсоход»
На этом этапе мы писали автоматизацию, которая должна работать вслепую. Чтобы при запуске в изолированной среде все работало точно по инструкции.
Для автоматизации развертывания и настройки кластеров был использован Ansible — набор скриптов на YAML, который покрывал все ключевые этапы: от подключения внутренних репозиториев и настройки файрволов до установки СУБД и кластеризации. Такой подход позволил стандартизировать процесс и упростить масштабирование. Автоматизация охватывала все необходимые комбинации: различные версии PostgreSQL и Postgre Pro (по три из каждого семейства), три операционные системы (Red Hat, RedOS и Astra Linux), а также три схемы отказоустойчивости, соответствующие разным уровням критичности систем. Это дало десятки уникальных сценариев развертывания, которые нужно было поддерживать из одной точки.
В скриптах установки и настройки кластеров Patroni были реализованы три варианта архитектуры, соответствующие классам критичности систем: Mission Critical, Business Critical и Business Operational / Office Productivity.
Для Mission Critical-систем был развернут трехузловой кластер Patroni в основном, а в резервном — отдельная реплика базы данных. Одна из них работала в синхронном режиме для исключения потери транзакций, вторая — в асинхронном. Если сервер с синхронной репликой выходил из строя, асинхронная могла автоматически переключаться в синхронную, чтобы сохранить устойчивость.
Размещение узлов etcd (три или пять) задавалось параметрами скриптов. Их можно разворачивать как на отдельных ВМ, так и на тех же, где работали Patroni/PostgreSQL. Автоматическое переключение между основным и резервным ЦОДом не предусматривалось — оно производилось вручную по команде администратора.
Для систем уровня Business Critical мы заложили архитектуру с двухузловым кластером Patroni в основном дата-центре и отдельной репликой в резервном ЦОДе.
Между узлами кластера использовалась асинхронная репликация. Это позволяло не нагружать основной экземпляр БД дополнительными задержками и сохранить предсказуемую производительность под пиковыми нагрузками. Реплика в резервном центре при этом находилась за пределами кластерного контура и не участвовала в процедуре выбора лидера. По сути, это был «изолированный запасной аэродром», с актуальными данными, но без влияния на работу основного кластера.
В качестве хранилища состояния для Patroni использовался etcd в конфигурации из трёх узлов. Размещение etcd оставалось гибким: его можно было разворачивать как на выделенных виртуальных машинах, так и совместно с узлами Patroni/PostgreSQL — конкретная схема задавалась параметрами скриптов.
Для систем класса критичности Business Operational и Office Productivity не предполагается использование средств кластеризации. Защита от сбоев обеспечивается средствами виртуализации. Реплики в резервном ЦОДе не предусмотрено, переключение базы данных в резервный ЦОД идёт путем восстановления виртуальной машины из резервной копии. Кластерные компоненты Patroni и etcd не устанавливаются.
Дополнительно была реализована логика автоматического расчета части конфигурационных параметров на основе текущих характеристик среды — например, объем оперативной памяти, число ядер и прочее. Это позволяло избежать ручного вмешательства и подгонки параметров под каждую машину.
Для удобства заказчика большая часть параметров кластера — даже тех, что не были явно описаны в ТЗ, — была вынесена в отдельный структурированный конфигурационный файл. Это позволяло быстро вносить изменения в логику развертывания и настройки без необходимости править сам код. Такой подход упрощал адаптацию решения под разные сценарии, особенно в условиях ограниченного доступа.
Небольшой пример кода переменных:
В случаях, когда нужный пакет отсутствовал в репозиториях заказчика, система автоматически переключалась на режим установки, адаптированный под ограничения. При этом в ряде случаев использовались компоненты, которые были доступны только в репозиториях самой ОС. Это увеличивало число вариаций, так как версии пакетов отличались в зависимости от дистрибутива. Например, в Red Hat требуемый пакет был недоступен вовсе. По согласованию с ИБ был создан дополнительный локальный репозиторий на деплой-хосте, в который загрузили верифицированный пакет. В будущем он должен быть добавлен в основной репозиторий. Также предусмотрели гибкую схему смены корневого источника пакетов — как полной, так и выборочной.
Учитывались строгие требования информационной безопасности, включая настройки файрволов, расположение каталогов логов и другие меры, прописанные в документации заказчика. Было разработано порядка 14 самодостаточных ролей, написано более 3000+ строк кода, вынесено более 100+ переменных параметров базы данных, созданы технологические записи для аудита, применено большое количество разнообразных уровней доступа, учтены требования выгрузки данных в SIEM. Все изменения и конфигурации выполнялись с точным соблюдением этих требований и контрольных списков.
Также была реализована автоматическая генерация самоподписанных TLS-сертификатов с последующим их применением в кластере. При этом, если у заказчика были собственные сертификаты, архитектура позволяла использовать их вместо автоматически сгенерированных — сценарий с внешними ключами тоже был предусмотрен.
Код писался вручную, без доступа к интернету и без возможности что-либо копировать — даже буфер обмена был отключен. Все передавалось только через утвержденные каналы.
Этап 3. ПСИ: проверяем «марсоход» в настоящей пыли Марса
После всех тестов в нашей среде пришло время запускать «экспедицию на другую планету» — в среду заказчика. Условия были похожи на «марсианские»: работать можно только в Citrix без буфера обмена, каждый прогон кластера занимает 3–5 минут (из-за ограничений виртуальной среды), отлаживать код на месте нельзя, только через многоступенчатые проверки безопасности.
В итоге заказчик не просто увидел, что кластер «встал». Он убедился, что он встал правильно, с нужными параметрами, в нужной конфигурации и с нужной логикой отказоустойчивости.
Особенности проекта
Во-первых, все развертывание происходило в полностью изолированной среде — без доступа к интернету, внешним репозиториям и публичной документации. Это требовало точной настройки путей установки, ручного сбора зависимостей и имитации привычных процессов, которые в обычных условиях делаются «по щелчку».
Во-вторых, объем возможных сценариев был действительно большим: две СУБД (PostgreSQL и Postgre Pro), по три версии каждой, три операционные системы, три схемы отказоустойчивости, плюс нюансы, связанные с требованиями безопасности. Все это перемножалось и порождало сотни уникальных вариантов развертывания, каждый из которых должен был работать без ручной доработки.
Третья особенность — автоматизация касалась не только установки кластеров, но и проверки результатов. Были реализованы механизмы, которые тестировали, соответствует ли развернутый кластер всем требованиям — от сетевых настроек до параметров безопасности. Это позволяло проводить полноценную верификацию после каждого запуска без участия инженера.
Конфигурация СУБД подбиралась автоматически: часть параметров рассчитывалась на лету, в зависимости от характеристик «железа». Заказчику не нужно было вручную подставлять значения — система делала это сама, по встроенной логике. А еще был реализован модуль, проверяющий настройки по внутренней таблице заказчика, включающей более 30 параметров. Каждая инсталляция проверялась на соответствие этим требованиям, и в случае отклонения система сообщала об этом в отчете.
Наконец, все наработки были снабжены подробной документацией и инструкциями. После завершения проекта заказчик получил полностью самостоятельное решение, которым можно было пользоваться без привлечения внешних специалистов.
Вместо заключения
Мы не просто автоматизировали развертывание. Мы автоматизировали все, включая:
проверку соответствия требованиям;
поведение в разных ОС;
реакцию на сбои, самопроверку всех параметров установки в автоматическом режиме;
автотесты;
и возможность быстро восстановиться.
У нашей команды за плечами десятки внедрений «вручную». Ее знания легли в основу логики того, как должен выглядеть «правильный» кластер. Затем писались скрипты — не просто «чтобы оно установилось», а «чтобы оно работало так, как должно».