Infrastructure as code: кнопка «Сделать всё», или Упаковываем наше окружение в 5 кБ текста

Меня зовут Вера Кокотова. Хочу рассказать про использование подхода «Инфраструктура как код» при разворачивании окружения для 1С-разработки на проекте.

Я более десяти лет работаю в КРОКе. Начинала как разработчик. Сейчас я работаю тимлидом группы технической архитектуры и разработки. Участвовала во многих крупных проектах компании.

КРОК – это крупная ИТ-компания. Мы давно работаем на рынке. В этом году КРОКу исполнилось 30 лет.

У нас работает более 2000 сотрудников. Направление 1С в КРОКе тоже более 10 лет. Мы выросли из направления Oracle, поэтому многие подходы к проектному управлению мы заимствовали из Oracle.

Мы специализируемся на крупных проектах автоматизации на базе флагманских продуктов 1С: ERP и Управление холдингом. Но я сегодня хочу поговорить не о методологических аспектах внедрения, а о конкретных инструментах и сервисах, и в частности об инфраструктуре, которую мы используем у себя на проектах.

Архитектура изолированного окружения под проект 1С в облаке

Прежде всего под каждый проект мы поднимаем стенд разработки:

• Раньше стенд разработки в основном поднимался на Windows, но с 2022 года по понятным причинам доля проектов на стеке Linux и PostgreSQL значительно выросла. Зачастую стенд разработки поднимается в нашем облаке, а не у заказчика, потому что до передачи системы в эксплуатацию разработка – это наша зона ответственности.

• Также под каждый проект у нас поднимается стенд со сборочной линией, поддерживающей процессы разработки.

• И может подниматься сборочная линия с автотестами – эта сборочная линия может также совмещаться со стендом разработки.

Основная трудоемкость лежит в разворачивании стенда со сборочной линией, которая поддерживает процесс разработки.

Этот стенд предоставляет следующие сервисы:

• СППР;

• сервис хранилищ конфигураций 1С;

• сервис управления версиями GitLab;

• сервис на базе Gitsync, который раскладывает версии хранилищ в Git;

• сервис проверки качества кода SonarQube;

• автотесты;

• ну и Jenkins, который обеспечивает автоматический запуск задач.

Все эти сервисы связывают работу участников проекта в единый процесс.

• Консультанты:

  • фиксируют требования в СППР;

  • описывают каталог бизнес-процессов и сами бизнес-процессы;

  • формируют список доработок в терминах объектов метаданных разрабатываемой конфигурации;

  • и отгружают уже техническое задание разработчику.

• Разработчик работает в хранилище:

  • каждая версия хранилища автоматически разбирается, помещается в Git-репозиторий;

  • также автоматически запускается проверка качества кода этой версии;

  • и адресно рассылаются замечания по результатам проверки.

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

• СУБД;

• сервер 1С;

• веб-сервер;

• и агент Jenkins, который позволяет нам запускать какие-то автоматические задачи: например обновление общих тестовых баз с какой-то периодичностью или по коммиту в хранилище.

Если говорить о базах, которые разворачиваются, их количество и состав тоже регламентирован:

• у нас есть эталонная база, в которую вносятся настройки для будущего прода;

• демобаза;

• база моделирования, в которой проводится общее моделирование для бизнес-пользователей;

• и уже индивидуальные базы для каждого консультанта и разработчика.

Во всех этих базах, кроме демобазы, должен быть создан набор пользователей, соответствующий участникам проектной команды.

Недостатки разворачивания инфраструктуры вручную

Поскольку при старте проекта нам нужно развернуть некоторое количество сервисов, стендов для проектной команды, самый тривиальный способ это сделать – дать задачу инженеру и погрузиться в ожидание.

Тут возникают несколько проблем.

• Во-первых, инженер в силу специфики своей работы участвует во многих проектах, поэтому процесс разворачивания может затянуться.

• На исполнение этой задачи требуются специальные знания – не каждый разработчик сможет такую инфраструктуру поднять.

• Когда мы выполняем много ручных действий, то вероятность какой-то ошибки велика. Инженер может забыть запустить какой-то скрипт, а потом долго разбираться, почему не работает.

Эволюция использования подхода

Наблюдая, сколько времени тратится на разворачивание, мы стали думать о том, как можно этот процесс ускорить.

• В самой первой редакции эти сервисы вообще поднимались на Windows, если говорить про стенд pipeline CI/CD.

• Потом мы почти сразу перешли на Linux – в том числе потому, что это экономит затраты на инфраструктуру. И с Linux мы сразу стали использовать Docker. Был создан шаблон виртуальной машины на базе Docker – при старте проекта нужно было создать из этого шаблона виртуалку и донастроить ее. Причем это тоже был достаточно трудоемкий процесс. В инструкции тех времен было описано 20 листов дополнительных действий – от создания хранилища до создания задач в Jenkins.

• И через какое-то время уже мы перешли к полной автоматизации, когда стенд разворачивается вообще по одной кнопке с использованием инструментов Terraform и Ansible.

Docker, Terraform, Ansible

Подробнее про инструменты.

Docker – это легковесная среда контейнеризации. Контейнеризация потребляет меньше ресурсов, чем виртуализация.

• Чтобы запустить в Docker какое-то приложение, необходимо подготовить образ, который является шаблоном запускаемого контейнера, и в нем уже содержатся приложения со всеми необходимыми зависимостями и настройками. Чтобы собрать такой образ для Docker, нужно написать Dockerfile с инструкциями. Пример Dockerfile на слайде. В классическом подходе инженеры выполняют скрипты, меняют настройки операционной системы, устанавливают дополнительные зависимости. Здесь все эти действия описаны в Dockerfile, и вероятность какой-то ошибки исключена.

