Vorbereiten der Bereitstellung einer IoT Edge-Lösung für die Produktion

Gilt für: IoT Edge 1.5

Wichtig

IoT Edge 1.5 LTS ist das unterstützte Release. IoT Edge 1.4 LTS wurde am 12. November 2024 eingestellt. Wenn Sie ein früheres Release verwenden, finden Sie weitere Informationen unter Aktualisieren von IoT Edge.

Wenn Sie bereit sind, Ihre IoT Edge-Lösung von der Entwicklung in die Produktion zu übernehmen, stellen Sie sicher, dass sie für die laufende Leistung konfiguriert ist.

Nicht alle Informationen in diesem Artikel sind ebenso wichtig. Um Ihnen bei der Priorisierung zu helfen, beginnt jeder Abschnitt mit Listen, die die Arbeit in zwei Gruppen aufteilen: wichtig, um sie abzuschließen, bevor Sie zur Produktion übergehen, oder hilfreich zu wissen.

Gerätekonfiguration

IoT Edge-Geräte können alles von einem Raspberry Pi bis zu einem Laptop oder einem virtuellen Computer sein, der auf einem Server ausgeführt wird. Sie können physisch oder über eine virtuelle Verbindung auf das Gerät zugreifen, oder das Gerät kann über längere Zeiträume isoliert werden. Stellen Sie auf beide Weise sicher, dass sie so konfiguriert ist, dass sie ordnungsgemäß funktioniert.

• Wichtig

  • Installieren von Produktionszertifikaten
  • Erstellen eines Geräteverwaltungsplans
  • Verwenden Sie Moby als Container-Engine. Wenn Sie Ubuntu Core-Snaps verwenden, wird das Docker-Snap von Canonical gewartet und unterstützt Produktionsszenarien.

• Hilfreich

  • Auswählen des Upstreamprotokolls

Installieren von Produktionszertifikaten

Auf jedem IoT Edge-Gerät in der Produktion muss ein Zertifikat der Zertifizierungsstelle (ZS) des Geräts installiert sein. Dieses Zertifizierungsstellenzertifikat wird dann in der Konfigurationsdatei für die IoT Edge-Runtime deklariert. Für Entwicklung und Tests erstellt die IoT Edge-Laufzeit temporäre Zertifikate, wenn keine Zertifikate in der Konfigurationsdatei deklariert werden. Diese temporären Zertifikate laufen jedoch nach drei Monaten ab und sind für Produktionsszenarien nicht sicher. Geben Sie für Produktionsszenarien Ihr eigenes Edge-Zertifizierungsstellenzertifikat an, entweder von einer selbstsignierten Zertifizierungsstelle oder einer, die von einer kommerziellen Zertifizierungsstelle erworben wurde.

Weitere Informationen zur Rolle des Edgezertifizierungsstellenzertifikats finden Sie unter Verwendung von Zertifikaten durch Azure IoT Edge.

Weitere Informationen zum Installieren von Zertifikaten auf einem IoT Edge-Gerät und zum Verweisen auf diese aus der Konfigurationsdatei finden Sie unter Verwalten des Zertifikats auf einem IoT Edge-Gerät.

Erstellen eines Geräteverwaltungsplans

Bevor Sie ein Gerät in die Produktion aufnehmen, überlegen Sie, wie Sie zukünftige Updates verwalten. Für ein IoT Edge-Gerät kann die Liste der zu aktualisierenden Komponenten Folgendes umfassen:

• Gerätefirmware
• Betriebssystembibliotheken
• Container-Engine, z.B. Moby
• IoT Edge
• ZS-Zertifikate

Geräteupdate für IoT Hub ist ein Dienst, mit dem Sie Over-the-Air-Updates (OTA) für Ihre IoT Edge-Geräte bereitstellen können.

Andere Möglichkeiten zum Aktualisieren von IoT Edge erfordern physischen oder SSH-Zugriff auf das IoT Edge-Gerät. Weitere Informationen finden Sie unter Aktualisieren der IoT Edge-Runtime. Zum Aktualisieren mehrerer Geräte wird empfohlen, die Aktualisierungsschritte einem Skript hinzuzufügen oder ein Automatisierungstool wie Ansible zu verwenden.

Containerengine

Für jedes IoT Edge-Gerät ist ein Containermodul erforderlich. Die Moby-Engine wird in der Produktion unterstützt. Wenn Sie Ubuntu Core-Snaps verwenden, wird das Docker-Snap von Canonical gewartet und unterstützt Produktionsszenarien. Andere Containermodule, z. B. Docker, arbeiten mit IoT Edge und es ist in Ordnung, diese Engines für die Entwicklung zu verwenden. Wenn Sie die Moby-Engine mit Azure IoT Edge nutzen, kann diese neu verteilt werden. Microsoft übernimmt die Wartung.

Auswählen des Upstreamprotokolls

Sie können das Protokoll (das den verwendeten Port bestimmt) für die Upstreamkommunikation mit IoT Hub sowohl für den IoT Edge-Agent als auch für den IoT Edge-Hub konfigurieren. Das Standardprotokoll ist AMQP, aber Sie möchten es möglicherweise abhängig von Ihrer Netzwerkeinrichtung ändern.

