212 lines
19 KiB
TeX
212 lines
19 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}
|
||
Виртуализация и контейнеризация
|
||
|
||
Микросервисная архитектура -- это такой подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными, используя легковесные механизмы. Такой подход получил распространение в середине 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}
|