Przygotowywanie do wdrożenia rozwiązania IoT Edge w środowisku produkcyjnym

Dotyczy:IoT Edge 1.4 checkmark IoT Edge 1.4

Ważne

Azure IoT Edge1.4 jest obsługiwaną wersją. Jeśli korzystasz z wcześniejszej wersji, zobacz aktualizację Azure IoT Edge.

Gdy wszystko będzie gotowe do skorzystania z rozwiązania usługi IoT Edge od programowania do środowiska produkcyjnego, upewnij się, że jest ona skonfigurowana pod kątem ciągłej wydajności.

Informacje podane w tym artykule nie są równe. Aby ułatwić ustalanie priorytetów, każda sekcja rozpoczyna się od list, które dzielą pracę na dwie sekcje: ważne , aby ukończyć przed przejściem do środowiska produkcyjnego lub przydatne do poznania.

Konfiguracja urządzenia

Urządzenia usługi IoT Edge mogą być dowolne z urządzenia Raspberry Pi do laptopa do maszyny wirtualnej działającej na serwerze. Być może masz dostęp do urządzenia fizycznie lub za pośrednictwem połączenia wirtualnego albo może być odizolowany przez dłuższy czas. Tak czy inaczej, chcesz upewnić się, że jest on skonfigurowany do odpowiedniego działania.

  • Ważny

    • Instalowanie certyfikatów produkcyjnych
    • Posiadanie planu zarządzania urządzeniami
    • Używanie narzędzia Moby jako aparatu kontenera
  • Przydatne

    • Wybieranie protokołu nadrzędnego

Instalowanie certyfikatów produkcyjnych

Każde urządzenie usługi IoT Edge w środowisku produkcyjnym wymaga zainstalowanego na nim certyfikatu urzędu certyfikacji urządzenia. Certyfikat urzędu certyfikacji jest następnie zadeklarowany w środowisku uruchomieniowym usługi IoT Edge w pliku konfiguracji. W przypadku scenariuszy tworzenia i testowania środowisko uruchomieniowe usługi IoT Edge tworzy certyfikaty tymczasowe, jeśli w pliku konfiguracji nie są deklarowane żadne certyfikaty. Jednak te certyfikaty tymczasowe wygasają po trzech miesiącach i nie są bezpieczne w scenariuszach produkcyjnych. W przypadku scenariuszy produkcyjnych należy podać własny certyfikat urzędu certyfikacji urządzenia z urzędu certyfikacji z podpisem własnym lub zakupiony w komercyjnym urzędzie certyfikacji.

Aby zrozumieć rolę certyfikatu urzędu certyfikacji urządzenia, zobacz Jak usługa Azure IoT Edge używa certyfikatów.

Aby uzyskać więcej informacji na temat sposobu instalowania certyfikatów na urządzeniu usługi IoT Edge i odwoływanie się do nich z pliku konfiguracji, zobacz Zarządzanie certyfikatem na urządzeniu usługi IoT Edge.

Posiadanie planu zarządzania urządzeniami

Przed umieszczeniem dowolnego urządzenia w środowisku produkcyjnym należy wiedzieć, jak będziesz zarządzać przyszłymi aktualizacjami. W przypadku urządzenia usługi IoT Edge lista składników do aktualizacji może obejmować:

  • Oprogramowanie układowe urządzenia
  • Biblioteki systemu operacyjnego
  • Aparat kontenera, taki jak Moby
  • IoT Edge
  • Certyfikaty urzędów certyfikacji

Aktualizacja urządzenia dla usługi IoT Hub to usługa, która umożliwia wdrażanie aktualizacji za pośrednictwem powietrza (OTA) dla urządzeń usługi IoT Edge.

Alternatywne metody aktualizowania usługi IoT Edge wymagają fizycznego lub SSH dostępu do urządzenia usługi IoT Edge. Aby uzyskać więcej informacji, zobacz Aktualizowanie środowiska uruchomieniowego usługi IoT Edge. Aby zaktualizować wiele urządzeń, rozważ dodanie kroków aktualizacji do skryptu lub użycie narzędzia automatyzacji, takiego jak Ansible.

Używanie narzędzia Moby jako aparatu kontenera

Aparat kontenera jest wymaganiem wstępnym dla dowolnego urządzenia usługi IoT Edge. Tylko aparat moby jest obsługiwany w środowisku produkcyjnym. Inne aparaty kontenerów, takie jak Docker, współpracują z usługą IoT Edge i można używać tych aparatów do opracowywania. Aparat moby można redystrybuować w przypadku użycia z usługą Azure IoT Edge, a firma Microsoft zapewnia obsługę tego aparatu.

Wybieranie protokołu nadrzędnego

Można skonfigurować protokół (który określa używany port) na potrzeby komunikacji nadrzędnej z usługą IoT Hub zarówno dla agenta usługi IoT Edge, jak i centrum usługi IoT Edge. Domyślny protokół to AMQP, ale można to zmienić w zależności od konfiguracji sieci.

