Подключение устройств Azure IoT Edge для создания иерархии

Статья
08/07/2024

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

Внимание

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

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

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

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

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

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

Проверка подлинности. Создайте удостоверения центра Интернета вещей для всех устройств в иерархии шлюзов.
Авторизация: настройте связь родительского или дочернего устройства в Центр Интернета вещей, чтобы авторизовать подчиненные устройства для подключения к родительскому устройству, как они будут подключаться к Центр Интернета вещей.
Обнаружение шлюза: убедитесь, что нижнее устройство может найти родительское устройство в локальной сети.
Безопасное подключение. Установите безопасное соединение с доверенными сертификатами, которые являются частью одной цепочки.

Необходимые компоненты

Центр Интернета вещей уровня "Бесплатный" или "Стандартный".
По крайней мере два устройства IoT Edge, одно из которых будет устройством верхнего уровня, а остальные — более низкого уровня. Если у вас нет доступных устройств IoT Edge, вы можете запустить Azure IoT Edge на виртуальных машинах Ubuntu.
Если вы используете Azure CLI для создания устройств и управления ими, установите расширение Azure IoT.

Совет

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

Создание иерархии шлюзов

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

Шаг настройки отношений "родительский или дочерний" разрешает подчиненным устройствам подключаться к родительскому устройству, как они будут подключаться к Центр Интернета вещей.

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

По умолчанию у родительского может быть до 100 дочерних элементов. Это ограничение можно изменить, задав переменную среды MaxConnectedClients в модуле edgeHub родительского устройства.

Портал
Azure CLI

На портале Azure можно управлять связью "родители-потомки" при создании новых удостоверений устройств или при изменении существующих.

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

Найдите нужный Центр Интернета вещей на портале Azure.
Выберите устройства в меню управления устройствами .
Выберите "Добавить устройство", а затем установите флажок "Устройство IoT Edge".
Помимо указания идентификатора устройства и параметров проверки подлинности можно Задать родительское устройство или Выбрать дочерние устройства.
Выберите устройство или устройства, которые должны быть родительскими или дочерними.

Вы также можете создавать и администрировать отношения "родители-потомки" для существующих устройств.

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

Расширение azure-iot для Azure CLI предоставляет команды для управления ресурсами Интернета вещей. Вы можете управлять связью "родители-потомки" для устройств Интернета вещей и IoT Edge при создании новых удостоверений устройств или изменении существующих.

Набор команд az iot hub device-identity позволяет управлять связями "родители-потомки" для конкретного устройства.

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

Дополнительные команды удостоверений устройства, включая add-children, list-children и remove-children или get-parent и set-parent, позволяют управлять связями "родители-потомки" для существующих устройств.

Примечание.

Если вы хотите установить связи "родители-потомки" программным образом, можно использовать пакет SDK службы Центра Интернета вещей для C#, Java или Node.js.

Ниже приведен пример назначения дочернего устройства с помощью пакета SDK для C#. В задаче RegistryManager_AddAndRemoveDeviceWithScope() показано, как программным способом создать иерархию из трех уровней. Устройство IoT Edge находится на первом уровне в качестве родительского. Другое устройство IoT Edge находится на уровне 2 в качестве дочернего и родительского. Наконец, устройство Интернета вещей находится на уровне 3 как дочернее устройство самого нижнего уровня.

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

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

С помощью этой установки каждое нижнее устройство IoT Edge может проверить удостоверение родительского устройства, убедившись, что edgeHub , к которому они подключаются, имеет сертификат сервера, подписанный общим корневым сертификатом ЦС.

Иллюстрация цепочки сертификатов, выданной корневым ЦС на шлюзе и нижнем устройстве

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

Создайте или запросите следующие сертификаты:
- Корневой сертификат ЦС, который является самым верхним общим сертификатом для всех устройств в данной иерархии шлюзов. Этот сертификат устанавливается на всех устройствах.
- Все промежуточные сертификаты, которые необходимо включить в цепочку корневых сертификатов.
- Сертификат ЦС Edge и его закрытый ключ, созданные корневыми и промежуточными сертификатами. Для каждого устройства IoT Edge в иерархии шлюза требуется один уникальный сертификат ЦС Edge.
Вы можете использовать самозаверяющий центр сертификации или приобрести один из доверенных коммерческих центров сертификации, таких как Baltimore, VeriSign, DigiCert или GlobalSign.
Если у вас нет собственных сертификатов для тестирования, создайте один набор корневых и промежуточных сертификатов, а затем создайте сертификаты ЦС Edge для каждого устройства. В этой статье мы будем использовать тестовые сертификаты, созданные с помощью тестовых сертификатов ЦС для примеров и учебников. Например, следующие команды создают корневой сертификат ЦС, родительский сертификат устройства и дочерний сертификат устройства.
```
# !!! For test only - do not use in production !!!

# Create the the root CA test certificate
./certGen.sh create_root_and_intermediate

# Create the parent (gateway) device test certificate 
# signed by the shared root CA certificate
./certGen.sh create_edge_device_ca_certificate "gateway"

# Create the downstream device test certificate
# signed by the shared root CA certificate
./certGen.sh create_edge_device_ca_certificate "downstream"
```
Предупреждение