Die beiden Runtimemodule verfügen über eine Umgebungsvariable UpstreamProtocol. Die gültigen Werte für die Variable lauten:

• MQTT
• AMQP
• MQTTWS
• AMQPWS

Konfigurieren Sie die Variable „UpstreamProtocol“ für den IoT Edge-Agent in der Konfigurationsdatei auf dem Gerät. Wenn sich Ihr IoT Edge-Gerät beispielsweise hinter einem Proxyserver befindet, der AMQP-Ports blockiert, müssen Sie möglicherweise den IoT Edge-Agent für die Verwendung von AMQP über WebSocket (AMQPWS) konfigurieren, um die erste Verbindung mit IoT Hub herzustellen.

Nachdem Ihr IoT Edge-Gerät eine Verbindung hergestellt hat, konfigurieren Sie die UpstreamProtocol-Variable für beide Laufzeitmodule in zukünftigen Bereitstellungen weiter. Weitere Informationen finden Sie unter Konfigurieren eines IoT Edge-Geräts für die Kommunikation über einen Proxyserver.

Bereitstellung

• Hilfreich
  • Verwenden konsistenter Upstreamprotokolle
  • Einrichten von Hostspeicher für Systemmodule
  • Reduzieren der Speicherplatzbelegung durch den IoT Edge-Hub
  • Verwenden der richtigen Modulbilder in Bereitstellungsmanifesten
  • Beachten von Größeneinschränkungen für Zwillinge bei der Verwendung benutzerdefinierter Module
  • Konfigurieren, wie Updates auf Module angewendet werden

Verwenden konsistenter Upstreamprotokolle

Wenn Sie den IoT Edge-Agent auf Ihrem IoT Edge-Gerät so konfiguriert haben, dass er ein anderes Protokoll als das Standard-AMQP verwendet, deklarieren Sie in allen zukünftigen Bereitstellungen das gleiche Protokoll. Wenn sich Ihr IoT Edge-Gerät beispielsweise hinter einem Proxyserver befindet, der AMQP-Ports blockiert, wurde das Gerät wahrscheinlich so konfiguriert, dass es sich über AMQP über WebSocket (AMQPWS) verbindet. Konfigurieren Sie beim Bereitstellen von Modulen auf dem Gerät das gleiche AMQPWS-Protokoll für den IoT Edge-Agent und den IoT Edge-Hub. Andernfalls setzt das Standard-AMQP die Einstellungen außer Kraft und verhindert eine erneute Verbindung.

Sie müssen nur die Umgebungsvariable „UpstreamProtocol“ für die Module „IoT Edge-Agent“ und „IoT Edge-Hub“ konfigurieren. Alle zusätzlichen Module übernehmen das Protokoll, das in den Runtimemodulen festgelegt ist.

Ein Beispiel für diesen Prozess finden Sie unter Konfigurieren eines IoT Edge-Geräts für die Kommunikation über einen Proxyserver.

Einrichten von Hostspeicher für Systemmodule

Die Module von IoT Edge-Hub und -Agent verwenden lokalen Speicher, um den Status beizubehalten und den Nachrichtenaustausch zwischen Modulen, Geräten und der Cloud zu ermöglichen. Für eine höhere Zuverlässigkeit und Leistung konfigurieren Sie die Systemmodule so, dass sie Speicherplatz auf dem Hostdateisystem verwenden.

Weitere Informationen finden Sie unter Hostspeicher für Systemmodule.

Reduzieren der Speicherplatzbelegung durch den IoT Edge-Hub

Wenn Sie eingeschränkte Geräte mit begrenzt verfügbarem Arbeitsspeicher bereitstellen, können Sie den IoT Edge-Hub so konfigurieren, dass er in einer optimierten Kapazität ausgeführt wird und weniger Speicherplatz benötigt. Diese Konfigurationen begrenzen jedoch die Leistung des IoT Edge-Hubs. Sie müssen die richtige Balance für Ihre Lösung finden.

Vermeiden von Leistungsoptimierung auf eingeschränkten Geräten

Der IoT Edge-Hub ist standardmäßig für Leistung optimiert, sodass er versucht, große Speicherblöcke zuzuordnen. Diese Konfiguration kann bei kleineren Geräten wie Raspberry Pi Stabilitätsprobleme verursachen. Wenn Sie Geräte mit eingeschränkten Ressourcen bereitstellen, legen Sie auf dem IoT Edge-Hub die Umgebungsvariable OptimizeForPerformance auf FALSE fest.

Wenn OptimizeForPerformance auf TRUE festgelegt wurde, wird im MQTT-Protokollkopf der Wert „PooledByteBufferAllocator“ verwendet, der eine bessere Leistung bietet, aber mehr Arbeitsspeicher zuordnet. Die Zuweisung funktioniert nicht gut unter 32-Bit-Betriebssystemen oder auf Geräten mit wenig Arbeitsspeicher. Und: Wenn RocksDb im Hinblick auf Leistung optimiert wurde, ordnet sie mehr Speicher für ihre Rolle als lokaler Speicheranbieter zu.