Oba moduły środowiska uruchomieniowego mają zmienną środowiskową UpstreamProtocol . Prawidłowe wartości dla zmiennej to:

  • MQTT
  • AMQP
  • MQTTWS
  • AMQPWS

Skonfiguruj zmienną UpstreamProtocol dla agenta usługi IoT Edge w pliku konfiguracji na samym urządzeniu. Jeśli na przykład urządzenie usługi IoT Edge znajduje się za serwerem proxy, który blokuje porty protokołu AMQP, może być konieczne skonfigurowanie agenta usługi IoT Edge do korzystania z protokołu AMQP za pośrednictwem protokołu WebSocket (AMQPWS) w celu nawiązania początkowego połączenia z usługą IoT Hub.

Po nawiązaniu połączenia urządzenia usługi IoT Edge należy kontynuować konfigurowanie zmiennej UpstreamProtocol dla obu modułów środowiska uruchomieniowego w przyszłych wdrożeniach. Przykład tego procesu znajduje się w temacie Konfigurowanie urządzenia usługi IoT Edge w celu komunikowania się za pośrednictwem serwera proxy.

Wdrożenie

  • Przydatne
    • Zachowaj spójność z protokołem nadrzędnym
    • Konfigurowanie magazynu hostów dla modułów systemowych
    • Zmniejszenie ilości miejsca na pamięć używanego przez centrum usługi IoT Edge
    • Używanie poprawnych obrazów modułów w manifestach wdrażania
    • Należy pamiętać o limitach rozmiaru bliźniaczych reprezentacji podczas korzystania z modułów niestandardowych
    • Konfigurowanie sposobu stosowania aktualizacji modułów

Zachowaj spójność z protokołem nadrzędnym

Jeśli agent usługi IoT Edge skonfigurowano na urządzeniu usługi IoT Edge do używania innego protokołu niż domyślny protokół AMQP, należy zadeklarować ten sam protokół we wszystkich przyszłych wdrożeniach. Jeśli na przykład urządzenie usługi IoT Edge znajduje się za serwerem proxy, który blokuje porty protokołu AMQP, prawdopodobnie skonfigurowano urządzenie do łączenia się za pośrednictwem protokołu AMQP za pośrednictwem protokołu WebSocket (AMQPWS). Podczas wdrażania modułów na urządzeniu należy skonfigurować ten sam protokół AMQPWS dla agenta usługi IoT Edge i centrum usługi IoT Edge. W przeciwnym razie domyślny protokół AMQP zastąpi ustawienia i uniemożliwi ponowne nawiązanie połączenia.

Wystarczy skonfigurować zmienną środowiskową UpstreamProtocol dla agenta usługi IoT Edge i modułów centrum usługi IoT Edge. Wszystkie dodatkowe moduły przyjmują dowolny protokół ustawiony w modułach środowiska uruchomieniowego.

Przykład tego procesu znajduje się w temacie Konfigurowanie urządzenia usługi IoT Edge w celu komunikowania się za pośrednictwem serwera proxy.

Konfigurowanie magazynu hostów dla modułów systemowych

Moduły centrum i agenta usługi IoT Edge używają magazynu lokalnego do obsługi stanu i włączania obsługi komunikatów między modułami, urządzeniami i chmurą. Aby uzyskać lepszą niezawodność i wydajność, skonfiguruj moduły systemowe do używania magazynu w systemie plików hosta.

Aby uzyskać więcej informacji, zobacz Host storage for system modules (Magazyn hostów dla modułów systemowych).

Zmniejszanie ilości miejsca na pamięć używanego przez centrum usługi IoT Edge

Jeśli wdrażasz ograniczone urządzenia z ograniczoną ilością dostępnej pamięci, możesz skonfigurować centrum usługi IoT Edge do uruchamiania w bardziej usprawnionej pojemności i używać mniej miejsca na dysku. Te konfiguracje ograniczają jednak wydajność centrum usługi IoT Edge, dlatego można znaleźć właściwą równowagę, która działa dla twojego rozwiązania.

Nie optymalizuj pod kątem wydajności na ograniczonych urządzeniach

Centrum usługi IoT Edge jest domyślnie zoptymalizowane pod kątem wydajności, dlatego próbuje przydzielić duże fragmenty pamięci. Ta konfiguracja może powodować problemy ze stabilnością na mniejszych urządzeniach, takich jak Raspberry Pi. Jeśli wdrażasz urządzenia z ograniczonymi zasobami, możesz ustawić zmienną środowiskową OptimizeForPerformance na wartość false w centrum usługi IoT Edge.

Gdy parametr OptimizeForPerformance ma wartość true, nagłówek protokołu MQTT używa klasy PooledByteBufferAllocator, który ma lepszą wydajność, ale przydziela więcej pamięci. Alokator nie działa dobrze w 32-bitowych systemach operacyjnych ani na urządzeniach z małą ilością pamięci. Ponadto w przypadku optymalizacji pod kątem wydajności baza Danych RocksDb przydziela więcej pamięci dla swojej roli jako lokalnego dostawcy magazynu.

