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

01.11.23

Разработка - DevOps и автоматизация разработки

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

Меня зовут Вера Кокотова. Хочу рассказать про использование подхода «Инфраструктура как код» при разворачивании окружения для 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.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Автотесты для типовых конфигураций ERP Управление предприятием 2 и Комплексная автоматизация 2 (для vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.15.111.

2220 руб.

04.07.2022    7064    26    1    

24

Управление сборкой. Расширение для конфигурации СППР

DevOps и автоматизация разработки Платформа 1С v8.3 Конфигурации 1cv8 1С:Франчайзи, автоматизация бизнеса Платные (руб)

Подсистема «Управление сборкой GLI» предназначена для динамического формирования сборочных линий Gitlab и отслеживания процесса доработок систем на базе1С:Предприятия Позволяет упростить выпуск новых релизов системы, подготовить описание доработок системы. Интегрируется с GitLab API по событиям Push, Merge-request, Pipeline. Уведомляет пользователей о результатах сборки/тестирования сборочных конвейеров через СВ, либо при её недоступности или отсутствию по E-Mail. Поможет при отправке исправлений ошибок в общую базу тестирования, сформирует запросы на слияние в ветку версии только по протестированному и подтверждённому функционалу. Подсистема рассчитана исключительно на клиент - серверную архитектуру тестовых ИБ. Поддерживаемая версии СППР 2.0.4.15, платформа не ниже 8.3.17.1549, 2.0.7.3 / не ниже 8.3.21.1664, начиная с релиза 1.0.4.30 требуется платформа не ниже 8.3.23 рекомендуемый релиз 8.3.23.1997

7000 руб.

26.08.2022    11017    8    5    

31

Системы контроля версий для 1С-разработчиков.

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Платформа 1С v8.3 Платные (руб)

Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8

4900 руб.

29.06.2022    9652    79    4    

113

Автоматическое подтверждение легальности обновления базы или как обновить 100 типовых баз 1С за 5 часов

DevOps и автоматизация разработки Обновление 1С Платформа 1С v8.3 Конфигурации 1cv8 1С:Бухгалтерия 3.0 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m)

Расширение для конфигураций 1С для автоматического подтверждения легальности обновления и выполнения обработчиков обновления при пакетном автоматическом обновлении большого числа баз 1С. А также сам модуль обработки по автоматическому обновлению баз.

2 стартмани

08.05.2019    24633    58    VPanin56    26    

28

Автотесты для типовых конфигураций Бухгалтерия предприятия КОРП 3.0 и Бухгалтерия предприятия 3.0 (vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.152.28.

1728 руб.

20.01.2022    6808    11    0    

10

1С, СППР и Архитектура как код

DevOps и автоматизация разработки Бесплатно (free)

Можно ли идеи подхода «Архитектура как код» положить на 1С или иную платформу, чтобы не изобретать ещё какой-то язык и сразу получить множество готовых библиотек функций и инструмент достижения главной цели подхода AaC.

01.02.2024    2975    roman72    9    

9

TCP прокси-сервер хранилища конфигурации 1С

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) OneScript Платформа 1С v8.3 Бесплатно (free)

Продолжение истории с прокси хранилища, но уже не на HTTP, а на TCP и без падений по памяти веб-сервера. Проверяем комментарии хранилища, вызываем веб-хуки, старты пайплайнов, gitsync по событию помещения версии в хранилище. И все это полностью на знакомом и понятном OneScript.

17.01.2024    3306    kamisov    19    

61

Обработка для подготовки файла настройки дымовых тестов измененных объектов конфигурации

DevOps и автоматизация разработки Тестирование QA Россия Абонемент ($m)

В статье приведен пример обработки, которая на основании измененных файлов git-репозитория готовит специальный файл настройки xUnitParams.json для последующего выполнения дымовых тестов (xUnitFor1C/add) только для измененных объектов конфигурации

1 стартмани

09.10.2023    832    5    ICL-Soft    1    

4
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Artem-B 100 06.11.23 14:23 Сейчас в теме
Спасибо за доклад.
Подскажите, а как у вас организовано окружение для CI/CD?
Под каждый пайплайн поднимаются контейнеры с Postgres, сервером 1С, тонким клиентом ?
В противном случае как решаете конфликты с конкуретным/параллельным запуском одного и того же пайплайна? (например, клиенты тестирования и менеджеры могут друг другу мешать, тоже самое касается и баз для тестов)
3. Libelle 30 28.11.23 14:04 Сейчас в теме
(1) под каждый пайплайн свое окружение, но пайплайн с автотестами - отдельный и таски параллельно в нем не запускаются
2. Alistan007 08.11.23 21:05 Сейчас в теме
Почему в стеке нет 1С Исполнителя? )
4. Libelle 30 28.11.23 14:06 Сейчас в теме
(2) его не было еще на момент создания скриптов
5. RayCon 785 05.02.24 02:51 Сейчас в теме
Оставьте свое сообщение