Не используйте сертификаты, созданные скриптами тестирования для рабочей среды. Они содержат жестко закодированные пароли и истекают по умолчанию через 30 дней. Тестовые сертификаты ЦС предоставляются для демонстрационных целей, которые помогут вам понять сертификаты ЦС. Используйте собственные рекомендации по обеспечению безопасности для создания сертификации и управления жизненным циклом в рабочей среде.

Дополнительные сведения о создании тестовых сертификатов см. в статье о создании демонстрационных сертификатов для тестирования функций устройств IoT Edge.
Вам потребуется передать сертификаты и ключи каждому устройству. Вы можете использовать USB-диск, службу, например Azure Key Vault, или функцию, например безопасную копию файлов. Выберите один из этих методов, которые лучше всего соответствуют вашему сценарию. Скопируйте файлы в предпочтительный каталог для сертификатов и ключей. Используется /var/aziot/certs для сертификатов и /var/aziot/secrets ключей.

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

Настройка родительского устройства

Чтобы настроить родительское устройство, откройте локальную или удаленную командную оболочку.

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

Проверьте сертификаты в соответствии с требованиями к формату.
Передайте корневой сертификат ЦС, родительский сертификат ЦС Edge и родительский закрытый ключ на родительское устройство.

Скопируйте сертификаты и ключи в правильные каталоги. Предпочтительный каталог для сертификатов устройств — /var/aziot/certs для сертификатов и /var/aziot/secrets ключей.

### Copy device certificate ###

# If the device certificate and keys directories don't exist, create, set ownership, and set permissions
sudo mkdir -p /var/aziot/certs
sudo chown aziotcs:aziotcs /var/aziot/certs
sudo chmod 755 /var/aziot/certs

sudo mkdir -p /var/aziot/secrets
sudo chown aziotks:aziotks /var/aziot/secrets
sudo chmod 700 /var/aziot/secrets

# Copy full-chain device certificate and private key into the correct directory
sudo cp iot-edge-device-ca-gateway-full-chain.cert.pem /var/aziot/certs
sudo cp iot-edge-device-ca-gateway.key.pem /var/aziot/secrets

### Root certificate ###

# Copy root certificate into the /certs directory
sudo cp azure-iot-test-only.root.ca.cert.pem /var/aziot/certs

# Copy root certificate into the CA certificate directory and add .crt extension.
# The root certificate must be in the CA certificate directory to install it in the certificate store.
# Use the appropriate copy command for your device OS or if using EFLOW.

# For Ubuntu and Debian, use /usr/local/share/ca-certificates/
sudo cp azure-iot-test-only.root.ca.cert.pem /usr/local/share/azure-iot-test-only.root.ca.cert.pem.crt
# For EFLOW, use /etc/pki/ca-trust/source/anchors/
sudo cp azure-iot-test-only.root.ca.cert.pem /etc/pki/ca-trust/source/anchors/azure-iot-test-only.root.ca.pem.crt

Измените владение и разрешения сертификатов и ключей.

# Give aziotcs ownership to certificates
# Read and write for aziotcs, read-only for others
sudo chown -R aziotcs:aziotcs /var/aziot/certs
sudo find /var/aziot/certs -type f -name "*.*" -exec chmod 644 {} \;

# Give aziotks ownership to private keys
# Read and write for aziotks, no permission for others
sudo chown -R aziotks:aziotks /var/aziot/secrets
sudo find /var/aziot/secrets -type f -name "*.*" -exec chmod 600 {} \;

# Verify permissions of directories and files
sudo ls -Rla /var/aziot

Выходные данные списка с правильным владением и разрешением аналогичны следующим:

azureUser@vm:/var/aziot$ sudo ls -Rla /var/aziot
/var/aziot:
total 16
drwxr-xr-x  4 root    root    4096 Dec 14 00:16 .
drwxr-xr-x 15 root    root    4096 Dec 14 00:15 ..
drwxr-xr-x  2 aziotcs aziotcs 4096 Jan 14 00:31 certs
drwx------  2 aziotks aziotks 4096 Jan 23 17:23 secrets

/var/aziot/certs:
total 20
drwxr-xr-x 2 aziotcs aziotcs 4096 Jan 14 00:31 .
drwxr-xr-x 4 root    root    4096 Dec 14 00:16 ..
-rw-r--r-- 1 aziotcs aziotcs 1984 Jan 14 00:24 azure-iot-test-only.root.ca.cert.pem
-rw-r--r-- 1 aziotcs aziotcs 5887 Jan 14 00:27 iot-edge-device-ca-gateway-full-chain.cert.pem

/var/aziot/secrets:
total 16
drwx------ 2 aziotks aziotks 4096 Jan 23 17:23 .
drwxr-xr-x 4 root    root    4096 Dec 14 00:16 ..
-rw------- 1 aziotks aziotks 3243 Jan 14 00:28 iot-edge-device-ca-gateway.key.pem

