De implementatie van uw IoT Edge-oplossing in productie voorbereiden

Van toepassing op: IoT Edge 1.5 IoT Edge 1.4

Belangrijk

IoT Edge 1.5 LTS en IoT Edge 1.4 LTS worden ondersteund releases. IoT Edge 1.4 LTS eindigt op 12 november 2024. Raadpleeg IoT Edge bijwerken als u een eerdere versie hebt.

Wanneer u klaar bent om uw IoT Edge-oplossing van ontwikkeling naar productie te nemen, moet u ervoor zorgen dat deze is geconfigureerd voor doorlopende prestaties.

De informatie in dit artikel is niet allemaal gelijk. Om u te helpen prioriteit te geven, begint elke sectie met lijsten die het werk in twee secties verdelen: belangrijk om te voltooien voordat u naar productie gaat, of nuttig voor u om te weten.

Apparaatconfiguratie

IoT Edge-apparaten kunnen van alles zijn, van een Raspberry Pi tot een laptop tot een virtuele machine die op een server wordt uitgevoerd. Mogelijk hebt u toegang tot het apparaat fysiek of via een virtuele verbinding, of kan het gedurende langere tijd worden geïsoleerd. In beide gevallen wilt u ervoor zorgen dat deze juist werkt.

• Belangrijk

  • Productiecertificaten installeren
  • Een apparaatbeheerplan hebben
  • Moby gebruiken als containerengine

• Nuttig

  • Upstream-protocol kiezen

Productiecertificaten installeren

Voor elk IoT Edge-apparaat in productie is een ca-certificaat (device certificate authority) geïnstalleerd. Dat CA-certificaat wordt vervolgens gedeclareerd aan de IoT Edge-runtime in het configuratiebestand. Voor ontwikkelings- en testscenario's maakt de IoT Edge-runtime tijdelijke certificaten als er geen certificaten worden gedeclareerd in het configuratiebestand. Deze tijdelijke certificaten verlopen echter na drie maanden en zijn niet veilig voor productiescenario's. Voor productiescenario's moet u uw eigen CA-certificaat voor apparaten opgeven, hetzij bij een zelfondertekende certificeringsinstantie of gekocht bij een commerciële certificeringsinstantie.

Zie Hoe Azure IoT Edge certificaten gebruikt voor meer informatie over de rol van het ca-certificaat van het apparaat.

Zie Certificaat beheren op een IoT Edge-apparaat voor meer informatie over het installeren van certificaten op een IoT Edge-apparaat en ernaar verwijzen vanuit het configuratiebestand.

Een apparaatbeheerplan hebben

Voordat u een apparaat in productie zet, moet u weten hoe u toekomstige updates gaat beheren. Voor een IoT Edge-apparaat kan de lijst met onderdelen die moeten worden bijgewerkt:

• Firmware van apparaat
• Besturingssysteembibliotheken
• Container-engine, zoals Moby
• IoT Edge
• CA-certificaten

Device Update voor IoT Hub is een service waarmee u over-the-air-updates (OTA) voor uw IoT Edge-apparaten kunt implementeren.

Alternatieve methoden voor het bijwerken van IoT Edge vereisen fysieke of SSH-toegang tot het IoT Edge-apparaat. Zie De IoT Edge-runtime bijwerken voor meer informatie. Als u meerdere apparaten wilt bijwerken, kunt u de updatestappen toevoegen aan een script of een automatiseringsprogramma zoals Ansible gebruiken.

Moby gebruiken als containerengine

Een containerengine is een vereiste voor elk IoT Edge-apparaat. Alleen moby-engine wordt ondersteund in productie. Andere containerengines, zoals Docker, werken wel met IoT Edge en het is geen probleem om deze engines te gebruiken voor ontwikkeling. De moby-engine kan opnieuw worden gedistribueerd wanneer deze wordt gebruikt met Azure IoT Edge en Microsoft biedt onderhoud voor deze engine.

Upstream-protocol kiezen

U kunt het protocol (dat de gebruikte poort bepaalt) configureren voor upstream-communicatie met IoT Hub voor zowel de IoT Edge-agent als de IoT Edge-hub. Het standaardprotocol is AMQP, maar mogelijk wilt u dat wijzigen, afhankelijk van uw netwerkinstallatie.

De twee runtimemodules hebben beide een omgevingsvariabele UpstreamProtocol . De geldige waarden voor de variabele zijn:

• MQTT
• AMQP
• MQTTWS
• AMQPWS

