DevOps -- стратегия разработки ПО, призванная устранить разрыв между разработчиками, и другими командами. Методология автомтизации технологических процессов сборки, настройки и развёртывания программного обеспечения. Методология предполагает активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обсулуживанию и взаимную интеграцию их технологических процессов друг в друга, для обеспечения высокого качества программного продукта.
Методологии разработки - waterfall (последовательный переход от одного этапа к другому), agile (scrum, lean) -- гибкая методология, система идей. Ключевой принцип - разработка через короткие итерации.
Водопадная модель разработки (Waterfall-разработка):
\item Системные и программные требования: закрепляются в PRD (product requirements documents, документ требований к продукту).
\item Анализ: воплощается в моделях, схемах и бизнес-правилах.
\item Дизайн: разрабатывается внутренняя архитектура ПО, способы реализации требований; Не только интерфейс, и внешний вид ПО, но и его внутренняя структурная логика.
\item Кодинг: непосредственно пишется код программы, идёт интеграция ПО.
\item Тестирование: баг-тестеры (тестировщики) проверяют финальный продукт, занося в трекеры сведения о дефектах кода программы или функционала. В случае ошибок и наличия времени/финансов происходит исправление багов.
\item Операции: продукт адаптируется под разные операционные системы, регулярно обновляется для исправления обнаруженных пользователями багов и добавления функционала. В рамках стадии также осуществляется техническая поддержка клиентов.
Обычно ИТ-команда это разработчики(Dev), тестировщики(QA), группа эксплуатации(Ops). Толчком к появлению девопс стало появление микросервисов. Цели девопс -- Сокращение времени выхода на рынок, надёжность (снижение частоты отказов новых релизов), сокращение времени выполнения исправлений, уменьшение количества времени на восстановления (в случае сбоя).
девопс предлагает представителям ранее разрозненных подразделений координировать свои действия. Культура: совместная работа и согласованность, изменения в сфере участия и ответственности, сокращение циклов выпуска (не количество, а сами циклы), непрерывное обучение.
\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}
внедряя методики девопс, различные подразделения стремятся обеспечить надёжность системы и высокую доступность, свести простои к нулю, а также повысить уровень безопасности и усовершенствовать управление.
Девопс предполагает представителям ранее разрозненных подразделений компании координировать свои действия и совместно создавать более качественные и надёжные продукты (постоянная обратная связь и оптимизация). Совместная работа и согласованность, изменения в сфере участия и ответственности, сокращение циклов выпуска, непрерывное обучение.
Внедрение облачных технологий в корне изменило способы создания развёртывания и эксплуатации приложений. Преимущества: затраты, скорость, глобальный масштаб, производительность, эффективность, надёжность, безопасность.
DevOps-инженер -- высококвалифицированный специалист, который отвечает за автоматизацию всех этапов создания приложений и обеспечивает взаимодействие программистов и системных администраторов. Прорабатывает сборку, доставку и тестирование. Build-инженер, Release-инженер, Automation-инженер, Security-инженер.
\begin{itemize}
\item [+] высокий заработок
\item [+] востребованность
\item [+] интересные задачи
\item [+] перспектива карьерного роста
\item [-] непрерывное обучение (\textit{а минус ли это? прим. Овчинников})
\item [-] необходимость знать много из разных областей
\item [-] возможны стрессовые ситуации и высокая нагрузка
\item Основы программирования (базовый уровень, несколько языков)
\item освоиться в принципах работы ОС
\item понимать облачные и гибридные решения
\item разбираться в системах оркестрации
\item освоить принципы работы микросервисов
\item понимать принципы работы с системами конфигурации
\end{itemize}
Используемые инструменты -- Jenkins, Docker, Kubernetes, Git, Приложения для управления инфраструктурой (Terraform), платформенные и облачные сервисы, утилиты мониторинга и оповещений.
Микросервисная архитектура -- это такой подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными, используя легковесные механизмы. Такой подход получил распространение в середине 2010х годов в связи с развитием гибких практик разработки.
До появления микросервисов и контейнеров повсеместно использовались монолитные приложения на основе систем виртуализации.
Виртуализацция -- это технология с помощью которой на одном физическом устройстве можно создать несколько виртуальных компьютеров. На компьютере с одной ОС можно запустить несколько других ОС или приложений. ОС запускаются в виртуальной среде, но используется инфраструктура хоста и позволяет им работать на одном устройстве изолированно друг от друга. ОС компьютера, на котором работает виртуальная среда, называется хост-системой, аОС, которая запускается в этой виртуальной среде -- гостевой системой. Хостовая и гостевая ОС могут иметь взаимоисключающие компоненты, но виртуальная среда позволяет урегулировать эти конфликты.
Виртуальная среда создаётся при помощи программной или аппаратной схемы -- гипервизора -- инструмента, обеспечивающего параллельное управление несколькими ОС на одном хосте.
Назрела необходимость в ином подходе к построению архитектуры приложений, при котором ядро ОС поддерживают несколько изолированных экземпляров пользовательского пространства вместо одного (namespaces)\footnote{namespace -- это функция ядра Linux, позволяющая изолировать и виртуализировать глобальные системные ресурсы множества процессов.}. Возникновение контейнеризации -- контейнерной виртуализации. Контейнеризация использует ядро хост системы, оставаясь при этом не менее функциональной и обеспечивающей необходимую изоляцию.
Контейнерная виртуализация -- это способ, при котором виртуальная среда запускается прямо из ядра хотовой ОС (то есть без установки другой ОС). В данном случае изоляцию ОС и приложений поддерживает контейнер. Контейнер содержит всё, что нужно для запускаемого в нём приложения: код, библиотеки, инструменты и настройки. Всё это упаковано в отдельный образ, работу которого запускает контейнерный движок.
В случае с контейнерами у нас есть базовая аппаратная инфраструктура (железа компьютера), ОС и движок, установленный на этой ОС. Движок управляет контейнерами, которые работают с библиотеками и зависимостями сами, в одиночку. В случае виртуальной машины у нас есть ОС на базовом оборудовании (наше железо), затем гипервизор, а затем виртуальные машины. У каждой ВМ внутри своя ОС. Контейнеры загружаются быстрее и работают эффективнее.
Докер -- платформа автоматизации и доставки приложений с открытым исходным кодом. Платформа позволяет быстрее тестировать и выкладывать приложения, запускать на одной машине требуемое количество контейнеров.
\item хост -- хост ПК, компьютер, на котором работает докер.
\item демон -- фоновый процесс, работающий на хосте постоянно и ожидающий команды управления. Имеет информацию обо всех контейнерах на хосте. Демон знает всё о контейнерах, запущенных на одном хосте -- сколько всего контейнеров, какие из них работают, где хранятся образы и так далее.
\item клиент -- клиент при помощи с котрого пользователь взаимодействует с демоном. Это может быть консоль, API или графический интерфейс.
Образ -- шаблон с набором инструкций, предназначенных для создания контейнера. Приложения упаковываются в образ, из которого затем создаются контейнеры.
Образ -- это единица, используемая для распространения приложений. Контейнер --
ПО, упакованное в контейнер:
\begin{itemize}
\item код приложения
\item системные пакеты
\item двоичные файлы
\item библиотеки
\item файлы конфигурации
\itemОС, работающую в контейнере
\end{itemize}
Например, разрабатываем портал отслеживания заказов, который будут использоваться торговыми точками некоторой компании. Нам нужно рассмотреть полный стек ПО длоял выполнения этого веб-приложения. MVC .Net Core, и мы планируем развернуть егос помощью Nginx в качестве обратного прокси-сервера в Ubuntu Linux.
Образ контейнера -- это переносимый пакет, содержащий ПО. При запуске он становится контейнером. Образ неизменен, после сборки образа, невозможно внести в него изменения.
ОС узла -- это ОС в которой выполняется модуль Docker.
ОС контейнера -- это ОС, которая входит в упакованный образ. В контейнере можно включать различные версии ОС Linux/Windows.
ОС контейнера изолирована от ОС узла и представляет собой среду, в которой развёртывается и выполняется приложение. В сочетании с неизменностью образа...
Что такое стековая файловая система унификации (unionfs)
Мы создаём образ для описанного веб-приложения. Расположим дистрибутив Ubuntu как базовый образ поверх файловой системы загрузки. Далее устанавливаем Nginx, который таким образом будет поверх Ubuntu.
Dockerfile -- это текстовый файл с инструкциями
\begin{itemize}
\itemВ файле определяется базовый и родительский образ, используемый для создания образа
\item команды для обновления базаоай ОС
\item ...
\end{itemize}
Базовый образ использует Docker scratch -- пустой образ, использующий ОС хоста.
Родительский образ -- предустановленная ОС или другая основа.
Оба типа образов...
Образы -- это файлы большого размера...
\subsection{Управление контейнерами}
Контейнер имеет ЖЦ, которым можно управлять и отслеживать состояние контейнера.
\begin{itemize}
\item создание
\item работа
\item приостановка
\item возобновление работы
\item запуск
\item остановка
\item перезапуск
\item принудительная остановка
\item удаление
\end{itemize}
\subsection{Работа с данными в Docker}
При планировании хранения данных контейнерным приложением необходимо помнить, что все данные из остановленных контейнеров уничтожаются.
Есть два основных способа обмена данными с контейнером -- тома (volume).
Контейнеры могут быть подключены...
Например, внутри контейнера по пути лежит файл индекс.хтмл.
Для монтирования данных используются следующие параметры: --вольюм и --маунт
Их различие в том, что маунт более явно заставляет указывать источник монтирования папки.
\subsection{Работа с сетью в Docker}
Конфигурация сети по умолчанию обеспечивает изоляцию контейнеров. Это позволяет..
Сеть типа мост -- конф по умолчанию к контейнерам при запуске, если иное не указано при запуске. Эта сеть является внутренней частной сетью, используемой контейнером. Она изолирует сеть узла от сети контейнера.
По умолчанию Docker не публикует порты контейнеров. Для включения сопоставления портов контейнеров и портов узла Docker используется флаг -п
Узел позволяет запускать непосредственно в сети узла.
