Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации Ордена Трудового Красного Знамени Государственное образовательное бюджетное учреждение высшего профессионального образования Московский технический университет связи и информатики Центр заочного обучения по программе бакалавриата Кафедра «Сетевые информационные технологии и сервисы» Курсовая работа по дисциплине «Технологии и средства облачных сервисов» на тему «Проектирование облачного приложения проведения конференций» Вариант №25 Выполнил: студент 5 курса заочного отделения группы БСТ1952 Соломинов И.В. Проверил: к.т.н., доцент Гадасин Денис Вадимович.. Москва 2023 г. Содержание Введение ................................................................................................................... 3 1. Общая архитектура приложения........................................................................ 4 2. Выбор средств разработки.................................................................................. 6 2.1 Выбор оркестратора контейнеров ................................................................ 7 2.2 Выбор платформы для хранения постоянных данных ............................... 8 2.3 Выбор реляционной системы управления базами данных ........................ 9 2.4 Выбор языка программирования и фреймворка для серверного приложения ......................................................................................................... 11 2.5 Выбор фреймворка для реализации клиентской части ............................ 12 3. Техническое задание ......................................................................................... 17 4. Проектирование ................................................................................................. 20 5. Разработка. ......................................................................................................... 27 5.1. Разработка серверного приложения .......................................................... 27 5.2. Разработка клиентской части. .................................................................... 31 Заключение............................................................................................................. 33 Список литературы ............................................................................................... 34 Введение В последние несколько лет классические поездки конференции стали вытесняться онлайн-трансляциями, в виду удобства для желающих послушать доклады, не выезжая в другой город. Пандемия COVID-19 изменила жизнь миллионов людей по всему миру: практически все образовательные учреждения и компании перешли на удалённый режим работы, много массовых мероприятий было отменено. Таким образом, жизнь «в режиме онлайн» постепенно стала нормой, а ценность самообразования возросла. Согласно отчету Bizzabo, 60% пользователей смартфонов используют свои устройства для участия в онлайн-конференциях. При этом количество таких людей постоянно растет не только из-за недавней пандемии и социального дистанцирования, но и потому, что видеозвонки предоставляют широкие возможности для общения внутри организации или между группами. Вышеперечисленные проблемы стали предпосылкой для разработки сервиса, который позволяет: ● заранее узнать о предстоящей IT-конференции; ● запланировать её просмотр в удобное для пользователя время вместо того, чтобы тратить время на поиски видеозаписи мероприятия или подстраиваться под часовой пояс страны/городаорганизатора; ● настроить профиль пользователя, чтобы добавлять интересные или понравившиеся доклады в «избранное». Такой метод позволяет ускорить и облегчить поиск в дальнейшем; ● у каждого доклада есть «тег», спикер и конференция, это позволяет группировать и сортировать доклады по упомянутым выше признакам, а также позволяет упрощать, ускорять и облегчать поиск понравившегося или интересующего доклада в дальнейшем. 1. Общая архитектура приложения. Разработанные инфраструктурные компоненты должны предоставлять следующий функционал: 1) обеспечивать возможность развертывания клиентского и серверного приложений с применением подхода CI/CD; 2) предоставлять файловое хранилище для клиентского и серверного приложений; 3) обеспечивать маршрутизацию и балансировку HTTP-трафика между компонентами системы; 4) обеспечивать мониторинг компонентов системы; 5) обеспечивать обновление приложений внутри системы без простоя для пользователя; 6) предоставлять систему управления реляционными базами данных и брокера сообщений для серверного приложения. Серверная часть сервиса содержит в себе основную бизнес-логику и занимается обработкой запросов от клиентской части приложения. Необходимые функции: 1) предоставлять REST-API клиентскому приложению для получения данных; 2) предоставлять интерфейс администратора для управления контентом; 3) предоставлять возможность регистрации и аутентификации пользователей посредством HTTP-API; 4) отправлять Email пользователям для подтверждения аккаунта; 5) предоставлять подписанные ссылки для просмотра видео для клиентского приложения. Взаимодействие пользователя и системы осуществляется по следующему алгоритму: 1) пользователь делает запрос в наше приложение на Next.js и получает ответ от сервера с HTML-страницей; 2) при этом весь статический контент, которая должна загрузить вебстраница, будет получен с географически распределённой сети доставки контента (далее CDN); 3) при возникновении каких-либо ошибок на стороне клиента они будут отправлены в удалённый мониторинг Sentry; 4) ошибки на стороне сервера также отправляются в Sentry; 5) разработчик при помощи настроенной систем continuous integration (далее CI) и continuous delivery (далее CD) в кратчайшие сроки доставляет изменения в работе приложения до конечных пользователей; 6) аналогично, при помощи систем CD и CD доставляются все изменения статического контента на сервера CDN сервиса Surge; 7) также разработчик имеет отдельный сервис с интерфейсом для мониторинга ошибок, которые содержат максимально подробную информацию для их устранения. Рисунок 1 – Описание общей архитектуры. 2. Выбор средств разработки Для реализации проекта необходимо выбрать технологии для следующих компонентов: 1) оркестратор контейнеров; 2) платформу для хранения постоянных данных; 3) реляционную систему управления базами данных; 4) язык программирования и фреймворк для разработки серверного приложения; Выбранные технологии для каждого из компонентов системы должны удовлетворять следующим критериям: 1) распространенность - технология должна широко использоваться в профессиональной среде и применяться ведущими компаниями на рынке разработки ПО; 2) открытый исходный код и свободная лицензия - технология должна использовать принципы открытого обеспечения и лицензироваться по GPL, BSD, аналогичных или производных от них лицензий; 3) широкое сообщество пользователей - при использовании свободнораспространяемого программного обеспечения возникают риски появления ошибок и наличие большого сообщества позволяет ускорить решение потенциальных проблем; 4) расширяемость - используемое программное обеспечение должно иметь возможность расширения функционала для покрытия потребностей в нестандартных ситуациях; 5) стабильность работы - используемые технологии должны быть отказоустойчивыми и способными работать при больших нагрузках и обеспечивать стабильную работу. Клиентская часть веб-приложения. Для веб-разработки создано очень много фреймворков и библиотек, и порой очень сложно сделать правильный выбор, чтобы получить оптимальное соотношение между скоростью и качеством разработки. В настоящее время для создания веб-приложения недостаточно использовать только HTML/JS/CSS, возможностей которых было достаточно 10 лет назад как пользователям, так и разработчикам. Сейчас существует много инструментов, которые не только упрощают разработку, но и позволяют применять эффективные подходы к разработке, а также повышают отзывчивость интерфейса даже на тех устройствах, которые уже «не поддерживаются». Фреймворк для веб-приложения должен соответствовать следующим критериям: 1) эффективная работа с DOM-деревом; 2) Server-Side Rendering (далее SSR); 3) Search Engine Optimization (далее SEO); 4) возможность гибкой интернализации. 2.1 Выбор оркестратора контейнеров Наиболее востребованными решениями в области оркестровки контейнеров являются Elastic Container Service от Amazon Web Services, Kubernetesот компании Google и Kubernetes Engine от компании Mirantis (ранее имел название Docker Enterprise). Использовать решение от Amazon в данном проекте не представляется возможным, поскольку оно поставляется в формате SaaS. Ключевыми преимуществами Kubernetes над конкурентами являются: 1) автоматизированное развертывание с возможностью автоматического отката на старую версию в случае ошибок и поддержка сине-зеленого развертывания; 2) автоматическое поддержание требуемого числа реплик; 3) продвинутая система healthcheck-ов; 4) система обнаружения сервисов и балансировки нагрузки; 5) развитая экосистема инструментов, позволяющая тонко настраивать многие компоненты. 6) распространяется по лицензии Apache License 2.0; 7) механизм Custom Resource Definition, позволяющий создавать пользовательские объекты с требуемым поведением; 8) используется в крупных IT-компаниях как основной инфраструктурный элемент; 9) множество расширений для автоматизации систем мониторинга, управления HTTP-трафиком и развертывания типовых решений для баз данных, брокера сообщений и других. Наиболее распространенными решениями являются kubeadm, kubespray, microk8s. В данном проекте будет использовано решение microk8s, как наиболее легковесное и мощное решение, готовое к работе в реальных условиях. Большими плюсами инсталляции Kubernetes на базе microk8s являются простота присоединения рабочих узлов к существующему кластеру, широкий выбор расширений для управления HTTP-трафиком, мониторингом и DNS внутри кластера. 2.2 Выбор платформы для хранения постоянных данных Идеологически контейнеры внутри оркестраторов являются расходным материалом. При блокировке процесса внутри контейнера, провалах проверок состояния оркестраторы пересоздают контейнеры и постоянные данные, записанные в них, могут теряться. Решением является механизм постоянных хранилищ, зачастую представленный в виде Persistent Volumes. Данный механизм позволяет оркестраторам сохранять данные контейнеров в постоянную память исполняющей ЭВМ. Однако, этот механизм противоречит динамической структуре оркестратора, поскольку постоянные хранилища не являются пересоздаваемым ресурсом. Для решения данной проблемы и создания отказоустойчивых систем обычно используются сторонние решения, обеспечивающие механизмы самовосстановления и репликации данных. Официальная документация Kubernetes предлагает расширения для монтирования постоянных хранилищ как к облачным провайдерам, так и к развернутым системам внутри компании. Среди представленных систем хранения можно выделить Ceph свободную программную объектную сеть хранения, использующую продвинутые механизмы балансировки данных и способную работать на тысячах рабочих узлов. Данное решение используется в компаниях «Google» (используется как хранение данных видеохостинга «Youtube»), «Twitter» и «Yahoo!». Для оркестраторов контейнеров существует реализация Ceph, носящая название Rook. Решение работает на базе Custom Resource Definition, обеспечивая работу с программными компонентами хранилища на уровне объектов оркестратора и бесшовную интеграцию с механизмом постоянных хранилищ. Распространяется Rook на базе лицензии Apache 2.0 и сертификацию от Cloud Native Computing Foundation - организации, развивающей критически важные компоненты глобальной облачной инфраструктуры, членами которой являются крупнейшие IT-компании (Google, Alibaba, Apple, Arm Holdings, Amazon, Cisco, Intel). С учетом приведенных выше преимуществ, Ceph на базе Rook был выбран как основное хранилище постоянных данных. 2.3 Выбор реляционной системы управления базами данных Данные являются важнейшим компонентом большинства информационных систем. Без накопленных и обработанных массивов информации практически любая система теряет ценность как для бизнеса, так и для его клиентов. Реляционные системы управления базами данных являются стандартным подходом при проектировании веб-приложений, поскольку удовлетворяют следующим критериям: 1) поддержание полноты и целостности хранимых данных за счет механизмов уникальности данных, внешних и первичных ключей, наложения ограничений на данные и контроля их связности; 2) поддержка свойства транзакционности, позволяющее выполнять несколько операций как неделимое действие и возвращать данные в прошлое состояние в случае провала фиксации данных; 3) поддержка требований ACID. По данным рейтинга DB-Engines, рассчитанного на основании частоты упоминания, количества вакансий, общего интереса к системе и частоты дискуссий в профессиональной среде, можно выделить следующие системы: 1) Oracle; 2) MySQL; 3) Microsoft SQL Server; 4) PostgreSQL. Лицензии Oracle и Microsoft SQL Server запрещают использование бесплатных версий систем в коммерческих проектах и имеют закрытый исходный код, следовательно не подходят по причине отсутствия открытого исходного кода и свободной лицензии. После проведения сравнительного анализа систем PostgreSQL и MySQL первая система была выбрана как наиболее подходящая для проекта. Ключевые преимущества PostgreSQL перед MySQL: 1) сбалансированная производительность чтения и записи данных; 2) продвинутая поддержка конкурентных запросов, включающая создание индексов без блокировки; 3) поддержка объектной модели работы для реализации наследования таблиц и перегрузки функций; 4) лучшая стабильность работы при стандартной конфигурации; 5) поддержка множества расширений, позволяющая выполнять сложные манипуляции с данными на стороне БД (например, расширение pg_trgm, реализующее функционал нечеткого и полнотекстового поиска). Исходя из вышеперечисленного, PostgreSQL была выбрана как система управления реляционными базами данных для реализации проекта. 2.4 Выбор языка программирования и фреймворка для серверного приложения Главный компонент любого приложения - язык программирования. Он определяет границы производительности, расширяемости и безопасности написанного приложения. Немаловажным фактором является влияние языка на скорость разработки. Высокоуровневые языки программирования (например, Java, Python, C#, JavaScript) значительно ускоряют разработку за счет готовых библиотек для реализации готового функционала и мощной поддержки абстракций. На данный момент в области информационных технологий существует множество языков программирования, реализующих различные парадигмы, различные способы исполнения итоговых текстов программ и распространения. По результатам агрегирования рейтингов TIOBE и PYPL можно выделить следующие языки программирования: 1) Python 2) Java 3) C/C++ 4) C# 5) JavaScript Наиболее оптимальным выбором из списка лидеров является Python высокоуровневый интерпретируемый язык программирования, созданный для быстрой разработки приложений и повышенной читаемости кода. Python обладает следующими преимуществами: 1) скорость разработки - язык легко читается и поддерживается, имеет минималистичный синтаксис, но обладает широким функционалом; 2) возможность расширения - язык поддерживает расширение кода с помощью C/C++ кода, позволяя оптимизировать важные фрагменты кода и сложные алгоритмы; 3) обширное сообщество - язык обладает одним из самых больших сообществ в области информационных технологий, постоянно создающих новые библиотеки, позволяющие ускорить разработку; Совокупность вышеперечисленных факторов позволяет выбрать Python как надежный и удобный инструмент, который долго не потеряет актуальность и позволит разрабатывать качественное программное обеспечение. Python имеет множество развитых фреймворков для написания WEBприложений. На момент написания работы в среде фреймворков можно выделить следующих основных лидеров: 1) Django 2) Flask 3) Tornado 4) Bottle 5) AIOHTTP Абсолютным лидером по скорости разработки и наличию вспомогательных инструментов является Django. Django предоставляет готовые решения для построения аутентификации, маршрутизации URL, имеет ORM с поддержкой автоматического создания миграций, механизмы валидации данных и множество расширений для фреймворка. 2.5 Выбор фреймворка для реализации клиентской части Для клиентской части в качестве рассматриваемых фреймворков (библиотек) для веб-приложения было решено взять следующие: 1) Angular.js 2) Vue.js 3) React.js Angular.js Angular - это JavaScript фреймворк, реализующий паттерн MVVM (далее Model-View-ViewModel), основанный в 2009 году, отлично подходит для создания интерактивных веб-приложений. Преимущества Angular: • наличие новых функций, таких как Generation Angular, использующих библиотеки NPM из CLI, Generation; • наличие подробной документации, позволяющей разработчику получить всю необходимую информацию, не прибегая к помощи его коллег. Однако это и своеобразный недостаток - требует больше времени для обучения; • односторонняя привязка данных обеспечивает исключительное поведение приложения, что сводит к минимуму риск возможных ошибок; • MVVM позволяет разработчикам работать отдельно над одним и тем же разделом приложения, используя один и тот же набор данных; • внедрение зависимостей от компонентов, связанных с модулями и модульностью в целом; • структура и архитектура, специально созданные для большой масштабируемости проекта. Недостатки Angular: • разнообразие различных структур (Injectables, Components, Pipes, Modules и т. д.) усложняет процесс изучения по сравнению с ним же в React и Vue, у которых есть только «Component»; • относительно медленная производительность, учитывая различные показатели. React.js React.js - это JavaScript библиотека, разработанная Facebook в 2013 году, отлично подходит для создания современных одностраничных приложений любого размера и масштаба. Преимущества React: • легко изучить благодаря простому дизайну, использованию JSX или TSX (HTML-подобный синтаксис) для шаблонов и очень подробной документации. Разработчики тратят больше времени на написание современного JavaScript и меньше беспокоятся о коде, специфичном для фреймворка; • очень быстрый благодаря реализации React Virtual DOM и различным оптимизациям рендеринга; • отличная поддержка рендеринга на стороне сервера, что делает его мощной платформой для контент-ориентированных приложений; • первоклассная поддержка Progressive Web App (далее PWA) благодаря генератору приложений «Create-React-App» (далее CRA); • привязка данных является односторонней, что приводит к уменьшению количества нежелательных побочных эффектов; • Redux - самая популярная платформа для управления состоянием приложений в React, её легко учить и использовать; • React реализует концепции функционального программирования (далее FP), создавая простой в тестировании и многократно используемый код; • приложения могут быть созданы с помощью TypeScript или Facebook’s Flow, имеющими встроенную поддержку JSX; • переход между версиями, как правило, очень прост: Facebook предоставляет «кодовые модули» для автоматизации большей части процесса. Недостатки React: • React не однозначен и оставляет разработчикам возможность выбирать лучший способ развития. Это может быть решено сильным лидерством проекта и хорошими процессами; • сообщество делится по способам написания CSS в React, которые разделяются на традиционные таблицы стилей (CSS Modules) и CSSin-JS (то есть Emotion и Styled Components); • React отходит от компонентов на основе классов, что может стать препятствием для разработчиков, которым более комфортно работать с объектно-ориентированным программированием (далее ООП); Vue.js Vue.js - это JavaScript фреймворк, основанный в 2013 году, который идеально подходит для создания высокоадаптируемых пользовательских интерфейсов и сложных одностраничных приложений. Преимущества Vue.js: • усиленный HTML. Это означает, что Vue.js имеет много характеристик схожих с Angular, а это, благодаря использованию различных компонентов, помогает оптимизации HTML-блоков; • Vue.js имеет очень подробную документацию, которая может ускорить процесс обучения для разработчиков и сэкономить много времени на разработку приложения, используя только базовые знания HTML и JavaScript; • Vue.js можно использовать как для создания одностраничных приложений, так и для более сложных веб-интерфейсов приложений. Важно, что небольшие интерактивные элементы можно легко интегрировать в существующую инфраструктуру без негативных последствий; • Vue.js может помочь в разработке довольно больших шаблонов многократного использования, которые могут быть сделаны почти за тоже время, что и более простые; • Vue.js весит около 20 КБ, сохраняя при этом свою скорость и гибкость, что позволяет достичь гораздо лучшей производительности по сравнению с другими фреймворками. Недостатки Vue.js: • Vue.js занимает довольно небольшую долю рынка по сравнению с React или Angular, поэтому сложно эффективно обмениваться знаниями и опытом. Next.js Проведение сравнительного анализа преимуществ и недостатков существующих на сегодняшний день популярных фреймворков и библиотек позволяет сделать выбор в пользу разработки с использованием React.js. React.js - библиотека, позволяющая только разрабатывать пользовательские интерфейсы. Для того, чтобы использовать технологии интернационализации, SSR и SEO, необходим отдельный фреймворк, реализующий эти функции. «Поверх» React.js работает ограниченное число фреймворков: CRA и Next.js. Проведём сравнительный анализ. CRA содержит настроенную среду для разработки SPA-приложений, но слабо поддерживает работу с SSR и SEO. Отличительными особенностями фреймворка Next.js является не только возможность эффективной работы с SSR и SEO, но и ряд других преимуществ, рассмотрим их подробнее: • эффективная работа с DOM-деревом, так как в основе его лежит React.js; • «ленивая» загрузка картинок, которая позволяет не «нагружать» устройство пользователя, когда в этом нет необходимости, например, когда картинка находится за пределами экрана пользователя; • поддержка интернационализации, которая эффективно реализуется с помощью клиентского роутинга; • настроенная среда, необходимая для сборки приложения; • поддержка аналитики веб-приложения; • поддержка SSR; • поддержка гибкой настройки SEO. Таким образом, возможности Next.js позволяют построить требуемую инфраструктуру, удовлетворяющую перечисленным ранее критериям. 3. Техническое задание Реализовать сервис агрегирования материалов конференций для упрощения доступа и поиска профессиональных знаний. При этом технические средства для разработки должны быть выбраны следующим образом. Конфигурация виртуальных машин для построения инфраструктуры должна осуществляться инструментом Ansible. Инфраструктура для проекта в режиме прототипа должна быть построена на базе дистрибутива Kubemetes microk8s и функционировать на одном узле в режиме master/worker и содержать в себе следующие компоненты: 1) сервер управления реляционными базами данных PostgreSQL; 2) брокер сообщений RabbitMQ; 3) система постоянного хранения данных на базе Rook Ceph. При установке Rook Ceph использовать версию 1.5.6. Для нормального функционирования хранилища должны быть установлены следующие ресурсы: 1) Ceph Block Pool и Storage Class с значением provisioner: rookceph.rbd.csi.ceph.com для обеспечения блочных хранилищ; 2) два Persistent Volume Claim на базе Storage Class из пункта 1 для обеспечения монтируемых хранилищ для PostgreSQL и RabbitMQ; 3) Ceph Object Store, Storage Class с конфигурацией provisioner: rookceph.ceph.rook.io/bucket и Object Bucket Claim для обеспечения работы S3-совместимого хранилища; 4) Service для экспортирования S3-хранилища наружу. Развертывание RabbitMQ и PostgreSQL должно производиться с использованием Helm Chart, в конфигурации предоставляемой bitnami. Подготавливаемые системы должны сохранять свои постоянные данные на Persistent Volumes, сконфигурированные Rook Ceph. Реквизиты доступа от всех сервисов должны хранится внутри оркестратора с помощью механизма Kubernetes Secrets. Основное приложение бизнес-логики серверной части должно быть построено на базе Python фреймворка Django с использованием Django REST Framework и контейнеризировано через Docker. Приложение, предоставляющее пользовательское API, должно реализовывать следующие маршруты: • POST /register - реализует функционал регистрации нового пользователя в системе, принимая адрес электронной почты, логин и пароль пользователя; • GET /confirm - реализует функционал подтверждения пользователя, принимает Query параметр h с хэшем из полученного пользователем электронного письма; • POST /token - реализует функционал аутентификации пользователя по протоколу JWT, принимает на вход адрес электронной почты и пароль, возвращает JWT токены для доступа и обновления; • POST /token/refresh - принимает на вход активный JWT токен и реализует функционал его обновления; • POST /token/verify - реализует функционал проверки данных токена (истечение срока действия, корректность токена); • GET /speakers, GET /speakers/:id - REST маршруты для получения данных сущности спикеров; • GET /conferences, GET /conferences/:id - REST маршруты для получения данных сущности конференций; • GET /videos, GET /videos/:id - REST маршруты для получения данных сущности видео; • GET /tags, GET /tags/:id - REST маршруты для получения данных сущности тэгов; • GET /reviews, GET /reviews/:id, POST /reviews/ - REST маршруты для получения и добавления данных сущности оценок. Хранилище пользовательских и статических данных должно быть организовано на базе SB-совместимого хранилища на базе Rook Ceph. Приложение с интерфейсом администратора должно запускаться в отдельном Deployment и быть полностью отделено от API. Данное решение позволит использовать реквизиты доступа к S3 с правами на чтение и запись только для администраторов. Экспортирование приложения c API наружу должно быть построено на базе механизма Name Based Virtual Hosting в Ingress, Service для SBхранилище через NodePort, приложение администратора через NodePort. Сборка и развертывание приложения в Kubernetes должно осуществляться через автоматический CI/CD в Gitlab с использованием Gitlab Runner. Виртуальные машины с Gitlab Runner и Kubernetes должны находится в одной внутренней подсети облачного провайдера. 4. Проектирование Ядро инфраструктуры базируется на следующих компонентах: • виртуальная машина с установленным Kubemetes; • виртуальная машина с установленным Gitlab Runner; • внешний сервис Gitlab для хранения кода и создания CI/CD цепочек. Принципиальная схема изображена на рисунке 4.1. Рисунок 4.1 – Схема инфраструктуры в разрезе виртуальных машин. Виртуальная машина 1 содержит в себе master/worker узлы для управления Kubernetes и развертывания приложений. Виртуальная машина 2 содержит в себе Docker Daemon и сервис Gitlab Runner, занимающийся исполнением стадий сборки и развертывания, описанных в репозитории. Обе виртуальные машины соединяются внутренней сетью облачного поставщика услуг. Такая настройка взаимодействия виртуальных машин позволяет реализовать алгоритм управления Kubemetes при развертывании приложения следующим образом: 1) в репозиторий приложения помещается файл с конфигурацией стадий CI/CD; 2) при изменении кода в master ветке запускается процесс CI/CD; 3) на стадии сборки Gitlab отправляет пакет команд в Gitlab Runner на ВМ 2; 4) пакет команд исполняется внутри виртуальной машины 2 и результат сборки отправляется в хранилище пакетов Gitlab; 5) на стадии развертывания пакет команд вновь отправляется на ВМ 2, происходит подстановка в шаблоны объектов Kubernetes необходимых значений и через внутреннюю сеть провайдера Gitlab Runner обращается к kube-apiserver для развертывания новых контейнеров, что обеспечивает безопасность при взаимодействии. Для корректной работы приложения в Kubernetes необходимо организовать следующие инфраструктурные компоненты. 1) объектная сеть хранения Ceph; 2) сервер баз данных PostgreSQL и брокер сообщений RabbitMQ; 3) S3-совместимое хранилище. Постоянные данные последних 3 пунктов должны храниться на базе интерфейсов хранения Ceph. Принципиальная схема объектов Kubernetes с представлена на рисунке 4.2. Рисунок 4.2 - Принципиальная схема объектов Kubemetes. Таким образом на базе Ceph создается высоконадежное хранилище, которое используется как при постоянном хранении данных от PostgreSQL и RabbitMQ, так и в хранении данных S3. Для развертывания инфраструктуры в режиме прототипа минимально необходимо две виртуальные машины: • виртуальная машина для настройки Gitlab Runner; • виртуальная машина для развертывания Kubernetes. К первой виртуальной машине предъявляются стандартные требования в соответствии с документацией Gitlab Runner - операционная система Linux, 1 CPU, 4 GB оперативной памяти. Вторая виртуальная машина запускает экземпляр Microk8s в режиме мастер/рабочий узел и требования, в соответствии с документацией Microk8s, следующие: • Ubuntu 20.04 LTS; • минимально 4 GB оперативной памяти; • 20 GB хранилища. Поскольку дополнительные внутри экземпляра приложения Kubernetes (отказоустойчивое будет развернуты хранилище Ceph, приложение бизнес-логики, системы мониторинга и Ingress) на виртуальную машину накладываются дополнительные требования: • дополнительное устройство хранения данных; • системная библиотека lvm2; • дополнительные 12 GB оперативной памяти. Для настройки виртуальных машин будет использовано ПО Ansible, обеспечивающее идемпотентность исполняемых на виртуальных машинах команд и позволяющее управлять инфраструктурой в соответствии с методологией «Инфраструктура как код». Первым этапом необходимо настроить виртуальную машину для Gitlab Runner. Для корректной настройки необходимо выполнить следующие шаги: 1) установить на виртуальную машину ПО Docker для работы исполнителя CI/CD в режиме Docker-in-Docker; 2) установить Gitlab Runner и выдать необходимые права в системе; 3) зарегистрировать внутри системы Runner как сервис; 4) зарегистрировать на Gitlab.com Runner для передачи команд. Для выполнения этих шагов были созданы две Ansible роли, первая устанавливает на ВМ Docker, вторая проводит необходимую настройку. Для настройки виртуальной машины с Kubernetes были созданы роли microk8s и rook_ceph_setup, реализующие следующий алгоритм настройки: 1) установить snapd; 2) через snap установить пакет microk8s; 3) настроить containerd внутри snap-пакета на работу с удаленным Gitlab Registry; 4) активировать расширения Ingress и Prometheus; 5) опубликовать сервис с Grafana наружу; 6) установить пакет lvm2; 7) развернуть необходимые объекты Kubernetes для Ceph; 8) обеспечить доступ к Ceph Dashboard извне кластера; 9) создать хранилища на базе Ceph для потребителей; 10) развернуть сервера PostgreSQL и RabbitMQ. Настройка Prometheus Operator дает возможность подключать в единый центр мониторинга метрики от других приложений. После исполнения вышеописанных Ansible ролей виртуальная машина готова к установке постоянных хранилищ, активации S3-совместимого хранилища и развертыванию серверов PostgreSQL и RabbitMQ. После применения конфигурации возможно начать развертывание баз данных и брокера сообщений. Для их установки в Kubernetes будет использована утилита Helm, позволяющая использовать заранее готовые контейнеры и объекты Kubernetes для развертывания. Следующий этап – развертывание PostgreSQL на базе постоянного хранилища Ceph. Завершающий этап – развертывание RabbitMQ. После запуска контейнера брокер сообщений будет готов к работе. Реквизиты доступа сохраняются в Kubernetes используя механизм Secrets, позволяя защищенно хранить реквизиты и передавать их в использование контейнеров. Экспортирование сервисов построено на механизмах Ingress и NodePort. Клиентское приложение размещается основных портах 80 и 443, позволяя пользователю по имени домена или IP-адресу получать приложение, не используя дополнительных постфиксов. Приложение, поставляющее API для клиентского приложения, размещается с помощью механизма Name Based Virtual Hosing, предоставляемого Ingress. Данный механизм позволяет маршрутизировать траффик на приложение с помощью измененного HTTP- заголовка Host. Таким образом можно избежать прямого использования приложения через NodePort. Приложение для администратора является внутренним и его можно экспортировать через NodePort. SB-хранилище экспортируется через NodePort, поскольку URL не является видимыми для пользователя. Для разработки клиентской части развернем базовый шаблон вебприложения на основе Next.js с использованием языка TypeScript. Внутри проекта идёт разделение на следующие каталоги: • api – каталог, который содержит в себе бизнес-логику для • осуществления запросов в backend; • components – компоненты написанные на JSX, которые будут использоваться на страницах; • contants – константы, которые хранят в себе конфигурацию текущего • окружения; • libs – библиотеки, разработанные в ходе реализации веб-приложения; • node_modules – сторонние фреймворки и библиотеки, которые требуются для разработки веб-приложения; • mocks - набор данных, которые предоставляет backend, чтобы исполнять сценарии CI/CD не обращаясь напрямую к API; • pages – основные страницы веб-приложения; • public – статичный контент веб-приложения; • SWR – каталог с хуками для библиотеки SWR, которая осуществляет запрос за данными и умеет их кэшировать и обновлять. В результате настройки получена готовая для работы инфраструктура, состоящая из следующих компонентов: 1) виртуальная машина с Gitlab Runner; 2) виртуальная машина с microk8s; 3) блочные и объектные хранилища на базе Rook Ceph; 4) SB-совместимый интерфейс доступа к объектному хранилищу; 5) сервера базы данных PostgreSQL и брокера сообщений RabbitMQ; 6) мониторинг на базе Prometheus Operator; 7) маршрутизирующие компоненты на базе Ingress. 8) клиентская часть на основе Next.js 5. Разработка. 5.1. Разработка серверного приложения Необходимо реализовать приложение, предоставляющее API для клиентского приложения и хранящее данные о конференциях в реляционной базе данных. Так же приложение должно обеспечивать механизмы авторизации и аутентификации пользователей, регистрации новых, предоставлять интерфейс администратора и отдачу подписанных ссылок на видеоматериалы из SS-хранилища Предлагаемый подход решения проблемы: 1) разработать схему базы данных; 2) создать систему авторизации и регистрации; 3) реализовать API для клиентского приложения; 4) настроить панель администратора; 5) реализовать работу с S3-хранилищем. Для создания каркаса проекта использована утилита Django-admin. Версия интерпретатора Python - 3.8, версия Django - 3.0.5. Первый этап разработки - проектирование схемы базы данных и создание моделей Django ORM с подходом CodeFirst (с начала создаются модели, после чего с помощью механизма миграций происходит изменение БД). Построенная схема БД для хранения данных пользователей показана на рисунке 5.1. Жирная точка на конце связи обозначает отношение «один ко многим», две жирные точки на конце связи - «многие ко многим». Рисунок 5.1. - Схема базы данных для хранения данных пользователей Для хранения данных о конференциях, видео, спикерах, оценок и связанными с ними тегами реализована следующая схема базы данных (рисунок 5.2). Рисунок 5.2. - Схема базы данных для хранения конференций, спикеров, видео, оценок и тегов. Следующим этапом разработки является написание отображений и сериализаторов данных для API регистрации, авторизации и подтверждения пользователей. Для реализации описанного функционала создано приложение внутри проекта с названием authorizer, спроектирована новая модель пользователя, наследующаяся от стандартной модели User из Django, и написаны соответствующие отображения и сериализаторы для нее. На этом этап работы с данными пользователей завершен и можно переходить к созданию REST API для клиентского приложения. Для отделения сущностей вся работа с конференциями и их побочными моделями вынесена в отдельное приложение Django conferences. Интерфейс администратора реализуется через стандартное приложение Django Admin, генерирующее CRUD для каждой зарегистрированной модели в модуле admin.py внутри приложения conferences. Интеграция с SB-хранилищем реализована через вспомогательную библиотеку django-storages, обеспечивающую механизмы записи и чтения пользовательских и статических данных. Для переключения стандартного хранилища Django на S3 необходимо установить в модуле DEFAULT_FILE_STORAGE настроек и константы settings.py STATICFILES_STORAGE на строку storages.backends.s3boto3.S3Boto3Storage и установить реквизиты доступа на чтение S3 хранилища. В процессе разработки было принято решение разделить приложение администратора и приложение с API для пользователей. Данное решение позволяет разделить конфигурации работы с S3 и ответственность приложения, предоставляя администраторам полные права на управление S3 хранилищем, а потребителям API - права только на чтение. В результате разработки создано приложение на Django, предоставляющее весь описанный в техническом задании функционал. Для развертывания приложения в настроенную инфраструктуру были описаны следующие объекты Kubernetes: 1) три объекта Deployment, описывающие конфигурацию приложений администратора, пользователя и рабочий узел для Celery. Каждое приложение имеет 2 реплики и механизмы проверки состояния контейнера (Readiness и Liveness probes); 2) два объекта Service, экспортирующие приложения для клиентского HTTP API и администратора наружу Kubernetes; 3) объект Ingress, обеспечивающий перенаправление трафика для клиентского HTTP API по HTTP заголовку Host api.django.com на приложения внутри Kubernetes. Для организации доставки приложения из репозитория в Kubernetes создана конфигурация Gitlab CI из следующих этапов: 1) build - начинает сборку Docker образа при слиянии или выполнения команды git push в ветки main или develop и публикует его в хранилище образов Gitlab с тегом по шаблону <название ветки><короткий SHA коммита>; 2) deploy - развертывает приложение в Kubernetes. Используется базовый образ dtzar/helm-kubectl, в который устанавливается утилита gettext для подстановки данных в шаблоны объектов Kubernetes через envsubrst, после чего утилитой kubectl конфигурация применяется в Kubernetes. В результате данного этапа работы было создано Python приложение на фреймворке Django, реализующее весь необходимый функционал. Для Gitlab CI описана конфигурация сборки и развертывания образа приложения в Kubernetes. Так же были созданы шаблоны объектов Kubernetes для использования в этапе развертывания в Gitlab CI. 5.2. Разработка клиентской части. После получения макетов основных страниц веб-приложения приступаем к их разработке. Макет страницы регистрации. Логика работы страницы: 1. пользователь вводит свои данные в соответствующие поля форм; 2. нажимает на кнопку «Зарегистрироваться»; 3. из клиентского кода веб-приложения уходит HTTP-запрос в backend; 4. backend возвращает JWT-токен, который далее используется для аутентификации запросов получения контента на остальных страницах; 5. JWT-токен сохраняется в локальное хранилище браузера; 6. в случае возникновения ошибки регистрации, например логин или почта пользователя уже существуют в системе, пользователь увидит страницу регистрации с уведомлением об ошибке; 7. пользователь переадресуется на страницу со списком конференций. Макет страницы аутентификации. Логика работы страницы: 1. пользователь вводит логин и пароль в соответствующие поля форм; 2. нажимает на кнопку «Войти»; 3. из клиентского кода веб-приложения уходит HTTP-запрос в backend; 4. backend возвращает JWT-токен, который далее используется для аутентификации запросов получения контента на остальных страницах; 5. JWT-токен сохраняется в локальное хранилище браузера; 6. в случае возникновения ошибки аутентификации, например логин или пароль пользователя указаны неверно, пользователь увидит страницу аутентификации с уведомлением об ошибке; 7. пользователь переадресуется на страницу со списком конференций. Бизнес-логика страниц, перечисленных выше, очень схожа и работает по следующему алгоритму: ● из клиентского кода веб-приложения уходит HTTP-запрос в backend, с указанием конкретного типа запрашиваемого контента; ● backend возвращает HTTP-ответ с контентом, который отрисовывает клиентский код согласно макетам. Заключение Облачные технологии меняют принципы проектирования приложений. Облачные приложения не монолитны, а состоят из небольших децентрализованных служб. Эти службы взаимодействуют между собой через API с помощью асинхронного обмена сообщениями или событиями. Приложения можно масштабировать горизонтально, добавляя новые экземпляры, если появляется потребность в этом. С этими тенденциями связаны новые сложности. Приходится распространять состояние приложения. Операции выполняются параллельно и асинхронно. Система в целом должна сохранять устойчивость в случае сбоев. Развертывания должны быть автоматизированными и предсказуемыми. Для понимания состояния системы крайне важно наладить эффективный мониторинг и телеметрию. В данной работе была спроектирована инфраструктура на базе оркестратора контейнеров Kubernetes, Rook Ceph, Ingress. Созданы Ansible роли для конфигурации виртуальных машин с Gitlab Runner и Kubernetes. Развернута виртуальная машина в режиме master/worker с инсталляцией Kubernetes на базе microk8s. Список литературы 1. Современный учебник JavaScript: сайт. – URL: https://learn.javascript.ru (дата обращения: 10.10.2023). – Текст: электронный. 2. Документация по TypeScript c официального сайта: сайт. – URL: https://www.typescriptlang.org/ (дата обращения: 12.10.2023). – Текст: электронный. 3. Основы CSS: сайт. – URL: https://developer.mozilla.org/ru/docs/Learn/Getting_started_with_the_web/ CSS_basics (дата обращения: 17.10.2023). – Текст: электронный. 4. Документация по Angular c официального сайта: сайт. – URL: https://angular.io (дата обращения: 11.10.2023). – Текст: электронный. 5. Документация по Vue.js: сайт. – URL: https://vuejs.org (дата обращения: 11.10.2023). – Текст: электронный. 6. Документация по React c официального сайта: сайт. – URL: https://ru.reactjs.org (дата обращения: 11.10.2023). – Текст: электронный. 7. Документация по Redux: сайт. – URL: https://reactdev.ru/redux/ (дата обращения: 11.10.2023). – Текст: электронный. 8. Документация по Next.js c официального сайта: сайт. – URL: https://nextjs.org (дата обращения: 13.10.2023). – Текст: электронный. 9. Документация по Docker c официального сайта: сайт. – URL: https://www.docker.com/get-started (дата обращения: 18.10.2023). – Текст: электронный. 10. Документация разработчика Sentry c официального сайта: сайт. – URL: https://develop.sentry.dev/ (дата обращения: 01.11.2023). – Текст: электронный. 11. Документация по GitHub c официального сайта: сайт. – URL: https://docs.github.com/en/actions (дата обращения: 29.10.2023). – Текст: электронный. 12. Статья Amazon Web Services «Что такое DevOps» – URL: https://aws.amazon.com/ru/devops/what-is-devops (Дата обращения – URL: 02.11.2023) 13. Документация Docker Swarm https://docs.docker.com/engine/swarm (Дата обращения 29.10.2023) 14. Документация Openshift – URL: https://www.openshift.com/learn/what-isopenshift (Дата обращения 18.10.2023) 15. Документация Kubernetes – URL: https://kubernetes.io/docs/home/ (Дата обращения 19.10.2023) 16. Документация Kubernetes StorageClass – URL: https://kubernetes.io/docs/concepts/storage/storageclasses/#provisioner (Дата обращения 28.10.2023) 17. Документация Ceph – URL: https://ceph.io (Дата обращения 29.10.2023) 18. Документация Rook – URL: https://rook.io (Дата обращения 27.10.2023) 19. Рейтинг DB-Engines – URL: https://db-engines.com/en/ranking (Дата обращения 25.10.2023) 20. Индекс TIOBE – URL: https://www.tiobe.com/tiobe-index/ (Дата обращения 05.11.2023) 21. Рейтинг PYPL – URL: https://pypl.github.io/PYPL.html (Дата обращения 11.11.2023) 22. Документация Gitlab Runner – URL: https://docs.gitlab.com/runner/ (Дата обращения 13.11.2023) 23. Документация Ansible – URL: https://www.ansible.com (Дата обращения 17.11.2023) 24. Документация библиотеки Django-storages – URL: https://djangostorages.readthedocs.io/en/latest/ (Дата обращения 15.10.2023)