Weitere Informationen finden Sie unter Stabilitätsprobleme auf kleineren Geräten.

Deaktivieren nicht verwendeter Protokolle

Eine weitere Möglichkeit, die Leistung des IoT Edge-Hubs zu optimieren und seine Speicherauslastung zu reduzieren, besteht darin, die Kopfteile aller Protokolle zu deaktivieren, die nicht in Ihrer Lösung verwendet werden.

Protokollkopfteile werden konfiguriert, indem boolesche Umgebungsvariablen für das IoT Edge-Hubmodul in Ihren Bereitstellungsmanifesten festgelegt werden. Die drei Variablen lauten:

• AMQP-Einstellungen__aktiviert
• mqttSettings__enabled
• httpSettings__enabled

Alle drei Variablen haben zwei Unterstriche und können entweder auf TRUE oder FALSE festgelegt werden.

Reduzieren der Speicherzeit für Nachrichten

Das IoT Edge-Hubmodul speichert Nachrichten vorübergehend, wenn sie nicht an IoT Hub übermittelt werden können. Sie können konfigurieren, wie lange der IoT Edge-Hub nicht zugestellte Nachrichten aufbewahrt, bevor sie ablaufen. Wenn Sie Speicherprobleme auf Ihrem Gerät haben, können Sie den Wert timeToLiveSecs im IoT Edge-Hubmodulzwilling verringern.

Der Standardwert des Parameters „timeToLiveSecs“ beträgt 7.200 Sekunden, das sind zwei Stunden.

Verwenden der richtigen Modulbilder in Bereitstellungsmanifesten

Wenn ein leeres oder falsches Modulimage verwendet wird, versucht der Edge-Agent erneut, das Image zu laden, wodurch zusätzlicher Datenverkehr generiert wird. Fügen Sie dem Bereitstellungsmanifest die richtigen Images hinzu, um unnötigen Datenverkehr zu vermeiden.

Vermeiden von Debugversionen von Modulimages

Wenn Sie von Test- zu Produktionsszenarien wechseln, entfernen Sie die Debugkonfigurationen aus den Bereitstellungsmanifesten. Achten Sie darauf, dass kein Modulimage in den Bereitstellungsmanifesten das Suffix debug aufweist. Wenn Sie Erstellungsoptionen hinzugefügt haben, um Ports in den Modulen zum Debuggen verfügbar zu machen, entfernen Sie auch diese Erstellungsoptionen.

Beachten von Größeneinschränkungen für Zwillinge bei der Verwendung benutzerdefinierter Module

Das Bereitstellungsmanifest, das benutzerdefinierte Module enthält, ist Teil des EdgeAgent-Zwillings. Überprüfen Sie die Einschränkung bei der Modulzwillingsgröße.

Wenn Sie eine große Anzahl von Modulen bereitstellen, überschreiten Sie möglicherweise dieses Größenlimit für Zwillinge. Ziehen Sie einige allgemeine Gegenmaßnahmen für dieses harte Limit in Betracht:

• Speichern Sie jede beliebige Konfiguration in dem benutzerdefinierten Modulzwilling, der ein eigenes Limit hat.
• Speichern Sie eine Konfiguration, die auf einen Speicherort ohne Speicherplatzbegrenzung verweist (d. h. auf einen Blobspeicher).

Konfigurieren, wie Updates auf Module angewendet werden

Wenn eine Bereitstellung aktualisiert wird, empfängt Edge-Agent die neue Konfiguration als Zwillingsupdate. Wenn es bei der neuen Konfiguration neue oder aktualisierte Modulimages gibt, verarbeitet Edge-Agent standardmäßig jedes Modul sequenziell:

1. Das aktualisierte Image wird heruntergeladen.
2. Das gerade ausgeführte Modul wird beendet.
3. Eine neue Modulinstanz wird gestartet.
4. Das nächste Modulupdate wird verarbeitet.

In einigen Fällen (z. B., wenn Abhängigkeiten zwischen Modulen bestehen) ist es möglicherweise wünschenswert, zuerst alle aktualisierten Modulimages herunterzuladen, bevor ausgeführte Module neu gestartet werden. Dieses Modulupdateverhalten kann durch Festlegen einer IoT Edge Agent-Umgebungsvariablen (ModuleUpdateMode) auf den Zeichenfolgenwert WaitForAllPulls konfiguriert werden. Weitere Informationen finden Sie unter IoT Edge-Umgebungsvariablen.

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

Containerverwaltung

• Wichtig
  • Verwenden von Tags für die Versionsverwaltung
  • Verwalten von Volumes
• Hilfreich
  • Speichern von Runtimecontainern in Ihrer privaten Registrierung
  • Konfigurieren der automatischen Speicherbereinigung für Images

Verwenden von Tags für die Versionsverwaltung

