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

Gilt für: IoT Edge 1.4

Wichtig

IoT Edge Version 1.4 wird unterstützt. Wenn Sie ein früheres Release verwenden, finden Sie weitere Informationen unter Aktualisieren von IoT Edge.

Wenn Sie Ihre IoT Edge-Lösung aus der Entwicklungsumgebung für die Produktion bereitstellen möchten, achten Sie darauf, dass sie für kontinuierliche Leistung konfiguriert ist.

Nicht alle Informationen in diesem Artikel sind gleichwertig. Um Ihnen bei der Priorisierung zu helfen, enthält jeder Abschnitt Listen, die einer von zwei Kategorien angehören: Wichtig beschreibt die Schritte, die vor der Produktion abgeschlossen werden müssen, und Hilfreich umfasst nützliche Tipps.

Gerätekonfiguration

Es gibt zahlreiche IoT Edge-Geräte: von einem Raspberry Pi über einen Laptop bis hin zu einer VM, die auf einem Server ausgeführt sind. Sie können entweder physisch oder über eine virtuelle Verbindung auf das Gerät zugreifen. Es kann auch für längere Zeit isoliert sein. In jedem Fall sollte das Gerät so konfiguriert sein, dass es ordnungsgemäß funktioniert.

• Wichtig

  • Installieren von Produktionszertifikaten
  • Erstellen eines Geräteverwaltungsplans
  • Verwenden von Moby als Container-Engine

• 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. Wenn in der Konfigurationsdatei keine Zertifikate deklariert wurden, erstellt die IoT Edge-Runtime temporäre Zertifikate für Entwicklungs- und Testszenarien. Allerdings laufen diese temporären Zertifikate nach drei Monaten ab und sind nicht sicher genug für die Produktion. In Produktionsszenarien müssen Sie ein eigenes Zertifizierungsstellenzertifikat bereitstellen, das entweder von einer selbstsignierten Zertifizierungsstelle erstellt oder von einer kommerziellen Zertifizierungsstelle erworben wurde.

Weitere Informationen zur Rolle des Zertifizierungsstellenzertifikat des Geräts finden Sie unter Verwenden von Zertifikaten durch Azure IoT Edge.

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

Erstellen eines Geräteverwaltungsplans

Bevor Sie ein Gerät für die Produktion verwenden, sollten Sie wissen, wie Sie künftige Updates verwalten werden. Bei einem IoT Edge-Gerät kann die Liste der zu aktualisierenden Komponenten Folgendes enthalten:

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

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

Alternative Methoden 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.

Verwenden von Moby als Container-Engine

Für jedes IoT Edge-Gerät muss eine Container-Engine vorhanden sein. In der Produktion wird nur die Moby-Engine unterstützt. Andere Container-Engines, z.B. Docker, sind mit IoT Edge kompatibel und können für die Entwicklung verwenden werden. 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 können es je nach 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 so konfigurieren, dass er AMQP über WebSocket (AMQPWS) verwendet, um die erste Verbindung zu IoT Hub herzustellen.

Wenn Ihr IoT Edge-Gerät verbunden ist, muss die Variable „UpstreamProtocol“ für beide Runtimemodule in künftigen Bereitstellungen weiter konfiguriert werden. Ein Beispiel für diesen Prozess 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:

• amqpSettings__enabled
• 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.1, die am Ende eines Containerrepositorys stehen. Beispiel: mcr.microsoft.com/azureiotedge-agent:1.1. 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. Beispielsweise wird, sobald eine neue Version veröffentlicht wird, 1.1 immer so aktualisiert, dass auf die neueste 1.1.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.1.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 sehr 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.4
   
   # Pull edgeHub image
   docker pull mcr.microsoft.com/azureiotedge-hub:1.4
   

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.4
   
   # Retag your edgeHub image
   docker tag <my-image-id> <registry-name/server>/azureiotedge-hub:1.4
   

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.4
   
   # Push your edgeHub image to your private registry
   docker push <registry-name/server>/azureiotedge-hub:1.4
   

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.4"
   

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 des Dataflows	Erforderlich	Standardwert
enabled	Aktiviert die automatische Speicherbereinigung für Images. Sie können das Feature deaktivieren, indem Sie diese Einstellung in false ändern.	Optional	true
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.	Optional	1d
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.	Optional	7d
cleanup_time	Uhrzeit des Tages, in lokaler Gerätezeit, wenn die Bereinigungsaufgabe ausgeführt wird. Muss im 24-Stunden-Format (HH:MM) vorliegen.	Optional	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 Container Registry
*.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	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 Edge-Gerät auf einen öffentlichen DNS-Server nicht zugreifen kann, verwenden Sie eine erreichbare DNS-Serveradresse in Ihrem Netzwerk. 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. Sie können das Befehlszeilentool journalctl verwenden, um die Daemonprotokolle abzufragen.

Ab Version 1.2 basiert IoT Edge auf mehreren Daemons. Obwohl die Protokolle jedes Daemons mit journalctl einzeln abgefragt werden können, bieten die iotedge system-Befehle eine bequeme Möglichkeit zum Abfragen der kombinierten Protokolle.

• 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, können Sie in der Regel auf Ihre Geräte zugreifen, um Protokolle abzurufen und Fehler zu beheben. In einem Bereitstellungsszenario haben Sie diese Option möglicherweise nicht. Überlegen Sie, wie Sie Informationen über Ihre Geräte in der Produktion sammeln können. Eine Möglichkeit besteht darin, ein Protokollierungsmodul zu verwenden, das Informationen von anderen Modulen erfasst und in die Cloud sendet. Ein Beispiel für ein Protokollierungsmodul ist logspout-loganalytics. Sie haben auch die Möglichkeit, Ihr eigenes Modul zu erstellen.

Einrichten des Standardprotokollierungstreibers

Die Moby-Containerengine legt standardmäßig keine Grenzwerte für die Größe des Containerprotokolls fest. Im Laufe der Zeit kann dies dazu führen, dass das Gerät mit Protokollen überfüllt wird und auf dem Datenträger nicht genügend Speicherplatz zur Verfügung steht. Konfigurieren Sie Ihr Containermodul so, dass es den local Protokollierungstreiber als Ihren Protokollierungsmechanismus verwendet. Der Protokollierungstreiber Local bietet einen Standardgrenzwert für die Protokollgröße, führt standardmäßig die Protokollrotation durch und verwendet ein effizienteres Dateiformat, das dazu beiträgt, eine Erschöpfung des Speicherplatzes auf dem Datenträger zu verhindern. Sie können auch verschiedene Protokollierungstreiber verwenden und je nach Bedarf unterschiedliche Grenzwerte für die Größe festlegen.

Option: Konfigurieren des Standardprotokollierungstreibers für alle Containermodule

Sie können Ihr Containermodul so konfigurieren, dass es einen bestimmten Protokollierungstreiber verwendet, indem Sie den Wert log driver auf den Namen des Protokolltreibers im daemon.json 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 der Datei daemon.json hinzu (oder fügen Sie sie an die Datei an), und speichern Sie die Datei dann am folgenden Ort:

• /etc/docker/

Die Containerengine muss neu gestartet werden, damit die Änderungen wirksam werden.

Option: Anpassen der Protokolleinstellungen für die einzelnen Containermodule

Sie können dies in den createOptions der einzelnen Module vornehmen. Beispiel:

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

Zusätzliche Optionen unter Linux-Systemen

• Konfigurieren Sie die Containerengine so, dass sie Protokolle an systemdjournal 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

Für das effizienteste IoT Edge-Bereitstellungsszenario wird die Integration Ihrer Produktionsumgebung in Ihre Test- und CI/CD-Pipelines empfohlen. 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-Geräten in der Produktion bereitstellen, legen Sie den Zugriff auf Ihre Containerregistrierung so fest, dass Außenstehende nicht auf Ihre Containerimages zugreifen oder Änderungen vornehmen können. Verwenden Sie eine private Containerregistrierung, um Containerimages zu verwalten.