Aby uzyskać więcej informacji, zobacz Problemy ze stabilnością na mniejszych urządzeniach.

Wyłączanie nieużywanych protokołów

Innym sposobem optymalizacji wydajności centrum usługi IoT Edge i zmniejszenia użycia pamięci jest wyłączenie głowic protokołów dla wszystkich protokołów, których nie używasz w rozwiązaniu.

Głowy protokołów są konfigurowane przez ustawienie zmiennych środowiskowych logicznych dla modułu centrum usługi IoT Edge w manifestach wdrażania. Trzy zmienne to:

  • amqp Ustawienia__enabled
  • mqtt Ustawienia__enabled
  • http Ustawienia__enabled

Wszystkie trzy zmienne mają dwa podkreślenia i można ustawić na wartość true lub false.

Skrócenie czasu przechowywania komunikatów

Moduł centrum usługi IoT Edge tymczasowo przechowuje komunikaty, jeśli nie mogą być dostarczane do usługi IoT Hub z jakiegokolwiek powodu. Możesz skonfigurować, jak długo centrum usługi IoT Edge będzie przechowywane w celu niedostarczenia komunikatów przed ich wygaśnięciem. Jeśli masz problemy z pamięcią na urządzeniu, możesz zmniejszyć wartość timeToLiveSecs w bliźniaczej reprezentacji modułu usługi IoT Edge.

Wartość domyślna parametru timeToLiveSecs wynosi 7200 sekund, czyli dwie godziny.

Używanie poprawnych obrazów modułów w manifestach wdrażania

Jeśli jest używany pusty lub nieprawidłowy obraz modułu, agent usługi Edge ponawia próbę załadowania obrazu, co powoduje wygenerowanie dodatkowego ruchu. Dodaj poprawne obrazy do manifestu wdrożenia, aby uniknąć generowania niepotrzebnego ruchu.

Nie używaj wersji debugowania obrazów modułów

Podczas przechodzenia ze scenariuszy testowych do scenariuszy produkcyjnych pamiętaj, aby usunąć konfiguracje debugowania z manifestów wdrożenia. Sprawdź, czy żaden z obrazów modułów w manifestach wdrażania nie ma sufiksu debugowania . Jeśli dodano opcje tworzenia w celu uwidocznienia portów w modułach na potrzeby debugowania, usuń te opcje tworzenia.

Należy pamiętać o limitach rozmiaru bliźniaczych reprezentacji podczas korzystania z modułów niestandardowych

Manifest wdrożenia zawierający moduły niestandardowe jest częścią bliźniaczej reprezentacji usługi EdgeAgent. Przejrzyj ograniczenie dotyczące rozmiaru bliźniaczej reprezentacji modułu.

Jeśli wdrożysz dużą liczbę modułów, możesz wyczerpać ten limit rozmiaru bliźniaczej reprezentacji. Rozważ niektóre typowe środki zaradcze dla tego twardego limitu:

  • Zapisz dowolną konfigurację w bliźniaczej reprezentacji modułu niestandardowego, która ma własny limit.
  • Przechowuj konfigurację wskazującą lokalizację nieopartą na przestrzeni (czyli do magazynu obiektów blob).

Konfigurowanie sposobu stosowania aktualizacji modułów

Po zaktualizowaniu wdrożenia agent usługi Edge otrzymuje nową konfigurację jako aktualizację bliźniaczej reprezentacji. Jeśli nowa konfiguracja ma nowe lub zaktualizowane obrazy modułów, domyślnie program Edge Agent sekwencyjnie przetwarza każdy moduł:

  1. Zaktualizowany obraz jest pobierany
  2. Uruchomiony moduł jest zatrzymany
  3. Uruchomiono nowe wystąpienie modułu
  4. Następna aktualizacja modułu jest przetwarzana

W niektórych przypadkach, na przykład gdy istnieją zależności między modułami, warto najpierw pobrać wszystkie zaktualizowane obrazy modułów przed ponownym uruchomieniem wszystkich uruchomionych modułów. To zachowanie aktualizacji modułu można skonfigurować, ustawiając zmienną środowiskową ModuleUpdateMode agenta usługi IoT Edge na wartość WaitForAllPullsciągu . Aby uzyskać więcej informacji, zobacz Zmienne środowiskowe usługi IoT Edge.

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

Zarządzanie kontenerami

  • Ważny
    • Zarządzanie wersjami przy użyciu tagów
    • Zarządzanie woluminami
  • Przydatne
    • Przechowywanie kontenerów środowiska uruchomieniowego w rejestrze prywatnym
    • Konfigurowanie odzyskiwania pamięci obrazu

Zarządzanie wersjami przy użyciu tagów

Tag to koncepcja platformy Docker, której można użyć do rozróżnienia między wersjami kontenerów platformy Docker. Tagi to sufiksy, takie jak 1.1 , które przechodzą na końcu repozytorium kontenerów. Na przykład mcr.microsoft.com/azureiotedge-agent:1.1. Tagi są modyfikowalne i mogą być zmieniane tak, aby wskazywały inny kontener w dowolnym momencie, więc zespół powinien uzgodnić konwencję, która będzie zgodna podczas aktualizowania obrazów modułów w przyszłości.