Ein Tag ist ein Docker-Konzept, mit dem Sie Versionen von Docker-Containern unterscheiden können. Tags sind Suffixe wie 1.5, die am Ende eines Containerrepositorys stehen. Beispiel: mcr.microsoft.com/azureiotedge-agent:1.5. Tags können jederzeit geändert werden, um auf einen anderen Container zu zeigen. Deswegen sollte sich Ihr Team auf eine Konvention einigen, die bei der fortschreitenden Aktualisierung Ihrer Modulimages beachtet wird.

Tags helfen Ihnen auch bei der Durchsetzung von Updates auf Ihren IoT Edge-Geräten. Wenn Sie eine aktualisierte Modulversion in Ihre Containerregistrierung pushen, erhöhen Sie das Tag. Pushen Sie dann eine neue Bereitstellung auf Ihre Geräte mit dem inkrementierten Tag. Die Container-Engine erkennt das inkrementierte Tag als neue Version und pullt die neueste Modulversion auf Ihr Gerät.

Tags für die IoT Edge-Runtime

Die IoT Edge-Agent- und IoT Edge-Hubimages sind im Tag mit der IoT Edge-Version gekennzeichnet, der sie zugeordnet sind. Es gibt zwei Möglichkeiten zum Verwenden von Tags mit den Runtime-Images:

• Fortlaufende Tags: Verwenden Sie nur die ersten zwei Stellen der Versionsnummer, um zum neuesten Image zu gelangen, das mit diesen Stellen übereinstimmt. Sobald eine neue Version veröffentlicht wird, wird 1.5 beispielsweise immer so aktualisiert, dass auf die neueste 1.5.x-Version verwiesen wird. Wenn die Containerruntime auf Ihrem IoT Edge-Gerät das Image erneut per Pull herunterlädt, werden die Laufzeitmodule auf die neueste Version aktualisiert. Bereitstellungen aus dem Azure-Portal weisen standardmäßig fortlaufende Tags auf. Dieses Vorgehen wird für Entwicklungszwecke vorgeschlagen.

• Spezifische Tags: Verwenden Sie alle drei Stellen der Versionsnummer, um die Imageversion explizit festzulegen. Beispielsweise ändert sich 1.5.0 nach dem ersten Release nicht. Sie können im Bereitstellungsmanifest eine neue Versionsnummer deklarieren, wenn Sie zur Aktualisierung bereit sind. Dieses Vorgehen wird für Produktionszwecke vorgeschlagen.

Verwalten von Volumes

IoT Edge entfernt keine Volumes, die an Modulcontainer angefügt sind. Dieses Verhalten ist beabsichtigt und ermöglicht es, dass die Daten über Containerinstanzen wie Upgradeszenarien hinweg beibehalten werden. Wenn diese Volumes jedoch nicht verwendet werden, kann dies zur Erschöpfung des Speicherplatzes auf dem Datenträger und nachfolgenden Systemfehlern führen. Wenn Sie Docker-Volumes in Ihrem Szenario verwenden, empfehlen wir Ihnen, die nicht verwendeten Volumes mithilfe von Docker-Tools wie docker volume prune und docker volume rm zu entfernen – insbesondere bei Produktionsszenarien.

Speichern von Runtimecontainern in Ihrer privaten Registrierung

Sie wissen, wie Sie Ihre Containerimages für benutzerdefinierte Codemodule in Ihrer privaten Azure-Registrierung speichern können, aber Sie können sie auch verwenden, um öffentliche Containerimages wie die Runtimemodule edgeAgent und edgeHub zu speichern. Dies kann erforderlich sein, wenn Sie strenge Firewallbeschränkungen besitzen, da diese Runtimecontainer in der Microsoft Container Registry (MCR) gespeichert sind.

Mit den folgenden Schritten können Sie ein Docker-Image von edgeAgent und edgeHub auf Ihren lokalen Computer abrufen, ihnen neue Tags zuordnen, sie zu Ihrer privaten Registrierung pushen und dann Ihre Konfigurationsdatei aktualisieren, damit Ihre Geräte die Images aus Ihrer privaten Registrierung abrufen können.

1. Rufen Sie das Docker-Image edgeAgent aus der Microsoft-Registrierung ab. Aktualisieren Sie bei Bedarf die Versionsnummer.

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

2. Listen Sie alle Docker-Images auf, suchen Sie die Images edgeAgent sowie edgeHub und kopieren Sie dann ihre Image-IDs.

   docker images
   

3. Ordnen Sie den Images edgeAgent und edgeHub neue Tags zu. Ersetzen Sie die Werte in Klammern durch Ihre eigenen.

   # 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
   

4. Pushen Sie die Images edgeAgent und edgeHub zu Ihrer privaten Registrierung. Ersetzen Sie den Wert in Klammern durch Ihren eigenen.

   # 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
   

5. Aktualisieren Sie die Imagereferenzen in der Datei deployment.template.json für die Systemmodule edgeAgent und edgeHub, indem Sie mcr.microsoft.com durch Ihr eigenes „registry-name/server“ für beide Module ersetzen.

6. Öffnen Sie einen Text-Editor auf Ihrem IoT Edge-Gerät, um die Konfigurationsdatei mit den Informationen über das Image der privaten Registrierung zu aktualisieren.

   sudo nano /etc/aziot/config.toml
   