• Когда образ протестирован, он может быть помещен в Docker Registry – приложение для управления доставкой и хранением образов. Оттуда его легко переиспользовать на других виртуальных машинах.

• Один контейнер содержит в себе один процесс – это значит, что для каждого приложения нужен свой контейнер. При этом приложение работает в своей среде и не мешает другим приложениям на этом хосте. Если приложение вдруг завершится с ошибкой или зависнет, на основную операционную систему это катастрофического влияния не окажет.

• На тот момент использование Docker помогало нам ускорить процесс развертывания всех сервисов.

Сами хосты, на которых разворачиваются эти сервисы, располагаются в облаке. Для использования виртуалки в облаке мы используем Terraform.

После того как Terraform создал эту виртуалку с необходимыми ресурсами, он возвращает айдишник к этой виртуалке Ansible.

А Ansible уже донастраивает эту виртуальную машину: устанавливает необходимые приложения, разворачивает докер-образы и так далее.

Чуть подробнее про Terraform.

• Terraform обращается к облаку через API.

• Ему передается конфигурационный файл, на основе которого должна быть создана виртуальная машина. Этот файл параметризован – мы можем заранее сказать, что для ERP нам нужна нода такой мощности, для самописной конфигурации на БСП – другой.

• Terraform умеет хранить состояние виртуальных машин.

• И он не требует установки агентов.

После того как Terraform развернул виртуальную машину в облаке, мы получили ее айдишник и отдаем его Ansible:

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

• Он также не требует установки агентов, что очень удобно.

• Ansible имеет низкий порог вхождения по сравнению с остальными системами управления конфигурацией.

• Существует очень много модулей Ansible, и при желании можно дописать свой модуль на Python. Это тоже не так сложно, потому что Python – тоже язык с низким порогом вхождения, плюс у нас уже есть скрипты на Python, которые мы используем в проде.

• И по Ansible много документации, она обновляется, информацию найти легко.

Основные базовые понятия Ansible – это:

• Inventory – файл, где хранятся пути к хостам, который мы настраиваем.

• Modules – это скрипты, которые выполняются на настраиваемых хостах. Например, можно написать модуль для копирования файлов с управляющей ноды на настраиваемую.

• Playbook – это сценарии в формате YML. Они тоже простые и понятные. Там описывается, где и какие действия мы выполняем. Там же мы можем описывать, какие переменные мы передаем.

• Role – это сущность, которая логически объединяет связанные между собой сценарии. Например, роль включает в себя:

  • установку PostgreSQL;

  • изменение конфигурационного файла PostgreSQL в зависимости от мощности виртуалки;

  • создание баз и пользователей.

Процесс создания стенда

Резюмируя – вот так теперь выглядит процесс создания стенда.

• Мы запускаем задачу в Jenkins и передаем туда необходимые параметры: вид стенда, проектную команду и версию платформы.

• Jenkins подключается к репозиторию Git, в котором хранится настройка пайплана для Jenkins и необходимые настройки конфигурационных файлов для Terraform и Ansible.

• Далее создается виртуальная машина Terraform,

• Потом она донастраивается с помощью Ansible.

• И на заключительном этапе для этой развернутой ноды в git-репозитории создается новая ветка, куда пушится ее состояние, чтобы мы видели, на основе чего эта нода была развернута.

Вот здесь показано, как видит настройка и запуск пайплайна в Jenkins.

А справа – файлик, где мы указываем логины, пароли, почту и роли участников проектной команды.

Теперь создание стенда происходит намного быстрее – время сократилось до 40 минут.

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

И в целом каждый участник команды может какие-то свои изменения внести в этот процесс и подключиться к развитию этого инструмента.

Преимущества подхода «Infrastructure as code»

Все ноды у нас едины между собой – нет так называемого configuration drift, когда вроде бы развернуты одинаковые сервисы, но с разными настройками. От этого поддержка усложняется – непонятно, кто делал на них, с какой целью.

При автоматическом развороте человеческий фактор исключается – мы не ловим какие-то ошибки на мелочах.

Ну и плюс наши инженеры радуются, потому что теперь они занимаются более интеллектуальной и интересной деятельностью: развиваются, развивают направление и тратят меньше времени на рутинные задачи.

Вопросы

Вы показали на примере линуксовой архитектуры, но я предполагаю, что у вас наверняка должны быть и виндовые проекты. Когда речь идет об экосистеме Microsoft, какие инструменты по аналогии с Ansible вы используете и используете ли вообще?

Последнее время стали использовать Chocolatey для разворота платформы и различные скрипты автоматизации на OneScript для подключения к серверу 1С через RAC и RAS.

Я не совсем понял, а в какой среде эти скрипты исполняются? Голый PowerShell или может быть 1С:Исполнитель у вас там все конфигурирует?

1С:Исполнитель пока не используем, потому что исторически больше использовали OneScript.

В основном создается шаблон виртуалки – это в полуручном режиме происходит. Все-таки стенд на Windows намного проще развернуть, чем стенд на Linux с кучей сервисов.

Поэтому для Windows пока нет полной автоматизации, и для нас это не так критично.

Скажите, пожалуйста, а почему вы используете два разных продукта: Terraform и Ansible? Почему не используется один? Потому что в моем понимании Ansible в вашем формате может заменить полностью Terraform?

Да, есть такой момент. На момент внедрения этой линии автоматизированного создания виртуальных машин Ansible еще не умел хранить состояние этих виртуалок. Поэтому было принято решение скрестить эти инструменты.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.