Połącz urządzenia z usługą Azure IoT Edge w celu utworzenia hierarchii

Artykuł
08/07/2024

Dotyczy: IoT Edge 1.5 IoT Edge 1.4

Ważne

Obsługiwane są wersje usługi IoT Edge 1.5 LTS i IoT Edge 1.4 LTS. Usługa IoT Edge 1.4 LTS kończy się 12 listopada 2024 r. Jeśli korzystasz z wcześniejszej wersji, zobacz aktualizację Azure IoT Edge.

Ten artykuł zawiera kroki nawiązywania zaufanego połączenia między bramą usługi IoT Edge i podrzędnym urządzeniem usługi IoT Edge. Ta konfiguracja jest również nazywana zagnieżdżonym krawędzią.

W scenariuszu bramy urządzenie usługi IoT Edge może być zarówno bramą, jak i urządzeniem podrzędnym. W celu utworzenia hierarchii urządzeń można utworzyć wiele bram usługi IoT Edge. Urządzenia podrzędne (podrzędne) mogą uwierzytelniać i wysyłać lub odbierać komunikaty za pośrednictwem urządzenia bramy (nadrzędnego).

Istnieją dwie różne konfiguracje urządzeń usługi IoT Edge w hierarchii bramy, a w tym artykule opisano oba te konfiguracje. Pierwszy to urządzenie usługi IoT Edge w górnej warstwie . Gdy wiele urządzeń usługi IoT Edge łączy się ze sobą, każde urządzenie, które nie ma urządzenia nadrzędnego, ale łączy się bezpośrednio z usługą IoT Hub, jest uważane za w górnej warstwie. To urządzenie jest odpowiedzialne za obsługę żądań ze wszystkich urządzeń poniżej. Druga konfiguracja dotyczy dowolnego urządzenia usługi IoT Edge w niższej warstwie hierarchii. Te urządzenia mogą być bramą dla innych podrzędnych urządzeń IoT i IoT Edge, ale także do kierowania komunikacji za pośrednictwem własnych urządzeń nadrzędnych.

Niektóre architektury sieci wymagają, aby tylko najważniejsze urządzenie usługi IoT Edge w hierarchii mogło łączyć się z chmurą. W tej konfiguracji wszystkie urządzenia usługi IoT Edge w niższych warstwach hierarchii mogą komunikować się tylko z urządzeniem bramy (nadrzędnym) i wszystkimi urządzeniami podrzędnymi (podrzędnymi).

Wszystkie kroki opisane w tym artykule opierają się na temacie Konfigurowanie urządzenia usługi IoT Edge w celu działania jako przezroczystej bramy, która konfiguruje urządzenie usługi IoT Edge jako bramę dla podrzędnych urządzeń IoT. Te same podstawowe kroki dotyczą wszystkich scenariuszy bramy:

Uwierzytelnianie: utwórz tożsamości usługi IoT Hub dla wszystkich urządzeń w hierarchii bramy.
Autoryzacja: skonfiguruj relację nadrzędną/podrzędną w usłudze IoT Hub, aby autoryzować urządzenia podrzędne do łączenia się z urządzeniem nadrzędnym, tak jakby łączyły się z usługą IoT Hub.
Odnajdywanie bramy: upewnij się, że urządzenie podrzędne może znaleźć swoje urządzenie nadrzędne w sieci lokalnej.
Bezpieczne połączenie: ustanów bezpieczne połączenie z zaufanymi certyfikatami, które są częścią tego samego łańcucha.

Wymagania wstępne

Bezpłatne lub standardowe centrum IoT.
Co najmniej dwa urządzenia usługi IoT Edge, które mają być urządzeniem warstwy górnej i co najmniej jednym urządzeniem warstwy niższej. Jeśli nie masz dostępnych urządzeń usługi IoT Edge, możesz uruchomić usługę Azure IoT Edge na maszynach wirtualnych z systemem Ubuntu.
Jeśli używasz interfejsu wiersza polecenia platformy Azure do tworzenia urządzeń i zarządzania nimi, zainstaluj rozszerzenie Azure IoT.

Napiwek

Ten artykuł zawiera szczegółowe kroki i opcje ułatwiające utworzenie odpowiedniej hierarchii bramy dla danego scenariusza. Aby zapoznać się z samouczkiem z przewodnikiem, zobacz Tworzenie hierarchii urządzeń usługi IoT Edge przy użyciu bram.

Tworzenie hierarchii bramy

Hierarchia bramy usługi IoT Edge jest tworzona przez zdefiniowanie relacji nadrzędnych/podrzędnych dla urządzeń usługi IoT Edge w tym scenariuszu. Urządzenie nadrzędne można ustawić podczas tworzenia nowej tożsamości urządzenia lub zarządzać elementami nadrzędnymi i elementami podrzędnym istniejącej tożsamości urządzenia.

Krok konfigurowania relacji nadrzędny/podrzędny autoryzuje urządzenia podrzędne do łączenia się z urządzeniem nadrzędnym, tak jakby łączyły się z usługą IoT Hub.

Tylko urządzenia usługi IoT Edge mogą być urządzeniami nadrzędnymi, ale urządzenia usługi IoT Edge i urządzenia IoT mogą być urządzeniami podrzędnymi. Rodzic może mieć wiele dzieci, ale dziecko może mieć tylko jednego rodzica. Hierarchia bramy jest tworzona przez łączenie zestawów nadrzędnych/podrzędnych w taki sposób, aby element podrzędny jednego urządzenia był elementem nadrzędnym innego.

Domyślnie element nadrzędny może mieć maksymalnie 100 elementów podrzędnych. Ten limit można zmienić, ustawiając zmienną środowiskową MaxConnectedClients w module edgeHub urządzenia nadrzędnego.

Portal
Interfejs wiersza polecenia platformy Azure

W witrynie Azure Portal można zarządzać relacją nadrzędną/podrzędną podczas tworzenia nowych tożsamości urządzeń lub edytując istniejące urządzenia.

Podczas tworzenia nowego urządzenia usługi IoT Edge możesz wybrać urządzenia nadrzędne i podrzędne z listy istniejących urządzeń usługi IoT Edge w tym centrum.