Установите сертификат корневого ЦС на родительском устройстве IoT Edge, обновив хранилище сертификатов на устройстве с помощью команды для конкретной платформы.
```
# Update the certificate store

# For Ubuntu or Debian - use update-ca-certificates
sudo update-ca-certificates
# For EFLOW or RHEL - use update-ca-trust
sudo update-ca-trust
```
Дополнительные сведения об использовании update-ca-trust в EFLOW см. в разделе CBL-Mariner SSL CERTIFICATEs management.

Команда сообщает, что в нее добавлен /etc/ssl/certsодин сертификат.

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.

Обновление родительского файла конфигурации

На устройстве уже должен быть установлен IoT Edge. Если нет, выполните действия, чтобы вручную подготовить одно устройство Linux IoT Edge.

Убедитесь, что /etc/aziot/config.toml файл конфигурации существует на родительском устройстве.

Если файл конфигурации не существует на устройстве, используйте следующую команду, чтобы создать ее на основе файла шаблона:
```
sudo cp /etc/aziot/config.toml.edge.template /etc/aziot/config.toml
```
Вы также можете использовать файл шаблона в качестве ссылки для добавления параметров конфигурации в этом разделе.
Откройте файл конфигурации IoT Edge с помощью редактора. Например, используйте nano редактор для открытия /etc/aziot/config.toml файла.
```
sudo nano /etc/aziot/config.toml
```
Найдите параметр имени узла или добавьте его в начало файла конфигурации. Обновите значение, чтобы иметь полное доменное имя (FQDN) или IP-адрес родительского устройства IoT Edge. Например:
```
hostname = "10.0.0.4"
```
Чтобы включить обнаружение шлюза, каждому устройству шлюза IoT Edge (родительскому) необходимо указать параметр имени узла, который будет использовать его дочерние устройства для поиска в локальной сети. Каждому нижнему устройству IoT Edge необходимо указать параметр parent_hostname для идентификации родительского элемента. В иерархическом сценарии, в котором одно устройство IoT Edge является родительским и дочерним, оно требует обоих параметров.

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

Используйте имя узла короче 64 символов — это лимит для общего имени сертификата сервера.

Соблюдайте согласованность с шаблоном имени узла по всей иерархии шлюза. Используйте либо полные доменные имена, либо IP-адреса, но не оба варианта. Полное доменное имя или IP-адрес требуются для подключения подчиненных устройств.

Задайте имя узла перед созданием контейнера edgeHub . Если edgeHub запущен, изменение имени узла в файле конфигурации не вступит в силу до повторного создания контейнера. Дополнительные сведения о том, как проверить применение имени узла, см. в разделе "Проверка родительской конфигурации ".
Найдите параметр сертификата пакета доверия или добавьте его в начало файла конфигурации.

trust_bundle_cert Обновите параметр с помощью URI файла до корневого сертификата ЦС на устройстве. Например:
```
trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"
```
Найдите или добавьте раздел сертификата ЦС Edge в файле конфигурации. Обновите параметры сертификата cert и закрытого ключа pk с помощью путей URI файла для полноцепочки сертификатов и файлов ключей на родительском устройстве IoT Edge. IoT Edge требует, чтобы сертификат и закрытый ключ были в текстовом формате электронной почты ( PEM). Например:
```
[edge_ca]
cert = "file:///var/aziot/certs/iot-edge-device-ca-gateway-full-chain.cert.pem"
pk = "file:///var/aziot/secrets/iot-edge-device-ca-gateway.key.pem"
```
Убедитесь, что устройство IoT Edge использует правильную версию агента IoT Edge при запуске. Найдите раздел агента Edge по умолчанию и задайте значение изображения для IoT Edge версии 1.5. Например:
```
[agent]
name = "edgeAgent"
type = "docker"

[agent.config]
image = "mcr.microsoft.com/azureiotedge-agent:1.5"
```

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

hostname = "10.0.0.4"
trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"

[edge_ca]
cert = "file:///var/aziot/certs/iot-edge-device-ca-gateway-full-chain.cert.pem"
pk = "file:///var/aziot/secrets/iot-edge-device-ca-gateway.key.pem"

Сохраните config.toml и закройте файл конфигурации. Например, если вы используете редактор nano, выберите ctrl+O - Write Out, ВВОД и CTRL+X - Exit.
Если вы ранее использовали другие сертификаты для IoT Edge, удалите файлы в следующих двух каталогах, чтобы убедиться, что будут применяться новые сертификаты:
- /var/lib/aziot/certd/certs
- /var/lib/aziot/keyd/keys
Примените изменения.
```
sudo iotedge config apply
```
Проверьте конфигурацию на наличие ошибок.
```
sudo iotedge check --verbose
```
Примечание.

На недавно подготовленном устройстве может появиться ошибка, связанная с Центром IoT Edge:

× рабочей готовности: каталог хранилища Edge Hub сохраняется в файловой системе узла — ошибка

Не удалось проверить текущее состояние контейнера edgeHub

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

Проверка родительской конфигурации

Имя узла должно быть полным доменным именем или IP-адресом устройства IoT Edge, так как IoT Edge использует это значение в сертификате сервера при подключении подчиненных устройств. Значения должны совпадать или вы получите ошибку несоответствия IP-адреса.

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