7. Ändern Sie im Text-Editor die Imagewerte unter [agent.config]. Ersetzen Sie die Werte in Klammern durch Ihre eigenen.

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

8. Wenn Ihre private Registrierung eine Authentifizierung erfordert, legen Sie die Authentifizierungsparameter in [agent.config.auth] fest.

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

9. Speichern Sie Ihre Änderungen und beenden Sie den Text-Editor.

10. Wenden Sie die IoT Edge-Konfigurationsänderung an.

    sudo iotedge config apply
    

    Ihre IoT Edge-Runtime wird neu gestartet.

Weitere Informationen finden Sie unter:

• Konfigurieren des IoT Edge-Agent
• Azure IoT Edge-Agent
• Azure IoT Edge Hub

Konfigurieren der automatischen Speicherbereinigung für Images

Die automatische Speicherbereinigung für Images ist ein Feature in IoT Edge v1.4 und höher, um Docker-Images automatisch zu bereinigen, die von IoT Edge-Modulen nicht mehr verwendet werden. Gelöscht werden nur Docker-Images, die von der IoT Edge-Runtime im Rahmen einer Bereitstellung abgerufen wurden. Das Löschen nicht verwendeter Docker-Images hilft, Speicherplatz zu sparen.

Das Feature wird in der IoT Edge-Hostkomponente, dem Dienst aziot-edged und standardmäßig aktiviert implementiert. Die Bereinigung geschieht jeden Tag um Mitternacht (lokale Gerätezeit), und dabei werden nicht verwendete Docker-Images entfernt, die vor sieben Tagen zuletzt verwendet wurden. Die Parameter zum Steuern des Bereinigungsverhaltens werden im config.toml-Code festgelegt und weiter unten in diesem Abschnitt erläutert. Wenn Parameter in der Konfigurationsdatei nicht angegeben wurden, werden die Standardwerte angewendet.

Das folgende Beispiel zeigt den Abschnitt config.toml zur automatischen Speicherbereinigung für Images, bei der Standardwerte verwendet werden:

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

In der folgenden Tabelle werden die Parameter der automatischen Speicherbereinigung für Images beschrieben. Alle Parameter sind optional und können einzeln festgelegt werden, um die Standardeinstellungen zu ändern.

Parameter	Beschreibung	Erforderlich	Standardwert
enabled	Aktiviert die automatische Speicherbereinigung für Images. Sie können das Feature deaktivieren, indem Sie diese Einstellung in false ändern.	Wahlfrei	Wahr
cleanup_recurrence	Steuert die Wiederholungshäufigkeit der Bereinigungsaufgabe. Muss als ein Vielfaches von Tagen (days, d) angegeben werden und kann nicht weniger als ein Tag sein. Beispiel: „1d“, „2d“, „6d“ usw.	Wahlfrei	1 Tag
image_age_cleanup_threshold	Definiert den Mindestalter-Schwellenwert von nicht verwendeten Images vor der Erwägung für eine Bereinigung und muss in Tagen angegeben werden. Sie können 0d angeben, um die Images zu bereinigen, sobald sie aus der Bereitstellung entfernt wurden. Images werden als nicht verwendet betrachtet, nachdem sie aus der Bereitstellung entfernt wurden.	Wahlfrei	7d
cleanup_time	Uhrzeit des Tages, in lokaler Gerätezeit, wenn die Bereinigungsaufgabe ausgeführt wird. Muss im 24-Stunden-Format (HH:MM) vorliegen.	Wahlfrei	00:00

Netzwerk

• Hilfreich
  • Überprüfen ausgehender/eingehender Konfigurationen
  • Zulassen von Verbindungen von IoT Edge-Geräten
  • Konfigurieren der Kommunikation über Proxy
  • Festlegen des DNS-Servers in den Einstellungen der Containerengine

Überprüfen ausgehender/eingehender Konfigurationen

Kommunikationskanäle zwischen IoT Edge und Azure IoT Hub sind immer als „Ausgehend“ konfiguriert. Die meisten IoT Edge-Szenarien erfordern nur drei Verbindungen. Die Container-Engine muss sich mit der Containerregistrierung (bzw. den Registrierungen) verbinden, die die Modulimages enthält. Die IoT Edge-Runtime muss sich mit IoT Hub verbinden, um Gerätekonfigurationsinformationen abzurufen sowie Nachrichten und Telemetrie zu senden. Und falls Sie eine automatische Bereitstellung verwenden, muss sich IoT Edge mit dem Gerätebereitstellungsdienst (Device Provisioning-Dienst) verbinden. Weitere Informationen finden Sie unter Firewall- und Portkonfigurationsregeln.

Zulassen von Verbindungen von IoT Edge-Geräten

Wenn Ihr Netzwerksetup erfordert, dass Sie Verbindungen von IoT Edge-Geräten explizit zulassen, prüfen Sie die folgende Liste der IoT Edge-Komponenten:

