another week and more
This commit is contained in:
parent
68f426bd51
commit
4749a6beca
|
|
@ -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}
|
||||
|
|
@ -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)
|
||||
транзисторы с тремя схемами включения
|
||||
усилитель
|
||||
дифференциальный усилитель
|
||||
токовое зеркало
|
||||
двухтактный выходной каскад
|
||||
ячейка гильберта (умножитель)
|
||||
|
|
|
|||
|
|
@ -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}
|
||||
|
|
|
|||
|
|
@ -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}
|
||||
|
||||
|
|
@ -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}
|
||||
|
|
|
|||
|
|
@ -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}
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 368 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 310 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 143 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 137 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 199 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 132 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 218 KiB |
Loading…
Reference in New Issue