Tagi ułatwiają również wymuszanie aktualizacji na urządzeniach usługi IoT Edge. Po wypchnięciu zaktualizowanej wersji modułu do rejestru kontenerów zwiększ tag. Następnie wypchnij nowe wdrożenie do urządzeń z tagiem przyrostowym. Aparat kontenera rozpozna tag przyrostowy jako nową wersję i pobierze najnowszą wersję modułu na urządzenie.

Tagi środowiska uruchomieniowego usługi IoT Edge

Obrazy agenta usługi IoT Edge i centrum usługi IoT Edge są oznaczane wersją usługi IoT Edge, z którą są skojarzone. Istnieją dwa różne sposoby używania tagów z obrazami środowiska uruchomieniowego:

  • Tagi stopniowe — użyj tylko dwóch pierwszych wartości numeru wersji, aby uzyskać najnowszy obraz zgodny z tymi cyframi. Na przykład wersja 1.1 jest aktualizowana za każdym razem, gdy jest dostępna nowa wersja, aby wskazywała najnowszą wersję 1.1.x. Jeśli środowisko uruchomieniowe kontenera na urządzeniu usługi IoT Edge ponownie ściągnie obraz, moduły środowiska uruchomieniowego zostaną zaktualizowane do najnowszej wersji. Wdrożenia z witryny Azure Portal domyślnie są tagami kroczącymi. Takie podejście jest sugerowane do celów programistycznych.

  • Określone tagi — użyj wszystkich trzech wartości numeru wersji, aby jawnie ustawić wersję obrazu. Na przykład wersja 1.1.0 nie zmieni się po jej początkowej wersji. Możesz zadeklarować nowy numer wersji w manifeście wdrożenia, gdy wszystko będzie gotowe do aktualizacji. Takie podejście jest sugerowane do celów produkcyjnych.

Zarządzanie woluminami

Usługa IoT Edge nie usuwa woluminów dołączonych do kontenerów modułów. Takie zachowanie jest celowe, ponieważ umożliwia utrwalanie danych między wystąpieniami kontenerów, na przykład w scenariuszach uaktualniania. Jeśli jednak te woluminy pozostają nieużywane, może to prowadzić do wyczerpania miejsca na dysku, a następnie błędów systemu. Jeśli w twoim scenariuszu używasz woluminów platformy Docker, zachęcamy do używania narzędzi platformy Docker, takich jak narzędzie docker volume prune i docker volume rm w celu usunięcia nieużywanych woluminów, szczególnie w przypadku scenariuszy produkcyjnych.

Przechowywanie kontenerów środowiska uruchomieniowego w rejestrze prywatnym

Wiesz, jak przechowywać obrazy kontenerów dla niestandardowych modułów kodu w prywatnym rejestrze platformy Azure, ale można go również używać do przechowywania publicznych obrazów kontenerów, takich jak moduły edgeAgent i edgeHub runtime. Może to być wymagane, jeśli masz bardzo ścisłe ograniczenia zapory, ponieważ te kontenery środowiska uruchomieniowego są przechowywane w usłudze Microsoft Container Registry (MCR).

W poniższych krokach pokazano, jak ściągnąć obraz platformy Docker edgeAgent i edgeHub na maszynę lokalną, zatagować go ponownie, wypchnąć go do rejestru prywatnego, a następnie zaktualizować plik konfiguracji, aby urządzenia wiedziały, aby ściągnąć obraz z rejestru prywatnego.

  1. Pobierz obraz edgeAgent platformy Docker z rejestru firmy Microsoft. W razie potrzeby zaktualizuj numer wersji.

    # Pull edgeAgent image
    docker pull mcr.microsoft.com/azureiotedge-agent:1.4
    
    # Pull edgeHub image
    docker pull mcr.microsoft.com/azureiotedge-hub:1.4
    
  2. Wyświetl listę wszystkich obrazów platformy Docker, znajdź obrazy edgeAgent i edgeHub , a następnie skopiuj ich identyfikatory obrazów.

    docker images
    
  3. Ponownie zataguj obrazy edgeAgent i edgeHub . Zastąp wartości w nawiasach własnymi.

    # Retag your edgeAgent image
    docker tag <my-image-id> <registry-name/server>/azureiotedge-agent:1.4
    
    # Retag your edgeHub image
    docker tag <my-image-id> <registry-name/server>/azureiotedge-hub:1.4
    
  4. Wypchnij obrazy edgeAgent i edgeHub do rejestru prywatnego. Zastąp wartość w nawiasach własnymi.

    # Push your edgeAgent image to your private registry
    docker push <registry-name/server>/azureiotedge-agent:1.4
    
    # Push your edgeHub image to your private registry
    docker push <registry-name/server>/azureiotedge-hub:1.4
    
  5. Zaktualizuj odwołania do obrazu w pliku deployment.template.json dla modułów systemowych edgeAgent i edgeHub , zastępując mcr.microsoft.com ciąg własnymi "nazwa rejestru/serwer" dla obu modułów.

  6. Otwórz edytor tekstów na urządzeniu usługi IoT Edge, aby zmienić plik konfiguracji, aby wiedział o prywatnym obrazie rejestru.

    sudo nano /etc/aziot/config.toml
    
  7. W edytorze tekstów zmień wartości obrazu w obszarze [agent.config]. Zastąp wartości w nawiasach własnymi.

    [agent.config]
    image = "<registry-name/server>/azureiotedge-agent:1.4"
    
  8. Jeśli rejestr prywatny wymaga uwierzytelniania, ustaw parametry uwierzytelniania w pliku [agent.config.auth].

    [agent.config.auth]
    serveraddress = "<login-server>" # Almost always equivalent to <registry-name/server>
    username = "<username>"
    password = "<password>"
    
  9. Zapisz zmiany i zamknij edytor tekstów.

  10. Zastosuj zmianę konfiguracji usługi IoT Edge.

    sudo iotedge config apply
    

    Środowisko uruchomieniowe usługi IoT Edge zostanie uruchomione ponownie.

