¶ Предпосылки
Работа над проектами включает в себя большое количество организационной работы, такой как планирование задач, обсуждение текущих проблем, организация и хранение исходных кодов программ, проведение рабочих встреч и многое другое. Для упрощения процесса ведения проектов в институте было настроено некоторое число онлайн сервисов, таких как корпоративный чат Zulip, система хранения документации Wiki, сервис видеоконференций Jitsi Meet и система управления проектами Taiga.io, которые свободно доступны всем сотрудникам и студентам. Кроме самих сервисов, силами студентов были разработаны различные интеграции между сервисами, нацеленные на решение часто возникающих в процессе работы вопросов и проблем. Каждый из этих сервисов изначально разрабатывался отдельной командой студентов, которые занимались их доработкой под нужды института и технической поддержкой. Однако через какое-то время студенты, занимавшиеся поддержкой сервисов, покинули институт и большая часть сервисов осталась в рабочем, но не поддерживаемом состоянии. Поскольку многие учебные процессы уже были завязаны на использование этих сервисов, то возникла необходимость продолжить обеспечивать работу сервисов для продолжения поддержки проектного обучения. В институте существует отдел технической поддержки, однако передача им сервисов была невозможна по следующим причинам: во-первых каждый сервис был развернут своим уникальным способом, что делало невозможным их переустановку и миграцию, а во-вторых сервисы содержали большое количество доработок и интеграций, которые не были никак задокументированы, что чрезвычайно осложняло процесс управления ими. В результате возникла задача по переработке архитектуры сервисов, актуализации интеграций сервисов между собой и написанию технической документации для разработчиков и системных администраторов для дальнейшей передачи сервисов на поддержку.
¶ Требования к проекту
В рамках проекта были сформулированы требования по отчуждаемости сервисов, возможности их передачи сторонним командам на поддержку и доработку. Требования формировались на практике, команда проекта сталкивалась с различными рабочими ситуациями, требующими повышения эффективности работ, понижения квалификации для выполнения поставленной задачи, понижения системных требований. Таким образом, в ходе проекта были сформулированы критерии готовности программного продукта, которые включали вышеописанные требования.
Основные критерии готовности:
- Унификация способов развертывания, запуска и настройки сервисов и их компонентов;
- Обеспечение возможности запуска сервисов без необходимости знания языков программирования;
- Сокращение времени на развертывание каждой из систем с нуля или из резервной копии. К примеру, на момент начала проекта развертывание сервиса Zulip занимало около 5–6 часов, так как требовалось вручную определить текущее местоположение каждого из компонентов и способ его развертывания, а также методы их конфигурирования;
- Наличие альтернативных способов развертывания;
- Низкие системные требования, позволяющие развернуть сервисы на широком спектре оборудования института или потенциального заказчика;
- Наличие системы автоматической сборки для каждого из микросервисов. До начала проекта все микросервисы собирались исключительно вручную;
- Переносимость каждого программного комплекса, то есть возможность развернуть его на другом сервере без необходимости изменять исходный код или выполнять переконфигурацию;
- Наличие возможности удаленно отслеживать состояние работоспособности каждого сервиса;
- Наличие комплекта документации, позволяющего выполнять обслуживание и настройку компонентов без знания языков программирования особенностей их внутренней имплементации.
Проект своей задачей ставит доработку программного продукта до соответствия критериям готовности, подготавливает сервисы для соответствия таким критериям как: отчуждаемый хостинг, возможность передачи текущих версий в эксплуатацию, а также возможность плановой модернизации и интеграции.
Каждый этап формирования сервиса сопровождается подробной документацией. Документация сформирована на основе ГОСТ 34 и размещена на платформе Wiki.
¶ Цели и задачи
Основной целью проекта является доработка сервисов Wiki, Zulip до состояния готовности, данные сервисы можно рассматривать как пример и опорную точку для дальнейшего применения разработанного подхода.
В рамках проекта дорабатывается текущий продукт, происходит его настройка для регулярной работы продолжительное время. Также проект решает задачи по улучшению качества и повышению эффективности разработки программного продукта в целом, так как подготавливает базис и образец для дальнейшего производства ПО. Предоставляет отобранные и настроенные инструменты для сборки, развертывания, мониторинга разрабатываемой системы.
¶ Ход работ
Для реализации требований по отчуждаемости была выбрана в качестве рабочего подхода методология DevOps.
Для выполнения поставленных требований, методология DevOps предлагает решения, которые сопровождаются инструментарием для их реализации. Также важным преимуществом выбранной методологии является ее общеизвестность и повсеместная применимость. Есть гарантия, что используемые инструменты (программные продукты, библиотеки и т.д.) будут сопровождаться документацией, в течении продолжительного времени будет поддерживаться их работоспособность путем обновлений, данная гарантия возникает из наличия сообщества активно использующего данные инструменты.
Таким образом, в рамках проекта были взяты сервисы Wiki, Zulip, которые с использованием методологии DevOps доводились до состояния, в котором они удовлетворяли критериям готовности. Далее подробнее ход работ:
- Исследование структуры сервиса Zulip -
Илья Постников
Изначально сервис представлял собой движок Zulip и набор разрозненных скриптов, расположенных на сервере в МИЭМ. К скриптам отсутствовала какая-либо документация и не было указаний, где эти скрипты размещаются. - Создание Dev-сервера Zulip для тестирования механизма миграции - Илья Постников
Сервер предназначался для тестирования настроек и интеграци до их переноса на основной сервер, а также для исследования особенностей функционирования системы. - Перенос сервера Zulip с серверов МИЭМ на внешний хостинг - Илья Постников
Единственной проблемой, связанной с переносом была невозможность мгновенной смены доменного имени. Для решения этой проблемы был настроен временный прокси сервер, который перенаправлял запросы со старого расположения на новое до момента перенастройки доменного имени. - Исследование механизмов авторизации Zulip - Илья Постников
Изначально настроенным способом авторизации Zulip был Google OAuth. Недостатком этого была зависимость от сервисов Google и невозможность использования чата сотрудниками и студентами не из МИЭМа. Для того чтобы решить эту проблему в институте была создана отдельная система авторизации на основе Keycloak, объединяющая в себе аккаунты Google и ЕЛК. Большинство сервисов (Taiga, Jitsi, GitLab, Wiki) к моменту начала работы над проектом уже перешли на новую систему авторизации с использованием протокола OAuth/OpenID. Zulip не поддерживал данный протокол, поэтому было решено подключить авторизацию по протоколу SAML. Данный протокол основан на обмене подписанными XML сообщениями.
В процессе настройки новой системы авторизации на dev-сервере были выявлены некоторые особенности, которые потребовали разработки дополнительных механизмов для миграции системы авторизации. Первой такой особенностью стало то, что аккаунт в системе авторизации и в Zulip сопоставляется по адресу электронной почты, соответственно для успешного входа в систему было необходимо чтобы адреса совпадали. Поскольку изначально Zulip использовал систему авторизации Google, то при включении новой системы авторизации было необходимо синхронизовать адреса электронных почт в Zulip с соответствующим им в Keycloak. Для решения этой задачи был разработан специальный скрипт, который должен был быть запущен перед включением новой системы авторизации. Другой проблемой стали особенности формата передаваемых данных между сервисом и системой авторизации(в частности названия идентификационных полей), из-за этого пришлось осуществить дополнительную конфигурацию как на стороне Keycloak так и на стороне Zulip. Кроме этого возможна ситуация, когда у пользователей имеются два несвязанных аккаунта в Keycloak и при входе через одних из них создается дублирующийся аккаунт в Zulip и пользователь теряет доступ к своей переписке. Для решения этой проблемы был разработан отдельный скрипт duplications-detector, который сообщает в техническую поддержку о возникновении аккаунтов-дубликатов. - Разработка клиента Zulip - Илья Постников, Светлана Мелехина
Был разработан клиент для Zulip на языке typescript, целиком реализующий API. - Переработка интеграций Zulip с другими сервисами - Илья Постников
Изначально сервис Zulip содержал следующие интеграционные скрипты:
6.1. Api-integration - первый скрипт, синхронизирующий состав Google групп и групп в Zulip
6.2. Update-zulip-groups -другой скрипт синхронизации Google групп
6.3 Update-profile-data - скрипт синхронизации данных о местоположении пользователя в оргструктуре института (по данным google домена)
6.4. Rename-stream-bot - бот для переименования проектных каналов
6.5. Zulip-cabinet-link - микросервис для интеграции с сервисом Кабинет
По большей части эти скрипты устарели, не имели документации и имели дублирование функционала. Поэтому было решено переписать скрипты с нуля чтобы во-первых обеспечить более простую структуру микросервисов, а во-вторых для актуализации функционала и устранения дублирования. В результате были разработаны следующие микросервисы:
6.6. Zulip-script - скрипт для синхронизации проектных(по данным Кабинета) и учебных (по данным Google) групп и информации профилей.
6.7. Rename-stream-bot-ts - новый бот для переименования проектных каналов
6.8. Zulip-cabinet-link-ts - новый микросервис для интеграции с кабинетом - Разработка CI/CD пайплайнов для скриптов Zulip - Илья Постников
Пайплайны для каждого из микросервиса имеют приблизительно идентичную структур. Они в автоматическом виде выполняют проверку стиля кода, проверку компиляции, запуск модульных тестов, компиляцию, сборку контейнеров и отправку их в хранилище контейнеров. - Доработка скрипта page-creator - Светлана Мелехина
Page-creator - скрипт для импорта информации со страниц GitLab, Taiga и Cabinet и создания на ее основе страниц Wiki. Была добавлена возможность импортировать вики-старницы из проектов gitlab, которые были распределены иерархически по вложенным группам. Был написан конвертатор из markdown GitLab в markdown для Wiki. - Миграция сервиса Wiki на Docker контейнеры. - Илья Постников
Работы включали в себя как разработку контейнеров для каждого из микросервисов, так и непосредственно миграцию сервиса на новый сервер. Сервис Wiki также как Zulip был развернут с помощью контейнеров Docker и инструмента управления Docker-Compose. - Развертывание S3 совместимого хранилища Minio на Dev-сервере. - Никита Гаврилов
Minio используется сервисом page-converter, развернут с помощью инструментов Docker Compose и Ansible Playbook . - Разработка сервиса(page-converter) для конвертации страниц Wiki в форматы Tex, PDF - Светлана Мелехина
Сервис page-converter позволяет создать на основе страницы Wiki, оформленной с помощью языка разметки markdown, документы в формате Tex и PDF с возможностью применения шаблонов. Можно создать документы в формате ГОСТ (ЕСПД, ЕСКД), научной статьи или отчета по ВКР.
Принцип работы сервиса. Принимает запрос на конвертацию страницы. Происходит конвертация при помощи утилиты pandoc, к полученному документу добавляются преамбулы в соответствии с типом запрашиваемого документа, в преамбулы вписывается ФИО пользователя и заголовок документа (взят со страницы Wiki). Если формат для конвертации - PDF, то сформированный tex документ при помощи утилиты xetex конвертируется в PDF.
Полученный документ помещается в базу данных minio, и в течении суток у пользователя есть возможность запросить документ по ссылке, предоставленной сервисом в ответ на запрос о конвертации. - Разработка плейбуков Ansible - Никита Гаврилов
С помощью плейбуков можно автоматизировать повторяющиеся действия, при этом выполнение плейбуков может происходить одновременно на нескольких серверах. Разработаны плейбуки: установка Docker, обновление движка Wiki, обновление Page-Creator, развертывание Minio. - Настройка системы мониторинга - Илья Постников
Система мониторинга включает в себя средство сбора метрик и временну́ю базу данных Prometheus и систему визуализации Grafana. Процесс настройки включал в себя установку программ-экспортеров на целевые устройства, настройку сбора метрик с этих устройств и создание панелей для визуализации метри(дашбордов) в Grafana - Документация Wiki
Документация содержит инструкцию по сборке и развертыванию скриптов различными способами, также перечень модулей и зависимостей.
14.1. Созданы структурные диаграммы С4 уровня системы(взаимодействие Wiki со сторонними сервисами), уровня контейнеров (составляющие части: скрипты, приложения). - Светлана Мелехина
14.2. MIEM Wiki.js (модифицированный движок Wiki.js) - Илья Постников
14.3. Page-Creator (скрипт генерации страниц) - Илья Постников
14.4. Webhook Server (сервер обработки вебхуков) - компонентная С4 диаграмма - Светлана Мелехина, документация - Никита Гаврилов
14.5. Wiki Deploy (набор скриптов для управления развертыванием) - Никита Гаврилов
14.6. User Generator (генератор страниц пользователей) - Светлана Мелехина
14.7. Wiki Client (Клиент Wiki.js) - Светлана Мелехина
14.8. Cabinet Client (Клиент Кабинета) - Светлана Мелехина
14.9. Taiga Client (Клиент Тайги) - Светлана Мелехина
14.10. Page-Converter (Сервер конвертации страниц) диаграмма классов - Светлана Мелехина
14.11. Описание инстансов (production, dev) - Илья Постников, Светлана Мелехина - Документация Zulip
Документация содержит инструкцию по сборке и развертыванию скриптов различными способами, также перечень модулей и зависимостей.
15.1. Структурные диаграммы С4 уровня системы(взаимодействие Zulip со сторонними сервисами), уровня контейнеров (составляющие части: скрипты, приложения). - Светлана Мелехина
15.2. Документация движка Zulip - Илья Постников
15.3. Duplication detector (скрипт для проверки дубликатов среди ново зарегистрировавшихся пользователей) - Никита Гаврилов
15.4. Zulip script (скрипт синхронизации Zulip)
15.5. Zulip Cabinet-link (связующий скрипт для Кабинета) - Никита Гаврилов
15.6. Rename stream bot (бот для переименования каналов Zulip) - Никита Гаврилов
15.7. Документация Production-сервера Zulip - Илья Постников
15.8. Документация Dev-сервера Zulip - Никита Гаврилов
¶ Результаты: описание разработанной системы
Сервисы Wiki, Zulip приведены к состоянию в котором они удовлетворяют требованиям готовности. Каждый из сервисов подготовлен к отчуждаемому хостингу, возможности его использовать независимо от команды разработки. Сервисы соответствуют единой структуре:
- каждый из микросервисов(составные части сервиса) представляет собой Docker контейнер
- имеется комплект документации, описывающей процедуру развертывания (См. Wiki, Zulip) различными способами: вручную или с помощью Docker, документация по настройке и обслуживанию каждого сервиса;
- Архитектура каждого сервиса и его составляющих представлена в виде диаграмм, а также описана в документации;
- Для каждого приложения (См. Wiki, Zulip) настроен механизм CI/CD: проверка(линт) и тестирование кода, сборка и выгрузка образов docker, учёт версий, контроль изменений, автоматические релизы(См. репоз-й Wiki, Zulip);
- Настроены и находятся в использовании тестовый и эксплуатационный серверы;
- Настроен мониторинг для отслеживания работоспособности сервиса
Сервис Wiki: - Разработан микросервис для интеграции с Taiga, Gitlab, Cabinet, позволяющий создавать страницы Wiki
- Разработан микросервис для конвертации страниц из Wiki в форматы Tex, PDF с возможностью применения шаблонов по ГОСТ (ЕСПД, ЕСКД), научной статьи или отчета по ВКР
¶ Вики
Архитектура сервиса. Wiki состоит из:
- Движка, который является ПО с открытым исходным кодом (движок модифицирован под нужды МИЭМ)
- Скриптов, которые вносят информацию в Wiki, а именно создают страницы (page-creator, user-generator)
- Веб-приложений, создающих страницы(webhook server) и использующих сервис для своей работы (page-converter).
Также сервис для своей работы использует библиотеки для интеграции с Gitlab, Taiga, Cabinet.
-370.png)
¶ Zulip
Архитектура:
Сервис состоит из:
- Движка, который является ПО с открытым исходным кодом
- Скриптов взаимодействующих с Api Zulip (Duplications detector, Rename stream bot, Zulip script, Zulip Cabinet-link)
- Клиента необходимого для работы с Api Кабинета (Cabinet Client)
¶ Проверка на соответствие требованиям
Оба сервиса, Wiki и Zulip соответствуют требованиям готовности. А именно, соответствие обеспечивается:
- Наличием документации необходимой и достаточной для автономного развертывания и подготовке к работе сервисов.
- Наличием документации о работе всех микросервисов
- Возможностью проверить на соответствие системным требованиям, обеспечивается работоспособной системой мониторинга
- Работоспособностью микросервисов и скриптов
¶ Реализация и внедрение результатов проекта
Таким образом, выдвинутые требования были полностью реализованы и внедрены на примере Wiki, Zulip. Данные сервисы сейчас развернуты и находятся в эксплуатации.
¶ Примеры работы ПО, описание использованных инструментов
Дашборд, предназначенный для отслеживания работоспособности серверов, на которых развернуты сервисы:
Pipeline - работа автоматизированного процесса тестирования и сборки:
Инструменты(DevOps):
- Docker (Контейнеризация), Docker compose - запуск и управление группами контейнеров с использованием конфигурационных файлов
- GitLab (Учет версий, контроль изменений, хранение исходников, CI/CD)
- Grafana, Prometheus (Мониторинг сервисов)
¶ Новизна/преимущества решений, полученных по результатам Проекта
Одним из ключевых решений было использовать методологию DevOps для доработки сервисов до соответствия требованиям готовности. Таким образом, сервисы Wiki, Zulip в текущем виде служат примером сервисов с отчуждаемым хостингом, на основе которого можно планировать создание новых программных продуктов и модифицировать уже существующие.
¶ Публикации
Идеи, развитые в рамках выполнения проекта были доложены на межвузовской конференции имени Е.В. Арменского