Configureer de variabele UpstreamProtocol voor de IoT Edge-agent in het configuratiebestand op het apparaat zelf. Als uw IoT Edge-apparaat zich bijvoorbeeld achter een proxyserver bevindt die AMQP-poorten blokkeert, moet u mogelijk de IoT Edge-agent configureren voor het gebruik van AMQP via WebSocket (AMQPWS) om de eerste verbinding met IoT Hub tot stand te brengen.

Zodra uw IoT Edge-apparaat verbinding maakt, moet u ervoor zorgen dat u de UpstreamProtocol-variabele voor beide runtimemodules in toekomstige implementaties blijft configureren. Een voorbeeld van dit proces is beschikbaar in Een IoT Edge-apparaat configureren om te communiceren via een proxyserver.

Implementatie

• Nuttig
  • Consistent zijn met het upstream-protocol
  • Hostopslag instellen voor systeemmodules
  • Geheugenruimte verminderen die wordt gebruikt door de IoT Edge-hub
  • Juiste module-installatiekopieën gebruiken in implementatiemanifesten
  • Houd rekening met limieten voor dubbelgrootte bij het gebruik van aangepaste modules
  • Configureren hoe updates voor modules worden toegepast

Consistent zijn met het upstream-protocol

Als u de IoT Edge-agent hebt geconfigureerd op uw IoT Edge-apparaat om een ander protocol te gebruiken dan de standaard AMQP, moet u hetzelfde protocol declareren in alle toekomstige implementaties. Als uw IoT Edge-apparaat zich bijvoorbeeld achter een proxyserver bevindt die AMQP-poorten blokkeert, hebt u het apparaat waarschijnlijk geconfigureerd om verbinding te maken via AMQP via WebSocket (AMQPWS). Wanneer u modules op het apparaat implementeert, configureert u hetzelfde AMQPWS-protocol voor de IoT Edge-agent en IoT Edge-hub, anders overschrijft de standaard-AMQP de instellingen en voorkomt u dat u opnieuw verbinding maakt.

U hoeft alleen de omgevingsvariabele UpstreamProtocol voor de IoT Edge-agent en IoT Edge-hubmodules te configureren. Eventuele aanvullende modules gebruiken elk protocol dat is ingesteld in de runtime-modules.

Een voorbeeld van dit proces is beschikbaar in Een IoT Edge-apparaat configureren om te communiceren via een proxyserver.

Hostopslag instellen voor systeemmodules

De IoT Edge-hub- en agentmodules maken gebruik van lokale opslag om de status te behouden en berichten tussen modules, apparaten en de cloud in te schakelen. Voor betere betrouwbaarheid en prestaties configureert u de systeemmodules voor het gebruik van opslag op het hostbestandssysteem.

Zie Hostopslag voor systeemmodules voor meer informatie.

Geheugenruimte verminderen die wordt gebruikt door IoT Edge-hub

Als u beperkte apparaten met beperkt geheugen implementeert, kunt u ioT Edge-hub configureren om te worden uitgevoerd in een meer gestroomlijnde capaciteit en minder schijfruimte te gebruiken. Deze configuraties beperken de prestaties van de IoT Edge-hub, dus zoek de juiste balans die geschikt is voor uw oplossing.

Niet optimaliseren voor prestaties op apparaten met beperkingen

De IoT Edge-hub is standaard geoptimaliseerd voor prestaties, dus er wordt geprobeerd grote segmenten geheugen toe te wijzen. Deze configuratie kan stabiliteitsproblemen veroorzaken op kleinere apparaten, zoals de Raspberry Pi. Als u apparaten met beperkte resources implementeert, kunt u de omgevingsvariabele OptimizeForPerformance instellen op false op de IoT Edge-hub.

Wanneer OptimizeForPerformance is ingesteld op true, gebruikt de hoofd van het MQTT-protocol de PooledByteBufferAllocator, die betere prestaties heeft, maar meer geheugen toewijst. De allocator werkt niet goed op 32-bits besturingssystemen of op apparaten met weinig geheugen. Bovendien wijst RocksDb, wanneer deze is geoptimaliseerd voor prestaties, meer geheugen toe voor zijn rol als lokale opslagprovider.

Zie Stabiliteitsproblemen op kleinere apparaten voor meer informatie.

Ongebruikte protocollen uitschakelen

Een andere manier om de prestaties van de IoT Edge-hub te optimaliseren en het geheugengebruik te verminderen, is door de protocolkoppen uit te schakelen voor protocollen die u niet in uw oplossing gebruikt.