W witrynie Azure Portal przejdź do centrum IoT Hub.
Wybierz pozycję Urządzenia w menu Zarządzanie urządzeniami .
Wybierz pozycję Dodaj urządzenie , a następnie zaznacz pole wyboru Urządzenie usługi IoT Edge.
Oprócz ustawiania identyfikatora urządzenia i ustawień uwierzytelniania można ustawić urządzenie nadrzędne lub wybrać urządzenia podrzędne.
Wybierz urządzenie lub urządzenia, które mają być urządzeniem nadrzędnym lub podrzędnym.

Można również tworzyć relacje nadrzędne/podrzędne dla istniejących urządzeń lub zarządzać nimi.

W witrynie Azure Portal przejdź do centrum IoT Hub.
Wybierz pozycję Urządzenia w menu Zarządzanie urządzeniami .
Wybierz urządzenie usługi IoT Edge, którym chcesz zarządzać z listy.
Wybierz ikonę Ustaw koło zębate urządzenia nadrzędnego lub Zarządzaj urządzeniami podrzędnym.
Dodaj lub usuń wszystkie urządzenia nadrzędne lub podrzędne.

Rozszerzenie azure-iot dla interfejsu wiersza polecenia platformy Azure udostępnia polecenia do zarządzania zasobami IoT. Relację nadrzędną/podrzędną urządzeń usługi IoT i IoT Edge można zarządzać podczas tworzenia nowych tożsamości urządzeń lub edytowania istniejących urządzeń.

Zestaw poleceń az iot hub device-identity set umożliwia zarządzanie relacjami nadrzędnymi/podrzędnymi dla danego urządzenia.

Polecenie create zawiera parametry dodawania urządzeń podrzędnych i ustawiania urządzenia nadrzędnego podczas tworzenia urządzenia.

Dodatkowe polecenia tożsamości urządzenia, w tym add-children,list-children i i remove-children get-parent set-parent, umożliwiają zarządzanie relacjami nadrzędny/podrzędnymi dla istniejących urządzeń.

Uwaga

Jeśli chcesz programowo ustanowić relacje nadrzędny-podrzędny, możesz użyć języka C#, Języka Java lub Node.js zestawu SDK usługi IoT Hub.

Oto przykład przypisywania urządzeń podrzędnych przy użyciu zestawu SDK języka C#. RegistryManager_AddAndRemoveDeviceWithScope() Zadanie pokazuje, jak programowo utworzyć hierarchię trójwarstwową. Urządzenie usługi IoT Edge znajduje się w warstwie 1 jako nadrzędne. Inne urządzenie usługi IoT Edge znajduje się w warstwie 2, służąc zarówno jako element podrzędny, jak i nadrzędny. Na koniec urządzenie IoT znajduje się w warstwie trzeciej jako urządzenie podrzędne najniższej warstwy.

Generowanie certyfikatów

Spójny łańcuch certyfikatów musi być zainstalowany na różnych urządzeniach w tej samej hierarchii bramy, aby ustanowić bezpieczną komunikację między sobą. Każde urządzenie w hierarchii, niezależnie od tego, czy urządzenie usługi IoT Edge, czy urządzenie podrzędne IoT, wymaga kopii tego samego certyfikatu głównego urzędu certyfikacji. Każde urządzenie usługi IoT Edge w hierarchii używa następnie tego certyfikatu głównego urzędu certyfikacji jako głównego certyfikatu urzędu certyfikacji usługi Edge.

W przypadku tej konfiguracji każde podrzędne urządzenie usługi IoT Edge może zweryfikować tożsamość elementu nadrzędnego, sprawdzając, czy na urządzeniu brzegowym , z którymi się łączą, ma certyfikat serwera podpisany przez udostępniony certyfikat głównego urzędu certyfikacji.

Ilustracja łańcucha certyfikatów wystawionego przez główny urząd certyfikacji na bramie i urządzeniu podrzędnym

Aby uzyskać więcej informacji na temat wymagań dotyczących certyfikatów usługi IoT Edge, zobacz Omówienie sposobu korzystania z certyfikatów usługi Azure IoT Edge.

Utwórz lub zażądaj następujących certyfikatów:
- Certyfikat głównego urzędu certyfikacji, który jest najbardziej udostępnionym certyfikatem dla wszystkich urządzeń w danej hierarchii bramy. Ten certyfikat jest instalowany na wszystkich urządzeniach.
- Wszystkie certyfikaty pośrednie, które mają zostać uwzględnione w łańcuchu certyfikatów głównych.
- Certyfikat urzędu certyfikacji usługi Edge i jego klucz prywatny wygenerowany przez certyfikaty główne i pośrednie. Potrzebujesz jednego unikatowego certyfikatu urzędu certyfikacji usługi Edge dla każdego urządzenia usługi IoT Edge w hierarchii bramy.
Możesz użyć urzędu certyfikacji z podpisem własnym lub kupić go od zaufanego komercyjnego urzędu certyfikacji, takiego jak Baltimore, Verisign, Digicert lub GlobalSign.
Jeśli nie masz własnych certyfikatów do użycia do testowania, utwórz jeden zestaw certyfikatów głównych i pośrednich, a następnie utwórz certyfikaty urzędu certyfikacji edge dla każdego urządzenia. W tym artykule użyjemy certyfikatów testowych generowanych przy użyciu certyfikatów testowego urzędu certyfikacji na potrzeby przykładów i samouczków. Na przykład następujące polecenia tworzą certyfikat głównego urzędu certyfikacji, certyfikat urządzenia nadrzędnego i certyfikat urządzenia podrzędnego.
```
# !!! 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"
```
Ostrzeżenie

Nie używaj certyfikatów utworzonych przez skrypty testowe dla środowiska produkcyjnego. Zawierają one zakodowane hasła i wygasają domyślnie po upływie 30 dni. Certyfikaty testowego urzędu certyfikacji są udostępniane w celach demonstracyjnych, aby ułatwić zrozumienie certyfikatów urzędu certyfikacji. Skorzystaj z własnych najlepszych rozwiązań w zakresie zabezpieczeń na potrzeby tworzenia certyfikatów i zarządzania okresem istnienia w środowisku produkcyjnym.

Aby uzyskać więcej informacji na temat tworzenia certyfikatów testowych, zobacz Tworzenie certyfikatów demonstracyjnych w celu testowania funkcji urządzeń usługi IoT Edge.
Należy przenieść certyfikaty i klucze na każde urządzenie. Możesz użyć dysku USB, usługi takiej jak Azure Key Vault lub funkcji takiej jak Secure file copy. Wybierz jedną z tych metod, która najlepiej pasuje do twojego scenariusza. Skopiuj pliki do preferowanego katalogu dla certyfikatów i kluczy. Służy /var/aziot/certs do certyfikatów i /var/aziot/secrets kluczy.

