Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy: IoT Edge 1.5
Ważne
Obsługiwana wersja usługi IoT Edge 1.5 LTS. Usługa IoT Edge 1.4 LTS kończy się od 12 listopada 2024 r. Jeśli korzystasz z wcześniejszej wersji, zobacz aktualizację Azure IoT Edge.
Gdy będziesz gotowy do wdrożenia rozwiązania IoT Edge z fazy programowania do środowiska produkcyjnego, upewnij się, że jest ono skonfigurowane dla zapewnienia ciągłej wydajności.
Nie wszystkie informacje zawarte w tym artykule są równie ważne. Aby ułatwić ustalanie priorytetów, każda sekcja rozpoczyna się listami, które dzielą pracę na dwie grupy: ważne, które należy ukończyć przed wejściem na produkcję, oraz warto wiedzieć.
Konfiguracja urządzenia
Urządzenia usługi IoT Edge mogą pochodzić z urządzenia Raspberry Pi do laptopa lub maszyny wirtualnej działającej na serwerze. Dostęp do urządzenia można uzyskać fizycznie lub za pośrednictwem połączenia wirtualnego lub można go odizolować przez dłuższy czas. W obu przypadkach upewnij się, że została skonfigurowana do odpowiedniego działania.
Ważny
- Instalowanie certyfikatów produkcyjnych
- Posiadanie planu zarządzania urządzeniami
- Użyj narzędzia Moby jako aparatu kontenera. Jeśli używasz przystawek Ubuntu Core, przystawka Docker jest serwisowana przez firmę Canonical i wspierana w scenariuszach produkcyjnych.
Pomocny
- 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. Na potrzeby programowania i testowania środowisko uruchomieniowe usługi IoT Edge tworzy certyfikaty tymczasowe, jeśli w pliku konfiguracji nie są deklarowane żadne certyfikaty. Te certyfikaty tymczasowe wygasają jednak po trzech miesiącach i nie są bezpieczne w przypadku scenariuszy produkcyjnych. W przypadku scenariuszy produkcyjnych podaj własny certyfikat CA Edge, czy to z podpisem własnym, czy kupiony od komercyjnego urzędu certyfikacji.
Aby zrozumieć rolę certyfikatu urzędu certyfikacji usługi Edge, zobacz Jak usługa Azure IoT Edge używa certyfikatów.
Aby uzyskać więcej informacji na temat instalowania certyfikatów na urządzeniu usługi IoT Edge i odwoływania 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 rozważyć sposób zarządzania 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
Device Update for IoT Hub to usługa, która umożliwia wdrażanie aktualizacji OTA dla urządzeń IoT Edge.
Inne sposoby 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.
Aparat kontenera
Silnik kontenerowy jest wymagany dla każdego urządzenia IoT Edge. Aparat moby jest obsługiwany w środowisku produkcyjnym. Jeśli używasz przystawek Ubuntu Core, przystawka Docker jest serwisowana przez firmę Canonical i wspierana w scenariuszach produkcyjnych. Inne silniki kontenerów, takie jak Docker, współpracują z IoT Edge i dobrze jest używać tych silników do tworzenia. 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:
- protokół komunikacyjny MQTT
- AMQP (Protokół przesyłania danych asynchronicznych)
- 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 z urządzeniem usługi IoT Edge kontynuuj konfigurowanie zmiennej UpstreamProtocol dla obu modułów środowiska uruchomieniowego w przyszłych wdrożeniach. Na przykład, zapoznaj się z Konfigurowaniem urządzenia IoT Edge w celu komunikacji za pośrednictwem serwera proxy.
Wdrożenie
-
Pomocny
- 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 lub w przeciwnym razie domyślna usługa AMQP zastępuje ustawienia i uniemożliwia ponowne nawiązywanie 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:
- amqpUstawienia__włączone
- mqttSettings__enabled
- httpSettings__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ł:
- Zaktualizowany obraz jest pobierany
- Uruchomiony moduł jest zatrzymany
- Uruchomiono nowe wystąpienie modułu
- 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ść WaitForAllPulls
cią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
-
Pomocny
- 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.5 , które przechodzą na końcu repozytorium kontenerów. Na przykład mcr.microsoft.com/azureiotedge-agent:1.5. 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 rozpoznaje tag przyrostowy jako nową wersję i ściąga 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.5 jest aktualizowana za każdym razem, gdy jest dostępna nowa wersja wskazująca najnowszą wersję 1.5.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.5.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 ś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.
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.5 # Pull edgeHub image docker pull mcr.microsoft.com/azureiotedge-hub:1.5
Wyświetl listę wszystkich obrazów platformy Docker, znajdź obrazy edgeAgent i edgeHub , a następnie skopiuj ich identyfikatory obrazów.
docker images
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.5 # Retag your edgeHub image docker tag <my-image-id> <registry-name/server>/azureiotedge-hub:1.5
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.5 # Push your edgeHub image to your private registry docker push <registry-name/server>/azureiotedge-hub:1.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.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
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.5"
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>"
Zapisz zmiany i zamknij edytor tekstów.
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ć
-
Pomocny
- 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 | Użycie |
---|---|---|
mcr.microsoft.com |
443 | Rejestr Kontenerów Microsoft |
*.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 | Użycie |
---|---|---|
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.
W katalogu na urządzeniu
/etc/docker
zmodyfikujdaemon.json
plik. Utwórz plik, jeśli nie istnieje.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 adresu serwera DNS dostępnego w sieci. Na przykład:
{ "dns": ["1.1.1.1"] }
Zarządzanie rozwiązaniami
-
Pomocny
- 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. Użyj narzędzia journalctl
wiersza polecenia, aby wysłać zapytanie do dzienników demona.
Począwszy od wersji 1.2, usługa IoT Edge opiera się na wielu demonach. Chociaż można wykonywać zapytania dotyczące dzienników każdego demona indywidualnie za pomocą polecenia journalctl
, użyj poleceń iotedge system
do wykonywania zapytań 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 uzyskujesz 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. Zastanów się, jak zebrać informacje 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. Możesz na przykład użyć logspout-loganalytics lub zaprojektować własne.
Konfigurowanie domyślnego sterownika rejestrowania
Domyślnie silnik kontenerów Moby nie ustawia ograniczeń rozmiaru logów kontenerów. Z czasem może to spowodować wypełnienie urządzenia dziennikami i brakiem miejsca na dysku. Ustaw silnik kontenera tak, aby używał sterownika rejestrowanialocal
jako systemu rejestrowania. Sterownik rejestrowania local
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
Ustaw aparat kontenera 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/
Uruchom ponownie silnik kontenera, aby zmiany zaczęły obowiązywać.
Opcja: Dostosowywanie ustawień dziennika dla każdego modułu kontenera
Ustaw te opcje 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
systemd
dziennika , ustawiającjournald
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
Aby uzyskać najbardziej wydajne wdrożenie IoT Edge, zintegruj wdrożenie w środowisku produkcyjnym z potokami testowania i CI/CD. 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 produkcyjnych urządzeniach usługi IoT Edge 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 zmienić ich. Zarządzanie obrazami kontenerów przy użyciu prywatnego rejestru kontenerów.
W samouczkach i innych dokumentach zalecamy użycie takich samych poświadczeń rejestru kontenerów na urządzeniu IoT Edge jak na maszynie deweloperskiej. Te instrukcje ułatwiają konfigurowanie środowisk testowych i programistycznych i nie są przeznaczone do użytku produkcyjnego.
Aby uzyskać bardziej bezpieczny dostęp do rejestru, wybierz jedną z kilku opcji uwierzytelniania. Użycie jednostki usługi Active Directory jest popularną i zalecaną metodą na automatyczne i nienadzorowane pobieranie obrazów kontenerów, podobnie jak robią to urządzenia IoT Edge. Możesz również użyć tokenów o zakresie repozytorium, które pozwalają na tworzenie tożsamości o długim lub krótkim czasie istnienia, istniejących wyłącznie w ramach Azure Container Registry, gdzie zostały utworzone, i mają dostęp na poziomie repozytorium.
Aby utworzyć jednostkę usługi, uruchom dwa skrypty opisane w artykule Tworzenie jednostki usługi. Te skrypty wykonują następujące czynności:
Pierwszy skrypt tworzy jednostkę usługi. Zawiera 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. Uruchom go następnie w razie potrzeby. Użyj 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 poświadczenia hasła z pierwszego skryptu 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 poświadczenia hasła, które uzyskasz po utworzeniu tokenu o zakresie repozytorium 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żytkownik administracyjny , aby domyślna nazwa użytkownika i dostęp do hasła nie był dostępny. Ustawienie rejestru kontenerów można znaleźć w witrynie Azure Portal, w obszarze Ustawienia wybierz pozycję Klucze dostępu.
Ograniczanie dostępu kontenera do zasobów hosta
Aby zrównoważyć współużytkowane zasoby hosta między modułami, ustaw limity użycia zasobów dla każdego modułu. Te limity pozwalają upewnić się, że jeden moduł nie może używać zbyt dużej ilości pamięci ani procesora CPU i zapobiegać uruchamianiu innych procesów na urządzeniu. Domyślnie platforma IoT Edge nie ogranicza zasobów dla modułów, ponieważ należy przetestować, ile zasobów potrzebuje moduł, aby działać prawidłowo.
Platforma Docker umożliwia ograniczenie 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
- Dowiedz się więcej o automatycznym wdrażaniu usługi IoT Edge.
- Zobacz, jak usługa IoT Edge obsługuje ciągłą integrację i ciągłe wdrażanie.