BMSTU/04-telematics.tex

\documentclass{article}

\input{settings/common-preamble}
\input{settings/bmstu-preamble}
\input{settings/fancy-listings-preamble}
\author{Мещеринова Ксения Владимировна}
\title{Телематика}
\date{2023-02-08}

\begin{document}
\sloppy
\fontsize{14}{18}\selectfont
\maketitle
\tableofcontents
\newpage
\section{Введение}
DevOps -- стратегия разработки ПО, призванная устранить разрыв между разработчиками, и другими командами. Методология автомтизации технологических процессов сборки, настройки и развёртывания программного обеспечения. Методология предполагает активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обсулуживанию и взаимную интеграцию их технологических процессов друг в друга, для обеспечения высокого качества программного продукта.

Методологии разработки - waterfall (последовательный переход от одного этапа к другому), agile (scrum, lean) -- гибкая методология, система идей. Ключевой принцип - разработка через короткие итерации.

Водопадная модель разработки (Waterfall-разработка):
\begin{itemize}
\item Системные и программные требования: закрепляются в PRD (product requirements documents, документ требований к продукту).
\item Анализ: воплощается в моделях, схемах и бизнес-правилах.
\item Дизайн: разрабатывается внутренняя архитектура ПО, способы реализации требований; Не только интерфейс, и внешний вид ПО, но и его внутренняя структурная логика.
\item Кодинг: непосредственно пишется код программы, идёт интеграция ПО.
\item Тестирование: баг-тестеры (тестировщики) проверяют финальный продукт, занося в трекеры сведения о дефектах кода программы или функционала. В случае ошибок и наличия времени/финансов происходит исправление багов.
\item Операции: продукт адаптируется под разные операционные системы, регулярно обновляется для исправления обнаруженных пользователями багов и добавления функционала. В рамках стадии также осуществляется техническая поддержка клиентов.
\end{itemize}

Основные принципы гибкой методологии:
\begin{itemize}
\item Люди и взаимодействие важнее процессов и инструментов
\item работающий продукт важнее исчерпывающей документации
\item сотрудничество с заказчиком важнее согласования условий контракта
\item готовность к изменениям важнее следования первоначальному плану.
\end{itemize}

Обычно ИТ-команда это разработчики(Dev), тестировщики(QA), группа эксплуатации(Ops). Толчком к появлению девопс стало появление микросервисов. Цели девопс -- Сокращение времени выхода на рынок, надёжность (снижение частоты отказов новых релизов), сокращение времени выполнения исправлений, уменьшение количества времени на восстановления (в случае сбоя).

девопс предлагает представителям ранее разрозненных подразделений координировать свои действия. Культура: совместная работа и согласованность, изменения в сфере участия и ответственности, сокращение циклов выпуска (не количество, а сами циклы), непрерывное обучение.

Жизненный цикл приложения

\begin{itemize}
\item \textbf{Планирование} помогает обеспечить командам гибкость и прозрачность
  \begin{itemize}
  \item представляют, определяют и описывают функции и возможности создаваемых приложений
  \item отслеживают ход работы на низком и высоком уровнях детализации
  \item создают журналы невыполненной работы, отслеживая ошибки, и так далее.
  \end{itemize}
\item \textbf{Разработка} включает написание, тестирование, проверку и интеграцию кода участниками команды. Быстро внедряют инновации, автоматизируя рутинные действия, а также запускают итерации с маленьким шагом при помощи автоматического тестирования и непрерывной интеграции.
\item \textbf{Доставка} -- это процесс последовательного и надёжного развёртывания приложений в рабочих средах. Этап доставки также включает развёртывание и настройку полностью управляемой базовой инфраструктуры, лежащей в основе этих сред.
  \begin{itemize}
  \item определяют процесс управления выпусками
  \item устанавливают автоматические шлюзы, с помощью которых приложения перемещаются между этапами, пока не станут доступными клиентам
  \end{itemize}
\item \textbf{Эксплуатация}.
  \begin{itemize}
  \item обслуживание
  \item мониторинг
  \item устранение неполадок приложений в рабочих средах
  \end{itemize}
  внедряя методики девопс, различные подразделения стремятся обеспечить надёжность системы и высокую доступность, свести простои к нулю, а также повысить уровень безопасности и усовершенствовать управление.