Aby uzyskać więcej informacji, zobacz:

Konfigurowanie odzyskiwania pamięci obrazu

Odzyskiwanie pamięci obrazu to funkcja w usłudze IoT Edge w wersji 1.4 lub nowszej, która automatycznie czyści obrazy platformy Docker, które nie są już używane przez moduły usługi IoT Edge. Usuwa tylko obrazy platformy Docker, które zostały pobrane przez środowisko uruchomieniowe usługi IoT Edge w ramach wdrożenia. Usunięcie nieużywanych obrazów platformy Docker pomaga zaoszczędzić miejsce na dysku.

Funkcja jest implementowana w składniku hosta usługi IoT Edge, aziot-edged usłudze i domyślnie włączonej. Oczyszczanie odbywa się codziennie o północy (czas lokalny urządzenia) i usuwa nieużywane obrazy platformy Docker, które były ostatnio używane siedem dni temu. Parametry do kontrolowania zachowania oczyszczania są ustawione w sekcji config.toml i wyjaśnione w dalszej części tej sekcji. Jeśli parametry nie są określone w pliku konfiguracji, zostaną zastosowane wartości domyślne.

Na przykład poniżej przedstawiono sekcję config.toml odzyskiwania pamięci obrazu przy użyciu wartości domyślnych:

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

W poniższej tabeli opisano parametry odzyskiwania pamięci obrazu. Wszystkie parametry są opcjonalne i można je ustawić indywidualnie, aby zmienić ustawienia domyślne.

Parametr opis Wymagania Domyślna wartość
enabled Włącza odzyskiwanie pamięci obrazu. Możesz wyłączyć tę funkcję, zmieniając to ustawienie na false. Opcjonalnie prawda
cleanup_recurrence Określa częstotliwość cyklu zadania oczyszczania. Musi być określona jako wiele dni i nie może być mniejsza niż jeden dzień.

Na przykład: 1d, 2d, 6d itp.
Opcjonalnie 1 dzień
image_age_cleanup_threshold Definiuje minimalny próg wieku nieużywanych obrazów przed rozważeniem czyszczenia i musi być określony w dniach. Możesz określić wartość 0d , aby wyczyścić obrazy zaraz po ich usunięciu z wdrożenia.

Obrazy są uznawane za nieużywane po usunięciu ich z wdrożenia.
Opcjonalnie 7 dni
cleanup_time Godzina dnia, w czasie lokalnym urządzenia, kiedy zadanie oczyszczania jest uruchamiane. Musi być w formacie 24-godzinnym HH:MM. Opcjonalnie 00:00

Sieć

  • Przydatne
    • Przeglądanie konfiguracji ruchu wychodzącego/przychodzącego
    • Zezwalaj na połączenia z urządzeń usługi IoT Edge
    • Konfigurowanie komunikacji za pośrednictwem serwera proxy
    • Ustawianie serwera DNS w ustawieniach aparatu kontenera

Przeglądanie konfiguracji ruchu wychodzącego/przychodzącego

Kanały komunikacyjne między usługą Azure IoT Hub i usługą IoT Edge są zawsze skonfigurowane do obsługi ruchu wychodzącego. W przypadku większości scenariuszy usługi IoT Edge niezbędne są tylko trzy połączenia. Aparat kontenera musi nawiązać połączenie z rejestrem kontenerów (lub rejestrami), które przechowuje obrazy modułu. Środowisko uruchomieniowe usługi IoT Edge musi nawiązać połączenie z usługą IoT Hub w celu pobrania informacji o konfiguracji urządzenia oraz wysyłania komunikatów i danych telemetrycznych. Jeśli używasz automatycznej aprowizacji, usługa IoT Edge musi nawiązać połączenie z usługą Device Provisioning Service. Aby uzyskać więcej informacji, zobacz Zapora i reguły konfiguracji portów.

Zezwalaj na połączenia z urządzeń usługi IoT Edge