Aby uzyskać więcej informacji na temat instalowania certyfikatów na urządzeniu, zobacz Zarządzanie certyfikatami na urządzeniu usługi IoT Edge.

Konfigurowanie urządzenia nadrzędnego

Aby skonfigurować urządzenie nadrzędne, otwórz lokalną lub zdalną powłokę poleceń.

Aby włączyć bezpieczne połączenia, każde urządzenie nadrzędne usługi IoT Edge w scenariuszu bramy musi być skonfigurowane przy użyciu unikatowego certyfikatu urzędu certyfikacji usługi Edge i kopii certyfikatu głównego urzędu certyfikacji współużytkowanego przez wszystkie urządzenia w hierarchii bramy.

Sprawdź, czy certyfikaty spełniają wymagania dotyczące formatu.
Przenieś certyfikat głównego urzędu certyfikacji, nadrzędny certyfikat urzędu certyfikacji usługi Edge i nadrzędny klucz prywatny do urządzenia nadrzędnego.

Skopiuj certyfikaty i klucze do odpowiednich katalogów. Preferowanymi katalogami certyfikatów urządzeń są /var/aziot/certs certyfikaty i /var/aziot/secrets klucze.

### 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

Zmień własność i uprawnienia certyfikatów i kluczy.

# 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

Dane wyjściowe listy z poprawną własnością i uprawnieniami są podobne do następujących:

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

Zainstaluj certyfikat głównego urzędu certyfikacji na nadrzędnym urządzeniu usługi IoT Edge, aktualizując magazyn certyfikatów na urządzeniu przy użyciu polecenia specyficznego dla platformy.
```
# 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
```
Aby uzyskać więcej informacji na temat korzystania z usługi update-ca-trust EFLOW, zobacz CBL-Mariner SSL CA management (Zarządzanie certyfikatami SSL CBL-Mariner SSL).

Polecenie zgłasza dodanie jednego certyfikatu do elementu /etc/ssl/certs.

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

Aktualizowanie pliku konfiguracji nadrzędnej

Na urządzeniu powinna być już zainstalowana usługa IoT Edge. Jeśli nie, wykonaj kroki ręcznej aprowizacji pojedynczego urządzenia usługi IoT Edge z systemem Linux.

Sprawdź, /etc/aziot/config.toml czy plik konfiguracji istnieje na urządzeniu nadrzędnym.

Jeśli plik konfiguracji nie istnieje na urządzeniu, użyj następującego polecenia, aby utworzyć go na podstawie pliku szablonu:
```
sudo cp /etc/aziot/config.toml.edge.template /etc/aziot/config.toml
```
Możesz również użyć pliku szablonu jako odwołania, aby dodać parametry konfiguracji w tej sekcji.
Otwórz plik konfiguracji usługi IoT Edge przy użyciu edytora. Na przykład użyj edytora nano , aby otworzyć /etc/aziot/config.toml plik.
```
sudo nano /etc/aziot/config.toml
```
Znajdź parametr nazwy hosta lub dodaj go na początku pliku konfiguracji. Zaktualizuj wartość tak, aby była w pełni kwalifikowaną nazwą domeny (FQDN) lub adresem IP urządzenia nadrzędnego usługi IoT Edge. Na przykład:
```
hostname = "10.0.0.4"
```
Aby włączyć odnajdywanie bramy, każde urządzenie bramy usługi IoT Edge (nadrzędne) musi określić parametr nazwy hosta, który będzie używany przez jego urządzenia podrzędne w celu znalezienia go w sieci lokalnej. Każde podrzędne urządzenie usługi IoT Edge musi określić parametr parent_hostname , aby zidentyfikować jego element nadrzędny. W scenariuszu hierarchicznym, w którym pojedyncze urządzenie usługi IoT Edge jest zarówno urządzeniem nadrzędnym, jak i podrzędnym, wymaga obu parametrów.

Parametry nazwy hosta i trust_bundle_cert muszą znajdować się na początku pliku konfiguracji przed wszelkimi sekcjami. Dodanie parametru przed zdefiniowanymi sekcjami gwarantuje, że jest on poprawnie stosowany.

Użyj nazwy hosta krótszej niż 64 znaki, która jest limitem znaków dla nazwy pospolitej certyfikatu serwera.

Zachowaj spójność ze wzorcem nazwy hosta w hierarchii bramy. Użyj nazw FQDN lub adresów IP, ale nie obu tych nazw. Do łączenia urządzeń podrzędnych jest wymagana nazwa FQDN lub adres IP.

Ustaw nazwę hosta przed utworzeniem kontenera edgeHub . Jeśli usługa edgeHub jest uruchomiona, zmiana nazwy hosta w pliku konfiguracji nie będzie obowiązywać do momentu ponownego utworzenia kontenera. Aby uzyskać więcej informacji na temat sprawdzania, czy nazwa hosta jest stosowana, zobacz sekcję Weryfikowanie konfiguracji nadrzędnej.
Znajdź parametr certyfikatu pakietu zaufania lub dodaj go na początku pliku konfiguracji.