\end{itemize}

Девопс предполагает представителям ранее разрозненных подразделений компании координировать свои действия и совместно создавать более качественные и надёжные продукты (постоянная обратная связь и оптимизация). Совместная работа и согласованность, изменения в сфере участия и ответственности, сокращение циклов выпуска, непрерывное обучение.

методики девопс
\begin{itemize}
\item непрерывная доставка (CI/CD)
\item управление версиями (git)
\item гибкая разработка (DevOps)
\item инфраструктура как код (IaC)
\item управление конфигурацией
\item непрерывный мониторинг
\end{itemize}

\begin{figure}[H]
  \centering
  \includegraphics[width=12cm]{04-telematics-devops.png}

  \includegraphics[width=12cm]{04-t-devops-table.jpg}
\end{figure}

Внедрение облачных технологий в корне изменило способы создания развёртывания и эксплуатации приложений. Преимущества: затраты, скорость, глобальный масштаб, производительность, эффективность, надёжность, безопасность.

Три способа развёртывания облачных служб:
\begin{itemize}
\item Публичное облако -- всё принадлежит облачному поставщику.
\item частное облако -- ресурсы только одной компании, локаный ЦОД (иногда аутсорс ЦОД)
\item гибридное облако
\end{itemize}

модели обслуживания:
\begin{itemize}
\item IaaS -- infrastructure (серверы, виртуальные машины, итд с оплатой по мере использования);
\item PaaS -- platform (среда по управлению, доставке, итд, упрощает разработчикам настройку связок);
\item Saas -- software (предоставление уже разработанного ПО как услуги);
\end{itemize}

В облаке, с помощью девопс возможно:
\begin{itemize}
\item создание собственных облачных приложений
\item тестирование и сборка приложений
\item хранение, резервное копирование, восстановление данных
\item анализ данных
\item доставка ПО по запросу
\end{itemize}

DevOps-инженер -- высококвалифицированный специалист, который отвечает за автоматизацию всех этапов создания приложений и обеспечивает взаимодействие программистов и системных администраторов. Прорабатывает сборку, доставку и тестирование. Build-инженер, Release-инженер, Automation-инженер, Security-инженер.

\begin{itemize}
\item [+] высокий заработок
\item [+] востребованность
\item [+] интересные задачи
\item [+] перспектива карьерного роста
\item [-] непрерывное обучение (\textit{а минус ли это? прим. Овчинников})
\item [-] необходимость знать много из разных областей
\item [-] возможны стрессовые ситуации и высокая нагрузка
\end{itemize}

Необходимые знания:
\begin{itemize}
\item Основы программирования (базовый уровень, несколько языков)
\item освоиться в принципах работы ОС
\item понимать облачные и гибридные решения
\item разбираться в системах оркестрации
\item освоить принципы работы микросервисов
\item понимать принципы работы с системами конфигурации
\end{itemize}

Используемые инструменты -- Jenkins, Docker, Kubernetes, Git, Приложения для управления инфраструктурой (Terraform), платформенные и облачные сервисы, утилиты мониторинга и оповещений.

\section{Система контейнеризации Docker}
\subsection{Виртуализация и контейнеризация}

Микросервисная архитектура -- это такой подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными, используя легковесные механизмы. Такой подход получил распространение в середине 2010х годов в связи с развитием гибких практик разработки.

До появления микросервисов и контейнеров повсеместно использовались монолитные приложения на основе систем виртуализации.

Особенности монолитных приложений
\begin{itemize}
\item много зависимостей
\item долгая разработка
\item повсеместное использование виртуализации
\end{itemize}

Виртуализацция -- это технология с помощью которой на одном физическом устройстве можно создать несколько виртуальных компьютеров. На компьютере с одной ОС можно запустить несколько других ОС или приложений. ОС запускаются в виртуальной среде, но используется инфраструктура хоста и позволяет им работать на одном устройстве изолированно друг от друга. ОС компьютера, на котором работает виртуальная среда, называется хост-системой, а ОС, которая запускается в этой виртуальной среде -- гостевой системой. Хостовая и гостевая ОС могут иметь взаимоисключающие компоненты, но виртуальная среда позволяет урегулировать эти конфликты.

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