In den Tutorials und anderen Dokumentationen werden Sie dazu aufgefordert, für die Containerregistrierung auf Ihrem IoT Edge-Gerät die gleichen Anmeldeinformationen zu verwenden wie auf Ihrem Entwicklungscomputer. Dieses Vorgehen dient nur der vereinfachten Einrichtung von Test- und Entwicklungsumgebungen und soll nicht für Produktionsszenarien verwendet werden.

Um den sicheren Zugriff auf Ihre Registrierung zu schützen, stehen Ihnen verschiedene Authentifizierungsoptionen zur Verfügung. Eine verbreitete und empfohlene Authentifizierungsmethode ist die Verwendung eines Active Directory-Dienstprinzipals. Dieser eignet sich sehr gut für Anwendungen oder Dienste, die Containerimages automatisiert oder auf anderweitig unbeaufsichtigte Weise (ohne Monitor) pullen, wie etwa bei IoT Edge-Geräten. Eine weitere Option ist die Verwendung von Tokens aus dem Repositorybereich, mit denen Sie lang- oder kurzlebige Identitäten erstellen können. Diese bestehen nur in dem Azure Container Registry, in dem sie erstellt wurden, und bieten Zugriff auf die Repositoryebene.

Um einen Dienstprinzipal zu erstellen, führen Sie die beiden Skripts wie in Erstellen eines Dienstprinzipals beschrieben aus. Diese Skripts führen folgende Aufgaben 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 für den Dienstprinzipal, die anschließend bei Bedarf ausgeführt werden können. Es wird empfohlen, für den Parameter role die Benutzerrolle acrPull anzuwenden. Eine Liste der Rollen finden Sie unter Azure Container Registry: Rollen und Berechtigungen.

Geben Sie zum Authentifizieren mithilfe eines Dienstprinzipals die Dienstprinzipal-ID und das Dienstprinzipalkennwort ein, die Sie durch das erste Skript erhalten haben. Geben Sie diese Anmeldeinformationen im Bereitstellungsmanifest an.

• 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.

Geben Sie für die Authentifizierung mit Tokens aus dem Repositorybereich den Tokennamen und das Kennwort ein, die Sie nach dem Erstellen des Tokens aus dem Repositorybereich erhalten haben. Geben Sie diese Anmeldeinformationen im Bereitstellungsmanifest an.

• Geben Sie als Benutzernamen den Benutzernamen des Tokens an.

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

Hinweis

Nachdem Sie eine erweiterte Sicherheitsauthentifizierung implementiert haben, deaktivieren Sie die Einstellung Administratorbenutzer, damit der Standardzugriff über Benutzername und Kennwort nicht mehr verfügbar ist. Wählen Sie in Ihrer Containerregistrierung im Azure-Portal im Menü im linken Bereich unter Einstellungen die Option Zugriffsschlüssel aus.

Beschränken des Containerzugriffs auf Hostressourcen

Um die gemeinsam genutzten Host-Ressourcen zwischen den Modulen auszugleichen, sollten Sie den Ressourcenverbrauch pro Modul begrenzen. Diese Grenzwerte stellen sicher, dass ein Modul nicht zu viel Arbeitsspeicher- oder CPU-Ressourcen beanspruchen und die Ausführung anderer Prozesse auf dem Gerät verhindern kann. Die Ressourcen für Module werden von der IoT Edge-Plattform standardmäßig nicht beschränkt, da Tests erforderlich sind, um zu ermitteln, wie viele Ressourcen für die optimale Ausführung eines Moduls erforderlich sind.

Docker bietet einige Einschränkungen, mit denen Sie die Nutzung von Ressourcen wie Arbeitsspeicher und CPU beschränken können. Weitere Informationen finden Sie unter Laufzeitoptionen mit Arbeitsspeicher, CPUs und GPUs.

Diese Einschränkungen können mithilfe von Erstellungsoptionen in Bereitstellungsmanifesten auf einzelne Module angewendet werden. 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 Continuous Integration und Continuous Deployment unterstützt.