Zaktualizuj parametr za trust_bundle_cert pomocą identyfikatora URI pliku do certyfikatu głównego urzędu certyfikacji na urządzeniu. Na przykład:
```
trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"
```
Znajdź lub dodaj sekcję certyfikatu urzędu certyfikacji usługi Edge w pliku konfiguracji. Zaktualizuj parametry certyfikatu cert i klucza pk prywatnego za pomocą ścieżek identyfikatora URI pliku dla plików certyfikatu pełnego łańcucha i plików kluczy na nadrzędnym urządzeniu usługi IoT Edge. Usługa IoT Edge wymaga, aby certyfikat i klucz prywatny był w formacie poczty rozszerzonej na podstawie tekstu (PEM). Na przykład:
```
[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"
```
Sprawdź, czy urządzenie usługi IoT Edge używa poprawnej wersji agenta usługi IoT Edge podczas jego uruchamiania. Znajdź sekcję Domyślny agent usługi Edge i ustaw wartość obrazu dla usługi IoT Edge na wersję 1.5. Na przykład:
```
[agent]
name = "edgeAgent"
type = "docker"

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

Początek pliku konfiguracji nadrzędnej powinien wyglądać podobnie do poniższego przykładu.

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"

Zapisz i zamknij config.toml plik konfiguracji. Jeśli na przykład używasz edytora nano, wybierz Ctrl+O - Write Out, Enter i Ctrl+X - Exit.
Jeśli wcześniej użyto innych certyfikatów dla usługi IoT Edge, usuń pliki w następujących dwóch katalogach, aby upewnić się, że nowe certyfikaty zostaną zastosowane:
- /var/lib/aziot/certd/certs
- /var/lib/aziot/keyd/keys
Zastosuj zmiany.
```
sudo iotedge config apply
```
Sprawdź błędy w konfiguracji.
```
sudo iotedge check --verbose
```
Uwaga

Na nowo aprowizowanych urządzeniach może zostać wyświetlony błąd związany z usługą IoT Edge Hub:

× gotowości produkcyjnej: katalog magazynu usługi Edge Hub jest utrwalany w systemie plików hosta — błąd

Nie można sprawdzić bieżącego stanu kontenera edgeHub

Ten błąd jest oczekiwany na nowo zaaprowizowanych urządzeniach, ponieważ moduł usługi IoT Edge Hub nie jest uruchomiony. Aby rozwiązać ten problem, w usłudze IoT Hub ustaw moduły dla urządzenia i utwórz wdrożenie. Utworzenie wdrożenia urządzenia powoduje uruchomienie modułów na urządzeniu, w tym modułu usługi IoT Edge Hub.

Weryfikowanie konfiguracji nadrzędnej

Nazwa hosta musi być kwalifikowaną nazwą domeny (FQDN) lub adresem IP urządzenia usługi IoT Edge, ponieważ usługa IoT Edge używa tej wartości w certyfikacie serwera podczas nawiązywania połączenia z urządzeniami podrzędnymi. Wartości muszą być zgodne lub otrzymasz błąd niezgodności adresu IP.

Aby sprawdzić nazwę hosta, należy sprawdzić zmienne środowiskowe kontenera edgeHub .

Wyświetl listę uruchomionych kontenerów usługi IoT Edge.

iotedge list

Sprawdź, czy kontenery edgeAgent i edgeHub są uruchomione. Dane wyjściowe polecenia powinny być podobne do poniższego przykładu.

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

Sprawdź kontener edgeHub.
```
sudo docker inspect edgeHub
```
W danych wyjściowych znajdź parametr EdgeDeviceHostName w sekcji Env .
```
"EdgeDeviceHostName=10.0.0.4"
```
Sprawdź, czy wartość parametru EdgeDeviceHostName jest zgodna z ustawieniem config.toml nazwy hosta. Jeśli kontener edgeHub nie jest zgodny, został uruchomiony podczas modyfikowania i stosowania konfiguracji. Aby zaktualizować element EdgeDeviceHostName, usuń kontener edgeAgent .
```
sudo docker rm -f edgeAgent
```
Kontenery edgeAgent i edgeHub są ponownie tworzone i uruchamiane w ciągu kilku minut. Po uruchomieniu kontenera edgeHub sprawdź kontener i sprawdź, czy parametr EdgeDeviceHostName jest zgodny z plikiem konfiguracji.

Konfigurowanie urządzenia podrzędnego

Aby skonfigurować urządzenie podrzędne, otwórz lokalną lub zdalną powłokę poleceń.

Aby umożliwić bezpieczne połączenia, każde urządzenie podrzędne usługi IoT Edge w scenariuszu bramy musi być skonfigurowane przy użyciu unikatowego certyfikatu urzędu certyfikacji usługi Edge i kopii certyfikatu głównego urzędu certyfikacji współużytkowanego przez wszystkie urządzenia w hierarchii bramy.

Sprawdź, czy certyfikaty spełniają wymagania dotyczące formatu.
Przenieś certyfikat głównego urzędu certyfikacji, podrzędny certyfikat urzędu certyfikacji edge i podrzędny klucz prywatny do urządzenia podrzędnego.

Skopiuj certyfikaty i klucze do odpowiednich katalogów. Preferowanymi katalogami certyfikatów urządzeń są /var/aziot/certs certyfikaty i /var/aziot/secrets klucze.

### 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

Zmień własność i uprawnienia certyfikatów i kluczy.

# 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 {} \;

Zainstaluj certyfikat głównego urzędu certyfikacji na urządzeniu podrzędnym usługi IoT Edge, aktualizując magazyn certyfikatów na urządzeniu przy użyciu polecenia specyficznego dla platformy.
```
# 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
```
Aby uzyskać więcej informacji na temat korzystania z usługi update-ca-trust EFLOW, zobacz CBL-Mariner SSL CA management (Zarządzanie certyfikatami SSL CBL-Mariner SSL).

Polecenie zgłasza dodanie jednego certyfikatu do elementu /etc/ssl/certs.

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

Aktualizowanie pliku konfiguracji podrzędnej

Na urządzeniu powinna być już zainstalowana usługa IoT Edge. Jeśli nie, wykonaj kroki ręcznej aprowizacji pojedynczego urządzenia usługi IoT Edge z systemem Linux.

Sprawdź, /etc/aziot/config.toml czy plik konfiguracji istnieje na urządzeniu podrzędnym.

Jeśli plik konfiguracji nie istnieje na urządzeniu, użyj następującego polecenia, aby utworzyć go na podstawie pliku szablonu:
```
sudo cp /etc/aziot/config.toml.edge.template /etc/aziot/config.toml
```
Możesz również użyć pliku szablonu jako odwołania, aby dodać parametry konfiguracji w tej sekcji.
Otwórz plik konfiguracji usługi IoT Edge przy użyciu edytora. Na przykład użyj edytora nano , aby otworzyć /etc/aziot/config.toml plik.
```
sudo nano /etc/aziot/config.toml
```
Znajdź parametr parent_hostname lub dodaj go na początku pliku konfiguracji Każde podrzędne urządzenie usługi IoT Edge musi określić parametr parent_hostname w celu zidentyfikowania jego elementu nadrzędnego. parent_hostname Zaktualizuj parametr tak, aby był nazwą FQDN lub adresem IP urządzenia nadrzędnego, pasując do podanej nazwy hosta w pliku konfiguracji urządzenia nadrzędnego. Na przykład:
```
parent_hostname = "10.0.0.4"
```
Znajdź parametr certyfikatu pakietu zaufania lub dodaj go na początku pliku konfiguracji.

Zaktualizuj parametr za trust_bundle_cert pomocą identyfikatora URI pliku do certyfikatu głównego urzędu certyfikacji na urządzeniu. Na przykład:
```
trust_bundle_cert = "file:///var/aziot/certs/azure-iot-test-only.root.ca.cert.pem"
```
Znajdź lub dodaj sekcję Certyfikat urzędu certyfikacji edge w pliku konfiguracji. Zaktualizuj parametry certyfikatu cert i klucza pk prywatnego za pomocą ścieżek identyfikatora URI pliku dla plików certyfikatu pełnego łańcucha i plików kluczy na urządzeniu podrzędnym usługi IoT Edge. Usługa IoT Edge wymaga, aby certyfikat i klucz prywatny był w formacie poczty rozszerzonej na podstawie tekstu (PEM). Na przykład:
```
[edge_ca]
cert = "file:///var/aziot/certs/iot-device-downstream-full-chain.cert.pem"
pk = "file:///var/aziot/secrets/iot-device-downstream.key.pem"
```
Sprawdź, czy urządzenie usługi IoT Edge używa poprawnej wersji agenta usługi IoT Edge podczas jego uruchamiania. Znajdź sekcję Domyślny agent usługi Edge i ustaw wartość obrazu dla usługi IoT Edge na wersję 1.5. Na przykład:
```
[agent]
name = "edgeAgent"
type = "docker"

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

