Хабр, привет! Меня зовут Вера Кокотова, я тимлид группы технической архитектуры и разработки в направлении 1С. В посте хочу рассказать, как мы в проектах управляем жизненным циклом приложений от инфраструктуры до развернутого в web-сервиса с помощью подхода Infrastructure as Code.  До автоматизации процессов мы тратили до 40 часов на то, чтобы поднять сервер со сборочной линией, и 1-2 дня на сам стенд разработки и автотесты. Сейчас – 40 минут и довольные инженеры, которые смогли почти полностью уйти от рутины системного администрирования и сосредоточиться на развитии практик в рамках группы. Как мы пришли к такому happy end и что у системы под капотом – читайте после ката.  Под каждый проект мы поднимаем стенд разработки. До этого года в основном на Windows, но сейчас (по понятным причинам) значительно выросла доля проектов на стеке Linux + Postgres. Стенд поднимается в нашем Облаке КРОК, а не у заказчика – по крайней мере до передачи системы в эксплуатацию. Также под каждый проект у нас поднимается стенд со сборочной линией под каждую конфигурацию и опционально сборочная линия для прогона автотестов. Сервер, на котором расположены сервисы CI/CD, разворачивается на Linux. Автотесты тоже на линукс или возможно размещение базы под автотесты на сервере разработки. В итоге процесс выглядит так: развернуть инфраструктуру, взять некоторое количество серверов, установить на них определенную ОС, установить и настроить другое нужное ПО, настроить скрипты автоматизации, выполнить настройки интеграции сервисов, создать пользователей. Основная трудоемкость лежит в разворачивании стенда со сборочной линией. Стенд предоставляет сервисы:  СППР сервис хранилищ конфигурации; Gitlab – сервис распределенной системы контроля версий; Сервис на базе Gitsync, который раскладывает версии хранилища в Git; Sonar Qube – сервис проверки качества кода; Автотесты; Jenkins, который обеспечивает автоматический запуск задач.  Все эти сервисы связывают работу участников проекта в единый процесс. Консультанты фиксируют требования к системе в СППР, описывают бизнес-процессы. Потом мы формируем каталог бизнес-процессов и на этапе проектирования описываем доработки (в терминах объектов метаданных, которые загружаются из хранилища 1С).  Доработки выполняются в хранилище 1С, конфигурация каждой версии хранилища с помощью сервиса синхронизации раскладывается на исходники и отправляется в Git-репозиторий. Все происходит автоматически после коммита, анализ проверки качества кода и прогон автотестов – тоже. Результаты – на почте :)  Под каждый проект мы разворачиваем ноду, на которой работают сервисы СУБД, сервер 1С, веб-сервер. Состав сервисов от стека не зависит. У нас есть:  эталонная база – прообраз базы продуктива с необходимыми настройками и НСИ; база моделирования – общая база для сквозного тестирования процессов; демо-база – типовая демо-база без доработок; по индивидуальной базе для каждого разработчика и консультанта. Плюс в этих базах (кроме демо) создается набор пользователей – по составу участников проектной команды.  Итак, есть проект, сервисы, стенды, проектная команда, понимание на каком стеке мы работаем и какие задачи хотим автоматизировать. Самый тривиальный способ – отдать все инженеру и погрузиться в ожидание. И тут как раз есть проблемы – инженер, в силу специфики своей работы, участвует во многих проектах, и поэтому процесс разворота может затянуться. Плюс требуются специальные знания, то есть не каждый сможет такую инфраструктуру поднять. Соответственно, когда мы выполняем много ручных действий, то и вероятность ошибки выше – инженер может забыть запустить какой-то скрипт, потом будет разбираться почему не работает. И пошло-поехало.  В общем, процесс хоть и рабочий, но слишком долгий (напомню, что это несколько дней, а то и неделя). К тому же, если хорошему инженеру постоянно давать однотипные задачи, он в итоге загрустит. В первой итерации сервисы поднимали на Windows, но почти сразу мы перешли на Linux, в том числе, потому что это экономит затраты на инфраструктуру. С Linux мы сразу же стали использовать Docker. Схема была такая: создали шаблон виртуальной машины с Docker, который донастраивался в процессе разворачивания стенда под новый проект. В такой конфигурации прожили несколько лет. Но даже при таком подходе оставалось достаточно много рутинных действий – инициализация репозиториев, создание хранилищ, настройка интеграций. С тех времен сохранилась инструкция по “донастройке” – это где-то 20 листов дополнительных действий.  В итоге пошли в сторону еще большей автоматизации – по сути сейчас стенд разворачивается по одной кнопке с помощью Terraform и Ansible. В дальнейшем к этому процессу подключили разворот стенда разработки на Linux и стенда с пайплайном под автотесты.  Расскажу по порядку кратко про каждый инструмент.  Большинство сервисов стенда работают в докер-контейнерах. В классическом подходе для установки программы нужно совершить несколько действий: выполнить скрипт, изменить файлы настроек и так далее. В этом процессе не исключена вероятность человеческой ошибки: инженер запустит скрипт два раза, перепутает последовательность или что-то забудет. Контейнеры позволяют полностью автоматизировать этот процесс, так как включают в себя все нужные зависимости и порядок выполнения действий. По сути, Docker-файл автоматизирует процесс сборки приложения, что делает процесс повторяемым.  Еще один плюс – возможность поместить образ после тестирования в Docker Registry и переиспользовать на других виртуальных машинах. Один контейнер соответствует одному запущенному сервису. Экземпляр приложения запускается в изолированной среде со своей ОС и настройками, не влияющей на основную операционную систему. Если приложение в контейнере завершится с ошибкой или зависнет, это никак не затронет основную ОС. И, конечно, использование Docker помогает нам ускорить процесс развертывания всех сервисов.  Сами хосты, где запускаются контейнеры, размещены в облаке. Для их разворачивания мы используем утилиту Terraform, а для донастройки ОС, сервисов интеграций – Ansible. Terraform предоставляет декларативный способ управления инфраструктурой – мы указываем требуемую конфигурацию виртуальной машины, а Terraform, взаимодействуя с API облака, разворачивает и запускает виртуальный хост.  В чем преимущества Terraform для нас? Используем единообразный подход к различающимся в зависимости от облака API. Не используем консоль облака – все операции можно выполнять из командной строки.  Terraform умеет хранить состояние виртульных машин (state) – локально или в специальном хранилище. Это позволяет при необходимости быстро вносить изменения в работающие ВМ без их пересоздания.  Файл описания ВМ параметризуем – конфигурацию создаваемой машины можно привязать, например, к количеству пользователей, которые будут с ней работать. Параметры можно передавать как в командной строке, так и в хранить в отдельных файлах. Теперь про Ansible. После того, как Terraform развернула виртуальную машину в облаке, мы получили ее IP и ID. Мы отдаем его в Ansible, и он уже заканчивает настройку ОС. Установка агентов не требуется, что очень удобно. Почему мы вообще выбрали Ansible? У него низкий порог вхождения по сравнению с остальными системами управления конфигурациями. У Ansible много модулей, при желании можно написать свой модуль на Python. Если это понадобится, мы сможем легко это сделать, так как команда знакома с языком, у нас есть скрипты на Python, которые используем в проде. А еще по Ansible много документации, она регулярно обновляется и если что, информацию найти легко. Суммирую, как теперь выглядит процесс создания стенда.  Мы запускаем задачу в Jenkins, передаем туда необходимые параметры, вид стенда, проектную команду, версию платформы. Jenkins подключается к Git-репозиторию, в котором хранится сама настройка этого pipeline: Jenkinsfile, - и необходимые настройки конфигурационных файлов Terraform и Ansible. Далее происходит разворот, создается виртуальная машина Terraform, потом она донастраивается Ansible. На заключительном этапе создается новая ветка для развернутой ноды, ее состояние пушится в Git-репозиторий, чтобы мы видели на основе чего эта нода была развернута.  Здесь показана сама задача Jenkins, как выглядит ее запуск и файлик с участниками проектной команды, т.е. мы указываем не только логин и пароль, но и почту, и саму роль участника проектной команды.  Теперь создание стенда происходит намного быстрее, буквально по кнопке, а время сократилось до 40 минут. Участие инженера необходимо, но в намного меньшем объеме, так как требуется только пересоздать контейнеры с другой версией платформы (зачастую они меняются от проекта к проекту). Каждый участник команды может внести в этот процесс свои изменения и подключиться к развитию этого инструмента. Ноды между собой едины и так называемого configuration drift нет.  И самое главное – высокое качество разработки и довольные инженеры с меньшим количеством рутины.  В статье упоминаю opensource-продукты – все собрала в таблицу.  Продукт Вендор/Автор Ссылка 1 Ссылка 2 1С 1С http://v8.1c.ru  1С: СППР 1С http://v8.1c.ru/model/  1С: ДО 1С http://v8.1c.ru/doc8/  Git SFC https://ru.wikipedia.org/wiki/Git  Gitlab Gitlab https://ru.wikipedia.org/wiki/GitLab https://about.gitlab.com/ Jira Atlassian https://ru.wikipedia.org/wiki/Jira https://ru.atlassian.com/software/jira ReportPortal EPAM Systems, Inc. https://github.com/reportportal https://rp.epam.com/ui/ SonarQube SonarSource https://ru.wikipedia.org/wiki/SonarQube https://github.com/SonarSource/sonarqube Jenkins Косукэ Кавагути https://ru.wikipedia.org/wiki/Jenkins https://github.com/jenkinsci SourceTree Atlassian https://www.sourcetreeapp.com/  xUnitFor1C artbear https://github.com/xDrivenDevelopment/xUnitFor1C https://github.com/artbear Gitsync EvilBeaver https://github.com/oscript-library/gitsync https://github.com/EvilBeaver SonarQube 1C (BSL) Community Plugin nixel2007 https://github.com/1c-syntax/sonar-bsl-plugin-community https://github.com/oscript-library/gitsync Ansible Михаэль ДеХаан/ Red Hat и Ansible https://ru.wikipedia.org/wiki/Ansible https://www.ansible.com/ Terraform Mitchell Hashimoto и др./HashiCorp https://ru.wikipedia.org/wiki/Terraform https://github.com/hashicorp/terraform  Docker Соломон Хайкс/ Docker https://ru.wikipedia.org/wiki/Docker https://www.docker.com/  Подписывайтесь на уютный Telegram-канал КРОК и чувствуйте себя как дома!  архитектор 1с