• Der IoT Edge-Agent öffnet eine persistente AMQP/MQTT-Verbindung zu IoT Hub, ggf. über WebSockets.
• Der IoT Edge-Hub öffnet eine einzelne persistente AMQP-Verbindung oder mehrere MQTT-Verbindungen zu IoT Hub, ggf. über WebSockets.
• Der IoT Edge-Dienst führt zeitweilig HTTPS-Aufrufe an IoT Hub aus.

In allen drei Fällen entspricht der vollqualifizierte Domänenname (Fully Qualified Domain Name, FQDN) dem Muster \*.azure-devices.net.

Containerregistrierungen

Die Container-Engine sendet Aufrufe an Containerregistrierungen über HTTPS. Der FQDN zum Abrufen der Containerimages der IoT Edge-Runtime lautet mcr.microsoft.com. Die Container-Engine verbindet sich mit anderen Registrierungen gemäß der Konfiguration in der Bereitstellung.

Diese Prüfliste ist ein Ausgangspunkt für Firewallregeln:

FQDN (* = Platzhalter)	Ausgehende TCP-Ports	Verbrauch
mcr.microsoft.com	443	Microsoft-Containerregistrierung
*.data.mcr.microsoft.com	443	Datenendpunkt, der Inhaltsübermittlung bietet
*.cdn.azcr.io	443	Bereitstellen von Modulen aus dem Marketplace auf Geräten
global.azure-devices-provisioning.net	443	Device Provisioning Service-Zugriff (optional)
*.azurecr.io	443	Persönliche Containerregistrierungen und Containerregistrierungen von Drittanbietern
*.blob.core.windows.net	443	Herunterladen von Azure Container Registry-Imagedeltas aus Blobspeicher
*.azure-devices.net	5671, 8883, 4431	IoT Hub-Zugriff
*.docker.io	443	Docker Hub-Zugriff (optional)

¹Öffnen Sie Port 8883 für sicheres MQTT oder Port 5671 für sicheres AMQP. Wenn Sie Verbindungen nur über Port 443 herstellen können, kann eines dieser Protokolle über einen WebSocket-Tunnel ausgeführt werden.

Da sich die IP-Adresse eines IoT-Hubs ohne vorherige Ankündigung ändern kann, verwenden Sie immer den FQDN für die Konfiguration der Positivliste. Weitere Informationen finden Sie unter IP-Adressen von IoT Hub.

Einige dieser Firewallregeln werden von Azure Container Registry geerbt. Weitere Informationen finden Sie unter Konfigurieren von Regeln für den Zugriff auf eine Azure-Containerregistrierung hinter einer Firewall.

Sie können dedizierte Datenendpunkte in Ihrer Azure Container-Registrierung aktivieren, um die Aufnahme von Platzhaltern in die Positivliste des FQDN *.blob.core.windows.net zu vermeiden. Weitere Informationen finden Sie unter Aktivieren dedizierter Datenendpunkte.

Hinweis

Um einen konsistenten vollqualifizierten Domänennamen zwischen dem REST-Endpunkt und den Datenendpunkten bereitzustellen, wird der Datenendpunkt für die Microsoft Container Registry ab 15. Juni 2020 von *.cdn.mscr.io in *.data.mcr.microsoft.com geändert.
Weitere Informationen finden Sie unter Microsoft Container Registry (MCR) Client Firewall Rules Configuration (Konfiguration der Firewallregeln für Microsoft Container Registry-Clients).

Wenn Sie Ihre Firewall nicht so konfigurieren möchten, dass sie den Zugriff auf öffentliche Containerregistrierungen zulässt, können Sie Images in Ihrer privaten Containerregistrierung speichern, wie unter Speichern von Runtimecontainern in Ihrer privaten Registrierung beschrieben.

Azure IoT-Identitätsdienst

Der IoT-Identitätsdienst bietet Bereitstellungs- und kryptografische Dienste für Azure IoT-Geräte. Der Identitätsdienst überprüft, ob die installierte Version die neueste Version ist. Die Überprüfung verwendet die folgenden FQDNs, um die Version zu überprüfen.

FQDN (vollqualifizierter Domainname)	Ausgehende TCP-Ports	Verbrauch
aka.ms	443	Vanity-URL für die Umleitung zur Versionsdatei
raw.githubusercontent.com	443	Die in GitHub gehostete Identitätsdienst-Versionsdatei

Konfigurieren der Kommunikation über Proxy

Wenn Ihre Geräte in einem Netzwerk bereitgestellt werden, das einen Proxyserver verwendet, müssen sie über den Proxy kommunizieren können, um IoT Hub und die Containerregistrierung zu erreichen. Weitere Informationen finden Sie unter Konfigurieren eines IoT Edge-Geräts für die Kommunikation über einen Proxyserver.

Festlegen des DNS-Servers in den Einstellungen der Containerengine

Geben Sie den DNS-Server für Ihre Umgebung in den Einstellungen der Container-Engine an. Die DNS-Servereinstellung gilt für alle Containermodule, die von der Engine gestartet wurden.

