Docker: запуск графических приложений в контейнерах / хабр

Docker

Dockerfile

Одна из важнейшей характеристик образа — это его размер. Компактный образ быстрее скачается с удаленного репозитория, займет меньше места, и ваш сервис быстрее стартует. Любой образ строится на основании базового образа, и рекомендуется выбирать наиболее минималистичный вариант. Хорошим вариантом является Alpine — полноценный дистрибутив Linux с минимумом пакетов.

Для начала попробуем написать Dockerfile «в лоб» (сразу скажу, что это плохой способ, не делайте так):

Здесь мы используем базовый образ на основе Alpine с уже установленным JDK для сборки нашего проекта. Командой ADD мы добавляем в образ текущую директорию src, отмечаем ее рабочей (WORKDIR) и запускаем сборку. Команда EXPOSE 8080 сигнализирует докеру, что приложение в контейнере будет использовать его порт 8080 (это не сделает приложение доступным извне, но позволит обратиться к приложению, например, из другого контейнера в той же сети докера).

Чтобы упаковать сервисы в образы надо выполнить команды из корня каждого проекта:

В результате получаем образ размером в 456 Мбайт (из них базовый образ JDK 340 занял Мбайт). И все притом, что классов в нашем проекте по пальцем пересчитать. Чтобы уменьшить размер нашего образа:

Используем многошаговую сборку. На первом шаге соберем проект, на втором установим JRE, а третим шагом скопируем все это в новый чистый Alpine образ. Итого в финальном образе окажутся только необходимые компоненты.
Воспользуемся модуляризацией java. Начиная с Java 9, можно с помощью инструмента jlink создать JRE только из нужных модулей

Для любознательных, вот хорошая статья про подходы уменьшения размеров образа https://habr.com/ru/company/ruvds/blog/485650/.

Итоговый Dockerfile:

Пересоздаем образ, и он в итоге похудел в 6 раз, составив 77 МБайт. Неплохо. После, готовые образы можно загрузить в реестр образов, чтобы ваши образы были доступны для скачивания из интернета.

Совместный запуск сервисов в Docker

Для начала наши сервисы должны быть в одной сети. В докере существует несколько типов сетей, и мы используем самый примитивный из них — bridge, позволяющий объединять в сеть контейнеры, запущенные на одном хосте. Создадим сеть следующей командой:

Далее запустим контейнер бекенда с именем ‘backend’ с образом microservices-backend:1.0.0:

Запускаем шлюз:

В этой команде мы указываем, что мы пробрасываем 80 порт нашего хоста на 8080 порт контейнера. Опции env мы используем для установки переменных среды, которые автоматически будут вычитаны спрингом и переопределят свойства из application.properties.

Глобальный логгер — Вред

Глобальный логгер — это объект, через который осуществляется логирование в Serilog, присвоенный публичному статическому свойству статического класса . Это свойство инициализируется при запуске приложения с конфигурацией в коде, а затем второй раз инициализируется при инициализации хоста веб-приложения на основе загруженной конфигурации.

Таким образом это не Singleton в чистом виде. Но в пределах работы веб-приложения он задумывается как единственный глобальный экземпляр.

Проблемы:

потеря лог-сообщений в модульных тестах. В зависимости от особенностей интеграции Serilog в .NET Core (параметр в методе ) могут возникнуть проблемы:
- с логированием в логгер из последнего теста
- эффект «»
по тем же причинам могут не задействоваться средства расширения подсистемы логирования, тестируемые в модульных тестах в составе развёрнутой подсистемы логирования .NET Core и Serilog
возможность в любой момент использовать мимо системы DI от .NET Core, которая реализуется под самыми весомыми предлогами:
- «это временно»;
- «а ну чё, и так же работает»;
- «Я так привык на .NET Framework»;
как следствие, использование в коде статического сервис-локатора — антипаттерн;
т.к. статическое свойство изменяемое, то есть вероятность несанкционированного замены логгера в непредназначенных для этого местах. Например, это могут быть временные костыли, которые имеют особенность становиться постоянными;
в библиотеке присутствует нехарактерное решение для .NET Core. Сильно напоминает .

