diff --git a/04-big-data-analysis-information-systems-developing-technologies.tex b/04-big-data-analysis-information-systems-developing-technologies.tex index 472d7e8..1a009f4 100644 --- a/04-big-data-analysis-information-systems-developing-technologies.tex +++ b/04-big-data-analysis-information-systems-developing-technologies.tex @@ -919,5 +919,77 @@ decision_function_shape='ovr', break_ties=False, random_state=None) \subsection{} +\newpage +\appendix +\setcounter{secnumdepth}{0} +\section*{Приложения} +\addcontentsline{toc}{section}{Приложения} +\renewcommand{\thesubsection}{\Asbuk{subsection}} +\subsection{Задачи с РК} +ловушка, 3 неразличимых выхода, 1вых 3ч 2вых 2ч ведёт обратно, 3 вых 1ч ведётобратно + +шанс с первого раза Мо1-1/3 +\begin{equation*} + \begin{gathered} + M = 1/3*3+1/3(1+M)+1/3(2+M)\\ + M-1/3M-1/3M=1+1/3+2/3\\ + 1/3M = 2\\ + M=6 + \end{gathered} +\end{equation*} + +$x \in [0,1]$, плотность распределения $f(x) = 1/2e^{-|x|}$, найти мат. ожидание и дисперсию +ChatGPT says: + + Математическое ожидание: + $$ + \mathbb{E}(X) = \int_{-\infty}^{\infty}xf(x)dx = + \int_{-1}^{0}\frac{x}{2}e^{x}dx + \int_{0}^{1}\frac{x}{2}e^{-x}dx + $$ + Интегрируем первое слагаемое по частям: + $$ + \int_{-1}^{0}\frac{x}{2}e^{x}dx = + \left[\frac{x}{2}e^{x}\right]_{-1}^{0} - + \int_{-1}^{0}\frac{1}{2}e^{x}dx = \frac{1}{2} - \frac{1}{2e} + $$ + Интегрируем второе слагаемое: + $$ + \int_{0}^{1}\frac{x}{2}e^{-x}dx = + -\left[\frac{x}{2}e^{-x}\right]_{0}^{1} + + \int_{0}^{1}\frac{1}{2}e^{-x}dx = \frac{1}{2} - \frac{1}{2e} + $$ + Суммируем: + $$ + \mathbb{E}(X) = \frac{1}{2} - \frac{1}{2e} + \frac{1}{2} - + \frac{1}{2e} = 1 - \frac{1}{e} \approx 0.632 + $$ + Дисперсия: + $$ + \mathbb{E}(X^2) = \int_{-\infty}^{\infty}x^2f(x)dx = + \int_{-1}^{0}\frac{x^2}{2}e^{x}dx + + \int_{0}^{1}\frac{x^2}{2}e^{-x}dx + $$ + Интегрируем по частям: + $$ + \int_{-1}^{0}\frac{x^2}{2}e^{x}dx = + \left[\frac{x^2}{2}e^{x}\right]_{-1}^{0} - \int_{-1}^{0}xe^{x}dx = + -\frac{1}{2} - \frac{1}{e} + $$ + $$ + \int_{0}^{1}\frac{x^2}{2}e^{-x}dx = + -\left[\frac{x^2}{2}e^{-x}\right]_{0}^{1} + \int_{0}^{1}xe^{-x}dx + = \frac{1}{2} - \frac{3}{2e} + $$ + Суммируем: + $$ + \mathbb{E}(X^2) = -\frac{1}{2} - \frac{1}{e} + \frac{1}{2} - + \frac{3}{2e} = 1 - \frac{5}{2e} \approx 0.472 + $$ + Используем формулу для дисперсии: + $$ + \text{Var}(X) = \mathbb{E}(X^2) - (\mathbb{E}(X))^2 \approx 0.472 + - (0.632)^2 \approx 0.109 + $$ + \end{document} \ No newline at end of file diff --git a/04-complex-electronic-devices-developing.tex b/04-complex-electronic-devices-developing.tex index f76742b..2a7b58d 100644 --- a/04-complex-electronic-devices-developing.tex +++ b/04-complex-electronic-devices-developing.tex @@ -585,13 +585,17 @@ $N=8$, $SNR=49,7dB$. реальный может быть 48,1 или 47,1 (пе \item параллельные \end{itemize} -Основной элемент -- это компаратор. +Основной элемент -- это компаратор. Усилитель, триггер шмидта, иногда стробирование и классический цифровой триггер. \begin{figure}[H] \centering \fontsize{12}{1}\selectfont \includesvg[scale=1.01]{pics/04-cedd-00-compare.svg} \end{figure} Это однобитный квантователь, перед ним стоит УВХ. + +\paragraph{АЦП параллельного преобразования} +Flash-ADC + \begin{figure}[H] \centering \fontsize{12}{1}\selectfont @@ -599,9 +603,105 @@ $N=8$, $SNR=49,7dB$. реальный может быть 48,1 или 47,1 (пе \end{figure} получаем 255 уровней квантования. на выходе 255-разрядный (позиционный, температурный) код. -Приоритетный шифратор формирует N-разрядный код. Слишком много компараторов (дорого, размер, потребление), зависит от точности резисторов (интегральная нелинейность), разброс задержек компараторов (решается цифровыми средствами), паразитные ёмкости. +Приоритетный шифратор формирует N-разрядный код. Часто накручивают логику дальше, например, коды Грея, чтобы избежать эффекта пузырька (паразитная единицка среди ноликов). +Слишком много компараторов (дорого, размер, потребление), зависит от точности резисторов (интегральная нелинейность), разброс задержек компараторов (решается цифровыми средствами), паразитные ёмкости. + +УВХ часто помогает стробировать сигнал и избавиться от части метастабильностей компараторов. + +\paragraph{Последовательного приближения} +ЦАП делать проще. проблем с реализацией логики никогда не было, регистр последовательного приближения даже выпускался отдельной схемой. + +с ЦАП даём опорное на компаратор, 10000000 это половина шкалы, сравниваем, далее компаратор говорит больше или меньше, 8 итераций, и регистр выдаёт сигнал данные готовы. +(1) + +Ушли от резисторов, пришли к конденсаторной логике (C-DAC). Компаратор линейный, нелинейности будут формироваться ЦАПоп, разрядность 10-12 бит, скорость до 1мгц. Самое важное, что мы занимаем место. + +Стоимость микросхемы определяется размером кремниевого камня (поэтому борятся за минимизацию). + +\paragraph{АЦП с интерполяцией} +Interpolation ADC Один из самых актуальных классов АЦП на сегодня + +(3) +Колическтво защёлок в компараторах не изменить, а усилители возможно +(4) +К=2 фактор интерполяции, нужные уровни интерполируем на резисторах, больше 4 не делают потому что резистор не идеальный элемент и формирует нелинейности, дргуих особых минусов нет. + +\paragraph{Folding ADC} +АЦП со сворачиванием + +(5) +старшие преобразуются напрямую 3 или 4 бита. младшие передаются на folding усилитель. +(6) +то есть входной сигнал сворачивается в один и тот же диапазон, и нам нужно много меньше компараторов, выигрыш в 8 раз. Реализовано на дифференциальных усилителях и верной коммутации их нагрузок. За счёт небольшой аналоговой обработки компараторы переиспользуются. +(7) +прямые подключаются только по нечётным, накрест - чётные. получается точный сигнал мы получим только с первого резистора, иногда только его и берут, это zero-crossing. + +\paragraph{folding and interpolating ADC} +(8) +проблемы с линейностью остаются. фактически все высокоскоростные АЦП сделаны так, потому что это на основе параллельного преобразования. + +\paragraph{Time interleaving} +АЦП со временным перемежением. + +Параллельно включаем несколько АЦП и на выходе мультплексируем. +(9) +В лоб засинхронизировать не получится, если работать только по фронтам то надо в 4 раза быстрее, нужно фазировать. +(10) +Ошибки у АЦП с перемежением +\begin{itemize} +\item смещения (11) разные нули +\item усиления (12) +\item временные (13) джиттер, приведёт к амплитудной ошибке +\end{itemize} + +\subsection{Конвейерные АЦП} +Pipeline ADC + +(14) + +Десятки (до сотен МГц) 1024 компаратора против 48 компараторов. На порядок снижается потребление. Набегают погрешности АЦП и ЦАП. Для некоторых задач может быть критичным, что существует конвейерная задержка. + +\subsection{Сигма-дельта} +$\Sigma-\Delta ADC$ +(15) + +Сумматор или вычитатель можно реализовать на вычитающем опреационном усилителе, интегратор это тоже ОУ, компаратор +(16) + +$$SNR = 6,02N+1,76dB = 7,78$$ + +для 24-рязрядного нужно 144дБ. +\begin{enumerate} +\item передискретизация (частоту берём в К раз больше) для Д-С-АЦП может быть в сотни или тысячи раз. +\item интегратор постоянно стремится минимизировать ошибку квантования (noise shaping) +\end{enumerate} + +принципиально отсутствует нелинейность. + +(17) +ДСМ второго порядка + +За счёт обратной связи происходит перенос спектра шума. + +\section{Методы построения ЦАП} +Максимально быстродействующий -- параллельный. +(18) +основная задача задать пороги источников тока, они формируют дифференциальную нелинейность + +\subsection{Сигма-Дельта ЦАП} +(19) \end{document} + +осциллограф с режимом стробоскопа. логический анализатор с функцией вычисления и последовательными протоколами + +(2) +транзисторы с тремя схемами включения +усилитель +дифференциальный усилитель +токовое зеркало +двухтактный выходной каскад +ячейка гильберта (умножитель) diff --git a/04-telematics.tex b/04-telematics.tex index 2dcc1dc..a7dac35 100644 --- a/04-telematics.tex +++ b/04-telematics.tex @@ -507,7 +507,19 @@ compose написан на python, конфигурация в yaml-файла докер-композ ямл - описывает процесс загрузки и настройки контейнеров. -Основные команды +\subsection{Основные команды} +К основным командам docker можно отнести: +\begin{itemize} +\item docker pull-скачивает образ +\item docker run - запускает контейнер на основе образа +\item docker ps - вызывает список запущенных контейнеров +\item docker exec - позволяет выполнять команды в контейнере +\item docker stop - останавливает контейнер +\item docker rm-удаляет контейнер +\item docker rmi - удаляет образ +\end{itemize} + +docker-compose \begin{itemize} \item build -- сборка \item up -- запуск @@ -522,19 +534,753 @@ compose написан на python, конфигурация в yaml-файла Оркестраторы управляют ЖЦ контейнеров микросервисных приложений. Задачи оркестратора: \begin{itemize} \item подготовка инфраструктуры и развёртывание -- установка приложения и его зависимостей на сервер, включая подготовку этого сервера -- установку библиотек, служб, и так далее. -\item Разделение ресурсов -- Для развёртывания в кластере требуется... +\item Разделение ресурсов -- Для развертывания приложения кластере разработки требуется B выделить вычислительные ресурсы сервера для различных процессов: это объемы памяти (RAM) центрального процессора (CPU). И Устанавливаются запрашиваемые и предельные параметры, правила при достижении контейнерами ресурсных лимитов, различные ограничения. Это важно для поддержания приложения в рабочем состоянии и сведения затрат к минимуму. \item Масштабирование контейнеров на основе рабочих нагрузок -- простой излишних ресурсов приводит к издержкам, а недостаток -- к нестабильно йработе приложения. Регулировать объёмы используемых ресурсов позволяет масштабирование, основанное на анализе нагрузок. Может быть ручным или автоматизированным. -\item Балансировка нагрузок -- автоматический анализ и распределение рабочих нагрузок на сервер целиком и контейнеры в частности. Балансировка оптимизирует использование ресурсов, увеличивает пропускную способность каналов связи,... -\item Маршрутизация трафика -\item Мониторинг состояния контейнеров -- позволяет видеть какие контейнеры и образы запущены -\item Обеспечение безопасного взаимодействия между контейнерами -- на основе непрерывной оценки кластеров, узлов и реестра контейнеров... +\item Балансировка нагрузок -- Автоматический анализ и распределение рабочих нагрузок на сервер целиком и контейнеры в частности. Балансировка оптимизирует использование ресурсов, увеличивает пропускную способность каналов связи, минимизирует Время отклика и помогает избежать перегрузки отдельных ресурсов. +\item Маршрутизация трафика -- Чтобы приложение было доступно из интернета, нужно настроить правильное распределение трафика из внешней сети по контейнерам и нужным сервисам. +\item Мониторинг состояния контейнеров -- Эта функция позволяет видеть, какие контейнеры и их образы запущены и где, какие команды используются в контейнерах, какие контейнеры потребляют слишком много ресурсов и почему. +\item Обеспечение безопасного взаимодействия между контейнерами -- На основе непрерывной оценки кластеров, узлов и реестра контейнеров предоставляются данные о неверных конфигурациях и других уязвимостях, которые могут представлять угрозу, а также рекомендации по устранению Выявленных угроз. \end{itemize} -\subsection{Kubernetes} -Считается отраслевым стандартом +\subsection{Системы оркестрации контейнеров} +\subsubsection{Kubernetes (k8s)} + +Эта платформа открытым исходным кодом считается отраслевым C стандартом. Позволяет автоматизировать масштабирование, развертывание с помощью шаблонов управление рабочей нагрузкой сервисами и контейнеров. Поддерживает ОС: Windows, macOS, Linux. + +Предлагает: \begin{itemize} -\item мониторинг сервисов -\item +\item мониторинг сервисов и распределение нагрузки, +\item автомонтирование гибкой системы хранения, +\item автоматизированные откаты и развертывания, +\item автораспределение нагрузки, +\item горизонтальное автомасштабирование, +\item автоперезапуск, замена и завершение работы отказавших контейнеров, +\item управление конфигурацией и конфиденциальной информацией, самовосстановление. \end{itemize} +\subsection{OpenShift Container Platform} +Платформа в формате PaaS для разработки, развертывания и управления не только контейнерными, но классическими приложениями И И их компонентами в режиме самообслуживания. Позволяет автоматизировать их в физических, виртуальных и общедоступных, частных и гибридных облачных средах. Поддержка ОС: Linux. + +Предлагает: +\begin{itemize} +\item встроенные средства кластеризации и оркестрации; +\item автомасштабирование; +\item балансировку нагрузки; +\item совместимость созданных на платформе приложений с любыми другими платформами, поддерживающими контейнеры Docker. +\end{itemize} + +\subsection{Nomad} +Легкий в поддержке, гибкий оркестратор для развертывания и управления контейнерными и классическими приложениями в физической или облачной среде. Поддерживает ОС: Linux, Windows, macOS. B основном Nomad управляет развертыванием и перезапускает контейнеры при обнаружении ошибок. Этого часто оказывается достаточно для небольших проектов. + +Предлагает: +\begin{itemize} +\item простое управление, +\item хорошую экосистему встроенную интеграцию с другими продуктами (например, Terraform), +\item автоматизацию переноса приложения из монолитной в микросервисную архитектуру, +\item масштабируемость, +\item возможность развернуть все кластерное приложение с несколькими контейнерами с помощью плагина из каталога одним щелчком мыши. +\end{itemize} + +\subsection{Docker Swarm} +Это «родная», базовая система кластеризации и оркестрации контейнеров Docker. **Docker Swarm** - базовая система кластеризации и оркестрации контейнеров Docker. Взаимодействие с кластером происходит через команды Docker, a управление действиями - через менеджер Swarm. Поддержка ОС: \textbf{Windows, macOS, Linux}. + +Кластер \textbf{Swarm (Docker Swarm Cluster)} состоит из узлов (нод), которые делят на два типа: +\begin{itemize} +\item управляющая нода (\textbf{manager}). Это нода, которая принимает запросы и распределяет задачи между всеми нодами в кластере. +\item рабочие (\textbf{worker}) ноды (узлы) +\end{itemize} + +\textbf{Docker Swarm} - \textbf{встроенное} в Docker решение по контейнерной оркестрации. Более легкое в освоении, чем Kubernetes. +Swarm - стандартный оркестратор для Docker контейнеров, доступный вам, если у вас установлен сам Docker. + +Что потребуется для освоения: +\begin{itemize} +\item Иметь опыт работы с Docker и Docker Compose. +\item Настроенный Docker registry. +\item Swarm не очень любит работать с локальными образами. +\item Несколько виртуальных машин для создания кластера, хотя по факту кластер может состоять из одной ВМ, но так будет нагляднее. +\end{itemize} + +\subsection{Устройство} +Основу кластера Docker Swarm представляют управляющие (manager) и рабочие (worker) узлы +\begin{figure}[H] + \centering + \includegraphics[width=12cm]{04-telematics-ustr.png} +\end{figure} +Docker Swarm состоит из менеджеров и воркеров. Менеджеры определяют, на каких воркерах и как будут работать контейнеры. + +\subsection{Термины} +Для того чтобы пользоваться Docker Swarm надо запомнить несколько типов сущностей: +\textbf{Node} - это BM, на которых установлен Docker. Есть manager и worker ноды. +\textbf{Manager нода} управляет worker нодами. Она отвечает за workers a также за их создание/обновление/удаление сервисов на workers, масштабирование и поддержку в требуемом состоянии. Worker ноды используются только для выполнения поставленных задач и не могут управлять кластером. +\textbf{Stack} - это набор сервисов, которые логически связаны между собой. По сути это набор сервисов, которые мы описываем в обычном compose файле. Части Stack (services) могут располагаться как на одной ноде, так и на разных. +\textbf{Service} это как раз то, из чего состоит Stack. Service является описанием - того, какие контейнеры будут создаваться. Как Docker-compose.yaml. Кроме стандартных полей Docker B режиме Swarm поддерживает ряд дополнительных, большинство из которых находятся внутри секции deploy. +\textbf{Task} - это непосредственно созданный контейнер, который Docker создал на основе той информации, которую мы указали при описании Service. Swarm будет следить за состоянием контейнера и при необходимости его перезапускать или перемещать на другую ноду. + +\begin{figure}[H] + \centering + \includegraphics[width=12cm]{04-telematics-swarm.png} +\end{figure} + +\subsection{Создание кластера} +Для того чтобы кластер работал корректно, необходимо: +\begin{itemize} +\item IP-адрес управляющей ноды должен быть назначен сетевому интерфейсу, доступному операционной системе хоста. Все ноды в Swarm должны подключаться к менеджеру по IP-адресу. +\item Открытые протоколы и порты между хостами +\item Должны быть доступны следующие порты. В некоторых системах они открыты по умолчанию. + \begin{itemize} + \item \textbf{ТСР-порт 2377} для управления кластером. + \item \textbf{Порт ТСР и UDP 7946} для связи между узлами. + \item \textbf{UDP-порт 4789} для оверлейного сетевого трафика. + \end{itemize} +\end{itemize} +\textbf{docker swarm init} необходимо выполнить на всех worker node, чтобы присоединить их в только что созданный кластер. Если все прошло успешно: + +\textbf{docker node ls} Ha manager Hоде в консоли, вы увидите что-то подобное: + +Чтобы убрать ноду из кластера, необходимо зайти на ВМ, которая является ею, и выполнить команду: \textbf{docker swarm leave} + +Если затем зайти на manager ноду и выполнить docker node ls, вы заметите, что статус у нее поменялся с Ready на Down (это может занять некоторое время). Swarm больше не будет использовать данную ноду для размещения контейнеров. + +Для того чтобы окончательно удалить ноду, надо выполнить (на manager node): \textbf{docker node rm stage} + +\begin{figure}[H] + \centering + \includegraphics[width=12cm]{04-telematics-stack.png} +\end{figure} + +В начале необходимо достать image из registry и только затем развернуть в наш кластер: + +\begin{verbatim} +docker pull docker-registry.ru:5000/ptm:stage; +docker stack deploy --with-registry-auth \ + -c ./docker-compose.stage.yaml stage;* +\end{verbatim} + +Команды выполняются на manager node. Флаг --with-registry-auth позволяет передать авторизационные данные на worker ноды, для того чтобы использовался один и тот же образ из регистра. Stage это имя нашего стэка. Посмотреть список стэков можно с помощью: + +docker stack ls Список сервисов внутри стэка: + +docker stack services stage + +Удалить стэк можно следующим образом: docker stack rm stage + +Можно запускать и отдельно взятые сервисы, например: + +\begin{verbatim} +docker service create --name nginx --replicas 3 nginx:alpine; +docker service ps nginx; +\end{verbatim} + +В данном примере мы запустили сервис nginx в виде 3 экземпляров, которые Swarm раскидал по 3 нодам. + +\begin{figure}[H] + \centering + \includegraphics[width=12cm]{04-telematics-ps.png} +\end{figure} + +Удалить сервис можно следующим образом: docker service rm nginx + +Для того чтобы увидеть более подробную информацию по сервису в виде JSON: \verb|docker service inspect stage_back|. Тут также можно увидеть, какие порты слушает сервис, в каких сетях участвует, какой у него статус и т.д. + +\textbf{Label Swarm} по умолчанию развертывает сервисы на любой доступной ноде/нодах, но как правило нам необходимо развертывать их на конкретной ноде или на специфической группе. Для этого нужны labels. Например, у нас есть stage и prod окружение. Stage используется для внутренней демонстрации продукта, а prod группой разработки. + +Для каждого из окружений у есть compose файл: docker-compose.stage.yaml и docker-compose.prod.yaml. По умолчанию Swarm будет раскидывать service произвольно по нодам. А нам нужно, чтобы сервис для stage запускался только на stage BM и аналогично для prod. + +В начале, добавим еще одну ноду в кластер, в качестве worker + +\begin{verbatim} +# заходим по ssh на еще одну виртуальную +# машину и добавляем ее в кластер +docker swarm join --token \ + SWMTKN-1-54k2k418tw2jejuwm3inq6crp4ow6xogswihcc5azg7oc +# выполняем команду на manager ноде: +docker node ls +\end{verbatim} + +Затем необходимо разметить ноды: +\begin{verbatim} +docker node update --label-add TAG=stage stage +docker node update --label-add TAG=prod prod-1 +\end{verbatim} + +Используя hostname виртуальных машин, мы ставим label. Для того чтобы убедиться, что все прошло успешно, необходимо выполнить команду: docker node inspect stage. Ищем раздел Spec. Labels, где мы должны увидеть label, который добавили: + +\begin{verbatim} +"Spec": { + "Labels": { + "TAG": "stage" + }, + "Role": "worker", + "Availability": "active" +} +\end{verbatim} + +После чего в compose файл необходимо добавить директиву placement, где прописывается условие, которое указывает, на каких нодах разворачивать данный сервис: Для docker-compose.prod.yaml будет аналогично, но с тэгом prod (однако для внешнего мира надо использовать другой порт, например 4004). После развертывания данных Stacks сервисы разворачиваются только на нодах с определенным тэгом. + +docker-compose.stage.yaml + +\begin{verbatim} +version: "3.9" +services: +back: +image: docker-registry.ru:5000/pta:stage +ports: +-"4003:4083" +environment: +12: "Europe/Moscow" +extra_hosts: +- host docker. internal:host-gateway command: make server_start volumes: +- /p/ptm/config/config-yaml:/p/ptm/config/config.yaml +- /p/ptm/stat/web:/p/ptm/stat/web. +#swarm deploy: +placement: +constraints: +- "node.labels. TAG==stage” +\end{verbatim} + +\subsection{Маршрутизация} +В данный момент у нас 3 ноды: manager нода, нода для stage версии приложения и еще одна для разработки. + +docker node ls + +Если развернуть наш стэк для docker-compose.prod.yaml на том же 4003 порту, что и для уже запущенного стэка docker-compose.stage.yaml, то получим ошибку, связанную с тем, что порт уже занят. + +Почему это произошло? И более того, если мы зайдем на ВМ prod-1 и Сделаем curl 127.0.0.1:4003, то увидим, что наш сервис доступен, хотя на этой ноде мы еще не успели ничего развернуть? + +Связано это с тем, что у Swarm имеется ingress сеть, которая используется для маршрутизации траффика между нодами. Если у сервиса есть публичный порт, то Swarm слушает его и в случае поступления запроса на него делает следующее: определяет есть ли контейнер на этой хост машине и если нет, то находит ноду, на которой запущен контейнер для данного сервиса, и перенаправляет запрос туда. + +В данном примере используется внешний балансировщик, который балансирует запросы между тремя ВМ, а дальше Swarm перенаправляет запросы в соответствующие контейнеры. + +?ФОТО + +Поэтому для docker-compose.prod.yaml нужно использовать любой другой публичный порт, отличный от того, который указан в docker-compose.stage.yaml. + +Отключить автоматическую маршрутизацию трафика можно с помощью mode: host при декларации ports: + +В данном случае запрос, который придет на порт 4004, Swarm будет направлять только на контейнер текущей ноде никуда И больше. + +Настройка mode (напрямую это не относится к маршрутизации). Она может принимать следующие значения: global или replicated (по умолчанию): + +\begin{verbatim} +*deploy: + mode: global +deploy: + mode: replicated + replicas: A* +\end{verbatim} + +Если global это означает, что данный сервис будет запущен ровно в одном экземпляре на всех возможных нодах. A replicated означает, что п-ое кол-во контейнеров для данного сервиса будет запущено на всех доступных нодах. + +\textbf{Zero downtime deployment} Это возможность организовать «бесшовную» смену контейнеров во время развертывания. Это возможно и в Docker-compose, но надо держать дополнительную реплику контейнера (даже, если по нагрузке требуется всего одна) и на уровне балансировщика переключать трафик с одного контейнера на другой. C Docker Swarm это все не нужно, необходимо лишь немного скорректировать конфигурацию сервиса. Для начала нужно добавить директиву healthcheck: + +\begin{verbatim} +*healthcheck: +test: curl -ss http://127.0.0.1:4004/ptm/api/healthcheck || +echo 1 +interval: 30s +timeout: 3s +retries: 12* +\end{verbatim} + +Она предназначена, чтобы Docker мог определить, корректно ли работает контейнер. test - результат исполнения этой команды Docker использует для определения корректно +ли работает контейнер. +*interval* - с какой частотой проверять состояние. В данном случае каждые 30 секунд. +*timeout* - таймаут для ожидания выполнения команды. +*retries* - количество попыток для проверки состояния сервера внутри контейнера. + +После добавления директивы healthcheck в compose file мы увидим в Status информацию о состоянии контейнера: +**docker container Is** + +После развертывания стэка контейнер сначала имеет статус **starting** (сервер внутри нашего контейнера запускается), а через некоторое время получит статус **healthy** (сервер запустился), в противном случае **unhealthy**. +**Docker** в режиме **Swarm** не просто отслеживает жизненное состояние контейнера, но и в случае перехода в состояние **unhealthy** попытается пересоздать контейнер. + +**Настройки для обновления контейнера:** +**replicas** - количество контейнеров, которые необходимо запустить +для данного сервиса. +Директива \verb|update_config| описывает каким образом сервис должен обновляться: +**parallelism** количество контейнеров для одновременного - обновления. По умолчанию данный параметр имеет значение 1 - контейнеры будут обновляться по одному. 0 - обновить сразу все контейнеры. В большинстве случаев это число должно быть меньше, чем общее количество реплик сервиса. + +\begin{verbatim} +deploy: + replicas: 1 +update_config: +parallelism: 1 +order: start-first +failure_action: rollback +delay: 10s +\end{verbatim} + +order - порядок обновления контейнеров. По умолчанию ptop-first, сначала текущий контейнер останавливается, а затем запускается новый. Для «бесшовного» обновления нужно использовать start- first. В этом случае вначале запускается новый контейнер, а затем выключается старый. +\verb|failure_action| - стратегия в случае сбоя. Вариантов несколько: continue, rollback, или pause (по умолчанию). +delay - задержка между обновлением группы контейнеров. + +**Docker secrets** +Swarm предоставляет хранилище для приватных данных (secrets), которые необходимы контейнерам. Это используется для хранения логинов, паролей, ключей шифрования и токенов доступа от внешних систем, БД и т.д. +**Создадим yaml файл с «секретным» токеном:** +* example.yaml +\begin{verbatim} +token: sfsjksajflsf_secret* +\end{verbatim} + +В данный момент у нас 3 ноды: manager нода, нода для stage версии приложения и еще одна для разработки. +**docker node 1s** + +Если развернуть наш стэк для docker-compose.prod.yaml на том же 4003 порту, что и для уже запущенного стэка docker-compose.stage.yaml, то получим ошибку, связанную с тем, что порт уже занят. + +Почему это произошло? И более того, если мы зайдем на ВМ prod-1 и Сделаем curl 127.0.0.1:4003, то увидим, что наш сервис доступен, хотя на этой ноде мы еще не успели ничего развернуть? + +Связано это с тем, что у Swarm имеется ingress сеть, которая используется для маршрутизации траффика между нодами. Если у сервиса есть публичный порт, то Swarm слушает его и в случае поступления запроса на него делает следующее: определяет есть ли контейнер на этой хост машине и если нет, то находит ноду, на которой запущен контейнер для данного сервиса, и перенаправляет запрос туда. + +В данном примере используется внешний балансировщик, который балансирует запросы между тремя ВМ, а дальше Swarm перенаправляет запросы в соответствующие контейнеры. + +? ФОТО + +Поэтому для docker-compose.prod.yaml нужно использовать любой другой публичный порт, отличный от того, который указан в docker-compose.stage.yaml. +Отключить +автоматическую маршрутизацию трафика можно с помощью mode: host при декларации ports: +В данном случае запрос, который придет на порт 4004, Swarm будет направлять только на контейнер текущей ноде никуда И больше. + +Настройка **mode** (напрямую это не относится к маршрутизации). Она может принимать следующие значения: global или replicated (по умолчанию): + +\begin{verbatim} +*deploy: + mode: global +deploy: + mode: replicated + replicas: A* +\end{verbatim} + +Если global это означает, что данный сервис будет запущен ровно в одном экземпляре на всех возможных нодах. A replicated означает, что п-ое кол-во контейнеров для данного сервиса будет запущено на всех доступных нодах. + +**Zero downtime deployment** +Это возможность организовать «бесшовную» смену контейнеров во время развертывания. +Это возможно и в Docker-compose, но надо держать дополнительную реплику контейнера (даже, если по нагрузке требуется всего одна) и на уровне балансировщика переключать трафик с одного контейнера на другой. +C **Docker Swarm** это все не нужно, необходимо лишь немного скорректировать конфигурацию сервиса. +Для начала нужно добавить директиву healthcheck: + +\begin{verbatim} +*healthcheck: +test: curl -ss http://127.0.0.1:4004/ptm/api/healthcheck || +echo 1 +interval: 30s +timeout: 3s +retries: 12* +\end{verbatim} + +Она предназначена, чтобы Docker мог определить, корректно ли работает контейнер. test - результат исполнения этой команды Docker использует для определения корректно +ли работает контейнер. +*interval* - с какой частотой проверять состояние. В данном случае каждые 30 секунд. +*timeout* - таймаут для ожидания выполнения команды. +*retries* - количество попыток для проверки состояния сервера внутри контейнера. + +После добавления директивы healthcheck в compose file мы увидим в Status информацию о состоянии контейнера: +**docker container Is** + +После развертывания стэка контейнер сначала имеет статус **starting** (сервер внутри нашего контейнера запускается), а через некоторое время получит статус **healthy** (сервер запустился), в противном случае **unhealthy**. +**Docker** в режиме **Swarm** не просто отслеживает жизненное состояние контейнера, но и в случае перехода в состояние **unhealthy** попытается пересоздать контейнер. + +**Настройки для обновления контейнера:** +**replicas** - количество контейнеров, которые необходимо запустить +для данного сервиса. +Директива \verb|update_config| описывает каким образом сервис должен обновляться: +**parallelism** количество контейнеров для одновременного - обновления. По умолчанию данный параметр имеет значение 1 - контейнеры будут обновляться по одному. 0 - обновить сразу все контейнеры. В большинстве случаев это число должно быть меньше, чем общее количество реплик сервиса. + +\begin{verbatim} +deploy: + replicas: 1 +update_config: +parallelism: 1 +order: start-first +failure_action: rollback +delay: 10s +\end{verbatim} + +order - порядок обновления контейнеров. По умолчанию ptop-first, сначала текущий контейнер останавливается, а затем запускается новый. Для «бесшовного» обновления нужно использовать start- first. В этом случае вначале запускается новый контейнер, а затем выключается старый. +\verb|failure_action| - стратегия в случае сбоя. Вариантов несколько: continue, rollback, или pause (по умолчанию). +delay - задержка между обновлением группы контейнеров. + +**Маршрутирзация** + +В данный момент у нас 3 ноды: manager нода, нода для stage версии приложения и еще одна для разработки. +**docker node 1s** +Если развернуть наш стэк для docker-compose.prod.yaml на том же 4003 порту, что и для уже запущенного стэка docker-compose.stage.yaml, то получим ошибку, связанную с тем, что порт уже занят. +Почему это произошло? И более того, если мы зайдем на ВМ prod-1 и Сделаем curl 127.0.0.1:4003, то увидим, что наш сервис доступен, хотя на этой ноде мы еще не успели ничего развернуть? +Связано это с тем, что у Swarm имеется ingress сеть, которая используется для маршрутизации траффика между нодами. Если у сервиса есть публичный порт, то Swarm слушает его и в случае поступления запроса на него делает следующее: определяет есть ли контейнер на этой хост машине и если нет, то находит ноду, на которой запущен контейнер для данного сервиса, и перенаправляет запрос туда. + +В данном примере используется внешний балансировщик, который балансирует запросы между тремя ВМ, а дальше Swarm перенаправляет запросы в соответствующие контейнеры. + +Поэтому для docker-compose.prod.yaml нужно использовать любой другой публичный порт, отличный от того, который указан в docker-compose.stage.yaml. +Отключить +автоматическую маршрутизацию трафика можно с помощью mode: host при декларации ports: +В данном случае запрос, который придет на порт 4004, Swarm будет направлять только на контейнер текущей ноде никуда И больше. + +Настройка **mode** (напрямую это не относится к маршрутизации). Она может принимать следующие значения: global или replicated (по умолчанию): + +\begin{verbatim} +*deploy: + mode: global +deploy: + mode: replicated + replicas: A* +\end{verbatim} + +Если global это означает, что данный сервис будет запущен ровно в одном экземпляре на всех возможных нодах. A replicated означает, что п-ое кол-во контейнеров для данного сервиса будет запущено на всех доступных нодах. + +**Zero downtime deployment** +Это возможность организовать «бесшовную» смену контейнеров во время развертывания. +Это возможно и в Docker-compose, но надо держать дополнительную реплику контейнера (даже, если по нагрузке требуется всего одна) и на уровне балансировщика переключать трафик с одного контейнера на другой. +C **Docker Swarm** это все не нужно, необходимо лишь немного скорректировать конфигурацию сервиса. +Для начала нужно добавить директиву healthcheck: + +\begin{verbatim} +*healthcheck: +test: curl -ss http://127.0.0.1:4004/ptm/api/healthcheck || +echo 1 +interval: 30s +timeout: 3s +retries: 12* +\end{verbatim} + +Она предназначена, чтобы Docker мог определить, корректно ли работает контейнер. test - результат исполнения этой команды Docker использует для определения корректно +ли работает контейнер. +*interval* - с какой частотой проверять состояние. В данном случае каждые 30 секунд. +*timeout* - таймаут для ожидания выполнения команды. +*retries* - количество попыток для проверки состояния сервера внутри контейнера. + +После добавления директивы healthcheck в compose file мы увидим в Status информацию о состоянии контейнера: +**docker container Is** + +После развертывания стэка контейнер сначала имеет статус **starting** (сервер внутри нашего контейнера запускается), а через некоторое время получит статус **healthy** (сервер запустился), в противном случае **unhealthy**. +**Docker** в режиме **Swarm** не просто отслеживает жизненное состояние контейнера, но и в случае перехода в состояние **unhealthy** попытается пересоздать контейнер. + +**Настройки для обновления контейнера:** +**replicas** - количество контейнеров, которые необходимо запустить +для данного сервиса. +Директива \verb|update_config| описывает каким образом сервис должен обновляться: +**parallelism** количество контейнеров для одновременного - обновления. По умолчанию данный параметр имеет значение 1 - контейнеры будут обновляться по одному. 0 - обновить сразу все контейнеры. В большинстве случаев это число должно быть меньше, чем общее количество реплик сервиса. +**order** - порядок обновления контейнеров. По умолчанию ptop-first, сначала текущий контейнер останавливается, а затем запускается новый. Для «бесшовного» обновления нужно использовать start- first. В этом случае вначале запускается новый контейнер, а затем выключается старый. +\verb|failure_action| - стратегия в случае сбоя. Вариантов несколько: continue, rollback, или pause (по умолчанию). +**delay** - задержка между обновлением группы контейнеров. + +\begin{verbatim} +deploy: + replicas: 1 + update_config: + parallelism: 1 + order: start-first + failure_action: rollback + delay: 10s +\end{verbatim} + +**Docker secrets** + +**Swarm** предоставляет хранилище для приватных данных (secrets), которые необходимы контейнерам. Это используется для хранения логинов, паролей, ключей шифрования и токенов доступа от внешних систем, БД и т.д. +**Создадим yaml файл с «секретным» токеном:** +* example.yaml +\begin{verbatim} +token: sfsjksajflsf_secret* +\end{verbatim} + +Создадим **secret** с именем \verb|back_config|: + +\begin{verbatim} +docker secret create back_config example.yaml +nys6v16j4d8ymmi f8755305 +\end{verbatim} + +docker secret is + +\begin{verbatim} +*#inspect specific secret* +docker secret inspect back_config +"ID": "nys6v16j4d8ynnif875q6305", +"Version": [ +"Index"; 24683 +"CreatedAt": "2022-04-13715:19:14.4746056842", "UpdatedAt": "2022-04-13T15:19:14.4746086842", +"Spec": { +"Name": "back_config", +"Labels": {} +\end{verbatim} + +**docker ps** +Чтобы просмотреть все контейнеры во всех состояниях, передайте аргумент - а. Docker автоматически настраивает локальный реестр образов на компьютере. Про- смотреть образы в реестре с помощью команды: docker images +Удалить образ из локального реестра Docker с помощью команды docker rmi. Указывается имя или ID образа, который требуется удалить. Допустим, удалим образ с именем temp-Ubuntu:version-1.0: +**docker rmi temp-Ubuntu:version-1.0** +Если образ используется контейнером, удалить его нельзя. Команда docker rmi возвращает сообщение об ошибке, в котором указывается контейнер, использующий +образ. Для удаления контейнера служит команда docker rm +\begin{verbatim} +docker rm happy_wilbur +\end{verbatim} +После удаления контейнера все данные В нем уничтожаются. При планировании хранения данных важно учитывать, что контейнеры являются временными. +Для перезапуска контейнера используется команда docker restart +\begin{verbatim} +docker restart happy_wilbur +\end{verbatim} +Так контейнер получает команду stop, а затем команду start. +Приостанавливает контейнер команда docker pause. +\begin{verbatim} +docker pause happy_wilbur +\end{verbatim} +Приостановка контейнера приводит к приостановке всех процессов. Эта команда позволяет контейнеру продолжить процессы в дальнейшем. Команда docker unpause отменяет приостановку всех процессов в указанных контейнерах. +**2.7 Флаги команды docker run** +Если перед флагом стоит два тире то это его полная форма, флаг с одним тире +- это сокращённый вариант некоего флага. Действуют они одинаково. Например, -р - это сокращённая форма флага рort:-1(--interactive) поток STDIN под- держивается в открытом состоянии даже если контейнер к STDIN не подключён; -t (--tty)-соединяет используемый терминал с потоками STDIN и STDOUT контей- нера. +Для того чтобы получить возможность взаимодействия с контейнером через тер- минал нужно совместно использовать флаги -i и -t. +**docker run -it tmp-ubuntu** +Запускает контейнер команда docker run. Для запуска контейнера из образа нужно просто указать его имя или идентификатор. +**docker run -d tmp-ubuntu** +Здесь для запуска контейнера в фоновом режиме следует добавить флаг -. -р (--port) порт это интерфейс, благодаря которому контейнер взаимодей- ствует с внешним миром. Например: конструкция 1000: 8000 перенаправляет порт Docker 8000 на порт 1000 компьютера, на котором выполняется контейнер. Если в контейнере работает некое приложение, способное выводить что-то в браузер, то, для того, чтобы к нему обратиться, в нашем случае можно перейти в браузере по адресу localhost:1000. +-d (--detach) запуск контейнер в фоновом режиме. Это позволяет использовать + +**Docker Swarm** несложный оркестратор для контейнеров, который - доступен для пользователей **Docker**. +Преимущества: +низкий порог вхождения, простота использования +Недостатки: +- уступает **Kubernetes** в широте администрирования +- отсутствует автомасштабирование +- функционал сильно уступает Kubernetes + +**Основы безопасности в Docker** + +5 основных правил: + +1) Регулярно устанавливайте обновления + +2) Ограничьте доступ к сокету службы Docker + +3) Используйте непривилегированного пользователя внутри контейнера + +4) Не запускайте контейнер с повышенными привилегиями + +5) Используйте инструменты проверки docker-image на уязвимости + +**Основы безопасности в Docker** +**Правило 1:** Регулярно устанавливайте обновления +Регулярные обновление хостовой машины и Docker позволят вам: +- Защититься от уязвимостей +Получать новый функционал +Продлевать поддержку производителя ПО +Быть в курсе имеющихся проблем у производителя Осваивать новые технологии +Помните, что контейнеры используют ядро совместно с хостом. +Эксплойт, запущенный внутри контейнера напрямую выполняются в ядре хоста. + +**Правило 2:** Ограничьте доступ к сокету службы Docker +**Docker daemon** использует UNIX сокет /var/run/docker.sock для входящих соединений API. **Владельцем данного ресурса должен быть пользователь root.** И никак иначе. Изменение прав доступа к этому сокету по сути равносильно предоставлению root-доступа к хостовой системе. +Не используйте **Docker TCP** сокет без защиты (авторизации, шифрования): +***Expose daemon on tcp://localhost:2375 without TLS** +Exposing daemon on TCP without TLS helps legacy clients connect to the daemon. It also makes yourself vulnerable to remote code execution attacks. Use with caution.* + +**Правило 3:** Настройка контейнера на +использование +непривилегированного +пользователя. +Это лучший способ избежать атаки на повышение привилегий. +Это можно сделать различными способами: + +1. Используя флаг и команды docker run: +**docker run -u 4000 alpine** + +2. Во время сборки образа: + +\begin{verbatim} +FROM alpine +**RUN groupadd-r myuser && useradd-r-g myuser myuser +<Здесь ещё можно выполнять команды от root-пользователя, например, ставить пакеты> +USER myuser** +\end{verbatim} + +3. Включить поддержку «user namespace» (пользовательского окружения) в Docker daemon: + +**Правило 4** Избегайте запуска контейнеров с файлом - - privileged +docker run - -privileged -p 127.0.0.1:3306:3306 —name mariadb + +**Правило 5:** Используйте инструменты проверки docker-image + +на уязвимости + +Используйте команду docker scan для сканирования образов: + +Package manager: deb +project name: docker-image|mariadb +Docker image: mariadb +Platform: linux/amd64 +Base image: ubuntu:20.04 + +Tested 185 dependencies for known vulnerabilities, found 19 vulnerabilities. + +\section{Kubernetes} +Kubernetes (k8s) + +**Kubernetes** работает по принципу «ведущий - ведомый». +Управление системой основано на двух подходах +**декларативном** - разработчик задает цели, а не пути их достижения, - которые система автоматически выбирает сама +**императивном** - разработчик может распоряжаться ресурсами с помощью команд «Создать», «Изменить», «Удалить>> + +\subsection{Как работает Kubernetes} + +**Kubectl** модуль **Kubernetes** для управления кластером (все - команды управления посылаются на **Master ноду**). +https://kubernetes.io/docs/tasks/tools/install-kubectl-windows + +**Minikube** для создания **Kubernetes кластера Single-Node**, - оптимизированного для тестов и учебы (Master и Worker B одном). + +Итак, мультиконтейнерное приложение запущено на сервере +Контейнеров несколько, задача настроить их совместную работу так, чтобы +они не отбирали друг у друга ресурсы аппаратной платформы +эффективно их расходовали +периодически следить за корректной работой и исправлять ошибки. +Kubernetes позволяет автоматизировать большинство процессов + +\subsection{Возможности Kubernetes:} + +• мониторинг сервисов и распределения нагрузки • автомонтирование гибкой системы хранения, +• автоматизированные откаты и развертывания, • автораспределение нагрузки, +горизонтальное автомасштабирование, +автоперезапуск, замена и завершение работы отказавших контейнеров, управление конфигурацией и конфиденциальной информацией. +Kubernetes - это широкие возможности по автоматизированной оркестрации мультиконтейнерных приложений, но необходима предварительная подготовка и настройка + +Поднятие простого Kubernetes кластера на Windows + +Minikube для создания Kubernetes кластера Single-Node, - оптимизированного для тестов и учебы (Master и Worker B одном). + +\subsection{Кластер Kubernetes} + +Компоненты кластера Kubernetes + +\begin{figure}[H] + \centering + \includegraphics[width=12cm]{04-telematics-kub-cluster.png} +\end{figure} + +\subsection{Nodes (ноды, узлы)} + +Это физические или виртуальные машины. на которых развертываются и запускаются контейнеры с приложениями. +Совокупность Kubernetes нод образует кластер Kubernetes +Nodes бывают двух типов: +**Master** (мастер-нода) - узел, управляющий +всем кластером. +**Worker** (рабочие ноды) - узлы, на которых работают контейнеры + +\subsection{Pods (Поды)} +Pods - базовые модули управления приложениями состоящие из одного или нескольких контейнеров +Контейнеры в поде запускаются и работают вместе имеют общие сетевые ресурсы и хранилище +Под и все его контейнеры функционируют на одном узле и находятся там до завершения работы +Обычно Kubernetes сам создает поды + +\begin{figure}[H] + \centering + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{04-telematics-kub-pods.png} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.48\textwidth} + \centering + \includegraphics[width=\textwidth]{04-telematics-kub-01.png} + \caption{Компоненты master-ноды кластера Kubernetes} + \end{subfigure} +\end{figure} + +Поднятие простого Kubernetes кластера на Windows + +Проще всего воспользоваться готовой реализацией - **Minikube**. Нам потребуется установить 3 приложения: +**VirtualBox +Kubectl +Minikube** +Другие модули **Kubernetes: kubeadm** (создание и настройка кластеров), **kubelet** (их запуск на хостах), **kubectl** (настройка компонентов, входящих в кластер - управление кластером). + +Kubectl - модуль Kubernetes для управления кластером (все команды управления посылаются на Master ноду). +https://kubernetes.io/docs/tasks/tools/install-kubectl-windows/ + +Далее в терминале запускаем кластер: +minikube start +"minikube ans Windows Home minikube start --no-vtx-check-cpusx-memory-gb-d-e-Ig + +**Поднятие простого Kubernetes кластера на Windows** +Далее в терминале видим, если все прошло успешно: +**Done! kubectl is now configured to use "minikube"** +Конфигурационный файл **«config» kubectl расположен в: +\begin{verbatim} +C:\Users\User\.kube** +\end{verbatim} + +Конфигурационный файл «config» kubectl расположен +\begin{verbatim} +C:\Users\User.kube +\end{verbatim} + +Работа с Kubectl + +Что такое Kubectl? +Kubectl - это инструмент командной строки для управления кластерами Kubernetes. +Kubectl ищет файл config в директории /.kube + +Синтаксис Kubectl + +Синтаксис для выполнения команд kubectl в терминале + +**kubectl [command] [TYPE] [NAME] [flags]** + +- command: определяет выполняемую операцию с одним или несколькими ресурсами, например, create, get, delete. +- TYPE: определяет тип ресурса. +- NAME: определяет имя ресурса. +- flags: определяет дополнительные флаги. + +Простая инструкция по работе с k8s-кластером +Базовые команды по работе с k8s-кластером, используя утилиту rubectl: +**kubectl cluster-info** - информация о кластере +**kubectl get nodes** - получить все доступные ноды в кластере +**kubectl get pods** - получение списка развернутых подов +**kubectl run** - запуск пода на основе докер-образа (архаичный вариант запуска, обычно используются специально подготовленные манифесты в формате yaml). +**kubectl expose pod** - создание службы для межподового/межконтейнерного взаимодействия (архаичный вариант, обычно используются специально подготовленные манифесты в формате yaml) + +**Поднятие простого Kubernetes кластера на Windows** + +**Управление созданным Single-Node кластером** + +**minikube start** - запуск кластера minikube + +**minikube pause** - приостановка кластера minikube, не затрагивая развернутые приложения. + +**minikube unpause** - возобновление работы приостановленного экземпляра + +**minikube stop** - остановка. + +**minikube delete** - удаление кластера minikube. + +Работа внутри minikube: **minikube ssh** + +Установка «Dashboard» - панели управления Kubernetes + +**Установка «Dashboard» - панели управления Kubernetes** +**Dashboard** - панель управления Kubernetes + +**Dashboard** - это веб-интерфейс пользователя Kubernetes. + +**Dashboard** удобен для: + +- развертывания контейнерных приложений в кластере Kubernetes, +- устранения неполадок в контейнерном приложении +- управления ресурсами кластера. +Dashboard не устанавливается по умолчанию. + +**Dashboard** также предоставляет информацию о состоянии ресурсов +**Kubernetes** в кластере и об возникших ошибках. + +Dashboard - панель управления Kubernetes + +Команды для установки на: + +[https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/) + +Интерактивное руководство - создание кластера Kubernetes + +[https://kubernetes.io/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/](https://kubernetes.io/docs/tutorials/kubernetes-basics/create-cluster/cluster-) + +Интерактивное руководство - работа с кластером Docker Swarm + +[https://labs.play-with-docker.com/](https://labs.play-with-docker.com/) + +\section{git} + \end{document} diff --git a/04-time-series-analysis-forecasting.tex b/04-time-series-analysis-forecasting.tex index abe09aa..31ef702 100644 --- a/04-time-series-analysis-forecasting.tex +++ b/04-time-series-analysis-forecasting.tex @@ -586,6 +586,47 @@ Var(\xi_t) = E(\xi_t^2-E\xi_t) \end{equation*} В основном рассматриваются процессы прогнозирующие изменения доходности ARCH, GARCH. +\section{Многомерные параметрические модели временных рядов} +Какие ряды следует включать в модель? Включаются только те, которые являются «причинными по Грейнджеру». Факторы должны иметь тот же порядок интеграции. То есть если изъятие информации о факторе меняет условное матожидание ряда. + +$$E(Y_{t+1}|Y_t, Y_{t-1} X_t, ...) = E(Y_{t+1}|Y_t, Y_{t-1})$$ + +Связь должна быть односторонняя, то есть если Х объясняет У, а У объясняет Х -- они не подходят. Тест проверяет, может ли фактор Х улучшить прогноз У. + +\begin{equation*} + \begin{gathered} + X_t = \alpha_0+\alpha_1X_{t-1}+\beta Y_{t-1} + \xi_t\\ + Y_t = \gamma_0+\gamma_1Y_{t-1}+\delta Y_{t-1} + \xi_t + \end{gathered} +\end{equation*} + +$Y_t$ причинная по грейнджеру для $X_t$ +$$ +\begin{cases} + H_0 \beta_1 = 0 \text{отвергнута}\\ + H_0 \delta_1 = 0 \text{не может быть отвергнута}\\ +\end{cases} +$$ + +Если вероятность ошибиться меньше 0,05 -- принимаем гипотезу. + +\subsection{Ложная регрессия} + +\subsection{Коинтеграция} +Если наблюдаемые ряды принадлежат к классы DS процессов, то при определённых условиях между ними может существовать связь, проявляющаяся в том, что для них существует стационарная линейная комбинация. + +\subsection{Стационарные ряды} + +\subsection{Модель коррекции ошибками ECM} +\begin{equation*} + \begin{gathered} + Y_t = \mu + \alpha_2 Y_{t-1}+\beta_0 X_t + \beta_1 X_{t-1} + \xi_t\\ + Y_t - Y_{t-1} = \mu -(1-\alpha_1) * Y_{t-1}+\beta_0 X_t + \beta_1 X_{t-1} + \xi_t\\ + \Delta Y_t = \beta_0 \Delta X_t -(1-\alpha_1)(Y_{t-1} - \frac{\beta_0+\beta_1}{1-\alpha_1}X_{t-1} - \frac{\mu}{1-\alpha_1}) + \xi_t + \end{gathered} +\end{equation*} + + \appendix \setcounter{secnumdepth}{0} @@ -655,7 +696,5 @@ r = число параметров модели, N - объём выборки. SARIMA(p,d,q)(P,D,Q,S) -- учёт сезонности. - - \end{document} \ No newline at end of file diff --git a/04-tsaf-01-hw.tex b/04-tsaf-01-hw.tex index 989a715..267235e 100644 --- a/04-tsaf-01-hw.tex +++ b/04-tsaf-01-hw.tex @@ -74,7 +74,7 @@ z_2 = 1.25 - \sqrt{6.25-4} = 1.25 - 1.5 \approx -0.25 \subsection{Процесс ARMA(1, 1)} Для того чтобы процесс ARMA(1,1) был стационарным, необходимо выполнение следующих условий: \begin{itemize} -\item Корни характеристического уравнения $1 - \alpha z = 0$ должны лежать вне единичного круга на комплексной плоскости. Характеристическое уравнение имеет вид $z = \frac{1}{\alpha}$, поэтому условие стационарности может быть записано как $|\frac{1}{\alpha}| > 1$, что эквивалентно $|\alpha| < 1$. +\item Корни характеристического уравнения $1 - \alpha z = 0$ должны быть по модулю больше единицы. Характеристическое уравнение имеет вид $z = \frac{1}{\alpha}$, поэтому условие стационарности может быть записано как $|\frac{1}{\alpha}| > 1$, что эквивалентно $|\alpha| < 1$. \item Веса авторегрессии и скользящего среднего должны быть ограничены, то есть $|\alpha| < 1$ и $|1 - \beta| < 1$, где $\beta$ - коэффициент скользящего среднего. Таким образом, из условия 1 получаем, что $|\alpha| < 1$. Из условия 2 следует, что $|1 - \alpha| < 1$, что эквивалентно $0 < \alpha < 2$. \end{itemize} diff --git a/04-videostream-object-parameter-recognition-algorithms.tex b/04-videostream-object-parameter-recognition-algorithms.tex index bd833a3..fa89a12 100644 --- a/04-videostream-object-parameter-recognition-algorithms.tex +++ b/04-videostream-object-parameter-recognition-algorithms.tex @@ -389,6 +389,23 @@ $S_x$ -- размер одного пикселя светочувствител \textbf{Детекторы} -- обнаружение. \textbf{Дескрипторы} -- обнаружение и описание. Мы всё будем называть детекторами. Хороший алгоритм должен быть инвариантен к шумам и деформациям. +\subsection{Характеристики хорошего детектора} +\begin{itemize} +\item инвариантность относительно преобразования изображения + \begin{enumerate} + \item смещения + \item поворота + \item к изменению масштаба (харрис-, харрис-лаплас+) + \item изменению яркости (моравец-, харрис+) + \item изменению точки положения камеры + \end{enumerate} +\item повторяемость (при изменении условийсъёмки) +\item локальность (при перекрытии объекта часть признаков должна остаться видимой, например если взять контур и его часть перекроется -- он перестанет детектироваться) +\item репрезентативность (кол-во признаков должно быть достаточным для детектировании даже на небольшом масштабе) +\item Точность +\item Эффективность (не требовательны к вычислительным ресурсам и времени) +\end{itemize} + \subsection{Детектор Моравеца} Самый простой детектор углов на изображении. \begin{figure}[H] @@ -461,5 +478,65 @@ Features from Accelerated Test Строим дерево решений. Множество которое соответствует узлу дерева разбивается на подмножества и на основе этих деревьев не рассматриваем всё, а проходим по дереву и находим характерные точки. \subsection{Детектор MSER} +Maximally stable extremal regions + +не будут исчезать при изменении порогового значения. То есть превращаем изображение не в градации серого, а в ч/б (бинаризация). Варьируем порог и в итоге смотрим какие участки исчезают, а те что остались -- наиболее устойчивые. +$$ I_g(x,y) = +\begin{cases} + 255, I(x,y)>g\\ + 0, I(x,y)\leq g +\end{cases}, g \in [0,255] +$$ +g -- порог бинаризации. варьируем, строим дерево +(1) +светлая буква на тёмном фоне. Можем это изображение масштабировать. Если мы делаем маленький порог ($g=50$) всё изображение светлое, иногда только точки будут тёмные, увеличивая порог видим разное поведение характерных точек. Если точки совсем пропали - нет смысла ни масштабировать ни менять пороги. Плохо выраженные точки при изменённых порогах не попадут в стабильные характерные точки. + +Применяется чаще всего для градаций серого, хотя цветные тоже иногда делят на компоненты и применяют этот метод. + +\subsection{Дескрипторы} +\subsubsection{SIFT} +Scale Invariant Feature Transform. Размываем начальное изображение гауссовым ядром +$$\mathbb{G}(x, y, \sigma) = \frac{1}{2\pi\sigma^2}e^{\frac{-(x^2+y^2)}{2\pi^2}}$$ + +$$\mathbb{L}(x,y,\sigma) = I(x, y)*\mathbb{G}(x,y,\sigma)$$ + +размываем не всё изображение, а, например, окрестность 16х16 пикселей. Для каждого из пикселей определяем магнитуды и направление, задаём веса (чтобы какие-то учитывались больше, а какие-то меньше). +(2) +по каждому из пикселей таких квадратов вычисляем амплитуду градиента и направление, строим гистограммы по каждому квадрату. ориентация ключевой точки +$$m(x,y)=\sqrt{(L(x+1, y)-L(x-1, y))^2+(L(x, y+1)-L(x, y-1))^2}$$ +направление ориентации можно вычислить как +$$\theta(x,y)=\arctan\left(\frac{L(x, y+1)-L(x, y-1)}{L(x+1, y)-L(x-1, y)}\right)$$ +(3) +Выбираем порог, который отсеит маленькие значения (обычно берут 80\%) Всё что выше будет потенциальными характерными точками изображения. на основе гистаграммы можем построить некий усреднённый дескриптор квадратов 8х8 (можно отсортировать для ускорения). Квадраты 8х8 можем представить как набор градиентов +(4) + +\begin{itemize} +\item [+] инвариантность относительно масштаба, поворота, смещения +\item [+] устойчивость к шуму +\item [+] вычислительная эффективность +\end{itemize} +\subsubsection{SURF} +speeded-up robust features +Также как и в предыдущем -- инвариантен к поворотам и масштабированию. Используется матрица гёссе - гессиан (вторые производные). +(5) +сигма - это не размытие, а масштаб. Использование гессиана позволяет определять характерные точки инвариантные к повороту и масштабированию, вычисляем точки, которые не будут меняться. Детерминант будет достигать экстремумов в точках с максимальным изменением яркости. + +Делим изображение на квадраты (например, 8х8) +(6) +вычисляем для каждого квадрата градиент, можно использовать свёртку с примитивами Хаара и строим функцию различия (где наибольшее и где наименьшее). где меньше там примитив хаара хуже описывает объект. в итоге описываем отдельные части изображения. + +\subsubsection{GLOH} +Gradient location orientation histogram -- модификация SIFT, но здесь окрестности не квадратные, а рассматриваются разные сектора. +(7) +и для каждого сектора делаем тоже самое про градиент как в СИФТ. радиусы 6, 11, 15 пикселей. В каждом таком секторе строим свой набор (карту) градиентов. Получается 17 шт. строим и определяем наибольшие с порогом 0,8 и суммируем те, которые прошли порог. + +В отличие от сифт учитывает характерные точки, попавшие на границы разделения квадратами + +\subsubsection{DAISY} +модификация SIFT рассматриваем окрестности в виде окружностей (не секторов как гло) +(8) +окрестности внахлёст и в некоторых задачах лучше подходит, но будет гораздо хуже по вычислительной сложности. + +$$I(x,y)$$ \end{document} diff --git a/pics/04-telematics-kub-01.png b/pics/04-telematics-kub-01.png new file mode 100644 index 0000000..05db9b7 Binary files /dev/null and b/pics/04-telematics-kub-01.png differ diff --git a/pics/04-telematics-kub-cluster.png b/pics/04-telematics-kub-cluster.png new file mode 100644 index 0000000..8ae0517 Binary files /dev/null and b/pics/04-telematics-kub-cluster.png differ diff --git a/pics/04-telematics-kub-pods.png b/pics/04-telematics-kub-pods.png new file mode 100644 index 0000000..f5a55d4 Binary files /dev/null and b/pics/04-telematics-kub-pods.png differ diff --git a/pics/04-telematics-ps.png b/pics/04-telematics-ps.png new file mode 100644 index 0000000..5bfddd8 Binary files /dev/null and b/pics/04-telematics-ps.png differ diff --git a/pics/04-telematics-stack.png b/pics/04-telematics-stack.png new file mode 100644 index 0000000..6779515 Binary files /dev/null and b/pics/04-telematics-stack.png differ diff --git a/pics/04-telematics-swarm.png b/pics/04-telematics-swarm.png new file mode 100644 index 0000000..a8d71ce Binary files /dev/null and b/pics/04-telematics-swarm.png differ diff --git a/pics/04-telematics-ustr.png b/pics/04-telematics-ustr.png new file mode 100644 index 0000000..16fa23d Binary files /dev/null and b/pics/04-telematics-ustr.png differ