1. Bearbeiten Sie im Verzeichnis /etc/docker auf Ihrem Gerät die Datei daemon.json. Erstellen Sie die Datei, wenn sie nicht vorhanden ist.

2. Fügen Sie den Schlüssel dns hinzu und legen Sie die DNS-Serveradresse auf einen öffentlich zugänglichen DNS-Dienst fest. Wenn Ihr Edgegerät nicht auf einen öffentlichen DNS-Server zugreifen kann, verwenden Sie eine DNS-Serveradresse, auf die in Ihrem Netzwerk zugegriffen werden kann. Beispiel:

   {
       "dns": ["1.1.1.1"]
   }
   

Lösungsverwaltung

• Hilfreich
  • Einrichten von Protokollen und Diagnosen
  • Einrichten des Standardprotokollierungstreibers
  • Integration in Test- und CI/CD-Pipelines

Einrichten von Protokollen und Diagnosen

Unter Linux verwendet der IoT Edge-Daemon Journale als Standardprotokolltreiber. Verwenden Sie das Befehlszeilentool journalctl , um die Daemonprotokolle abzufragen.

Ab Version 1.2 basiert IoT Edge auf mehreren Daemons. Sie können zwar die Protokolle der einzelnen Daemons mit journalctl abfragen, und die iotedge system Befehle verwenden, um die kombinierten Protokolle abzufragen.

• Konsolidierter iotedge Befehl:

  sudo iotedge system logs
  

• Entsprechender journalctl-Befehl:

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

Wenn Sie eine IoT Edge-Bereitstellung testen, greifen Sie in der Regel auf Ihre Geräte zu, um Protokolle und Problembehandlung abzurufen. In einem Bereitstellungsszenario haben Sie diese Option möglicherweise nicht. Überlegen Sie, wie Sie Informationen zu Ihren Geräten in der Produktion sammeln. Eine Möglichkeit besteht darin, ein Protokollierungsmodul zu verwenden, das Informationen aus anderen Modulen sammelt und an die Cloud sendet. Verwenden Sie beispielsweise logspout-loganalytics, oder entwerfen Sie Eigene.

Einrichten des Standardprotokollierungstreibers

Standardmäßig legt das Moby-Containermodul keine Grenzwerte für die Größe von Containerprotokollen fest. Im Laufe der Zeit kann dies dazu führen, dass das Gerät Protokolle ausfüllt und nicht mehr genügend Speicherplatz hat. Legen Sie das Containermodul so fest, dass der local Protokollierungstreiber als Protokollierungsmechanismus verwendet wird. Der local Protokollierungstreiber bietet standardmäßig ein Standardlimit für die Protokollgröße, führt standardmäßig eine Protokolldrehung durch und verwendet ein effizienteres Dateiformat, wodurch die Auslastung des Speicherplatzes verhindert wird. Sie können auch unterschiedliche Protokollierungstreiber verwenden und je nach Ihren Anforderungen unterschiedliche Größenbeschränkungen festlegen.

Option: Konfigurieren des Standardprotokollierungstreibers für alle Containermodule

Konfigurieren Sie Ihr Containermodul so, dass es einen bestimmten Protokollierungstreiber verwendet, indem Sie den Wert von log driver auf den Namen des Protokolltreibers in der daemon.json Datei festlegen. Im folgenden Beispiel wird der Standardprotokollierungstreiber auf den Protokolltreiber local festgelegt (empfohlen).

{
    "log-driver": "local"
}

Sie können ihre log-opts-Schlüssel auch so konfigurieren, dass in der Datei daemon.json geeignete Werte verwendet werden. Im folgenden Beispiel wird der Protokolltreiber auf local festgelegt. Außerdem werden die Optionen max-size und max-file festgelegt.

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

Fügen Sie diese Informationen einer Datei mit dem Namen daemon.json hinzu, oder fügen Sie sie an den folgenden Speicherort an:

• /etc/docker/

Starten Sie die Container-Engine neu, damit die Änderungen wirksam werden.

Option: Anpassen der Protokolleinstellungen für die einzelnen Containermodule

Legen Sie diese Optionen in den createOptions jedes Moduls fest. Beispiel:

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

Zusätzliche Optionen unter Linux-Systemen

• Konfigurieren Sie die Container-Engine so, dass sie Protokolle an das systemd-Journal sendet, indem Sie journald als Standardprotokolltreiber festlegen.

• Entfernen Sie regelmäßig alte Protokolle von Ihrem Gerät, indem Sie ein logrotate-Tool installieren. Verwenden Sie die folgende Dateispezifikation:

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

Integration in Test- und CI/CD-Pipelines

Integrieren Sie Ihre Produktionsbereitstellung für die effizienteste IoT Edge-Bereitstellung in Ihre Test- und CI/CD-Pipelines. Azure IoT Edge unterstützt mehrere CI/CD-Plattformen, einschließlich Azure DevOps. Weitere Informationen finden Sie unter Continuous Integration und Continuous Deployment für Azure IoT Edge.

Sicherheitshinweise

• Wichtig
  • Verwalten des Zugriffs auf die Containerregistrierung
  • Beschränken des Containerzugriffs auf Hostressourcen