Jeśli konfiguracja sieci wymaga jawnego zezwolenia na połączenia z urządzeń usługi IoT Edge, zapoznaj się z następującą listą składników usługi IoT Edge:

  • Agent usługi IoT Edge otwiera trwałe połączenie AMQP/MQTT z usługą IoT Hub, prawdopodobnie za pośrednictwem obiektów WebSocket.
  • Centrum usługi IoT Edge otwiera jedno trwałe połączenie AMQP lub wiele połączeń MQTT z usługą IoT Hub, prawdopodobnie za pośrednictwem obiektów WebSocket.
  • Usługa IoT Edge wykonuje sporadyczne wywołania HTTPS do usługi IoT Hub.

We wszystkich trzech przypadkach w pełni kwalifikowana nazwa domeny (FQDN) będzie zgodna ze wzorcem \*.azure-devices.net.

Rejestry kontenerów

Aparat kontenera wykonuje wywołania rejestrów kontenerów za pośrednictwem protokołu HTTPS. Aby pobrać obrazy kontenera środowiska uruchomieniowego usługi IoT Edge, nazwa FQDN to mcr.microsoft.com. Aparat kontenera łączy się z innymi rejestrami zgodnie z konfiguracją we wdrożeniu.

Ta lista kontrolna jest punktem wyjścia dla reguł zapory:

Nazwa FQDN (* = symbol wieloznaczny) Wychodzące porty TCP Sposób użycia
mcr.microsoft.com 443 Microsoft Container Registry
*.data.mcr.microsoft.com 443 Punkt końcowy danych zapewniający dostarczanie zawartości
*.cdn.azcr.io 443 Wdrażanie modułów z witryny Marketplace na urządzeniach
global.azure-devices-provisioning.net 443 Dostęp do usługi Device Provisioning Service (opcjonalnie)
*.azurecr.io 443 Osobiste i inne rejestry kontenerów
*.blob.core.windows.net 443 Pobieranie różnic obrazów usługi Azure Container Registry z magazynu obiektów blob
*.azure-devices.net 5671, 8883, 4431 Dostęp do usługi IoT Hub
*.docker.io 443 Dostęp do usługi Docker Hub (opcjonalnie)

1Otwórz port 8883 na potrzeby bezpiecznego protokołu MQTT lub portu 5671 w celu zapewnienia bezpiecznego protokołu AMQP. Jeśli połączenia można nawiązać tylko za pośrednictwem portu 443, jeden z tych protokołów może być uruchamiany za pośrednictwem tunelu Protokołu WebSocket.

Ponieważ adres IP centrum IoT może ulec zmianie bez powiadomienia, zawsze używaj nazwy FQDN do konfiguracji listy dozwolonych. Aby dowiedzieć się więcej, zobacz Opis adresu IP usługi IoT Hub.

Niektóre z tych reguł zapory są dziedziczone z usługi Azure Container Registry. Aby uzyskać więcej informacji, zobacz Konfigurowanie reguł dostępu do rejestru kontenerów platformy Azure za zaporą.

Możesz włączyć dedykowane punkty końcowe danych w rejestrze kontenerów platformy Azure, aby uniknąć wieloznacznych dozwolonych nazw FQDN *.blob.core.windows.net . Aby uzyskać więcej informacji, zobacz Włączanie dedykowanych punktów końcowych danych.

Uwaga

Aby zapewnić spójną nazwę FQDN między punktami końcowymi REST i danych, począwszy od 15 czerwca 2020 r. punkt końcowy danych usługi Microsoft Container Registry zmieni się z *.cdn.mscr.io na *.data.mcr.microsoft.com
Aby uzyskać więcej informacji, zobacz Konfiguracja reguł zapory klienta usługi Microsoft Container Registry

Jeśli nie chcesz konfigurować zapory, aby zezwolić na dostęp do publicznych rejestrów kontenerów, możesz przechowywać obrazy w prywatnym rejestrze kontenerów zgodnie z opisem w artykule Przechowywanie kontenerów środowiska uruchomieniowego w rejestrze prywatnym.

Azure IoT Identity Service

Usługa IoT Identity Service udostępnia usługi aprowizacji i usług kryptograficznych dla urządzeń Azure IoT. Usługa tożsamości sprawdza, czy zainstalowana wersja jest najnowszą wersją. Sprawdzanie używa następujących nazw FQDN do zweryfikowania wersji.

Nazwa FQDN Wychodzące porty TCP Sposób użycia
aka.ms 443 Adres URL vanity, który zapewnia przekierowanie do pliku wersji
raw.githubusercontent.com 443 Plik wersji usługi tożsamości hostowany w usłudze GitHub

Konfigurowanie komunikacji za pośrednictwem serwera proxy

Jeśli urządzenia zostaną wdrożone w sieci korzystającej z serwera proxy, muszą być w stanie komunikować się za pośrednictwem serwera proxy w celu uzyskania dostępu do usługi IoT Hub i rejestrów kontenerów. Aby uzyskać więcej informacji, zobacz Konfigurowanie urządzenia usługi IoT Edge pod kątem komunikacji za pośrednictwem serwera proxy.