Перечислите запущенные контейнеры IoT Edge.

iotedge list

Убедитесь, что запущены контейнеры edgeAgent и edgeHub . Выходные данные команды должны быть похожи на следующий пример.

NAME                        STATUS           DESCRIPTION      CONFIG
SimulatedTemperatureSensor  running          Up 5 seconds     mcr.microsoft.com/azureiotedge-simulated-temperature-sensor:1.0
edgeAgent                   running          Up 17 seconds    mcr.microsoft.com/azureiotedge-agent:1.5
edgeHub                     running          Up 6 seconds     mcr.microsoft.com/azureiotedge-hub:1.5

Проверьте контейнер edgeHub.
```
sudo docker inspect edgeHub
```
В выходных данных найдите параметр EdgeDeviceHostName в разделе Env .
```
"EdgeDeviceHostName=10.0.0.4"
```
Убедитесь, что значение параметра EdgeDeviceHostName соответствует параметру config.toml имени узла. Если он не соответствует, контейнер edgeHub выполнялся при изменении и применении конфигурации. Чтобы обновить EdgeDeviceHostName, удалите контейнер edgeAgent .
```
sudo docker rm -f edgeAgent
```
Контейнеры edgeAgent и edgeHub создаются и запускаются в течение нескольких минут. После запуска контейнера EdgeHub проверьте контейнер и убедитесь , что параметр EdgeDeviceHostName соответствует файлу конфигурации.

Настройка нижестоящего устройства

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

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

Проверьте сертификаты в соответствии с требованиями к формату.
Передайте сертификат корневого ЦС, дочерний сертификат ЦС edge и дочерний закрытый ключ на нижнее устройство.

### Copy device certificate ###

# If the device certificate and keys directories don't exist, create, set ownership, and set permissions
sudo mkdir -p /var/aziot/certs
sudo chown aziotcs:aziotcs /var/aziot/certs
sudo chmod 755 /var/aziot/certs

sudo mkdir -p /var/aziot/secrets
sudo chown aziotks:aziotks /var/aziot/secrets
sudo chmod 700 /var/aziot/secrets

# Copy device full-chain certificate and private key into the correct directory
sudo cp iot-device-downstream-full-chain.cert.pem /var/aziot/certs
sudo cp iot-device-downstream.key.pem /var/aziot/secrets

### Root certificate ###

# Copy root certificate into the /certs directory
sudo cp azure-iot-test-only.root.ca.cert.pem /var/aziot/certs

# Copy root certificate into the CA certificate directory and add .crt extension.
# The root certificate must be in the CA certificate directory to install it in the certificate store.
# Use the appropriate copy command for your device OS or if using EFLOW.

# For Ubuntu and Debian, use /usr/local/share/ca-certificates/
sudo cp azure-iot-test-only.root.ca.cert.pem /usr/local/share/azure-iot-test-only.root.ca.cert.pem.crt
# For EFLOW, use /etc/pki/ca-trust/source/anchors/
sudo cp azure-iot-test-only.root.ca.cert.pem /etc/pki/ca-trust/source/anchors/azure-iot-test-only.root.ca.pem.crt

Измените владение и разрешения сертификатов и ключей.

# Give aziotcs ownership to certificates
# Read and write for aziotcs, read-only for others
sudo chown -R aziotcs:aziotcs /var/aziot/certs
sudo find /var/aziot/certs -type f -name "*.*" -exec chmod 644 {} \;

# Give aziotks ownership to private keys
# Read and write for aziotks, no permission for others
sudo chown -R aziotks:aziotks /var/aziot/secrets
sudo find /var/aziot/secrets -type f -name "*.*" -exec chmod 600 {} \;

Установите корневой сертификат ЦС на нижнем устройстве IoT Edge, обновив хранилище сертификатов на устройстве с помощью команды для конкретной платформы.
```
# Update the certificate store

# For Ubuntu or Debian - use update-ca-certificates
sudo update-ca-certificates
# For EFLOW or RHEL - use update-ca-trust
sudo update-ca-trust
```
Дополнительные сведения об использовании update-ca-trust в EFLOW см. в разделе CBL-Mariner SSL CERTIFICATEs management.

Команда сообщает, что в нее добавлен /etc/ssl/certsодин сертификат.

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.

Обновление нижестоящего файла конфигурации

Убедитесь, что /etc/aziot/config.toml файл конфигурации существует на нижнем устройстве.

Если файл конфигурации не существует на устройстве, используйте следующую команду, чтобы создать ее на основе файла шаблона:
```
sudo cp /etc/aziot/config.toml.edge.template /etc/aziot/config.toml
```
Вы также можете использовать файл шаблона в качестве ссылки для добавления параметров конфигурации в этом разделе.
Откройте файл конфигурации IoT Edge с помощью редактора. Например, используйте nano редактор для открытия /etc/aziot/config.toml файла.
```
sudo nano /etc/aziot/config.toml
```
Найдите параметр parent_hostname или добавьте его в начало файла конфигурации Каждый подчиненный устройство IoT Edge, чтобы указать параметр parent_hostname для идентификации родительского элемента. parent_hostname Обновите параметр, чтобы быть полным доменным именем или IP-адресом родительского устройства, совпадая с именем узла в файле конфигурации родительского устройства. Например:
```
parent_hostname = "10.0.0.4"
```
Найдите параметр сертификата пакета доверия или добавьте его в начало файла конфигурации.

