another week and more

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}

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)
+транзисторы с тремя схемами включения
+усилитель
+дифференциальный усилитель
+токовое зеркало
+двухтактный выходной каскад
+ячейка гильберта (умножитель)

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}

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}
  

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}

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}