\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}
Виртуализация и контейнеризация

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

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

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

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

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

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

Новый подход к виртуализации

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

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

В случае с контейнерами у нас есть...

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

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

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

Контейнеризаторы приложений

Докер -- платформа автоматизации и доставки приложений.
\begin{itemize}
\item сервер dockerd
\item API
\item CLI
\end{itemize}

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

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

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


\end{document}