trust_bundle_cert Обновите параметр с помощью URI файла до корневого сертификата ЦС на устройстве. Например:
```
trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"
```
Найдите или добавьте раздел сертификата ЦС Edge в файл конфигурации. Обновите параметры сертификата cert и закрытого ключа pk с помощью путей URI файла для полного цепочки сертификатов и файлов ключей на нижнем устройстве IoT Edge. IoT Edge требует, чтобы сертификат и закрытый ключ были в текстовом формате электронной почты ( PEM). Например:
```
[edge_ca]
cert = "file:///var/aziot/certs/iot-device-downstream-full-chain.cert.pem"
pk = "file:///var/aziot/secrets/iot-device-downstream.key.pem"
```
Убедитесь, что устройство IoT Edge использует правильную версию агента IoT Edge при запуске. Найдите раздел агента Edge по умолчанию и задайте значение изображения для IoT Edge версии 1.5. Например:
```
[agent]
name = "edgeAgent"
type = "docker"

[agent.config]
image: "mcr.microsoft.com/azureiotedge-agent:1.5"
```

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

parent_hostname = "10.0.0.4"
trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"

[edge_ca]
cert = "file:///var/aziot/certs/iot-device-downstream-full-chain.cert.pem"
pk = "file:///var/aziot/secrets/iot-device-downstream.key.pem"

Сохраните config.toml и закройте файл конфигурации. Например, если вы используете редактор nano, выберите ctrl+O - Write Out, ВВОД и CTRL+X - Exit.
Если вы ранее использовали другие сертификаты для IoT Edge, удалите файлы в следующих двух каталогах, чтобы убедиться, что будут применяться новые сертификаты:
- /var/lib/aziot/certd/certs
- /var/lib/aziot/keyd/keys
Примените изменения.
```
sudo iotedge config apply
```
Проверьте конфигурацию на наличие ошибок.
```
sudo iotedge check --verbose
```
Совет

Средство проверки IoT Edge использует контейнер для выполнения некоторых диагностических проверок. Если вы хотите использовать это средство на подчиненных устройствах IoT Edge, убедитесь, что у них есть доступ к mcr.microsoft.com/azureiotedge-diagnostics:latest или в частном реестре контейнеров есть образ контейнера.

Примечание.

На недавно подготовленном устройстве может появиться ошибка, связанная с Центром IoT Edge:

× рабочей готовности: каталог хранилища Edge Hub сохраняется в файловой системе узла — ошибка

Не удалось проверить текущее состояние контейнера edgeHub

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

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

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

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

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

Модуль прокси API требуется для любого шлюза IoT Edge, под которым расположено другое устройство IoT Edge. Это означает, что он должен находиться на каждом уровне иерархии шлюзов, за исключением нижнего. Этот модуль использует обратный прокси-сервер nginx для маршрутизации данных HTTP через сетевые уровни с помощью одного порта. Она настраивается с помощью двойника модуля и переменных среды, поэтому ее можно настроить в соответствии с требованиями к сценарию шлюза.
Модуль реестра Docker можно развернуть на шлюзе IoT Edge на верхнем уровне иерархии шлюзов. Этот модуль отвечает за извлечение и кэширование образов контейнеров от имени всех устройств IoT Edge на более низких уровнях. Альтернативой развертыванию этого модуля на верхнем уровне является использование локального реестра или ручная загрузка образов контейнеров на устройства и установка для политики извлечения модуля значения never.
Хранилище BLOB-объектов Azure на IoT Edge можно развернуть на шлюзе IoT Edge на верхнем уровне иерархии шлюзов. Этот модуль отвечает за отправку больших двоичных объектов от имени всех устройств IoT Edge на более низких уровнях. Возможность отправки BLOB-объектов также позволяет использовать полезные функции устранения неполадок для устройств IoT Edge на более низких уровнях, например передача журнала модуля и отправка пакета поддержки.

Сетевая конфигурация

Для каждого устройства шлюза на верхнем уровне операторы сети должны:

Предоставлять статический IP-адрес или полное доменное имя (FQDN).
Авторизовать исходящие коммуникации с этого IP-адреса на имя узла центра Интернета вещей Azure через порты 443 (HTTPS) и 5671 (AMQP).
Авторизовать исходящие коммуникации с этого IP-адреса на имя узла Реестра контейнеров Azure через порт 443 (HTTPS).

Модуль прокси API может одновременно управлять подключениями только к одному реестру контейнеров. Мы рекомендуем использовать все образы контейнеров, включая общедоступные образы, предоставляемые Microsoft Container Registry (mcr.microsoft.com), которые хранятся в частном реестре контейнеров.

Для каждого устройства шлюза на нижнем уровне операторы сети должны:

Предоставлять статический IP-адрес.
Авторизовать исходящие подключения с этого IP-адреса к IP-адресу родительского шлюза через порты 443 (HTTPS) и 5671 (AMQP).

Развертывание модулей на устройствах верхнего уровня

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

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

Портал
Azure CLI

Найдите нужный Центр Интернета вещей на портале Azure.
Выберите устройства в меню управления устройствами .
Выберите устройство верхнего уровня IoT Edge, которое вы настраиваете из списка.
Щелкните Set modules (Настроить модули).
В разделе модулей IoT Edge выберите "Добавить", а затем выберите "Модуль IoT Edge".

Обновите следующие параметры модуля:

Параметр	Значение
Имя модуля Интернета вещей	`IoTEdgeAPIProxy`
URI образа	`mcr.microsoft.com/azureiotedge-api-proxy:latest`
Политика перезапуска	всегда
Требуемое состояние	выполняется

Если вы хотите использовать другую версию или архитектуру прокси-модуля API, найдите доступные образы в Реестр артефактов Microsoft.

На вкладке "Переменные среды" добавьте переменную типа NGINX_DEFAULT_PORT Text со значением443.
На вкладке Параметры создания контейнера обновите привязки портов, чтобы они ссылались на порт 443.
```
{
  "HostConfig": {
    "PortBindings": {
      "443/tcp": [
        {
          "HostPort": "443"
        }
      ]
    }
  }
}
```

Эти изменения настраивают модуль прокси API для прослушивания порта 443. Чтобы предотвратить конфликты привязки портов, необходимо настроить модуль edgeHub так, чтобы он не прослушивал порт 443. Вместо этого модуль прокси API будет маршрутизировать любой трафик edgeHub через порт 443.

Нажмите кнопку Добавить, чтобы добавить модуль в развертывание.
Выберите параметры среды выполнения и найдите параметры создания контейнера модуля EdgeHub. Удалите привязку портов для порта 443, оставив привязки для портов 5671 и 8883.
```
{
  "HostConfig": {
    "PortBindings": {
      "5671/tcp": [
        {
          "HostPort": "5671"
        }
      ],
      "8883/tcp": [
        {
          "HostPort": "8883"
        }
      ]
    }
  }
}
```
Нажмите кнопку "Применить" , чтобы сохранить изменения в параметрах среды выполнения.

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

В разделе модулей IoT Edge выберите "Добавить", а затем выберите "Модуль IoT Edge".

Параметр	Значение
Имя модуля Интернета вещей	`registry`
URI образа	`registry:latest`
Политика перезапуска	`always`
Требуемое состояние	`running`

На вкладке переменных среды добавьте следующие переменные:

Имя.	Тип	значение
`REGISTRY_PROXY_REMOTEURL`	Текст	URL-адрес реестра контейнеров, с которым необходимо сопоставить этот модуль реестра. Например, `https://myregistry.azurecr`. Модуль реестра может сопоставляться только с одним реестром контейнеров, поэтому мы рекомендуем использовать все образы контейнеров в одном частном реестре контейнеров.
`REGISTRY_PROXY_USERNAME`	Текст	Имя пользователя для проверки подлинности в реестре контейнеров.
`REGISTRY_PROXY_PASSWORD`	Текст	Пароль для проверки подлинности в реестре контейнеров.

На вкладке "Параметры создания контейнера" обновите привязки портов для ссылки на порт 5000.

{
  "HostConfig": {
    "PortBindings": {
      "5000/tcp": [
        {
          "HostPort": "5000"
        }
      ]
    }
  }
}