Protocolkoppen worden geconfigureerd door booleaanse omgevingsvariabelen in te stellen voor de IoT Edge-hubmodule in uw implementatiemanifesten. De drie variabelen zijn:

• amqp Instellingen__enabled
• mqtt Instellingen__enabled
• http Instellingen__enabled

Alle drie de variabelen hebben twee onderstrepingstekens en kunnen worden ingesteld op waar of onwaar.

Opslagtijd voor berichten verminderen

In de IoT Edge-hubmodule worden berichten tijdelijk opgeslagen als ze om welke reden dan ook niet aan IoT Hub kunnen worden geleverd. U kunt configureren hoelang de IoT Edge-hub berichten bevat voordat ze verlopen. Als u geheugenproblemen ondervindt op uw apparaat, kunt u de timeToLiveSecs-waarde in de IoT Edge-hubmoduledubbel verlagen.

De standaardwaarde van de parameter timeToLiveSecs is 7200 seconden, wat twee uur is.

Juiste module-installatiekopieën gebruiken in implementatiemanifesten

Als er een lege of verkeerde module-installatiekopieën worden gebruikt, probeert de Edge-agent de installatiekopieën opnieuw te laden, waardoor er extra verkeer wordt gegenereerd. Voeg de juiste installatiekopieën toe aan het implementatiemanifest om onnodig verkeer te voorkomen.

Gebruik geen foutopsporingsversies van module-installatiekopieën

Wanneer u overstapt van testscenario's naar productiescenario's, moet u de foutopsporingsconfiguraties verwijderen uit implementatiemanifesten. Controleer of geen van de module-installatiekopieën in de implementatiemanifesten het achtervoegsel .debug heeft. Als u opties voor maken hebt toegevoegd om poorten beschikbaar te maken in de modules voor foutopsporing, verwijdert u deze opties voor maken ook.

Houd rekening met limieten voor dubbelgrootte bij het gebruik van aangepaste modules

Het implementatiemanifest met aangepaste modules maakt deel uit van de EdgeAgent-dubbel. Bekijk de beperking van de grootte van de moduledubbel.

Als u een groot aantal modules implementeert, kunt u deze limiet voor dubbelgrootte uitputten. Overweeg enkele veelvoorkomende oplossingen voor deze vaste limiet:

• Sla elke configuratie op in de aangepaste moduledubbel, die een eigen limiet heeft.
• Sla een configuratie op die verwijst naar een niet-ruimte-beperkte locatie (dat wil gezegd, naar een blobarchief).

Configureren hoe updates voor modules worden toegepast

Wanneer een implementatie wordt bijgewerkt, ontvangt de Edge-agent de nieuwe configuratie als een dubbele update. Als de nieuwe configuratie nieuwe of bijgewerkte module-installatiekopieën bevat, verwerkt De Edge-agent standaard elke module sequentieel:

1. De bijgewerkte afbeelding wordt gedownload
2. De actieve module is gestopt
3. Er wordt een nieuw module-exemplaar gestart
4. De volgende module-update wordt verwerkt

In sommige gevallen, bijvoorbeeld wanneer er afhankelijkheden bestaan tussen modules, kan het wenselijk zijn om eerst alle bijgewerkte module-installatiekopieën te downloaden voordat u actieve modules opnieuw start. Dit updategedrag van de module kan worden geconfigureerd door een omgevingsvariabele ModuleUpdateMode van de IoT Edge-agent in te stellen op tekenreekswaarde WaitForAllPulls. Zie IoT Edge-omgevingsvariabelen voor meer informatie.

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

Containerbeheer

• Belangrijk
  • Tags gebruiken om versies te beheren
  • Volumes beheren
• Nuttig
  • Runtimecontainers opslaan in uw privéregister
  • Garbagecollection van installatiekopieën configureren

Tags gebruiken om versies te beheren

Een tag is een docker-concept dat u kunt gebruiken om onderscheid te maken tussen versies van docker-containers. Tags zijn achtervoegsels zoals 1.5 die aan het einde van een containeropslagplaats gaan. Bijvoorbeeld mcr.microsoft.com/azureiotedge-agent:1.5. Tags zijn veranderlijk en kunnen op elk gewenst moment worden gewijzigd zodat deze naar een andere container verwijzen, zodat uw team het eens moet zijn over een conventie die moet worden gevolgd wanneer u de module-installatiekopieën bijwerkt.