\subsection{Виртуализация}
Гипервизор -- это инструмент, обеспечивающий параллельное управление несколькими ОС на хосте.
\begin{figure}[H]
  \centering
  \fontsize{12}{1}\selectfont
  \includesvg[scale=1.01]{pics/04-t-00-hyperv.svg}
\end{figure}

Типы гипервизоров
Гипервизоры:
\begin{itemize}
\item аппаратные -- VMWare ESX, Citrix XenServer, MS Hyper-V;
\item устанавливаемые поверх базовой ОС -- MS Virtual PC, VMWare Workstation, VirtualBox;
\item гибридные -- Citrix XenServer, Microsoft Hyper-V.
\end{itemize}

Назрела необходимость в ином подходе к построению архитектуры приложений, при котором ядро ОС поддерживают несколько изолированных экземпляров пользовательского пространства вместо одного (namespaces)\footnote{namespace -- это функция ядра Linux, позволяющая изолировать и виртуализировать глобальные системные ресурсы множества процессов.}. Возникновение контейнеризации -- контейнерной виртуализации. Контейнеризация использует ядро хост системы, оставаясь при этом не менее функциональной и обеспечивающей необходимую изоляцию.

Контейнерная виртуализация -- это способ, при котором виртуальная среда запускается прямо из ядра хотовой ОС (то есть без установки другой ОС). В данном случае изоляцию ОС и приложений поддерживает контейнер. Контейнер содержит всё, что нужно для запускаемого в нём приложения: код, библиотеки, инструменты и настройки. Всё это упаковано в отдельный образ, работу которого запускает контейнерный движок.

В случае с контейнерами у нас есть базовая аппаратная инфраструктура (железа компьютера), ОС и движок, установленный на этой ОС. Движок управляет контейнерами, которые работают с библиотеками и зависимостями сами, в одиночку. В случае виртуальной машины у нас есть ОС на базовом оборудовании (наше железо), затем гипервизор, а затем виртуальные машины. У каждой ВМ внутри своя ОС. Контейнеры загружаются быстрее и работают эффективнее.

Проблемы контейнеризации. Для контейнеров используется виртуализация на уровне ядра, то есть от гипервизора можно отказаться. Однако:
\begin{itemize}
\item контейнер использует ядро хост системы, а отсюда проблемы с безопасностью;
\item в контейнере может быть запущен экземпляр ОС только с тем же ядром, что и у хост ОС.
\end{itemize}

Возможно получить доступ к возможностям Windows и Linux одновременно при помощи WSL.

Как решить проблемы проблемы контейнеризации:
\begin{itemize}
\item следование принципу единственной ответственности (Single responsibility principle)
\item Всё необходимое должно быть в самом контейнере
\item Образы должны быть небольшого размера
\item контейнер должен быть эфемерным
\end{itemize}

Контейнеризаторы приложений (Docker, LXC)

Докер -- платформа автоматизации и доставки приложений с открытым исходным кодом. Платформа позволяет быстрее тестировать и выкладывать приложения, запускать на одной машине требуемое количество контейнеров.
\begin{itemize}
\item сервер dockerd
\item API
\item CLI
\end{itemize}

Компоненты докер
\begin{itemize}
\item хост -- хост ПК, компьютер, на котором работает докер.
\item демон -- фоновый процесс, работающий на хосте постоянно и ожидающий команды управления. Имеет информацию обо всех контейнерах на хосте. Демон знает всё о контейнерах, запущенных на одном хосте -- сколько всего контейнеров, какие из них работают, где хранятся образы и так далее.
\item клиент -- клиент при помощи с котрого пользователь взаимодействует с демоном. Это может быть консоль, API или графический интерфейс.
\item образ -- неизменяемый образ приложения (можно представить как установочный диск)
\item контейнер -- развёрнутое на основе образа и запущенное приложение.
\item докерфайл -- файл-инструкция для сборки докер-образа. Строки файла это слои образа. Инструкции обрабатываются последовательно.
\item docker registry -- репозиторий, в котором хранятся образы (докерхаб)
\end{itemize}

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

Контейнер -- уже собранное, настроенное и запущенное на основе образа приложение в изолированное среде.


\end{document}