Ustawianie serwera DNS w ustawieniach aparatu kontenera

Określ serwer DNS dla środowiska w ustawieniach aparatu kontenera. Ustawienie serwera DNS dotyczy wszystkich modułów kontenera uruchomionych przez aparat.

  1. W katalogu na urządzeniu /etc/docker zmodyfikuj daemon.json plik. Utwórz plik, jeśli nie istnieje.

  2. Dodaj klucz DNS i ustaw adres serwera DNS na publicznie dostępną usługę DNS. Jeśli urządzenie brzegowe nie może uzyskać dostępu do publicznego serwera DNS, użyj dostępnego adresu serwera DNS w sieci. Na przykład:

    {
        "dns": ["1.1.1.1"]
    }
    

Zarządzanie rozwiązaniami

  • Przydatne
    • Konfigurowanie dzienników i diagnostyki
    • Konfigurowanie domyślnego sterownika rejestrowania
    • Rozważ testy i potoki ciągłej integracji/ciągłego wdrażania

Konfigurowanie dzienników i diagnostyki

W systemie Linux demon usługi IoT Edge używa dzienników jako domyślnego sterownika rejestrowania. Narzędzie wiersza journalctl polecenia umożliwia wykonywanie zapytań dotyczących dzienników demona.

Począwszy od wersji 1.2, usługa IoT Edge opiera się na wielu demonach. Chociaż dzienniki każdego demona mogą być indywidualnie odpytywane za pomocą journalctlpolecenia , iotedge system polecenia zapewniają wygodny sposób wykonywania zapytań dotyczących połączonych dzienników.

  • iotedge Skonsolidowane polecenie:

    sudo iotedge system logs
    
  • Równoważne journalctl polecenie:

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

Podczas testowania wdrożenia usługi IoT Edge zwykle można uzyskać dostęp do urządzeń w celu pobrania dzienników i rozwiązywania problemów. W scenariuszu wdrażania może nie być dostępna ta opcja. Rozważ sposób zbierania informacji o urządzeniach w środowisku produkcyjnym. Jedną z opcji jest użycie modułu rejestrowania, który zbiera informacje z innych modułów i wysyła je do chmury. Jednym z przykładów modułu rejestrowania jest logspout-loganalytics lub możesz zaprojektować własne.

Konfigurowanie domyślnego sterownika rejestrowania

Domyślnie aparat kontenerów Moby nie ustawia limitów rozmiaru dziennika kontenera. Po pewnym czasie może to prowadzić do zapełnienia urządzenia dziennikami i wyczerpania miejsca na dysku. Skonfiguruj aparat kontenera tak, aby używał sterownika rejestrowania local jako mechanizmu rejestrowania. Local Sterownik rejestrowania oferuje domyślny limit rozmiaru dziennika, domyślnie wykonuje rotację dziennika i używa bardziej wydajnego formatu pliku, co pomaga zapobiec wyczerpaniu miejsca na dysku. Możesz również użyć różnych sterowników rejestrowania i ustawić różne limity rozmiaru w zależności od potrzeb.

Opcja: Skonfiguruj domyślny sterownik rejestrowania dla wszystkich modułów kontenera

Aparat kontenera można skonfigurować tak, aby używał określonego sterownika rejestrowania, ustawiając wartość log driver na nazwę sterownika dziennika w pliku daemon.json. Poniższy przykład ustawia domyślny sterownik rejestrowania na local sterownik dziennika (zalecane).

{
    "log-driver": "local"
}

Możesz również skonfigurować log-opts klucze tak, aby używały odpowiednich wartości w daemon.json pliku. Poniższy przykład ustawia sterownik dziennika na local i ustawia max-size opcje i max-file .

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

Dodaj (lub dołącz) te informacje do pliku o nazwie daemon.json i umieść je w następującej lokalizacji:

  • /etc/docker/

Aby zmiany zaczęły obowiązywać, należy ponownie uruchomić aparat kontenera.

Opcja: Dostosowywanie ustawień dziennika dla każdego modułu kontenera

Można to zrobić w obszarze createOptions każdego modułu. Na przykład:

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

Dodatkowe opcje w systemach Linux

  • Skonfiguruj aparat kontenera, aby wysyłał dzienniki do systemddziennika , ustawiając journald jako domyślny sterownik rejestrowania.

  • Okresowo usuwaj stare dzienniki z urządzenia, instalując narzędzie logrotate. Użyj następującej specyfikacji pliku:

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

Rozważ testy i potoki ciągłej integracji/ciągłego wdrażania

W przypadku najbardziej wydajnego scenariusza wdrażania usługi IoT Edge rozważ zintegrowanie wdrożenia produkcyjnego z potokami testowania i ciągłej integracji/ciągłego wdrażania. Usługa Azure IoT Edge obsługuje wiele platform ciągłej integracji/ciągłego wdrażania, w tym usługę Azure DevOps. Aby uzyskać więcej informacji, zobacz Ciągła integracja i ciągłe wdrażanie w usłudze Azure IoT Edge.