Tags helpen u ook bij het afdwingen van updates op uw IoT Edge-apparaten. Wanneer u een bijgewerkte versie van een module naar uw containerregister pusht, moet u de tag verhogen. Push vervolgens een nieuwe implementatie naar uw apparaten met de tag verhoogd. De containerengine herkent de incrementele tag als een nieuwe versie en haalt de meest recente moduleversie naar uw apparaat.

Tags voor de IoT Edge-runtime

De IoT Edge-agent- en IoT Edge-hubinstallatiekopieën worden gelabeld met de IoT Edge-versie waaraan ze zijn gekoppeld. Er zijn twee verschillende manieren om tags te gebruiken met de runtime-installatiekopieën:

• Rolling tags : gebruik alleen de eerste twee waarden van het versienummer om de meest recente installatiekopieën op te halen die overeenkomen met die cijfers. 1.5 wordt bijvoorbeeld bijgewerkt wanneer er een nieuwe release is die verwijst naar de nieuwste versie 1.5.x. Als de containerruntime op uw IoT Edge-apparaat de installatiekopie opnieuw ophaalt, worden de runtimemodules bijgewerkt naar de nieuwste versie. Implementaties vanuit Azure Portal zijn standaard ingesteld op rolling tags. Deze benadering wordt voorgesteld voor ontwikkelingsdoeleinden.

• Specifieke tags : gebruik alle drie de waarden van het versienummer om de versie van de installatiekopieën expliciet in te stellen. 1.5.0 wordt bijvoorbeeld niet gewijzigd na de eerste release. U kunt een nieuw versienummer declareren in het implementatiemanifest wanneer u klaar bent om bij te werken. Deze benadering wordt voorgesteld voor productiedoeleinden.

Volumes beheren

IoT Edge verwijdert geen volumes die zijn gekoppeld aan de modulecontainers. Dit gedrag is standaard, omdat hiermee de gegevens kunnen worden bewaard in containerinstanties, zoals upgradescenario's. Als deze volumes echter ongebruikt blijven, kan dit leiden tot uitputting van de schijfruimte en daaropvolgende systeemfouten. Als u docker-volumes in uw scenario gebruikt, raden we u aan docker-hulpprogramma's zoals docker-volumes prune en docker volume rm te gebruiken om de ongebruikte volumes te verwijderen, met name voor productiescenario's.

Runtimecontainers opslaan in uw privéregister

U weet hoe u containerinstallatiekopieën kunt opslaan voor aangepaste codemodules in uw persoonlijke Azure-register, maar u kunt deze ook gebruiken om openbare containerinstallatiekopieën op te slaan, zoals de edgeAgent - en edgeHub-runtimemodules . Dit kan nodig zijn als u zeer strikte firewallbeperkingen hebt, omdat deze runtimecontainers worden opgeslagen in het Microsoft Container Registry (MCR).

De volgende stappen laten zien hoe u een Docker-installatiekopie van edgeAgent en EdgeHub naar uw lokale computer haalt, deze opnieuw tagt, pusht naar uw privéregister en vervolgens uw configuratiebestand bijwerkt, zodat uw apparaten de installatiekopie uit uw privéregister kunnen ophalen.

1. Haal de EdgeAgent Docker-installatiekopie op uit het Microsoft-register. Werk indien nodig het versienummer bij.

   # 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. Vermeld al uw Docker-installatiekopieën, zoek de edgeAgent - en edgeHub-installatiekopieën en kopieer vervolgens hun installatiekopie-id's.

   docker images
   

3. Tag uw edgeAgent - en edgeHub-installatiekopieën opnieuw. Vervang de waarden tussen vierkante haken door uw eigen waarden.

   # 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. Push uw edgeAgent - en EdgeHub-installatiekopieën naar uw privéregister. Vervang de waarde tussen vierkante haken door uw eigen waarde.

   # 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. Werk de installatiekopieën in het deployment.template.json-bestand voor de edgeAgent - en edgeHub-systeemmodules bij door uw eigen registernaam/server te vervangen mcr.microsoft.com door beide modules.

6. Open een teksteditor op uw IoT Edge-apparaat om het configuratiebestand te wijzigen, zodat het weet wat uw persoonlijke registerinstallatiekopieën zijn.

   sudo nano /etc/aziot/config.toml
   

7. Wijzig in de teksteditor de afbeeldingswaarden onder [agent.config]. Vervang de waarden tussen vierkante haken door uw eigen waarden.

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