Verwalten des Zugriffs auf die Containerregistrierung

Bevor Sie Module auf IoT-Edge-Produktionsgeräten bereitstellen, müssen Sie den Zugriff auf Ihre Containerregistrierung steuern, damit Externe nicht auf Ihre Containerimages zugreifen oder diese ändern können. Verwenden Sie eine private Containerregistrierung, um Containerimages zu verwalten.

In den Lernprogrammen und anderen Dokumentationen teilen wir Ihnen mit, dass Sie dieselben Anmeldeinformationen für die Containerregistrierung auf Ihrem IoT Edge-Gerät wie auf Ihrem Entwicklungscomputer verwenden. Diese Anweisungen helfen Ihnen, Test- und Entwicklungsumgebungen einfacher einzurichten und sind nicht für die Produktionsverwendung geeignet.

Um einen sichereren Zugriff auf Ihre Registrierung zu erhalten, wählen Sie aus mehreren Authentifizierungsoptionen aus. Die Verwendung eines Active Directory-Dienstprinzipals ist eine beliebte und empfohlene Methode für Apps oder Dienste, um Container-Images automatisch und unbeaufsichtigt abzurufen, wie es z. B. bei IoT Edge-Geräten der Fall ist. Sie können auch repository-spezifische Token verwenden, mit denen Sie lang- oder kurzlebige Identitäten erstellen können, die nur in der Azure-Containerregistrierung existieren, in der Sie sie erstellen, und die Zugriff auf die Repositoryebene erlauben.

Führen Sie zum Erstellen eines Dienstprinzipals die beiden skripts aus, die im Erstellen eines Dienstprinzipals beschrieben sind. Diese Skripts führen die folgenden Aktionen aus:

• Mit dem ersten Skript wird der Dienstprinzipal erstellt. Es gibt die Dienstprinzipal-ID und das zugehörige Kennwort aus. Speichern Sie diese Werte.

• Das zweite Skript erstellt Rollenzuweisungen, die dem Dienstprinzipal gewährt werden sollen. Führen Sie sie anschließend bei Bedarf aus. Verwenden Sie die acrPull-Benutzerrolle für den role Parameter. Eine Liste der Rollen finden Sie unter Azure Container Registry: Rollen und Berechtigungen.

Um sich mit einem Dienstprinzipal zu authentifizieren, stellen Sie die Dienstprinzipal-ID und Kennwortanmeldeinformationen aus dem ersten Skript im Bereitstellungsmanifest bereit.

• Geben Sie als Benutzernamen oder Client-ID die Dienstprinzipal-ID an.

• Geben Sie als Kennwort oder geheimen Clientschlüssel das Dienstprinzipalkennwort an.

Zum Erstellen von Tokens aus dem Repositorybereich, folgen Sie den Anweisungen unter Ein Token aus dem Repositorybereich erstellen.

Um sich mithilfe von repository-spezifischen Token zu authentifizieren, geben Sie den Tokennamen und die Zugangsdaten an, die Sie erhalten, nachdem Sie ihr repository-spezifisches Token im Bereitstellungsmanifest erstellt haben.

• Geben Sie als Benutzernamen den Benutzernamen des Tokens an.

• Geben Sie als Kennwort eines der Kennwörter des Tokens an.

Hinweis

Deaktivieren Sie nach der Implementierung einer erweiterten Sicherheitsauthentifizierung die Administratorbenutzereinstellung , sodass der Standardmäßige Benutzername- und Kennwortzugriff nicht verfügbar ist. Sie finden die Einstellung für Ihre Containerregistrierung im Azure-Portal unter "Einstellungen", und wählen Sie "Zugriffstasten" aus.

Beschränken des Containerzugriffs auf Hostressourcen

Um gemeinsam genutzte Hostressourcen über Module hinweg auszugleichen, legen Sie Grenzwerte für die Ressourcennutzung für jedes Modul fest. Diese Grenzwerte stellen sicher, dass ein Modul nicht zu viel Arbeitsspeicher oder CPU verwenden kann, und verhindern, dass andere Prozesse auf dem Gerät ausgeführt werden. Standardmäßig beschränkt die IoT Edge-Plattform keine Ressourcen für Module, da Sie testen müssen, um herauszufinden, wie viele Ressourcen ein Modul benötigt, um gut zu laufen.

Mit Docker können Sie Ressourcen wie Arbeitsspeicher und CPU-Auslastung einschränken. Weitere Informationen finden Sie unter Laufzeitoptionen mit Arbeitsspeicher, CPUs und GPUs.

Sie können diese Einschränkungen auf einzelne Module anwenden, indem Sie Optionen in Bereitstellungsmanifesten erstellen. Weitere Informationen finden Sie unter Konfigurieren von Erstellungsoptionen für Container für IoT Edge-Module.

Nächste Schritte

• Erfahren Sie mehr zur automatischen IoT Edge-Bereitstellung.
• Erfahren Sie, wie IoT Edge kontinuierliche Integration und kontinuierliche Bereitstellung unterstützt.