BMSTU/04-telematics.tex

217 lines
22 KiB
TeX
Raw Normal View History

2023-02-13 13:59:23 +03:00
\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{Введение}
2023-02-14 10:08:47 +03:00
DevOps -- стратегия разработки ПО, призванная устранить разрыв между разработчиками, и другими командами. Методология автомтизации технологических процессов сборки, настройки и развёртывания программного обеспечения. Методология предполагает активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обсулуживанию и взаимную интеграцию их технологических процессов друг в друга, для обеспечения высокого качества программного продукта.
Методологии разработки - waterfall (последовательный переход от одного этапа к другому), agile (scrum, lean) -- гибкая методология, система идей. Ключевой принцип - разработка через короткие итерации.
Водопадная модель разработки (Waterfall-разработка):
2023-02-14 12:34:47 +03:00
\begin{itemize}
\item Системные и программные требования: закрепляются в PRD (product requirements documents, документ требований к продукту).
\item Анализ: воплощается в моделях, схемах и бизнес-правилах.
\item Дизайн: разрабатывается внутренняя архитектура ПО, способы реализации требований; Не только интерфейс, и внешний вид ПО, но и его внутренняя структурная логика.
\item Кодинг: непосредственно пишется код программы, идёт интеграция ПО.
\item Тестирование: баг-тестеры (тестировщики) проверяют финальный продукт, занося в трекеры сведения о дефектах кода программы или функционала. В случае ошибок и наличия времени/финансов происходит исправление багов.
\item Операции: продукт адаптируется под разные операционные системы, регулярно обновляется для исправления обнаруженных пользователями багов и добавления функционала. В рамках стадии также осуществляется техническая поддержка клиентов.
\end{itemize}
2023-02-14 10:08:47 +03:00
2023-02-14 12:34:47 +03:00
Основные принципы гибкой методологии:
\begin{itemize}
\item Люди и взаимодействие важнее процессов и инструментов
\item работающий продукт важнее исчерпывающей документации
\item сотрудничество с заказчиком важнее согласования условий контракта
\item готовность к изменениям важнее следования первоначальному плану.
\end{itemize}
2023-02-14 10:08:47 +03:00
2023-02-14 12:34:47 +03:00
Обычно ИТ-команда это разработчики(Dev), тестировщики(QA), группа эксплуатации(Ops). Толчком к появлению девопс стало появление микросервисов. Цели девопс -- Сокращение времени выхода на рынок, надёжность (снижение частоты отказов новых релизов), сокращение времени выполнения исправлений, уменьшение количества времени на восстановления (в случае сбоя).
2023-02-13 13:59:23 +03:00
2023-02-14 12:34:47 +03:00
девопс предлагает представителям ранее разрозненных подразделений координировать свои действия. Культура: совместная работа и согласованность, изменения в сфере участия и ответственности, сокращение циклов выпуска (не количество, а сами циклы), непрерывное обучение.
2023-02-13 13:59:23 +03:00
2023-02-14 12:34:47 +03:00
Жизненный цикл приложения
2023-02-13 13:59:23 +03:00
2023-02-14 12:34:47 +03:00
\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}
2023-02-13 13:59:23 +03:00
2023-02-14 12:34:47 +03:00
Девопс предполагает представителям ранее разрозненных подразделений компании координировать свои действия и совместно создавать более качественные и надёжные продукты (постоянная обратная связь и оптимизация). Совместная работа и согласованность, изменения в сфере участия и ответственности, сокращение циклов выпуска, непрерывное обучение.
2023-02-13 13:59:23 +03:00
2023-02-14 12:34:47 +03:00
методики девопс
2023-02-13 13:59:23 +03:00
\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}
2023-02-14 12:34:47 +03:00
\includegraphics[width=12cm]{04-t-devops-table.jpg}
\end{figure}
2023-02-13 13:59:23 +03:00
2023-02-14 12:34:47 +03:00
Внедрение облачных технологий в корне изменило способы создания развёртывания и эксплуатации приложений. Преимущества: затраты, скорость, глобальный масштаб, производительность, эффективность, надёжность, безопасность.
2023-02-13 13:59:23 +03:00
Три способа развёртывания облачных служб:
\begin{itemize}
\item Публичное облако -- всё принадлежит облачному поставщику.
\item частное облако -- ресурсы только одной компании, локаный ЦОД (иногда аутсорс ЦОД)
\item гибридное облако
\end{itemize}
модели обслуживания:
\begin{itemize}
\item IaaS -- infrastructure (серверы, виртуальные машины, итд с оплатой по мере использования);
\item PaaS -- platform (среда по управлению, доставке, итд, упрощает разработчикам настройку связок);
\item Saas -- software (предоставление уже разработанного ПО как услуги);
\end{itemize}
2023-02-14 12:34:47 +03:00
В облаке, с помощью девопс возможно:
2023-02-13 13:59:23 +03:00
\begin{itemize}
\item создание собственных облачных приложений
\item тестирование и сборка приложений
\item хранение, резервное копирование, восстановление данных
\item анализ данных
\item доставка ПО по запросу
\end{itemize}
2023-02-14 12:34:47 +03:00
DevOps-инженер -- высококвалифицированный специалист, который отвечает за автоматизацию всех этапов создания приложений и обеспечивает взаимодействие программистов и системных администраторов. Прорабатывает сборку, доставку и тестирование. Build-инженер, Release-инженер, Automation-инженер, Security-инженер.
\begin{itemize}
\item [+] высокий заработок
\item [+] востребованность
\item [+] интересные задачи
\item [+] перспектива карьерного роста
\item [-] непрерывное обучение (\textit{а минус ли это? прим. Овчинников})
\item [-] необходимость знать много из разных областей
\item [-] возможны стрессовые ситуации и высокая нагрузка
\end{itemize}
2023-02-13 13:59:23 +03:00
Необходимые знания:
\begin{itemize}
\item Основы программирования (базовый уровень, несколько языков)
\item освоиться в принципах работы ОС
\item понимать облачные и гибридные решения
\item разбираться в системах оркестрации
\item освоить принципы работы микросервисов
\item понимать принципы работы с системами конфигурации
\end{itemize}
Используемые инструменты -- Jenkins, Docker, Kubernetes, Git, Приложения для управления инфраструктурой (Terraform), платформенные и облачные сервисы, утилиты мониторинга и оповещений.
2023-02-17 12:10:11 +03:00
\section{Система контейнеризации Docker}
2023-02-27 15:52:29 +03:00
\subsection{Виртуализация и контейнеризация}
2023-02-17 12:10:11 +03:00
Микросервисная архитектура -- это такой подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными, используя легковесные механизмы. Такой подход получил распространение в середине 2010х годов в связи с развитием гибких практик разработки.
До появления микросервисов и контейнеров повсеместно использовались монолитные приложения на основе систем виртуализации.
Особенности монолитных приложений
\begin{itemize}
\item много зависимостей
\item долгая разработка
\item повсеместное использование виртуализации
\end{itemize}
2023-02-27 15:52:29 +03:00
Виртуализацция -- это технология с помощью которой на одном физическом устройстве можно создать несколько виртуальных компьютеров. На компьютере с одной ОС можно запустить несколько других ОС или приложений. ОС запускаются в виртуальной среде, но используется инфраструктура хоста и позволяет им работать на одном устройстве изолированно друг от друга. ОС компьютера, на котором работает виртуальная среда, называется хост-системой, а ОС, которая запускается в этой виртуальной среде -- гостевой системой. Хостовая и гостевая ОС могут иметь взаимоисключающие компоненты, но виртуальная среда позволяет урегулировать эти конфликты.
2023-02-17 12:10:11 +03:00
2023-02-27 15:52:29 +03:00
Виртуальная среда создаётся при помощи программной или аппаратной схемы -- гипервизора -- инструмента, обеспечивающего параллельное управление несколькими ОС на одном хосте.
2023-02-17 12:10:11 +03:00
2023-02-27 15:52:29 +03:00
\subsection{Виртуализация}
Гипервизор -- это инструмент, обеспечивающий параллельное управление несколькими ОС на хосте.
\begin{figure}[H]
\centering
\fontsize{12}{1}\selectfont
\includesvg[scale=1.01]{pics/04-t-00-hyperv.svg}
\end{figure}
Типы гипервизоров
2023-02-17 12:10:11 +03:00
Гипервизоры:
\begin{itemize}
2023-02-27 15:52:29 +03:00
\item аппаратные -- VMWare ESX, Citrix XenServer, MS Hyper-V;
\item устанавливаемые поверх базовой ОС -- MS Virtual PC, VMWare Workstation, VirtualBox;
\item гибридные -- Citrix XenServer, Microsoft Hyper-V.
2023-02-17 12:10:11 +03:00
\end{itemize}
2023-02-27 15:52:29 +03:00
Назрела необходимость в ином подходе к построению архитектуры приложений, при котором ядро ОС поддерживают несколько изолированных экземпляров пользовательского пространства вместо одного (namespaces)\footnote{namespace -- это функция ядра Linux, позволяющая изолировать и виртуализировать глобальные системные ресурсы множества процессов.}. Возникновение контейнеризации -- контейнерной виртуализации. Контейнеризация использует ядро хост системы, оставаясь при этом не менее функциональной и обеспечивающей необходимую изоляцию.
2023-02-17 12:10:11 +03:00
2023-02-27 15:52:29 +03:00
Контейнерная виртуализация -- это способ, при котором виртуальная среда запускается прямо из ядра хотовой ОС (то есть без установки другой ОС). В данном случае изоляцию ОС и приложений поддерживает контейнер. Контейнер содержит всё, что нужно для запускаемого в нём приложения: код, библиотеки, инструменты и настройки. Всё это упаковано в отдельный образ, работу которого запускает контейнерный движок.
2023-02-17 12:10:11 +03:00
2023-02-27 15:52:29 +03:00
В случае с контейнерами у нас есть базовая аппаратная инфраструктура (железа компьютера), ОС и движок, установленный на этой ОС. Движок управляет контейнерами, которые работают с библиотеками и зависимостями сами, в одиночку. В случае виртуальной машины у нас есть ОС на базовом оборудовании (наше железо), затем гипервизор, а затем виртуальные машины. У каждой ВМ внутри своя ОС. Контейнеры загружаются быстрее и работают эффективнее.
2023-02-17 12:10:11 +03:00
2023-02-27 15:52:29 +03:00
Проблемы контейнеризации. Для контейнеров используется виртуализация на уровне ядра, то есть от гипервизора можно отказаться. Однако:
2023-02-17 12:10:11 +03:00
\begin{itemize}
2023-02-27 15:52:29 +03:00
\item контейнер использует ядро хост системы, а отсюда проблемы с безопасностью;
2023-02-17 12:10:11 +03:00
\item в контейнере может быть запущен экземпляр ОС только с тем же ядром, что и у хост ОС.
\end{itemize}
Возможно получить доступ к возможностям Windows и Linux одновременно при помощи WSL.
2023-02-27 15:52:29 +03:00
Как решить проблемы проблемы контейнеризации:
2023-02-17 12:10:11 +03:00
\begin{itemize}
\item следование принципу единственной ответственности (Single responsibility principle)
\item Всё необходимое должно быть в самом контейнере
\item Образы должны быть небольшого размера
\item контейнер должен быть эфемерным
\end{itemize}
2023-02-27 15:52:29 +03:00
Контейнеризаторы приложений (Docker, LXC)
2023-02-17 12:10:11 +03:00
2023-02-27 15:52:29 +03:00
Докер -- платформа автоматизации и доставки приложений с открытым исходным кодом. Платформа позволяет быстрее тестировать и выкладывать приложения, запускать на одной машине требуемое количество контейнеров.
2023-02-17 12:10:11 +03:00
\begin{itemize}
\item сервер dockerd
\item API
\item CLI
\end{itemize}
Компоненты докер
\begin{itemize}
2023-02-27 15:52:29 +03:00
\item хост -- хост ПК, компьютер, на котором работает докер.
\item демон -- фоновый процесс, работающий на хосте постоянно и ожидающий команды управления. Имеет информацию обо всех контейнерах на хосте. Демон знает всё о контейнерах, запущенных на одном хосте -- сколько всего контейнеров, какие из них работают, где хранятся образы и так далее.
\item клиент -- клиент при помощи с котрого пользователь взаимодействует с демоном. Это может быть консоль, API или графический интерфейс.
2023-02-17 12:10:11 +03:00
\item образ -- неизменяемый образ приложения (можно представить как установочный диск)
\item контейнер -- развёрнутое на основе образа и запущенное приложение.
\item докерфайл -- файл-инструкция для сборки докер-образа. Строки файла это слои образа. Инструкции обрабатываются последовательно.
\item docker registry -- репозиторий, в котором хранятся образы (докерхаб)
\end{itemize}
2023-02-27 15:52:29 +03:00
Образ -- шаблон с набором инструкций, предназначенных для создания контейнера. Приложения упаковываются в образ, из которого затем создаются контейнеры.
2023-02-17 12:10:11 +03:00
Контейнер -- уже собранное, настроенное и запущенное на основе образа приложение в изолированное среде.
2023-02-13 13:59:23 +03:00
\end{document}