8. Als voor uw privéregister verificatie is vereist, stelt u de verificatieparameters in [agent.config.auth].

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

9. Sla uw wijzigingen op en sluit de teksteditor af.

10. Pas de configuratiewijziging van IoT Edge toe.

    sudo iotedge config apply
    

    Uw IoT Edge-runtime wordt opnieuw opgestart.

Zie voor meer informatie:

• De IoT Edge-agent configureren
• Azure IoT Edge-agent
• Azure IoT Edge Hub

Garbagecollection van installatiekopieën configureren

Garbagecollection van installatiekopieën is een functie in IoT Edge v1.4 en hoger om automatisch Docker-installatiekopieën op te schonen die niet meer worden gebruikt door IoT Edge-modules. Er worden alleen Docker-installatiekopieën verwijderd die zijn opgehaald door de IoT Edge-runtime als onderdeel van een implementatie. Als u ongebruikte Docker-installatiekopieën verwijdert, bespaart u schijfruimte.

De functie wordt geïmplementeerd in het hostonderdeel van IoT Edge, de aziot-edged service en standaard ingeschakeld. Het opschonen wordt elke dag om middernacht uitgevoerd (lokale tijd van het apparaat) en verwijdert ongebruikte Docker-installatiekopieën die zeven dagen geleden zijn gebruikt. De parameters voor het beheren van het opschoongedrag worden ingesteld in de config.toml en worden verderop in deze sectie uitgelegd. Als parameters niet zijn opgegeven in het configuratiebestand, worden de standaardwaarden toegepast.

Het volgende is bijvoorbeeld de sectie garbagecollection van de config.toml installatiekopieën met behulp van standaardwaarden:

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

In de volgende tabel worden parameters voor garbagecollection van de installatiekopieën beschreven. Alle parameters zijn optioneel en kunnen afzonderlijk worden ingesteld om de standaardinstellingen te wijzigen.

Parameter	Omschrijving	Vereist	Default value
enabled	Hiermee schakelt u de garbagecollection van de installatiekopieën in. U kunt ervoor kiezen om de functie uit te schakelen door deze instelling te wijzigen in false.	Optioneel	true
cleanup_recurrence	Hiermee bepaalt u de terugkeerfrequentie van de opschoontaak. Moet worden opgegeven als een veelvoud van dagen en mag niet minder dan één dag zijn. Bijvoorbeeld: 1d, 2d, 6d, enzovoort.	Optioneel	1 d
image_age_cleanup_threshold	Definieert de minimale leeftijdsdrempel van ongebruikte afbeeldingen voordat u overweegt op te ruimen en moet worden opgegeven in dagen. U kunt opgeven als 0d om de installatiekopieën op te schonen zodra ze uit de implementatie zijn verwijderd. Installatiekopieën worden als ongebruikt beschouwd nadat ze uit de implementatie zijn verwijderd.	Optioneel	7 d
cleanup_time	Tijdstip van de dag, in lokale tijd van het apparaat, wanneer de opschoontaak wordt uitgevoerd. Moet de 24-uurs HH:MM-indeling hebben.	Optioneel	00:00

Netwerken

• Nuttig
  • Uitgaande/inkomende configuratie controleren
  • Verbindingen van IoT Edge-apparaten toestaan
  • Communicatie configureren via een proxy
  • DNS-server instellen in instellingen voor containerengine

Uitgaande/inkomende configuratie controleren

Communicatiekanalen tussen Azure IoT Hub en IoT Edge zijn altijd geconfigureerd om uitgaand te zijn. Voor de meeste IoT Edge-scenario's zijn slechts drie verbindingen nodig. De containerengine moet verbinding maken met het containerregister (of registers) met de moduleinstallatiekopieën. De IoT Edge-runtime moet verbinding maken met IoT Hub om apparaatconfiguratiegegevens op te halen en berichten en telemetrie te verzenden. En als u automatische inrichting gebruikt, moet IoT Edge verbinding maken met Device Provisioning Service. Zie Firewall- en poortconfiguratieregels voor meer informatie.

Verbindingen van IoT Edge-apparaten toestaan

Als uw netwerkinstallatie vereist dat u verbindingen van IoT Edge-apparaten expliciet toestaat, raadpleegt u de volgende lijst met IoT Edge-onderdelen:

• IoT Edge-agent opent een permanente AMQP-/MQTT-verbinding met IoT Hub, mogelijk via WebSockets.
• IoT Edge-hub opent één permanente AMQP-verbinding of meerdere MQTT-verbindingen met IoT Hub, mogelijk via WebSockets.
• De IoT Edge-service voert onregelmatige HTTPS-aanroepen naar IoT Hub uit.

In alle drie gevallen komt de FQDN (Fully Qualified Domain Name) overeen met het patroon \*.azure-devices.net.

Containerregisters

De containerengine roept containerregisters via HTTPS aan. Als u de installatiekopieën van de IoT Edge-runtimecontainer wilt ophalen, is mcr.microsoft.comde FQDN. De containerengine maakt verbinding met andere registers zoals geconfigureerd in de implementatie.

Deze controlelijst is een startpunt voor firewallregels:

FQDN (* = jokerteken)	Uitgaande TCP-poorten	Gebruik
mcr.microsoft.com	443	Microsoft Container Registry
*.data.mcr.microsoft.com	443	Gegevenseindpunt dat inhoud levert
*.cdn.azcr.io	443	Modules implementeren vanuit Marketplace op apparaten
global.azure-devices-provisioning.net	443	Toegang tot Device Provisioning Service (optioneel)
*.azurecr.io	443	Persoonlijke en externe containerregisters
*.blob.core.windows.net	443	Azure Container Registry-installatiekopieën downloaden uit blobopslag
*.azure-devices.net	5671, 8883, 4431	Toegang tot IoT Hub
*.docker.io	443	Docker Hub-toegang (optioneel)

¹Open poort 8883 voor beveiligde MQTT of poort 5671 voor beveiligde AMQP. Als u alleen verbindingen kunt maken via poort 443, kan een van deze protocollen worden uitgevoerd via een WebSocket-tunnel.

Omdat het IP-adres van een IoT-hub zonder kennisgeving kan worden gewijzigd, gebruikt u altijd de FQDN om de configuratie van de acceptatielijst toe te staan. Zie Inzicht in het IP-adres van uw IoT Hub voor meer informatie.

Sommige van deze firewallregels worden overgenomen van Azure Container Registry. Zie Regels configureren voor toegang tot een Azure-containerregister achter een firewall voor meer informatie.

U kunt toegewezen gegevenseindpunten inschakelen in uw Azure Container Registry om acceptatielijst met jokertekens van de FQDN van *.blob.core.windows.net te voorkomen. Zie Toegewezen gegevenseindpunten inschakelen voor meer informatie.

Notitie

Als u een consistente FQDN wilt bieden tussen de REST- en gegevenseindpunten, wordt vanaf 15 juni 2020 het microsoft Container Registry-gegevenseindpunt gewijzigd van *.cdn.mscr.io in *.data.mcr.microsoft.com
Zie de configuratie van firewallregels voor de Microsoft Container Registry-client voor meer informatie

Als u uw firewall niet wilt configureren om toegang tot openbare containerregisters toe te staan, kunt u installatiekopieën opslaan in uw privécontainerregister, zoals beschreven in Store Runtime-containers in uw privéregister.

Azure IoT Identity Service

De IoT Identity Service biedt inrichtings- en cryptografische services voor Azure IoT-apparaten. De identiteitsservice controleert of de geïnstalleerde versie de nieuwste versie is. De controle gebruikt de volgende FQDN's om de versie te controleren.

FQDN	Uitgaande TCP-poorten	Gebruik
aka.ms	443	Vanity-URL die omleiding naar het versiebestand biedt
raw.githubusercontent.com	443	Het versiebestand van de identiteitsservice dat wordt gehost in GitHub

Communicatie configureren via een proxy

Als uw apparaten worden geïmplementeerd in een netwerk dat gebruikmaakt van een proxyserver, moeten ze kunnen communiceren via de proxy om IoT Hub en containerregisters te bereiken. Zie Een IoT Edge-apparaat configureren voor communicatie via een proxyserver voor meer informatie.

DNS-server instellen in instellingen voor containerengine

Geef de DNS-server voor uw omgeving op in de instellingen van de containerengine. De DNS-serverinstelling is van toepassing op alle containermodules die door de engine zijn gestart.

1. Bewerk het daemon.json bestand in de /etc/docker map op uw apparaat. Maak het bestand als het niet bestaat.

2. Voeg de DNS-sleutel toe en stel het DNS-serveradres in op een openbaar toegankelijke DNS-service. Als uw edge-apparaat geen toegang heeft tot een openbare DNS-server, gebruikt u een toegankelijk DNS-serveradres in uw netwerk. Voorbeeld:

   {
       "dns": ["1.1.1.1"]
   }
   