Początek pliku konfiguracji podrzędnej powinien wyglądać podobnie do poniższego przykładu.

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"

Zapisz i zamknij config.toml plik konfiguracji. Jeśli na przykład używasz edytora nano, wybierz Ctrl+O - Write Out, Enter i Ctrl+X - Exit.
Jeśli wcześniej użyto innych certyfikatów dla usługi IoT Edge, usuń pliki w następujących dwóch katalogach, aby upewnić się, że nowe certyfikaty zostaną zastosowane:
- /var/lib/aziot/certd/certs
- /var/lib/aziot/keyd/keys
Zastosuj zmiany.
```
sudo iotedge config apply
```
Sprawdź błędy w konfiguracji.
```
sudo iotedge check --verbose
```
Napiwek

Narzędzie do sprawdzania usługi IoT Edge używa kontenera do przeprowadzania niektórych kontroli diagnostycznych. Jeśli chcesz użyć tego narzędzia na podrzędnych urządzeniach usługi IoT Edge, upewnij się, że mają one dostęp do mcr.microsoft.com/azureiotedge-diagnostics:latestusługi lub mają obraz kontenera w prywatnym rejestrze kontenerów.

Uwaga

Na nowo aprowizowanych urządzeniach może zostać wyświetlony błąd związany z usługą IoT Edge Hub:

× gotowości produkcyjnej: katalog magazynu usługi Edge Hub jest utrwalany w systemie plików hosta — błąd

Nie można sprawdzić bieżącego stanu kontenera edgeHub

Ten błąd jest oczekiwany na nowo zaaprowizowanych urządzeniach, ponieważ moduł usługi IoT Edge Hub nie jest uruchomiony. Aby rozwiązać ten problem, w usłudze IoT Hub ustaw moduły dla urządzenia i utwórz wdrożenie. Utworzenie wdrożenia urządzenia powoduje uruchomienie modułów na urządzeniu, w tym modułu usługi IoT Edge Hub.

Izolowanie sieci urządzeń podrzędnych

Kroki opisane w tym artykule umożliwiają skonfigurowanie urządzeń usługi IoT Edge jako bramy lub urządzenia podrzędnego oraz utworzenie zaufanego połączenia między nimi. Urządzenie bramy obsługuje interakcje między urządzeniem podrzędnym a usługą IoT Hub, w tym uwierzytelnianiem i routingiem komunikatów. Moduły wdrożone na podrzędnych urządzeniach usługi IoT Edge nadal mogą tworzyć własne połączenia z usługami w chmurze.

Niektóre architektury sieci, takie jak te zgodne ze standardem ISA-95, starają się zminimalizować liczbę połączeń internetowych. W tych scenariuszach można skonfigurować podrzędne urządzenia usługi IoT Edge bez bezpośredniej łączności z Internetem. Poza routingiem komunikacji usługi IoT Hub za pośrednictwem urządzenia bramy urządzenia podrzędne usługi IoT Edge mogą polegać na urządzeniu bramy dla wszystkich połączeń w chmurze.

Ta konfiguracja sieci wymaga, aby tylko urządzenie usługi IoT Edge w górnej warstwie hierarchii bramy ma bezpośrednie połączenia z chmurą. Urządzenia usługi IoT Edge w niższych warstwach mogą komunikować się tylko z urządzeniem nadrzędnym lub dowolnymi urządzeniami podrzędnymi. Specjalne moduły na urządzeniach bramy umożliwiają korzystanie z tego scenariusza, w tym:

Moduł serwera proxy interfejsu API jest wymagany w dowolnej bramie usługi IoT Edge, która ma poniżej niego inne urządzenie usługi IoT Edge. Oznacza to, że musi znajdować się w każdej warstwie hierarchii bramy z wyjątkiem warstwy dolnej. W tym module używany jest zwrotny serwer proxy nginx do kierowania danych HTTP za pośrednictwem warstw sieciowych za pośrednictwem pojedynczego portu. Jest on wysoce konfigurowalny za pomocą bliźniaczej reprezentacji modułu i zmiennych środowiskowych, dzięki czemu można dostosować je do wymagań scenariusza bramy.
Moduł rejestru platformy Docker można wdrożyć w bramie usługi IoT Edge w górnej warstwie hierarchii bramy. Ten moduł jest odpowiedzialny za pobieranie i buforowanie obrazów kontenerów w imieniu wszystkich urządzeń usługi IoT Edge w niższych warstwach. Alternatywą do wdrożenia tego modułu w górnej warstwie jest użycie rejestru lokalnego lub ręczne załadowanie obrazów kontenerów na urządzenia i ustawienie zasad ściągania modułu na nigdy.
Usługę Azure Blob Storage w usłudze IoT Edge można wdrożyć w bramie usługi IoT Edge w górnej warstwie hierarchii bramy. Ten moduł jest odpowiedzialny za przekazywanie obiektów blob w imieniu wszystkich urządzeń usługi IoT Edge w niższych warstwach. Możliwość przekazywania obiektów blob umożliwia również przydatne funkcje rozwiązywania problemów dla urządzeń usługi IoT Edge w niższych warstwach, takich jak przekazywanie dzienników modułów i przekazywanie pakietów pomocy technicznej.