Нажмите кнопку Добавить, чтобы добавить модуль в развертывание.
Нажмите Далее: маршруты, чтобы перейти к следующему шагу.
Чтобы разрешить отправку сообщений с устройства в облако, то есть с подчиненных устройств в центр Интернета вещей, включите маршрут, передающий все сообщения в центр Интернета вещей. Например:
1. Имя: Route
2. Значение: FROM /messages/* INTO $upstream
Нажмите Проверка и создание, чтобы перейти к последнему шагу.
Нажмите Создать для развертывания на устройстве.

В Azure Cloud Shell создайте JSON-файл развертывания. Например:

{
    "modulesContent": {
        "$edgeAgent": {
            "properties.desired": {
                "modules": {
                    "dockerContainerRegistry": {
                        "settings": {
                            "image": "registry:latest",
                            "createOptions": "{\"HostConfig\":{\"PortBindings\":{\"5000/tcp\":[{\"HostPort\":\"5000\"}]}}}"
                        },
                        "type": "docker",
                        "version": "1.0",
                        "env": {
                            "REGISTRY_PROXY_REMOTEURL": {
                                "value": "The URL for the container registry you want this registry module to map to. For example, https://myregistry.azurecr"
                            },
                            "REGISTRY_PROXY_USERNAME": {
                                "value": "Username to authenticate to the container registry."
                            },
                            "REGISTRY_PROXY_PASSWORD": {
                                "value": "Password to authenticate to the container registry."
                            }
                        },
                        "status": "running",
                        "restartPolicy": "always"
                    },
                    "IoTEdgeAPIProxy": {
                        "settings": {
                            "image": "mcr.microsoft.com/azureiotedge-api-proxy:1.1",
                            "createOptions": "{\"HostConfig\": {\"PortBindings\": {\"443/tcp\": [{\"HostPort\":\"443\"}]}}}"
                        },
                        "type": "docker",
                        "env": {
                            "NGINX_DEFAULT_PORT": {
                                "value": "443"
                            },
                            "DOCKER_REQUEST_ROUTE_ADDRESS": {
                                "value": "registry:5000"
                            }
                        },
                        "status": "running",
                        "restartPolicy": "always",
                        "version": "1.0"
                    }
                },
                "runtime": {
                    "settings": {
                        "minDockerVersion": "v1.25"
                    },
                    "type": "docker"
                },
                "schemaVersion": "1.1",
                "systemModules": {
                    "edgeAgent": {
                        "settings": {
                            "image": "mcr.microsoft.com/azureiotedge-agent:1.5",
                            "createOptions": "{}"
                        },
                        "type": "docker"
                    },
                    "edgeHub": {
                        "settings": {
                            "image": "mcr.microsoft.com/azureiotedge-hub:1.5",
                            "createOptions": "{\"HostConfig\":{\"PortBindings\":{\"5671/tcp\":[{\"HostPort\":\"5671\"}],\"8883/tcp\":[{\"HostPort\":\"8883\"}]}}}"
                        },
                        "type": "docker",
                        "env": {},
                        "status": "running",
                        "restartPolicy": "always"
                    }
                }
            }
        },
        "$edgeHub": {
            "properties.desired": {
                "routes": {
                    "route": "FROM /messages/* INTO $upstream"
                },
                "schemaVersion": "1.1",
                "storeAndForwardConfiguration": {
                    "timeToLiveSecs": 7200
                }
            }
        }
    }
}

Этот файл развертывания настраивает модуль прокси-сервера API для прослушивания порта 443. Чтобы предотвратить конфликты привязки портов, необходимо настроить модуль edgeHub так, чтобы он не прослушивал порт 443. Вместо этого модуль прокси API будет маршрутизировать любой трафик edgeHub через порт 443.

Введите следующую команду, чтобы создать развертывание на устройстве IoT Edge:
```
az iot edge set-modules --device-id <device_id> --hub-name <iot_hub_name> --content ./<deployment_file_name>.json
```

Развертывание модулей на устройствах нижнего уровня

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

Извлечение образа контейнера для маршрутизации

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

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

Например, вместо вызова mcr.microsoft.com/azureiotedge-api-proxy:1.1 устройства более низкого уровня должны вызывать $upstream:443/azureiotedge-api-proxy:1.1.

Параметр $upstream указывает на родителя устройства более низкого уровня, поэтому запрос будет проходить по всем уровням до тех пор, пока не достигнет верхнего уровня, у которого есть среда прокси, перенаправляющая запросы контейнера в модуль реестра. Порт :443 в этом примере следует заменить на порт, прослушиваемый модулем прокси API на родительском устройстве.

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

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

Начальная загрузка агента IoT Edge

Агент IoT Edge — это первый компонент среды выполнения, который можно запустить на любом устройстве IoT Edge. Необходимо убедиться, что все подчиненные устройства IoT Edge могут получить доступ к образу модуля edgeAgent при запуске, чтобы затем получить доступ к развертываниям и запустить остальные образы модулей.

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

Если устройство шлюза верхнего уровня настроено для обработки запросов образа контейнера, замените mcr.microsoft.com на имя родительского узла и порт прослушивания прокси API. В манифесте развертывания можно использовать $upstream в качестве ярлыка, но для этого необходимо, чтобы модуль edgeHub обрабатывал маршрутизацию и не запускался на этом этапе. Например:

[agent]
name = "edgeAgent"
type = "docker"

[agent.config]
image: "{Parent FQDN or IP}:443/azureiotedge-agent:1.5"

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

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

Прокси API необходим для маршрутизации всех взаимодействий между облаком и любыми подчиненными устройствами IoT Edge. Для устройства IoT Edge на нижнем уровне иерархии без подчиненных устройств IoT Edge этот модуль не требуется.

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

Найдите нужный Центр Интернета вещей на портале Azure.
Выберите устройства в меню управления устройствами .
Выберите устройство ioT Edge нижнего уровня, которое вы настраиваете в списке.
Щелкните Set modules (Настроить модули).
В разделе модулей IoT Edge выберите "Добавить", а затем выберите "Модуль IoT Edge".

Обновите следующие параметры модуля:

Параметр	Значение
Имя модуля Интернета вещей	`IoTEdgeAPIProxy`
URI образа	`mcr.microsoft.com/azureiotedge-api-proxy:latest`
Политика перезапуска	`always`
Требуемое состояние	`running`

На вкладке "Переменные среды" добавьте переменную типа NGINX_DEFAULT_PORT Text со значением443.
На вкладке Параметры создания контейнера обновите привязки портов, чтобы они ссылались на порт 443.
```
{
  "HostConfig": {
    "PortBindings": {
      "443/tcp": [
        {
          "HostPort": "443"
        }
      ]
    }
  }
}
```

Выберите Параметры среды выполнения.
Обновите параметры модуля edgeHub:
1. В поле Образ замените mcr.microsoft.com на $upstream:443.
2. В поле Создание параметров удалите привязку для порта 443, оставив привязки для портов 5671 и 8883.
```
{
  "HostConfig": {
    "PortBindings": {
      "5671/tcp": [
        {
          "HostPort": "5671"
        }
      ],
      "8883/tcp": [
        {
          "HostPort": "8883"
        }
      ]
    }
  }
}
```
Обновите параметры модуля edgeAgent:
1. В поле Образ замените mcr.microsoft.com на $upstream:443.
Нажмите кнопку "Применить" , чтобы сохранить изменения в параметрах среды выполнения.
Нажмите Далее: маршруты, чтобы перейти к следующему шагу.
Чтобы разрешить отправку сообщений с устройства в облако, то есть с подчиненных устройств в центр Интернета вещей, включите маршрут, передающий все сообщения в $upstream. Параметр вышестоящего устройства указывает на родительское устройство в случае более низкоуровневых устройств. Например:
1. Имя: Route
2. Значение: FROM /messages/* INTO $upstream
Нажмите Проверка и создание, чтобы перейти к последнему шагу.
Нажмите Создать для развертывания на устройстве.

Проверка подключения от дочернего к родительскому

Проверьте подключение TLS/SSL от дочернего объекта к родителю, выполнив следующую openssl команду на нижнем устройстве. Замените <parent hostname> полное доменное имя или IP-адрес родительского объекта.
```
openssl s_client -connect <parent hostname>:8883 </dev/null 2>&1 >/dev/null
```
Команда должна подтвердить успешную проверку родительской цепочки сертификатов, аналогичную следующему примеру:
```
azureUser@child-vm:~$ openssl s_client -connect <parent hostname>:8883 </dev/null 2>&1 >/dev/null
Can't use SSL_get_servername
depth=3 CN = Azure_IoT_Hub_CA_Cert_Test_Only
verify return:1
depth=2 CN = Azure_IoT_Hub_Intermediate_Cert_Test_Only
verify return:1
depth=1 CN = gateway.ca
verify return:1
depth=0 CN = <parent hostname>
verify return:1
DONE
```
Сообщение "Не удается использовать SSL_get_servername", можно игнорировать.

Значение depth=0 CN = должно соответствовать параметру имени узла, указанному в файле конфигурации родительского config.toml элемента.

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

Не используя полный сертификат в разделе шлюза [edge_ca] , возникают ошибки проверки сертификата с нижнего устройства. Например, приведенная openssl s_client ... выше команда будет производить:
```
Can't use SSL_get_servername
depth=1 CN = gateway.ca
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = <parent hostname>
verify return:1
DONE
```
Эта же проблема возникает для устройств с поддержкой TLS, которые подключаются к нижнему устройству IoT Edge, если сертификат устройства полной цепочки не используется и настроен на нижнем устройстве.

Интеграция Microsoft Defender для Интернета вещей с шлюзом IoT Edge

Подчиненные устройства можно использовать для интеграции микроагента Microsoft Defender для Интернета вещей с шлюзом IoT Edge с помощью прокси-сервера нижестоящего устройства.

Дополнительные сведения о микроагенте Defender для Интернета вещей.

Чтобы интегрировать Microsoft Defender для Интернета вещей с IoT Edge с помощью прокси-сервера нижестоящего устройства:

Войдите на портал Azure.
Перейдите к устройствам управления>Центр Интернета вещей>Your Hub> Device
Выберите устройство.
DefenderIotMicroAgent Выберите двойник модуля, созданный из этих инструкций.
Нажмите кнопку , чтобы скопировать строку подключения (первичный ключ).
Вставьте строка подключения в текстовое приложение редактирования и добавьте gatewayHostName в строку. GatewayHostName — это полное доменное имя или IP-адрес родительского устройства. Например, HostName=nested11.azure-devices.net;DeviceId=downstream1;ModuleId=module1;SharedAccessKey=xxx;GatewayHostName=10.16.7.4.
Откройте терминал на нижнем устройстве.
Используйте следующую команду, чтобы поместить строка подключения в кодировке utf-8 в каталог агента Defender для облака в файл connection_string.txt в следующем пути: /etc/defender_iot_micro_agent/connection_string.txt
```
sudo bash -c 'echo "<connection string>" > /etc/defender_iot_micro_agent/connection_string.txt'
```
Теперь файл connection_string.txt должен находиться по такому пути: /etc/defender_iot_micro_agent/connection_string.txt.
Перезапустите службу с помощью следующей команды:
```
sudo systemctl restart defender-iot-micro-agent.service 
```
Вернитесь к устройству.
Включите подключение к Центр Интернета вещей и выберите значок шестеренки.
Выберите родительское устройство из отображаемого списка.
Убедитесь, что порт 8883 (MQTT) между нижестоящим устройством и устройством IoT Edge открыт.