Zagadnienia dotyczące zabezpieczeń

  • Ważny
    • Zarządzanie dostępem do rejestru kontenerów
    • Ograniczanie dostępu kontenera do zasobów hosta

Zarządzanie dostępem do rejestru kontenerów

Przed wdrożeniem modułów na urządzeniach usługi IoT Edge w środowisku produkcyjnym upewnij się, że masz kontrolę dostępu do rejestru kontenerów, aby osoby zewnętrzne nie mogły uzyskać dostępu do obrazów kontenerów ani wprowadzić ich zmian. Zarządzanie obrazami kontenerów przy użyciu prywatnego rejestru kontenerów.

W samouczkach i innych dokumentach poinstruujemy Cię, aby używać tych samych poświadczeń rejestru kontenerów na urządzeniu usługi IoT Edge, które jest używane na komputerze deweloperskim. Te instrukcje są przeznaczone tylko do ułatwienia konfigurowania środowisk testowych i programistycznych i nie powinny być przestrzegane w scenariuszu produkcyjnym.

Aby uzyskać bardziej bezpieczny dostęp do rejestru, możesz wybrać opcje uwierzytelniania. Popularne i zalecane uwierzytelnianie polega na użyciu jednostki usługi Active Directory, która jest odpowiednia dla aplikacji lub usług do ściągania obrazów kontenerów w sposób zautomatyzowany lub w inny sposób nienadzorowany (bez użycia głowy), jak robią urządzenia usługi IoT Edge. Inną opcją jest użycie tokenów o zakresie repozytorium, które umożliwiają tworzenie długich lub krótkich tożsamości istniejących tylko w usłudze Azure Container Registry, w których zostały utworzone, oraz dostęp do zakresu do poziomu repozytorium.

Aby utworzyć jednostkę usługi, uruchom dwa skrypty zgodnie z opisem w artykule Tworzenie jednostki usługi. Te skrypty wykonują następujące zadania:

  • Pierwszy skrypt tworzy jednostkę usługi. Zwraca on identyfikator jednostki usługi i hasło jednostki usługi. Bezpieczne przechowywanie tych wartości w rekordach.

  • Drugi skrypt tworzy przypisania ról w celu udzielenia jednostce usługi, które można następnie uruchomić w razie potrzeby. Zalecamy zastosowanie roli użytkownika acrPull dla parametru role . Aby uzyskać listę ról, zobacz Role i uprawnienia usługi Azure Container Registry.

Aby uwierzytelnić się przy użyciu jednostki usługi, podaj identyfikator jednostki usługi i hasło uzyskane z pierwszego skryptu. Określ te poświadczenia w manifeście wdrożenia.

  • Dla nazwy użytkownika lub identyfikatora klienta określ identyfikator jednostki usługi.

  • W przypadku hasła lub klucza tajnego klienta określ hasło jednostki usługi.


Aby utworzyć tokeny o zakresie repozytorium, postępuj zgodnie z instrukcjami tworzenia tokenu o zakresie repozytorium.

Aby uwierzytelnić się przy użyciu tokenów o zakresie repozytorium, podaj nazwę tokenu i hasło uzyskane po utworzeniu tokenu o zakresie repozytorium. Określ te poświadczenia w manifeście wdrożenia.

  • W polu nazwa użytkownika określ nazwę użytkownika tokenu.

  • W przypadku hasła określ jedno z haseł tokenu.

Uwaga

Po zaimplementowaniu rozszerzonego uwierzytelniania zabezpieczeń wyłącz ustawienie użytkownika Administracja, aby domyślny dostęp do nazwy użytkownika/hasła nie był już dostępny. W rejestrze kontenerów w witrynie Azure Portal w menu po lewej stronie w obszarze Ustawienia wybierz pozycję Klucze dostępu.

Ograniczanie dostępu kontenera do zasobów hosta

Aby równoważyć współużytkowane zasoby hosta między modułami, zalecamy wprowadzenie limitów użycia zasobów na moduł. Te limity zapewniają, że jeden moduł nie może zużywać zbyt dużej ilości pamięci ani czasu procesora CPU, i zapobiegają uruchamianiu innych procesów na urządzeniu. Platforma IoT Edge domyślnie nie ogranicza zasobów dla modułów, ponieważ wiedza o tym, ile zasobów dany moduł potrzebuje uruchomić do optymalnego działania, wymaga testowania.

Platforma Docker udostępnia pewne ograniczenia, których można użyć do ograniczania zasobów, takich jak użycie pamięci i procesora CPU. Aby uzyskać więcej informacji, zobacz Opcje środowiska uruchomieniowego z pamięcią, procesorami CPU i procesorami GPU.

Te ograniczenia można zastosować do poszczególnych modułów przy użyciu opcji tworzenia w manifestach wdrażania. Aby uzyskać więcej informacji, zobacz How to configure container create options for IoT Edge modules (Jak skonfigurować opcje tworzenia kontenera dla modułów usługi IoT Edge).

Następne kroki