Konfiguracja sieci

Dla każdego urządzenia bramy w górnej warstwie operatorzy sieci muszą:

Podaj statyczny adres IP lub w pełni kwalifikowaną nazwę domeny (FQDN).
Autoryzuj komunikację wychodzącą z tego adresu IP do nazwy hosta usługi Azure IoT Hub za pośrednictwem portów 443 (HTTPS) i 5671 (AMQP).
Autoryzuj komunikację wychodzącą z tego adresu IP do nazwy hosta usługi Azure Container Registry za pośrednictwem portu 443 (HTTPS).

Moduł serwera proxy interfejsu API może obsługiwać tylko połączenia z jednym rejestrem kontenerów jednocześnie. Zalecamy posiadanie wszystkich obrazów kontenerów, w tym obrazów publicznych udostępnianych przez usługę Microsoft Container Registry (mcr.microsoft.com), przechowywanych w prywatnym rejestrze kontenerów.

Dla każdego urządzenia bramy w niższej warstwie operatorzy sieci muszą:

Podaj statyczny adres IP.
Autoryzuj komunikację wychodzącą z tego adresu IP do adresu IP bramy nadrzędnej za pośrednictwem portów 443 (HTTPS) i 5671 (AMQP).

Wdrażanie modułów na urządzeniach najwyższej warstwy

Urządzenie usługi IoT Edge w górnej warstwie hierarchii bramy ma zestaw wymaganych modułów, które muszą być w nim wdrożone, oprócz wszystkich modułów obciążenia, które można uruchomić na urządzeniu.

Moduł serwera proxy interfejsu API został zaprojektowany tak, aby był dostosowany do najbardziej typowych scenariuszy bramy. Ten artykuł zawiera przykład konfigurowania modułów w podstawowej konfiguracji. Zobacz Konfigurowanie modułu serwera proxy interfejsu API dla scenariusza hierarchii bramy, aby uzyskać bardziej szczegółowe informacje i przykłady.

Portal
Interfejs wiersza polecenia platformy Azure

W witrynie Azure Portal przejdź do centrum IoT Hub.
Wybierz pozycję Urządzenia w menu Zarządzanie urządzeniami .
Wybierz urządzenie usługi IoT Edge w górnej warstwie, które konfigurujesz z listy.
Wybierz opcję Ustaw moduły.
W sekcji Moduły usługi IoT Edge wybierz pozycję Dodaj, a następnie wybierz pozycję Moduł usługi IoT Edge.

Zaktualizuj następujące ustawienia modułu:

Ustawienie	Wartość
Nazwa modułu IoT	`IoTEdgeAPIProxy`
Identyfikator URI obrazu	`mcr.microsoft.com/azureiotedge-api-proxy:latest`
Zasady ponownego uruchamiania	zawsze
Żądany stan	uruchomiono

Jeśli chcesz użyć innej wersji lub architektury modułu serwera proxy interfejsu API, znajdź dostępne obrazy w Rejestr Artefaktów Microsoft.

Na karcie Zmienne środowiskowe dodaj zmienną o nazwie NGINX_DEFAULT_PORT Text z wartością 443.

Na karcie Opcje tworzenia kontenera zaktualizuj powiązania portów, aby odwoływać się do portu 443.

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

Te zmiany umożliwiają skonfigurowanie modułu serwera proxy interfejsu API do nasłuchiwania na porcie 443. Aby zapobiec kolizjom powiązań portów, należy skonfigurować moduł edgeHub, aby nie nasłuchiwać na porcie 443. Zamiast tego moduł serwera proxy interfejsu API będzie kierować dowolny ruch edgeHub na porcie 443.

Wybierz pozycję Dodaj , aby dodać moduł do wdrożenia.

Wybierz pozycję Ustawienia środowiska uruchomieniowego i znajdź opcje tworzenia kontenera modułu edgeHub. Usuń powiązanie portu dla portu 443, pozostawiając powiązania dla portów 5671 i 8883.

{
  "HostConfig": {
    "PortBindings": {
      "5671/tcp": [
        {
          "HostPort": "5671"
        }
      ],
      "8883/tcp": [
        {
          "HostPort": "8883"
        }
      ]
    }
  }
}

Wybierz pozycję Zastosuj , aby zapisać zmiany w ustawieniach środowiska uruchomieniowego.

Podaj następujące wartości, aby dodać moduł rejestru platformy Docker do wdrożenia.

W sekcji Moduły usługi IoT Edge wybierz pozycję Dodaj, a następnie wybierz pozycję Moduł usługi IoT Edge.

Ustawienie Wartość

Nazwa modułu IoT registry

Identyfikator URI obrazu registry:latest

Zasady ponownego uruchamiania always

Żądany stan running

Ustawienie	Wartość
Nazwa modułu IoT	`registry`
Identyfikator URI obrazu	`registry:latest`
Zasady ponownego uruchamiania	`always`
Żądany stan	`running`

Na karcie Zmienne środowiskowe dodaj następujące zmienne:

Nazwisko	Typ	Wartość
`REGISTRY_PROXY_REMOTEURL`	Text	Adres URL rejestru kontenerów, do którego ma zostać zamapowyny ten moduł rejestru. Na przykład `https://myregistry.azurecr`. Moduł rejestru może mapować tylko na jeden rejestr kontenerów, dlatego zalecamy posiadanie wszystkich obrazów kontenerów w jednym prywatnym rejestrze kontenerów.
`REGISTRY_PROXY_USERNAME`	Text	Nazwa użytkownika do uwierzytelniania w rejestrze kontenerów.
`REGISTRY_PROXY_PASSWORD`	Text	Hasło do uwierzytelniania w rejestrze kontenerów.

Na karcie Opcje tworzenia kontenera zaktualizuj powiązania portów, aby odwoływać się do portu 5000.

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