Oplossingsbeheer

• Nuttig
  • Logboeken en diagnostische gegevens instellen
  • Standaardstuurprogramma voor logboekregistratie instellen
  • Overweeg tests en CI/CD-pijplijnen

Logboeken en diagnostische gegevens instellen

In Linux gebruikt de IoT Edge-daemon logboeken als het standaardstuurprogramma voor logboekregistratie. U kunt het opdrachtregelprogramma journalctl gebruiken om een query uit te voeren op de daemon-logboeken.

Vanaf versie 1.2 is IoT Edge afhankelijk van meerdere daemons. Hoewel de logboeken van elke daemon afzonderlijk kunnen worden opgevraagd journalctl, bieden de iotedge system opdrachten een handige manier om query's uit te voeren op de gecombineerde logboeken.

• Geconsolideerde iotedge opdracht:

  sudo iotedge system logs
  

• Equivalente journalctl opdracht:

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

Wanneer u een IoT Edge-implementatie test, hebt u meestal toegang tot uw apparaten om logboeken op te halen en problemen op te lossen. In een implementatiescenario hebt u deze optie mogelijk niet. Bedenk hoe u informatie over uw apparaten in productie gaat verzamelen. Een optie is om een logboekregistratiemodule te gebruiken waarmee gegevens uit de andere modules worden verzameld en naar de cloud worden verzonden. Een voorbeeld van een logboekmodule is logspout-loganalytics, of u kunt uw eigen module ontwerpen.

Standaardstuurprogramma voor logboekregistratie instellen

De Moby-containerengine stelt standaard geen limieten in voor de grootte van het containerlogboek. Na verloop van tijd kan dit ertoe leiden dat het apparaat vol raakt met logboeken en onvoldoende schijfruimte heeft. Configureer uw containerengine om het local logboekregistratiestuurprogramma te gebruiken als het mechanisme voor logboekregistratie. Local Het stuurprogramma voor logboekregistratie biedt een standaardlimiet voor logboekgrootte, voert standaard logboekrotatie uit en maakt gebruik van een efficiëntere bestandsindeling die helpt om uitputting van schijfruimte te voorkomen. U kunt er ook voor kiezen om verschillende stuurprogramma's voor logboekregistratie te gebruiken en verschillende groottelimieten in te stellen op basis van uw behoeften.

Optie: Het standaardstuurprogramma voor logboekregistratie configureren voor alle containermodules

U kunt uw containerengine configureren voor het gebruik van een specifiek logboekstuurprogramma door de waarde van log driver het logboekstuurprogramma in te stellen op de naam van het logboekstuurprogramma in de daemon.json. In het volgende voorbeeld wordt het standaardstuurprogramma voor logboekregistratie ingesteld op het local logboekstuurprogramma (aanbevolen).

{
    "log-driver": "local"
}

U kunt uw log-opts sleutels ook configureren voor het gebruik van de juiste waarden in het daemon.json bestand. In het volgende voorbeeld wordt het logboekstuurprogramma local ingesteld op en stelt u de max-size en max-file opties in.

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

Voeg deze informatie toe (of voeg deze toe aan een bestand met de naam daemon.json en plaats deze op de volgende locatie):

• /etc/docker/

De containerengine moet opnieuw worden gestart om de wijzigingen van kracht te laten worden.

Optie: Logboekinstellingen voor elke containermodule aanpassen

U kunt dit doen in de createOptions van elke module. Voorbeeld:

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

Aanvullende opties op Linux-systemen

• Configureer de containerengine om logboeken naar logboek te systemdverzenden door de instelling in te stellen journald als het standaardstuurprogramma voor logboekregistratie.

• Verwijder regelmatig oude logboeken van uw apparaat door een logrotate-hulpprogramma te installeren. Gebruik de volgende bestandsspecificatie:

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

Overweeg tests en CI/CD-pijplijnen

Voor het meest efficiënte IoT Edge-implementatiescenario kunt u overwegen om uw productie-implementatie te integreren in uw test- en CI/CD-pijplijnen. Azure IoT Edge ondersteunt meerdere CI/CD-platforms, waaronder Azure DevOps. Zie Continue integratie en continue implementatie in Azure IoT Edge voor meer informatie.

Beveiligingsoverwegingen

• Belangrijk
  • Toegang tot uw containerregister beheren
  • Containertoegang tot hostbronnen beperken

