Подготовка к развертыванию решения IoT Edge в рабочей среде

Область применения: IoT Edge 1.4

Важно!

IoT Edge 1.4 является поддерживаемым выпуском. Если вы используете более ранний выпуск, см. статью Обновление IoT Edge.

Когда вы будете готовы перейти от разработки решения IoT Edge к его развертыванию в рабочей среде, убедитесь, что оно настроено для непрерывной работы.

Не все сведения, представленные в этой статье, равноценны. Чтобы помочь вам расставить приоритеты, каждый раздел начинается со списков, разделяющих работу на две части: важные задачи, которые следует выполнить перед переходом в рабочую среду, и полезные для вас сведения.

Конфигурация устройств

Устройством IoT Edge может быть что угодно — от Raspberry Pi до ноутбука или виртуальной машины, работающей на сервере. У вас может быть доступ к устройству (физически или через виртуальное подключение), либо оно может быть изолировано в течение продолжительного времени. В любом случае вам нужно убедиться, что оно настроено для надлежащей работы.

• Важно!

  • Установка рабочих сертификатов
  • Составление плана управления устройствами
  • Использование Moby в качестве модуля контейнеров

• Полезное

  • Выбор вышестоящего протокола

Установка рабочих сертификатов

На каждом устройстве IoT Edge в рабочей среде необходимо установить сертификат от центра сертификации (ЦС). Затем этот сертификат ЦС объявляется в файле конфигурации для среды выполнения IoT Edge. Для сценариев разработки и тестирования среда выполнения IoT Edge создает временные сертификаты, если они не объявлены в файле конфигурации. Однако срок действия этих сертификатов истекает спустя три месяца, и они недостаточно безопасны для рабочих сценариев. В рабочих сценариях необходимо предоставить собственный сертификат ЦС устройства либо из центра самозаверяющих сертификатов, либо приобретенный в коммерческом центре сертификации.

Сведения о роли сертификатов ЦС для устройств см. в статье Сведения об использовании сертификатов Azure IoT Edge.

Дополнительные сведения о том, как устанавливать сертификаты на устройстве IoT Edge и ссылаться на них из файла конфигурации см. в статье Управление сертификатами на устройстве IoT Edge.

Составление плана управления устройствами

Прежде чем внедрять устройство в рабочую среду, следует определить, как вы будете управлять будущими обновлениями. В случае устройства IoT Edge могут обновляться перечисленные ниже компоненты.

• Встроенное ПО устройства
• Библиотеки операционной системы
• Модуль контейнеров (например, Moby)
• IoT Edge
• Сертификаты ЦС

Обновление устройств для Центр Интернета вещей — это служба, которая позволяет развертывать обновления через воздух (OTA) для устройств IoT Edge.

Альтернативные методы обновления IoT Edge требуют физического или SSH-доступа к устройству IoT Edge. Дополнительные сведения см. в разделе Обновление среды выполнения IOT Edge. Чтобы обновить несколько устройств, попробуйте добавить шаги обновления в скрипт или использовать средство автоматизации, например Ansible.

Использование Moby в качестве модуля контейнеров

Наличие модуля контейнеров — обязательное условие для любого устройства IoT Edge. В рабочей среде поддерживается только moby-engine. Другие модули контейнеров, например Docker, совместимы с IoT Edge, и их можно использовать при разработке. Модуль moby-engine можно распространять при использовании с Azure IoT Edge, а корпорация Майкрософт выполняет обслуживание этого модуля.

Выбор вышестоящего протокола

Можно настроить протокол (который определяет используемый порт) для связи по восходящему каналу с центром Интернета вещей как для агента IoT Edge, так и для центра IoT Edge. По умолчанию используется протокол AMQP, но его можно изменить в зависимости от конфигурации сети.

У двух модулей среды выполнения есть переменная среды UpstreamProtocol. Допустимые значения переменной:

• MQTT
• AMQP
• MQTTWS
• AMQPWS

Настройте переменную UpstreamProtocol для агента IoT Edge в файле конфигурации на самом устройстве. Например, если устройство IoT Edge защищено прокси-сервером, блокирующим порты AMQP, то вам может потребоваться настроить агент IoT Edge на использование AMQP через WebSocket (AMQPWS) для установки первоначального подключения к Центру Интернета вещей.