Wybierz pozycję Dodaj , aby dodać moduł do wdrożenia.
Wybierz pozycję Dalej: Trasy , aby przejść do następnego kroku.
Aby umożliwić urządzeniu przesyłanie komunikatów z urządzeń podrzędnych do usługi IoT Hub, dołącz trasę przekazującą wszystkie komunikaty do usługi IoT Hub. Na przykład:
1. Nazwa: Route
2. Wartość: FROM /messages/* INTO $upstream
Wybierz pozycję Przejrzyj i utwórz , aby przejść do ostatniego kroku.
Wybierz pozycję Utwórz , aby wdrożyć na urządzeniu.

W usłudze Azure Cloud Shell utwórz plik JSON wdrożenia. Na przykład:

{
    "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
                }
            }
        }
    }
}

Ten plik wdrożenia konfiguruje moduł serwera proxy interfejsu API do nasłuchiwania na porcie 443. Aby zapobiec kolizjom powiązań portów, plik konfiguruje moduł edgeHub tak, aby nie nasłuchiwać na porcie 443. Zamiast tego moduł serwera proxy interfejsu API będzie kierować dowolny ruch edgeHub na porcie 443.

Wprowadź następujące polecenie, aby utworzyć wdrożenie na urządzeniu usługi IoT Edge:

az iot edge set-modules --device-id <device_id> --hub-name <iot_hub_name> --content ./<deployment_file_name>.json

Wdrażanie modułów na urządzeniach niższej warstwy

Urządzenia usługi IoT Edge w niższych warstwach hierarchii bramy mają jeden wymagany moduł, który musi zostać wdrożony, oprócz wszystkich modułów obciążenia, które można uruchomić na urządzeniu.

Ściąganie obrazu kontenera trasy

Przed omówieniem wymaganego modułu proxy dla urządzeń usługi IoT Edge w hierarchii bramy należy zrozumieć, jak urządzenia usługi IoT Edge w niższych warstwach uzyskują obrazy modułów.

Jeśli urządzenia niższej warstwy nie mogą łączyć się z chmurą, ale chcesz, aby ściągały obrazy modułów w zwykły sposób, należy skonfigurować urządzenie najwyższego warstwy hierarchii bramy do obsługi tych żądań. Urządzenie w górnej warstwie musi uruchomić moduł rejestru platformy Docker, który jest mapowany na rejestr kontenerów. Następnie skonfiguruj moduł serwera proxy interfejsu API w celu kierowania do niego żądań kontenera. Te szczegóły zostały omówione we wcześniejszych sekcjach tego artykułu. W tej konfiguracji urządzenia niższej warstwy nie powinny wskazywać rejestrów kontenerów w chmurze, ale do rejestru uruchomionego w górnej warstwie.

Na przykład zamiast wywoływania mcr.microsoft.com/azureiotedge-api-proxy:1.1urządzenia niższej warstwy powinny wywoływać metodę $upstream:443/azureiotedge-api-proxy:1.1.

Parametr $upstream wskazuje element nadrzędny urządzenia niższej warstwy, więc żądanie będzie kierowane przez wszystkie warstwy, dopóki nie osiągnie górnej warstwy, która ma żądanie kontenera routingu środowiska proxy do modułu rejestru. Port :443 w tym przykładzie powinien zostać zastąpiony portem, na którym nasłuchuje moduł serwera proxy interfejsu API na urządzeniu nadrzędnym.

Moduł proxy interfejsu API może kierować tylko do jednego modułu rejestru, a każdy moduł rejestru może mapować tylko na jeden rejestr kontenerów. W związku z tym wszystkie obrazy, które urządzenia niższej warstwy muszą być ściągane, muszą być przechowywane w jednym rejestrze kontenerów.

Jeśli nie chcesz, aby urządzenia niższej warstwy wysyłały żądania ściągnięcia modułu za pośrednictwem hierarchii bramy, inną opcją jest zarządzanie lokalnym rozwiązaniem rejestru. Możesz też wypchnąć obrazy modułów na urządzenia przed utworzeniem wdrożeń, a następnie ustawić obrazPullPolicy na nigdy.

Uruchamianie agenta usługi IoT Edge

Agent usługi IoT Edge jest pierwszym składnikiem środowiska uruchomieniowego do uruchomienia na dowolnym urządzeniu usługi IoT Edge. Należy się upewnić, że wszystkie podrzędne urządzenia usługi IoT Edge mogą uzyskiwać dostęp do obrazu modułu edgeAgent podczas uruchamiania, a następnie uzyskiwać dostęp do wdrożeń i uruchamiać pozostałe obrazy modułów.

Po przejściu do pliku konfiguracji na urządzeniu usługi IoT Edge w celu udostępnienia informacji o uwierzytelnianiu, certyfikatach i nadrzędnej nazwie hosta zaktualizuj również obraz kontenera edgeAgent.

Jeśli urządzenie bramy najwyższego poziomu jest skonfigurowane do obsługi żądań obrazów kontenera, zastąp element mcr.microsoft.com nadrzędnym nazwą hosta i portem nasłuchiwania serwera proxy interfejsu API. W manifeście wdrażania można użyć $upstream skrótu, ale wymaga to modułu edgeHub do obsługi routingu i moduł nie został uruchomiony w tym momencie. Na przykład:

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

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

Jeśli używasz lokalnego rejestru kontenerów lub ręcznie udostępniasz obrazy kontenerów na urządzeniu, zaktualizuj odpowiednio plik konfiguracji.

Konfigurowanie środowiska uruchomieniowego i wdrażanie modułu serwera proxy

Moduł serwera proxy interfejsu API jest wymagany do routingu całej komunikacji między chmurą a dowolnymi podrzędnymi urządzeniami usługi IoT Edge. Urządzenie usługi IoT Edge w dolnej warstwie hierarchii bez podrzędnych urządzeń usługi IoT Edge nie wymaga tego modułu.

Moduł serwera proxy interfejsu API został zaprojektowany tak, aby był dostosowany do najbardziej typowych scenariuszy bramy. W tym artykule krótko opisano kroki konfigurowania modułów w podstawowej konfiguracji. Zobacz Konfigurowanie modułu serwera proxy interfejsu API dla scenariusza hierarchii bramy, aby uzyskać bardziej szczegółowe informacje i przykłady.

W witrynie Azure Portal przejdź do centrum IoT Hub.
Wybierz pozycję Urządzenia w menu Zarządzanie urządzeniami .
Wybierz urządzenie usługi IoT Edge niższej warstwy, które konfigurujesz z listy.
Wybierz opcję Ustaw moduły.
W sekcji Moduły usługi IoT Edge wybierz pozycję Dodaj, a następnie wybierz pozycję Moduł usługi IoT Edge.

Zaktualizuj następujące ustawienia modułu:

Ustawienie	Wartość
Nazwa modułu IoT	`IoTEdgeAPIProxy`
Identyfikator URI obrazu	`mcr.microsoft.com/azureiotedge-api-proxy:latest`
Zasady ponownego uruchamiania	`always`
Żądany stan	`running`

Jeśli chcesz użyć innej wersji lub architektury modułu serwera proxy interfejsu API, znajdź dostępne obrazy w Rejestr Artefaktów Microsoft.

Na karcie Zmienne środowiskowe dodaj zmienną o nazwie NGINX_DEFAULT_PORT Text z wartością 443.

Na karcie Opcje tworzenia kontenera zaktualizuj powiązania portów, aby odwoływać się do portu 443.

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

Wybierz pozycję Ustawienia środowiska uruchomieniowego.

Zaktualizuj ustawienia modułu edgeHub:

W polu Obraz zastąp wartość mcr.microsoft.com .$upstream:443
W polu Utwórz opcje usuń powiązanie portów dla portu 443, pozostawiając powiązania portów 5671 i 8883.

{
  "HostConfig": {
    "PortBindings": {
      "5671/tcp": [
        {
          "HostPort": "5671"
        }
      ],
      "8883/tcp": [
        {
          "HostPort": "8883"
        }
      ]
    }
  }
}

Zaktualizuj ustawienia modułu edgeAgent:
1. W polu Obraz zastąp wartość mcr.microsoft.com .$upstream:443
Wybierz pozycję Zastosuj , aby zapisać zmiany w ustawieniach środowiska uruchomieniowego.
Wybierz pozycję Dalej: Trasy , aby przejść do następnego kroku.
Aby włączyć komunikaty urządzenie-chmura z urządzeń podrzędnych w celu dotarcia do usługi IoT Hub, dołącz trasę przekazującą wszystkie komunikaty do $upstreamusługi . Nadrzędny parametr wskazuje urządzenie nadrzędne w przypadku urządzeń niższej warstwy. Na przykład:
1. Nazwa: Route
2. Wartość: FROM /messages/* INTO $upstream
Wybierz pozycję Przejrzyj i utwórz , aby przejść do ostatniego kroku.
Wybierz pozycję Utwórz , aby wdrożyć na urządzeniu.

Weryfikowanie łączności z elementu podrzędnego do elementu nadrzędnego

Sprawdź połączenie TLS/SSL z elementu podrzędnego do elementu nadrzędnego, uruchamiając następujące openssl polecenie na urządzeniu podrzędnym. Zastąp <parent hostname> ciąg nazwą FQDN lub adresem IP elementu nadrzędnego.
```
openssl s_client -connect <parent hostname>:8883 </dev/null 2>&1 >/dev/null
```
Polecenie powinno potwierdzić pomyślną walidację nadrzędnego łańcucha certyfikatów podobne do następującego przykładu:
```
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
```
Komunikat "Nie można użyć SSL_get_servername" można zignorować.

Wartość powinna być zgodna depth=0 CN = z parametrem nazwy hosta określonym w pliku konfiguracji elementu nadrzędnego config.toml .

Jeśli upłynął limit czasu polecenia, między urządzeniami podrzędnym i nadrzędnymi mogą być zablokowane porty. Przejrzyj konfigurację sieci i ustawienia dla urządzeń.
Ostrzeżenie

Nieużywaj certyfikatu pełnego łańcucha w sekcji bramy [edge_ca] powoduje błędy weryfikacji certyfikatu z urządzenia podrzędnego. Na przykład openssl s_client ... powyższe polecenie spowoduje wygenerowanie:
```
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
```
Ten sam problem występuje w przypadku urządzeń z obsługą protokołu TLS, które łączą się z podrzędnym urządzeniem usługi IoT Edge, jeśli certyfikat urządzenia pełnego łańcucha nie jest używany i skonfigurowany na urządzeniu podrzędnym.

Integracja usługi Microsoft Defender dla IoT z bramą usługi IoT Edge

Urządzenia podrzędne mogą służyć do integracji mikro agenta usługi Microsoft Defender for IoT z bramą usługi IoT Edge przy użyciu serwera proxy urządzeń podrzędnych.

Dowiedz się więcej o mikro agentze usługi Defender for IoT.

Aby zintegrować usługę Microsoft Defender dla IoT Edge z usługą IoT Edge przy użyciu serwera proxy urządzeń podrzędnych:

Zaloguj się w witrynie Azure Portal.
Przejdź do pozycji Urządzenia zarządzania urządzeniami>usługi IoT Hub>Your Hub>
Wybierz urządzenie.
Wybierz bliźniacze reprezentację modułu utworzoną DefenderIotMicroAgent na podstawie tych instrukcji.
Wybierz przycisk , aby skopiować parametry połączenia (klucz podstawowy).
Wklej parametry połączenia do aplikacji do edycji tekstu i dodaj wartość GatewayHostName do ciągu. GatewayHostName to w pełni kwalifikowana nazwa domeny lub adres IP urządzenia nadrzędnego. Na przykład HostName=nested11.azure-devices.net;DeviceId=downstream1;ModuleId=module1;SharedAccessKey=xxx;GatewayHostName=10.16.7.4.
Otwórz terminal na urządzeniu podrzędnym.
Użyj następującego polecenia, aby umieścić parametry połączenia zakodowane w formacie utf-8 w katalogu agenta Defender dla Chmury w pliku connection_string.txt w następującej ścieżce: : /etc/defender_iot_micro_agent/connection_string.txt
```
sudo bash -c 'echo "<connection string>" > /etc/defender_iot_micro_agent/connection_string.txt'
```
Element connection_string.txt powinien teraz znajdować się w następującej lokalizacji ścieżki /etc/defender_iot_micro_agent/connection_string.txt.

Uruchom ponownie usługę przy użyciu tego polecenia:

sudo systemctl restart defender-iot-micro-agent.service

Wróć do urządzenia.
Włącz połączenie z usługą IoT Hub i wybierz ikonę koła zębatego.
Wybierz urządzenie nadrzędne z wyświetlonej listy.
Upewnij się, że port 8883 (MQTT) między urządzeniem podrzędnym a urządzeniem usługi IoT Edge jest otwarty.

Następne kroki

Jak używać urządzenia usługi IoT Edge jako bramy

Konfigurowanie modułu serwera proxy interfejsu API dla scenariusza hierarchii bramy

Udostępnij za pośrednictwem