217 lines
22 KiB
TeX
217 lines
22 KiB
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}
|