После подключения устройства IoT Edge обязательно настраивайте переменную UpstreamProtocol для обоих модулей среды выполнения в будущих развертываниях. Пример этого процесса представлен в статье Настройка устройства IoT Edge для обмена данными через прокси-сервер.

Развертывание

• Полезное
  • Согласование с вышестоящим протоколом
  • Настройка хранилища узлов для системных модулей
  • Сокращение объема памяти, используемого центром IoT Edge
  • Использование правильных образов модулей в манифестах развертывания
  • Учитывайте ограничения размера двойника при использовании пользовательских модулей
  • Настройка применения обновлений для модулей

Согласование с вышестоящим протоколом

Если вы настроили агент IoT Edge на устройстве IoT Edge на использование протокола, отличного от стандартного AMQP, то следует объявлять тот же протокол во всех будущих развертываниях. Например, если устройство IoT Edge защищено прокси-сервером, блокирующим порты AMQP, то оно наверняка настроено на подключение по протоколу AMQP через WebSocket (AMQPWS). При развертывании модулей на устройстве задайте для агента и центра IoT Edge один и тот же протокол (APQPWS), в противном случае стандартный протокол AMQP переопределит параметры и не позволит снова подключиться.

Переменную среды UpstreamProtocol достаточно настроить для модулей агента и центра IoT Edge. Все остальные модули используют протокол, заданный в модулях среды выполнения.

Пример этого процесса представлен в статье Настройка устройства IoT Edge для обмена данными через прокси-сервер.

Настройка хранилища узлов для системных модулей

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

Дополнительные сведения см. в разделе Хранилище узла для системных модулей.

Сокращение объема памяти, используемого центром IoT Edge

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

Не оптимизируйте устройства с ограниченными ресурсами для высокой производительности

Центр IoT Edge по умолчанию оптимизирован для высокой производительности, поэтому всегда пытается выделить большие блоки памяти. Такая конфигурация может привести к проблемам со стабильностью на небольших устройствах, таких как Raspberry Pi. При развертывании устройств с ограниченными ресурсами рекомендуем задавать для переменной среды OptimizeForPerformance значение false в центре IoT Edge.

Если для параметра OptimizeForPerformance задано значение true, в заголовке протокола MQTT используется параметр PooledByteBufferAllocator, что повышает производительность, но приводит к выделению большего объема памяти. Распределитель плохо работает в 32-разрядных операционных системах или на устройствах с нехваткой памяти. Кроме того, при оптимизации под повышение производительности RocksDb выделяет больше памяти для своей роли в качестве локального поставщика хранилища.

Дополнительные сведения см. в статье Проблемы стабильности на небольших устройствах.

Отключение неиспользуемых протоколов

Еще один способ оптимизировать производительность центра IoT Edge и снизить использование памяти — отключить заголовки тех протоколов, которые не используются в вашем решении.

Заголовки протоколов настраиваются с помощью логических переменных среды для модуля центра IoT Edge в манифестах развертывания. Вот эти переменные:

• amqpSettings__enabled
• mqttSettings__enabled
• httpSettings__enabled

Имена всех трех переменных содержат два подчеркивания, и для них можно задавать значение true или false.

Сокращение времени хранения сообщений

Модуль центра IoT Edge временно сохраняет сообщения, если по той или иной причине их не удается доставить в Центр Интернета вещей. Вы можете настраивать продолжительность хранения недоставленных сообщений в центре IoT Edge. Если вас беспокоит использование памяти на устройстве, вы можете снизить значение timeToLiveSecs в двойнике модуля центра IoT Edge.

Для параметра timeToLiveSecs по умолчанию задано значение 7200 секунд, то есть два часа.

Использование правильных образов модулей в манифестах развертывания

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

Не используйте отладочные версии образов модулей

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

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

Манифест развертывания, содержащий пользовательские модули, является частью двойника EdgeAgent. Проверьте ограничение размера двойника модуля.

При развертывании большого количества модулей может быть исчерпано это ограничение размера двойника. Рассмотрим некоторые распространенные способы устранения проблем с этим жестким ограничением:

• Сохраните любую конфигурацию в двойнике пользовательского модуля, которая имеет собственное ограничение.
• Сохраните некоторую конфигурацию, указывающую на непространство ограниченное расположение (т. е. в хранилище BLOB-объектов).

Настройка применения обновлений для модулей

При обновлении развертывания агент Edge получает новую конфигурацию в качестве обновления двойника. Если в новой конфигурации есть новые или обновленные образы модулей, по умолчанию агент Edge последовательно обрабатывает каждый модуль:

1. Обновленный образ скачан
2. Запущенный модуль остановлен
3. Запускается новый экземпляр модуля
4. Следующее обновление модуля обрабатывается

В некоторых случаях, например при наличии зависимостей между модулями, рекомендуется сначала скачать все обновленные образы модулей перед перезапуском всех запущенных модулей. Это поведение обновления модуля можно настроить, задав переменную ModuleUpdateMode среды агента IoT Edge строковое значение WaitForAllPulls. Дополнительные сведения см. в разделе "Переменные среды IoT Edge".

"modulesContent": {
    "$edgeAgent": {
        "properties.desired": {
            ...
            "systemModules": {
                "edgeAgent": {
                    "env": {
                        "ModuleUpdateMode": {
                            "value": "WaitForAllPulls"
                        }
                    ...

Управление контейнерами

• Важно!
  • Использование тегов для управления версиями
  • Управление томами
• Полезное
  • Сохранение контейнеров среды выполнения в частном реестре
  • Настройка сборки мусора образа

Использование тегов для управления версиями

Тег — это элемент Docker, с помощью которого можно различать версии контейнеров Docker. Теги — это суффиксы (например, 1.1), указываемые в конце имени репозитория контейнеров. Пример: mcr.microsoft.com/azureiotedge-agent:1.1. Теги можно в любой момент менять, чтобы указывать на другой контейнер, поэтому вашей команде следует договориться о правилах обновления образов модулей в будущем.

Теги также помогают принудительно устанавливать обновления на устройствах IoT Edge. Отправляя обновленную версию модуля в реестр контейнеров, увеличивайте тег. Затем отправьте новое развертывание на устройства с увеличенным тегом. Модуль контейнеров распознает увеличенный тег как новую версию и извлечет последнюю версию модуля на устройство.

Теги среды выполнения IoT Edge

Образы агента и центра IoT Edge отмечены тегами версии IoT Edge, с которой они связаны. Существует два способа использования тегов с образами среды выполнения:

• Последовательные теги: используются только первые два значения номера версии для получения последнего образа, соответствующего этим цифрам. Например, 1.1 обновляется всякий раз, когда появляется новый выпуск, указывающий на последнюю версию 1.1.x. Если среда выполнения контейнера на устройстве IoT Edge снова извлекает образ, модули среды выполнения обновляются до последней версии. Для развертываний с портала Azure по умолчанию установлены последовательные теги. Этот подход предлагается для целей разработки.

• Конкретные теги: используются все три значения номера версии для явной установки версии образа. Например, 1.1.0 не изменится после первоначального выпуска. Вы можете объявить новый номер версии в манифесте развертывания, когда будете готовы к обновлению. Этот подход предлагается для производственных целей.

Управление томами

IoT Edge не удаляет тома, подключенные к контейнерам модулей. Это поведение реализовано намеренно, так как оно позволяет сохранять данные в экземплярах контейнеров, например в сценариях обновления. Однако если эти тома не используются, это может привести к нехватке места на диске и последующим системным ошибкам. Если в сценарии используются тома docker, рекомендуется использовать такие средства docker, как docker volume prune и docker volume rm , чтобы удалить неиспользуемые тома, особенно для рабочих сценариев.

Сохранение контейнеров среды выполнения в частном реестре

Вы знаете, как хранить образы контейнеров для модулей пользовательского кода в частном реестре Azure, но вы также можете использовать его для хранения общедоступных образов контейнеров, таких как модули среды выполнения edgeAgent и edgeHub . Это может потребоваться, если у вас очень строгие ограничения брандмауэра, так как эти контейнеры среды выполнения хранятся в реестре контейнеров Майкрософт (MCR).

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

1. Извлеките образ Docker edgeAgent из реестра Майкрософт. При необходимости обновите номер версии.

   # Pull edgeAgent image
   docker pull mcr.microsoft.com/azureiotedge-agent:1.4
   
   # Pull edgeHub image
   docker pull mcr.microsoft.com/azureiotedge-hub:1.4
   

2. Выведите список всех образов Docker, найдите образы edgeAgent и edgeHub , а затем скопируйте идентификаторы изображений.

   docker images
   

3. Перетагируйте образы edgeAgent и edgeHub . Замените значения в скобках собственным.

   # Retag your edgeAgent image
   docker tag <my-image-id> <registry-name/server>/azureiotedge-agent:1.4
   
   # Retag your edgeHub image
   docker tag <my-image-id> <registry-name/server>/azureiotedge-hub:1.4
   

4. Отправьте образы edgeAgent и edgeHub в частный реестр. Замените значение в скобках собственным.

   # Push your edgeAgent image to your private registry
   docker push <registry-name/server>/azureiotedge-agent:1.4
   
   # Push your edgeHub image to your private registry
   docker push <registry-name/server>/azureiotedge-hub:1.4
   

5. Обновите ссылки на образы в файле deployment.template.json для модулей системы edgeAgent и EdgeHub , заменив mcr.microsoft.com собственный "реестр-имя/сервер" для обоих модулей.

6. Откройте текстовый редактор на устройстве IoT Edge, чтобы изменить файл конфигурации, чтобы он знал о образе частного реестра.

   sudo nano /etc/aziot/config.toml
   

7. В текстовом редакторе измените значения изображения в разделе [agent.config]. Замените значения в скобках собственным.

   [agent.config]
   image = "<registry-name/server>/azureiotedge-agent:1.4"
   

8. Если для частного реестра требуется проверка подлинности, задайте параметры проверки подлинности в [agent.config.auth].

   [agent.config.auth]
   serveraddress = "<login-server>" # Almost always equivalent to <registry-name/server>
   username = "<username>"
   password = "<password>"
   

9. Сохраните изменения и закройте текстовый редактор.

10. Примените изменение конфигурации IoT Edge.

    sudo iotedge config apply
    

    Среда выполнения IoT Edge перезапускается.

Дополнительные сведения см. в разделе:

• Настройка агента IoT Edge
• Агент Azure IoT Edge
• Центр Интернета вещей Azure

Настройка сборки мусора образа

Сборка мусора образа — это функция в IoT Edge версии 1.4 и более поздних версий для автоматического очистки образов Docker, которые больше не используются модулями IoT Edge. Он удаляет только образы Docker, которые были извлечены средой выполнения IoT Edge в рамках развертывания. Удаление неиспользуемых образов Docker помогает сохранить место на диске.

Эта функция реализована в компоненте узла IoT Edge, aziot-edged службе и включенной по умолчанию. Очистка выполняется каждый день в полночь (локальное время устройства) и удаляет неиспользуемые образы Docker, которые использовались семь дней назад. Параметры для управления поведением очистки задаются в config.toml разделе и описаны далее в этом разделе. Если параметры не указаны в файле конфигурации, применяются значения по умолчанию.

Например, ниже приведен config.toml раздел сборки мусора образа с использованием значений по умолчанию:

[image_garbage_collection]
enabled = true
cleanup_recurrence = "1d"
image_age_cleanup_threshold = "7d" 
cleanup_time = "00:00"

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

Параметр	Описание:	Обязательное поле	Default value
enabled	Включает сборку мусора образа. Вы можете отключить эту функцию, изменив этот параметр falseна .	Необязательно	true
cleanup_recurrence	Управляет частотой повторения задачи очистки. Необходимо указать как несколько дней и не может быть меньше одного дня. Например: 1d, 2d, 6d и т. д.	Необязательно	1 день
image_age_cleanup_threshold	Определяет минимальное пороговое значение возраста неиспользуемых изображений перед рассмотрением очистки и должно быть указано в днях. Вы можете указать значение 0d , чтобы очистить образы, как только они будут удалены из развертывания. Образы считаются неиспользуемые после удаления из развертывания.	Необязательно	7 дней
cleanup_time	Время дня в локальном времени устройства при выполнении задачи очистки. Должен быть в формате 24-часового HH:MM.	Необязательно	00:00

Сеть

• Полезное
  • Просмотр конфигурации исходящих и входящих подключений
  • Разрешение подключений с устройств IoT Edge
  • Настройка связи через прокси-сервер
  • Настройка DNS-сервера в параметрах обработчика контейнеров

Просмотр конфигурации исходящих и входящих подключений

Каналы связи между Центром Интернета вещей Azure и IoT Edge всегда настраиваются как исходящие. Для большинства сценариев IoT Edge достаточно трех подключений. Модуль контейнеров должен соединяться с реестрами контейнеров, в которых хранятся образы модулей. Среда выполнения IoT Edge должна подключиться к Центру Интернета вещей, чтобы получить сведения о конфигурации устройств, а также отправить сообщение и данные телеметрии. А если вы используете автоматическую подготовку, IoT Edge должен подключиться к службе подготовки устройств. Дополнительные сведения см. в разделе Правила конфигурации брандмауэра и порта для развертывания IoT Edge.

Разрешение подключений с устройств IoT Edge

Если ваша сетевая конфигурация требует явно добавлять в список разрешений подключения, установленные с устройств IoT Edge, просмотрите приведенный ниже список компонентов IoT Edge:

• Агент IoT Edge открывает постоянное подключение AMQP/MQTT к Центру Интернета вещей (возможно, через объекты WebSocket).
• Центр IoT Edge открывает одно постоянное подключение AMQP или несколько подключений MQTT к Центру Интернета вещей (возможно, через объекты WebSocket).
• Служба IoT Edge совершает прерывистые HTTPS-вызовы к Центру Интернета вещей.

Во всех трех случаях полное доменное имя (FQDN) будет соответствовать шаблону \*.azure-devices.net.

Реестры контейнеров

Подсистема контейнеров вызывает реестры контейнеров по протоколу HTTPS. Чтобы получить образы контейнеров среды выполнения IoT Edge, полное доменное имя имеет значение mcr.microsoft.com. Модуль контейнеров подключается к другим реестрам в соответствии с настройками развертывания.

Этот контрольный список является отправной точкой для настройки правил брандмауэра:

Полное доменное имя (* = wild карта)	Исходящие порты TCP	Использование
mcr.microsoft.com	443	Реестр контейнеров Майкрософт
*.data.mcr.microsoft.com	443	Конечная точка данных, обеспечивающая доставку содержимого
*.cdn.azcr.io	443	Развертывание модулей из Marketplace на устройствах
global.azure-devices-provisioning.net	443	Доступ к службе подготовки устройств (необязательно)
*.azurecr.io	443	Реестры личных и сторонних контейнеров
*.blob.core.windows.net	443	Скачивание изменений образа реестра контейнеров Azure из хранилища BLOB-объектов
*.azure-devices.net	5671, 8883, 4431	Доступ к Центру Интернета вещей
*.docker.io	443	Доступ к Docker Hub (необязательно)

¹Открытый порт 8883 для безопасного MQTT или порта 5671 для защиты AMQP. Если вы можете выполнять подключения только через порт 443, то любой из этих протоколов может выполняться через туннель WebSocket.

Так как IP-адрес Центра Интернета вещей может изменяться без уведомления, всегда используйте полное доменное имя для настройки списка разрешений. Дополнительные сведения см. в статье "Общие сведения о IP-адресе Центр Интернета вещей".

Некоторые из этих правил брандмауэра наследуются от реестра контейнеров Azure. Подробная информация приведена в статье Настройка правил для доступа к реестру контейнеров Azure за брандмауэром.

Вы можете включить выделенные конечные точки данных в реестре контейнеров Azure, чтобы избежать дикого карта разрешенного списка полного доменного имени *.blob.core.windows.net. Дополнительные сведения см. в разделе "Включение выделенных конечных точек данных".

Примечание.

Чтобы обеспечить согласованное полное доменное имя между REST и конечными точками данных, начиная с 15 июня 2020 г. конечная точка данных Microsoft Container Registry изменится с *.cdn.mscr.io на *.data.mcr.microsoft.com
Дополнительные сведения см. в статье Настройка правил брандмауэра для клиента Microsoft Container Registry

Если вы не хотите настраивать брандмауэр для разрешения доступа к общедоступным реестрам контейнеров, вы можете хранить образы в частном реестре контейнеров, как описано в разделе Хранение контейнеров среды выполнения в частном реестре.

Служба удостоверений Интернета вещей Azure

Служба удостоверений Интернета вещей предоставляет службы подготовки и шифрования для устройств Интернета вещей Azure. Служба удостоверений проверка, если установленная версия является последней. В проверка для проверки версии используется следующее полное доменное имя.

Полное доменное имя	Исходящие порты TCP	Использование
aka.ms	443	URL-адрес ванности, предоставляющий перенаправление в файл версии
raw.githubusercontent.com	443	Файл версии службы удостоверений, размещенный в GitHub

Настройка связи через прокси-сервер

Если устройства будут развернуты в сети, использующей прокси-сервер, они должны иметь возможность взаимодействовать через прокси-сервер, чтобы получать доступ к Центру Интернета вещей и реестрам контейнеров. Дополнительные сведения см. в статье Настройка устройства IoT Edge для обмена данными через прокси-сервер.

Настройка DNS-сервера в параметрах обработчика контейнеров

Укажите DNS-сервер для среды в параметрах обработчика контейнеров. Параметр DNS-сервера применяется ко всем модулям контейнеров, запущенным подсистемой.

1. В каталоге на устройстве измените /etc/dockerdaemon.json файл. Создайте файл, если он не существует.

2. Добавьте dns-ключ и задайте DNS-адрес dns-сервера в общедоступную службу DNS. Если пограничное устройство не может получить доступ к общедоступному DNS-серверу, используйте доступный DNS-адрес в сети. Например:

   {
       "dns": ["1.1.1.1"]
   }
   

Управление решениями

• Полезное
  • Настройка журналов и диагностики
  • Настройка драйвера ведения журнала по умолчанию
  • Тесты и конвейеры CI/CD

Настройка журналов и диагностики

В Linux управляющая программа IoT Edge использует journals как драйвер ведения журналов по умолчанию. Чтобы запрашивать журналы управляющей программы, можно использовать программу командной строки journalctl.

Начиная с версии 1.2 IoT Edge полагается на несколько управляющих программ. Хотя в каждый журнал управляющей программы можно отправлять индивидуальные запросы с помощью journalctl, команды iotedge system предоставляют удобный способ запроса к объединенным журналам.

• Консолидированная команда iotedge:

  sudo iotedge system logs
  

• Эквивалентная команда journalctl:

  journalctl -u aziot-edge -u aziot-identityd -u aziot-keyd -u aziot-certd -u aziot-tpmd
  

При тестировании развертывания IoT Edge обычно можно получать доступ к своим устройствам для извлечения журналов и устранения неполадок. В случае развертывания эта возможность может отсутствовать. Подумайте, как вы будете собирать сведения об устройствах в рабочей среде. Один вариант — использовать модуль ведения журнала, который собирает сведения от других модулей и отправляет их в облако. К примерам модулей ведения журнала относится logspout-loganalytics. Вы также можете создать собственный модуль.

Настройка драйвера ведения журнала по умолчанию

По умолчанию подсистема контейнеров Moby не устанавливает ограничения размера журнала контейнера. Со временем это может привести к заполнению устройства журналами и исчерпанию дискового пространства. Настройте подсистему контейнеров для использования local драйвера ведения журнала в качестве механизма ведения журнала. Local Драйвер ведения журнала предлагает ограничение размера журнала по умолчанию, выполняет смену журнала по умолчанию и использует более эффективный формат файла, который помогает предотвратить нехватку места на диске. Вы также можете использовать разные драйверы ведения журнала и задать различные ограничения размера в зависимости от необходимости.

Параметр. Настройка драйвера ведения журнала по умолчанию для всех модулей контейнеров

Вы можете настроить подсистему контейнеров для использования определенного драйвера ведения журнала, задав значение log driver имени драйвера журнала в файле daemon.json. В следующем примере драйвер ведения журнала по умолчанию задается драйвером local журнала (рекомендуется).

{
    "log-driver": "local"
}

Вы также можете настроить log-opts ключи для использования соответствующих значений daemon.json в файле. В следующем примере драйвер local журнала задает и задает max-size параметры и max-file параметры.

{
    "log-driver": "local",
    "log-opts": {
        "max-size": "10m",
        "max-file": "3"
    }
}

Добавьте (или внесите) эти сведения в файл с именем daemon.json и поместите его в следующее расположение:

• /etc/docker/

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

Вариант: настройка параметров журнала для каждого модуля контейнера

Это можно сделать с помощью createOptions каждого модуля. Например:

"createOptions": {
    "HostConfig": {
        "LogConfig": {
            "Type": "local",
            "Config": {
                "max-size": "10m",
                "max-file": "3"
            }
        }
    }
}

Дополнительные параметры в системах Linux

• Настройте подсистему контейнеров для отправки журналов systemdв журнал , установив journald в качестве драйвера ведения журнала по умолчанию.

• Периодически удаляйте старые журналы с устройства, установив средство logrotate. Используйте следующую спецификацию файла:

  /var/lib/docker/containers/*/*-json.log{
       copytruncate
       daily
       rotate7
       delaycompress
       compress
       notifempty
       missingok
  }
  

Тесты и конвейеры CI/CD

Для максимально эффективного развертывания IoT Edge рекомендуем интегрировать рабочую среду с конвейерами CI/CD и тестирования. Azure IoT Edge поддерживает множество платформ CI/CD, включая Azure DevOps. Дополнительные сведения см. в статье Непрерывная интеграция и непрерывное развертывание в Azure IoT Edge.

Вопросы безопасности

• Важно!
  • Управление доступом к реестру контейнеров
  • Ограничение доступа к контейнеру только ресурсами узла

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

Прежде чем развертывать модули на рабочих устройствах IoT Edge, убедитесь, что вы контролируете доступ к реестру контейнеров, чтобы посторонние не могли получать доступ к образам контейнеров и вносить в них изменения. Используйте частный реестр контейнеров для управления их образами.

В руководствах и другой документации говорится, что следует использовать на устройстве IoT Edge те же учетные данные реестра контейнеров, что и на компьютере для разработки. Эти инструкции призваны лишь помочь вам настраивать среды тестирования и разработки. Их не следует соблюдать в рабочей среде.

Для более безопасного доступа к реестру можно выбрать параметры проверки подлинности. Популярный и рекомендуемый способ проверки подлинности — использование субъекта-службы Active Directory, который хорошо подходит для приложений и служб для извлечения образов контейнеров в автоматизированном или ином автоматическом (автономном) режиме, как в устройствах IoT Edge. Другим вариантом является использование маркеров с область репозиторием, что позволяет создавать длинные или короткие удостоверения, которые существуют только в Реестр контейнеров Azure, в которых они были созданы и область доступ к уровню репозитория.

Чтобы создать субъект-службу, выполните два сценария, как описано в разделе Создание субъекта-службы. Эти сценарии выполняют следующие задачи.

• Первый сценарий создает субъект-службу. Он выдает идентификатор субъекта-службы и пароль субъекта-службы. Храните эти значения безопасным образом в ваших записях.

• Второй сценарий создает назначения ролей для их предоставления субъекту-службе, который при необходимости может выполняться в дальнейшем. Мы рекомендуем применять роль пользователя acrPull для параметра role. Список ролей см. в статье Роли и разрешения реестра контейнеров Azure.

Для проверки подлинности с помощью субъекта-службы укажите идентификатор и пароль субъекта-службы, полученные в результате работы первого сценария. Укажите эти учетные данные в манифесте развертывания.

• В качестве имени пользователя или идентификатора клиента укажите идентификатор субъекта-службы.

• В качестве пароля или секрета клиента укажите пароль субъекта-службы.

Чтобы создать маркеры репозитория, область d, следуйте инструкциям по созданию токена, область d репозитория.

Чтобы пройти проверку подлинности с помощью маркеров, область репозитория, укажите имя и пароль маркера, полученные после создания маркера область репозитория. Укажите эти учетные данные в манифесте развертывания.

• Для имени пользователя укажите имя пользователя маркера.

• Для пароля укажите один из паролей маркера.

Примечание.

После реализации расширенной защищенной проверки подлинности отключите параметр Администратор, чтобы доступ к имени пользователя и паролю по умолчанию отсутствовал. В реестре контейнеров на портале Azure в меню слева в разделе Параметры выберите Ключи доступа.

Ограничение доступа к контейнеру только ресурсами узла

Чтобы сбалансировать общие ресурсы узла в разных модулях, мы рекомендуем задать ограничения на потребление ресурсов для каждого модуля. Такие ограничения необходимы для того, чтобы отдельные модули не использовали слишком много ресурсов памяти или ЦП и не блокировали выполнение других процессов на устройстве. Платформа IoT Edge не ограничивает ресурсы для модулей по умолчанию, так как определение того, сколько ресурсов нужно определенному модулю для оптимального выполнения, требует тестирования.

Docker предоставляет некоторые ограничения, которые можно использовать для ограничения ресурсов, например использования памяти и ЦП. Дополнительные сведения см. на этой странице.

Эти ограничения можно применять к отдельным модулям с помощью параметров создания в манифестах развертывания. Дополнительные сведения см. в разделе Настройка параметров создания контейнера для модулей IOT Edge.

Следующие шаги

• Дополнительные сведения см. в статье об автоматическом развертывании IoT Edge.
• Узнайте о поддержке непрерывных интеграции и развертывания в IoT Edge.