Toegang tot uw containerregister beheren

Voordat u modules implementeert op IoT Edge-apparaten in productie, moet u ervoor zorgen dat u de toegang tot uw containerregister kunt beheren, zodat externen geen toegang hebben tot of wijzigingen kunnen aanbrengen in uw containerinstallatiekopieën. Gebruik een privécontainerregister om containerinstallatiekopieën te beheren.

In de zelfstudies en andere documentatie wordt u geïnstrueerd om dezelfde containerregisterreferenties te gebruiken op uw IoT Edge-apparaat als u op uw ontwikkelcomputer gebruikt. Deze instructies zijn alleen bedoeld om u te helpen bij het instellen van test- en ontwikkelomgevingen en mogen niet worden gevolgd in een productiescenario.

Voor een veiligere toegang tot uw register hebt u een keuze uit verificatieopties. Een populaire en aanbevolen verificatie is het gebruik van een Active Directory-service-principal die geschikt is voor toepassingen of services om containerinstallatiekopieën op een geautomatiseerde of anderszins niet-beheerde (headless) manier op te halen, zoals IoT Edge-apparaten doen. Een andere optie is het gebruik van tokens binnen het bereik van de opslagplaats, waarmee u lange of korte live identiteiten kunt maken die alleen bestaan in het Azure Container Registry waarin ze zijn gemaakt en toegang tot het niveau van de opslagplaats.

Als u een service-principal wilt maken, voert u de twee scripts uit zoals beschreven in een service-principal maken. Met deze scripts worden de volgende taken uitgevoerd:

• Met het eerste script wordt de service-principal gemaakt. De service-principal-id en het wachtwoord van de service-principal worden uitgevoerd. Sla deze waarden veilig op in uw records.

• Met het tweede script worden roltoewijzingen gemaakt die moeten worden verleend aan de service-principal, die vervolgens, indien nodig, kunnen worden uitgevoerd. U wordt aangeraden de acrPull-gebruikersrol voor de role parameter toe te passen. Zie Azure Container Registry-rollen en -machtigingen voor een lijst met rollen.

Als u wilt verifiëren met behulp van een service-principal, geeft u de service-principal-id en het wachtwoord op die u hebt verkregen uit het eerste script. Geef deze referenties op in het implementatiemanifest.

• Geef voor de gebruikersnaam of client-id de service-principal-id op.

• Geef voor het wachtwoord of clientgeheim het wachtwoord van de service-principal op.

Als u tokens met opslagplaatsbereik wilt maken, volgt u een token met opslagplaatsbereik.

Als u wilt verifiëren met tokens binnen het bereik van de opslagplaats, geeft u de tokennaam en het wachtwoord op die u hebt verkregen nadat u het token met opslagplaatsbereik hebt gemaakt. Geef deze referenties op in het implementatiemanifest.

• Geef voor de gebruikersnaam de gebruikersnaam van het token op.

• Geef voor het wachtwoord een van de wachtwoorden van het token op.

Notitie

Nadat u een verbeterde beveiligingsverificatie hebt geïmplementeerd, schakelt u de Beheer gebruikersinstelling uit, zodat de standaardtoegang tot gebruikersnaam en wachtwoord niet meer beschikbaar is. Selecteer toegangssleutels in het containerregister in Azure Portal in het linkerdeelvenstermenu onder Instellingen.

Containertoegang tot hostbronnen beperken

Als u de gedeelde hostresources wilt verdelen over modules, raden we u aan limieten in te stellen voor het resourceverbruik per module. Deze limieten zorgen ervoor dat één module niet te veel geheugen of CPU-gebruik kan verbruiken en voorkomen dat andere processen op het apparaat worden uitgevoerd. Het IoT Edge-platform beperkt de resources voor modules niet standaard, omdat testen vereist zijn om te weten hoeveel resources een bepaalde module optimaal moet uitvoeren.

Docker biedt enkele beperkingen die u kunt gebruiken om resources zoals geheugen en CPU-gebruik te beperken. Zie Runtime-opties met geheugen, CPU's en GPU's voor meer informatie.

Deze beperkingen kunnen worden toegepast op afzonderlijke modules met behulp van maakopties in implementatiemanifesten. Zie Opties voor het maken van containers configureren voor IoT Edge-modules voor meer informatie.

Volgende stappen

• Meer informatie over automatische implementatie van IoT Edge.
• Bekijk hoe IoT Edge continue integratie en continue implementatie ondersteunt.