Заключение

Статистика популярности log4net, NLog и Serilog 2013-2021 гг.

График на google trends.

Serilog был и есть отличным инструментом. Но он не был переработан и адаптирован в полной мере для .NET Core, поэтому в нём остались механизмы, которые больше характерны для решений на .NET Framework. Как показывает прогресс, .NET, в виде .NET 5, двигается в направлении архитектуры, взятой из .NET Core. Поэтому разработчикам Serilog рано или поздно придётся заняться вопросом адаптации более плотно.

К сожалению, простым запросом слияния в github проблему с глобальным логом полностью не решить. Тут требуется глобальный рефакторинг, который может, например включать такие изменения:

вынести из основной библиотеки Serilog все механизмы, относящиеся к .NET Framework в отдельную библиотеку на подобии serilog-aspnetcore, которая будет использовать основную библиотеку. И туда перенести в т.ч. класс Serilog.Log. тогда при подключении Serilog к проекту на .NET Core в приложении этот класс не будет доступен;
в serilog-aspnetcore в методе интеграции Serilog в подсистему логирования .NET Core всегда использовать алгоритм работы, соответствующий тому случаю, если указать вх. параметр , т.е. вместо глобального логгера создать новый.

В данной статье мы разобрались с тем, какое место в логировании через Serilog в .NET Core занимает глобальный логгер и какие проблемы он может принести.

Общее понятие дисплея

Каждое графическое приложение X Window при запуске считывает переменную
окружения DISPLAY, что бы выяснить на какой компьютерный экран посылать
графические данные. Это, вместе с сетевыми возможностями системы X Window
делает возможным удаленный запуск графических приложений. То есть вы используете
ресурсы процессора одной машины при работе с приложением на другой. Весь
GUI (графический интерфейс пользователя) появляется на той машине, с которой
вы им управляете. Вы даже не замечаете, что используете два компьютера. Конечно,
определенную роль здесь играет скорость передачи данных, но нормальной 10-мегабитной
локальной сети вполне достаточно.

Для чего это вам?Существует множество сетевых графических приложений.
Компании используют их для управления оборудованием находящимся может быть
за тысячи километров, и вы можете использовать такие же приложения так,
как если бы они были на вашем компьютере. Допустим, у вас есть два компьютера:
одна быстрая гигагерцевая машина и еще старенький Pentium-133 — вы вполне
сможете оценить скорость вашей новой машины, даже не садясь за нее. Возможно,
ваша сестра заняла быстрый компьютер — но вы все равно пользуете его. Как это работает?Все
приложения X Window (такие как например Gimp, Xterm, Konquerer, Netscape
и т. д.) в действительности являются сетевыми клиентами, которые присоединяются
к X-серверу. В задачу X-сервера входят: взаимодействие с графическим аппаратным
обеспечением, рисование картинок на вашем экране, считывание данных с мышки
и клавиатуры. Программы-клиенты (gimp, netscape) посылают серверу указания
о том, как рисовать рамки и кнопки. Взамен они принимают от сервера команды
с мышки и клавиатуры. Само собой разумеется, что потребуется аутентификация,
иначе кто угодно может испортить чей-нибудь экран. Существуют две программы
для управления доступом: — xhost: используя эту программу, вы можете допустить любого пользователя
с определенной машины передавать графику на ваш дисплей. Например: Вы работаете
на машине с именем philosophus. Что бы дать доступ на ваш дисплей любой программе
с хоста movietux вам нужно набрать команду:

xhost +movietuxЭто должно быть набрано в оболочке philosophus’а

xauth extract — philosophus:0.0 | ssh movietux
/usr/X11R6/bin/xauth mergeили scp ~/.Xauthority movietux:

Клиент проверяет переменную DISPLAY для поиска сервера или пытается подключиться к серверу на локальном хосте.
Сервер проверяет, имеет ли клиент допуск к передаче «картинок» к нему. Если имеет — тогда сервер рисует графику.

bash:export
DISPLAY=hostname:displaynumber.screennumbertcsh:setenv DISPLAY
hostname:displaynumber.screennumber

export DISPLAY=philosophus:0.0

Перенос дисплея на удаленный хост

Если вы используете ssh для входа на удаленный хост, тогда переменная
DISPLAY устанавливается автоматически. Существуют так же и другие программы
поддерживающие DISPLAY, но ssh наиболее распространенная.
Если же вы используете slogin или другие команды, тогда на удаленный хост вы можете установить следующие скрипты:Для tcsh:
# перенос дисплея на удаленный логин:# поместить его в свой файл ~/.loginset whoami=`who -ml`set remhost=`expr «$whoami» :
‘.*($.*$)’`if ( «$remhost» != «» ) thensetenv DISPLAY
«$remhost»:0.0endif

этот скрипт получает имя удаленного хоста из команды «who -ml». Команда возвращает что-то вроде

>who -mlmovietux!guido pts/3 Oct 26 21:55
(philosophus.tux.org)

если вы используете bash вам нужен такой скрипт:

# перенос дисплея на удаленный логин:# поместить его в свой файл ~/.bash_profilewhoami=`who -ml`remhost=`expr «$whoami» :
‘.*($.*$)’`if ;
thenDISPLAY=»$remhost»:0.0export DISPLAYfi

В то время как сетевые возможности X Window System очень
хороши, графика работает несколько медленнее из-за того, что вы пересылаете
данные через сетевой протокол. Обычно вы не замечаете разницы, но существуют
приложения, такие как быстрые игры с насыщенной графикой, для которых скорость
очень важна. Эти игры обычно основаны на библиотеках типа OpenGL. Эти библиотеки
предоставляют непосредственный доступ к графическому аппаратному обеспечению.
Никаких сетей. Это быстрые программы, но вы не сможете запускать их удаленно.

С X11 использовать мощность вашей сети очень легко. Вы
можете работать с удаленными приложениями так же как с локальными. Единственная
разница в том, что вы видите те файлы и домашнюю директорию, которые находятся
на удаленном хосте. Однако с установленными NFS и NIS вы сможете скрыть и
это небольшое отличие. Вы сможете использовать всю мощность процессора самых
быстрых машин в ваших сети, и ни о чем не беспокоиться.

система X11 используемая с Linux

Создание микросервисов

Чтобы иметь возможность проверить состояние каждого из сервисов, в их зависимости был добавлен Spring Actuator. Он создаст эндпойнт /actuator/health и будет возвращать 200 статус, если сервис готов принимать траффик, или 504 в случае проблем. В данном случае это довольно фиктивная проверка, так как сервисы очень просты, и при каком-то форсмажоре они скорее станут полностью недоступны, чем сохранят частичную работоспособность. Но в реальных системах Actuator может помочь диагностировать проблему до того, как об нее начнут биться пользователи. Например, при возникновении проблем с доступом к БД, мы сможем автоматически на это среагировать, прекратив обрабатывать запросы сломанным экземпляром сервиса.

Сервис бекенда будет просто считать и отдавать количество принятых запросов.

Код контроллера:

Тест на контроллер:

Сервис Gateway

Шлюз будет переадресовывать запрос сервису бекенда, дополняя его следующей информацией:

id шлюза

Он нужен, чтобы можно было по ответу сервера отличить один экземпляр шлюза от другого
Некий «секрет», который будет играть роль очень важного пароля (№ ключа шифрования важной куки). Конфигурация в application.properties:

Конфигурация в application.properties:

Адаптер для связи с бекендом:

Контроллер:

Всё вместе

Всё описанное можно запускать в docker-контейнерах. Причём всё конфигурируется таким образом, что всем стеком можно пользоваться как локально при разработке, так и в staging- и production-окружениях, где переменными остаются только переменные окружения.

Все описанные сервисы, за исключением Elastalert, позволяют использовать переменные окружения в конфигурациях. Проблему Elastalert удалось разрешить, используя команду вида в entrypoint-скрипте и доустановкой зависимостей, чтобы это работало.

Конфигурации каких сервисов стека оставлять в репозитории проекта, а какие выносить в отдельный репозиторий мониторинга, зависит от наличия других проектов и того, как они будут переиспользовать стек.

Такой вариант стека имеет следующие преимущества:

Снаружи доступен только 80 порт nginx, который проксирует запросы по basic auth к Kibana
Порт Logstash тоже закрыт. Доступ к нему производится с помощью ssh-туннеля
Одной командой поднимается весь стек кроме nginx
Отдельными командами можно пересобирать, перезапускать docker-образы
Отдельными командами можно произвести переразвертывание новой версии одного из образов
Сервисы автоматически запускаются при перезагрузке сервера или внутреннем сбое
Разворачивается одинаково в локальном и боевом окружении, отличаясь .env-файлом алертинга и файлом nginx-паролем
Параметры *_JAVA_OPTS подобраны таким образом, чтобы весь стек стабильно работал на одном инстансе с 4GB RAM (зависит от потока событий и длительности хранения в ES).

Стоит заметить, что в данном подходе не используется ни один из xpack-плагинов.

Допустим вариант использования docker-compose. Главное, что основная конфигурация, состоящая из Dockerfile-ов, конфига Filebeat, конфигов Logstash, правил оповещения, правил автоудаления индексов, находится под системой контроля версий, получая возможность быстрого переразвертывания, хранения истории изменений и всех других преимуществ VCS.

Важно уделять внимание автоматической проверки работоспособности стека. Я предлагаю организовать проверку следующим образом. В самом приложении создается задача, исполняемая по расписанию (в Laravel для этого есть scheduler), скажем, раз в неделю за 5 минут до дейлимитинга

Сама задача вызывает логгер и записывает сообщение с уровнем ALERT. Если весь стек функционирует нормально, то вы получите оповещение. Если такого оповещения нет, а вы к нему привыкли, то это станет сигналом для разбирательств

В самом приложении создается задача, исполняемая по расписанию (в Laravel для этого есть scheduler), скажем, раз в неделю за 5 минут до дейлимитинга. Сама задача вызывает логгер и записывает сообщение с уровнем ALERT. Если весь стек функционирует нормально, то вы получите оповещение. Если такого оповещения нет, а вы к нему привыкли, то это станет сигналом для разбирательств.

Выполнение скрипта/команды при срабатывании триггера Zabbix

Сентябрь 18th, 2017 Evgeniy Kamenev

Необходимо при срабатывании триггера выполнять команду/скрипт

Например, при срабатывании триггера о том, что служба обновления баз данных Clamav-антивируса (freshclam-clamav)не запущена, автоматически перезапускать эту службу

Создаем новое ДЕЙСТВИЕ

Configuration->Action->Create action

1	Configuration->Action->Create action

Вкладка Action

Name->Restart Clamav-freshclam process

1	Name->Restart Clamav-freshclam process

Вклдка Conditions

Type of calculation -> Custom Expression->(A and B and C) or (A and B and D) or (A and B and E) or (A and B and F) or (A and B and G)

1	Type of calculation->Custom Expression->(AandBandC)or(AandBandD)or(AandBandE)or(AandBandF)or(AandBandG)

Или

A and B and (C or D or E or F or G or H or I)

1	AandBand(CorDorEorForGorHorI)

где

A – статус/режим «Обслуживание» не включен
B – Триггер имеет значение «Проблема»
С – Триггер хоста1 с проверкой запущен ли процесс Clamav-freshclam на этом хосте1
D – Триггер хоста2 с проверкой запущен ли процесс Clamav-freshclam на этом хосте2
и т.д.

1
2
3
4
5

A–статусрежим«Обслуживание»невключен

B–Триггеримеетзначение«Проблема»
С–Триггерхоста1спроверкойзапущенлипроцессClamav-freshclamнаэтомхосте1

D–Триггерхоста2спроверкойзапущенлипроцессClamav-freshclamнаэтомхосте2

ит.д.

Вкладка Operations

Target list -> Current host
Type-> Custom script
Execute on->Zabbix server
Commands-> /usr/lib/zabbix/externalscripts/clamav-freshclam-restart.sh {HOST.HOST}

1
2
3
4

Target list->Current host

Type->Custom script

Execute on->Zabbix server

Commands->usrlibzabbixexternalscriptsclamav-freshclam-restart.sh{HOST.HOST}

На Zabbix-сервере создаем скрипт

# nano /usr/lib/zabbix/externalscripts/clamav-freshclam-restart.sh

1	# nano /usr/lib/zabbix/externalscripts/clamav-freshclam-restart.sh

#!/bin/bash
ssh -p3333 root@$1 «service clamav-freshclam restart»

1 2	#!/bin/bash ssh-p3333 root@$1″service clamav-freshclam restart»

# chmod +x /usr/lib/zabbix/externalscripts/clamav-freshclam-restart.sh

1	# chmod +x /usr/lib/zabbix/externalscripts/clamav-freshclam-restart.sh

zabbix-пользователь будет подключаться по SSH как пользователь root к хосту и перезапускать clamav-freshclam службу(предварительно необходимо настроить SSH-аутентификацию по ключам, добавив публичный ключ пользователя zabbix в /root/.ssh/authorized_keys на требуемом хосте)

В качестве усиления безопасности и запрета подключения под рутом необходимо подключаться под пользователем zabbix(требуется предварительная настройка SSH-аутентификации по ключам), а на хосте, на который происходит подключение, через visudo разрешить перезапуск службы clamav-freshclam для пользователя zabbix без запроса пароля

# visudo

zabbix ALL= NOPASSWD: service clamav-freshclam restart

1	zabbix ALL=NOPASSWDservice clamav-freshclam restart

Теперь при срабатывании триггера о том,что процесс freshclam не запущен, Zabbix подключится по SSH к проблемному хосту и перезапустит незапущенный процесс.

Опубликовано в рубрике Monitoring Метки: script, trigger, zabbix

4. Обратитесь к поставщику (-ам) (или к вашему собственному отделу упаковки).

После того, как вы подтвердили, что проблема самовосстановления основана на MSI, и это не ваше собственное программное обеспечение, первое, что нужно попробовать, — это связаться с поставщиком приложений и посмотреть, у вас есть обновленный установщик, чтобы устранить проблему.
Важно попробовать эту опцию, так как все остальные опции — «обходные пути», а не реальные исправления. Проблема может быть только полностью разрешена постоянно с помощью изменений в установщике поставщика и, возможно, самого исполняемого приложения.
Исправление 1

Исправление может быть таким же простым, как отказ поставщика отфильтровать конфиденциально установленные, но глобально зарегистрированные COM файлы с соответствующим общим » слиянием модуля», чтобы установить время выполнения правильно для всех. Они должны правильно установить COM файлы в общие местоположения, где они могут быть зарегистрированы глобально без побочного эффекта. Готов для всех.
Исправить 2: Если поставщик утверждает, что это невозможно, то они должны быть в состоянии обеспечить надлежащую установку COM без регистрации с правильно изолированными COM файлами, установленными в основной папке приложения. Они также должны позаботиться о развертывании любых обновлений безопасности, когда они появятся.

Важно!. Если поставщик использует правильный, общий модуль слияния для развертывания файлов или, обеспечивает изолированную установку, используя без регистрации, тогда проблема должна решаться постоянно для всех.

Проблема также может быть вызвана другими проблемами, но очень часто COM является виновником. Иногда очистка их установщика MSI может разрешать другие, более неясные конфликты
Если вы знаете хорошего упаковщика приложений, он/она должен иметь возможность быстро выявлять конфликты (и предоставлять отзывы поставщику).
Обратите внимание, что также возможно, что саморемонт вызван ошибочной (внутренней) переупаковкой программного обеспечения поставщика. В этом случае вы можете исправить свои собственные пакеты через обновления, предоставленные вашим собственным отделом упаковки/развертывания (и в большинстве случаев они должны быть в состоянии добиться этого)
Это на самом деле очень распространенная проблема.

Отладка .NET приложения запущенного в контейнере

Для нашего примера нам понадобится отдельная сеть, т.к. мы запустим целых два контейнера, которые будут взаимодействовать между собой. На самом деле все запускаемые контейнеры по умолчанию попадают в уже существующую сеть с именем bridge, но т.к. в своей сети мы без лишних проблем сможешь обращаться из одного контейнера к другому прямо по имени, создадим сеть с названием mynet типа bridge

Далее запустим redis и подключим его к ранее созданной сети. Благодаря параметру процесс в контейнере будет запущен в фоновом режиме

Далее с помощью Visual Studio 2019 создадим новый проект ASP.NET Core Web API, который будет использован для демонстрации отладки

Добавим для взаимодействия с Redis пакет StackExchange.Redis через Package Manager Console

Мы не будем акцентироваться на правильности и красоте дизайна, а быстро создадим рабочий пример

Добавим в проект файл RandomWeatherService.cs, где будет находится служба для выдачи не очень точного прогноза

Добавим файл RedisRepository.cs, где будет находится служба кеширования сформированных прогнозов

Зарегистрируем созданные службы в классе Startup

И наконец, изменим созданный автоматически единственный контроллер WeatherForecastController следующим образом

Помимо прочего в проект автоматически был добавлен файл Dockerfile с инструкциями для Docker. Оставим его без изменений

В результате получим следующую структуру проекта

Если по какой-то невероятной причине Вам понадобятся исходники, то они здесь

Запустим наше приложение в контейнере под отладкой

После того как контейнер будет запущен, также подключим его к сети mynet

После убедимся, что все необходимые контейнеры находятся в одной сети

Далее установим Breakpoint в единственном методе контроллера и пошлем запрос через Postman, или через любой браузер

Кстати, используемый порт в Вашем случае может отличаться и его можно посмотреть в окне Containers

Результат в окне Postman

Дополнительно убедимся, что значение зафиксировано в redis, подключившись с помощью консоли redis-cli

Создание учетных записей хостов

Создайте учетные записи хостов для цифровых видеорегистраторов, которые необходимо отслеживать и которыми необходимо управлять с помощью GV-GIS. GV-GIS поддерживает два типа хостов: Mobile Host (Мобильный хост) и Fixed Host (Стационарный хост). К мобильным хостам относятся устройства, оснащенные приемниками GPS и установленные в транспортных средствах; к стационарным хостам относятся устройства без поддержки GPS, которые установлены в фиксированных местах.

Можно создать 500 учетных записей для мобильных хостов и 1000 учетных записей для стационарных хостов. Количество созданных учетных записей отображается в нижней части окна Account (Учетная запись). В качестве примера рассмотрим рисунок. Создано 5 из 500 учетных записей для мобильных хостов и 2 из 1000 учетных записей для стационарных хостов.

Создание мобильного хоста

На панели инструментов нажмите кнопку Account (Учетная запись) (№ 3, рисунок 5-3). Появится окно Account (Учетная запись).
Чтобы создать папку группы, если необходимо, нажмите кнопку Add A Group (Добавить группу).
Нажмите кнопку Add A Subscriber (Добавить абонента), чтобы создать учетную запись хоста.
Назначьте ID (Идентификатор) и Password (Пароль) для хоста, чтобы выполнить вход в GV-GIS.
Другая информация, в том числе Name (Имя), TEL (Телефон), Mobile (Мобильный телефон), Address (Адрес) и E-Mail (Адрес электронной почты), является необязательной для ввода.
С помощью параметра Visible Level in Map (Уровень видимости на карте) можно установить минимальный уровень масштабирования значка хоста на карте. Например, если выбрать значение 14, значок хоста будет отображаться только при масштабировании до уровня 14 или выше. Если установить для уровня значение 0, значок хоста будет всегда отображаться независимо от уровня масштаба.

После создания учетных записей хостов нажмите кнопку Start/Stop Service (Стар/Стоп сервес) (№ 1, рисунок 5-3) на панели инструментов, чтобы запустить службу GV-GIS. При этом хосты должны быть настроены и подключены к GV-GIS. См. Подключение хостов к GV-GIS далее в этой главе, чтобы получить информацию о способах входа хостов в систему GV-GIS.

Создание стационарного хоста

На панели инструментов нажмите кнопку Account (Учетная запись) (№ 3, рисунок 5-3). Откроется диалоговое окноAccount (Учетная запись).
Чтобы создать папку группы, если необходимо, нажмите кнопку Add A Group (Добавить группу).
Нажмите кнопку Add A Fixed Host (Добавить стационарный хост), чтобы создать учетную запись хоста.
В диалоговом окне

Введите имя хоста в поле Host ID (Идентификатор хоста) и выберите тип устройства в выпадающем списке Host Type (Тип хоста).
В разделе Connection Information (Информация о подключении) введите значения IP Address (IP-адрес), Login ID (Идентификатор) и Password (Пароль), чтобы выполнить вход на хост. Используйте порты связи по умолчанию или измените значения портов по мере необходимости.
В разделе Device Information (Информация об устройстве) нажмите кнопку Update Information (Обновить информацию) , чтобы получить информацию о числе камер и модулей I/O, установленных на хосте.
Если необходимо отключить функции отслеживания на определенных камерах, нажмите кнопку Camera Monitor Setting (Настройка отслеживания камеры) . Дополнительную информацию см. в подразделе Обнаружение событий движения и срабатывания устройства входа в разделе 5.6 Операции отслеживания для стационарных хостов.
Поля Subscriber Information (Информация об абоненте) и Note (Примечание) являются необязательными.

Рис. 5-7

Примечание.

С помощью параметра Visible Level in Map (Уровень видимости на карте) в разделе Subscriber Information (Информация об абоненте) можно установить минимальный уровень масштабирования значка хоста на карте. Этот же параметр в разделе Device Information (Информация об устройстве) служит для установки минимального уровня масштабирования для значков камеры и I/O на карте. Дополнительную информацию об этом параметре см. в шаге 6 в разделе Создание стационарного хоста ранее в этой главе.
Порты связи цифрового видеорегистратора (командный порт 3388, порт данных 5611 и порт журнала 5552) должны соответствовать портам контрольного центра на этом же цифровом видеорегистраторе.

После создания учетных записей хостов неокоторые хосты необходимо настроить и подключить к GV-GIS. См. Подключение хостов к GV-GIS далее в этой главе, чтобы получить информацию о способах входа хостов в систему GV-GIS.

Заключение

В итоге мы создали два простеньких микросервиса, упаковали их в докер-контейнеры и совместно запустили на одной машине. У полученной системы, однако, есть ряд недостатков:

Плохая отказоустойчивость — у нас все работает на одном сервере
Плохая масштабируемость — при увеличении нагрузки было бы неплохо автоматически разворачивать дополнительные экземпляры сервисов и балансировать нагрузку между ними
Сложность запуска — нам понадобилось ввести как минимум 3 команды, причем с определенными параметрами (это только для 2 сервисов)

Для устранения вышеперечисленных проблем существует ряд решений, таких как Docker Swarm, Nomad, Kubernetes или OpenShift. Если вся система будет написана на Java можно посмотреть в сторону Spring Cloud (хорошая статья).