De implementatie van uw IoT Edge in productie voorbereiden

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

De informatie in dit artikel is niet allemaal gelijk. Om u te helpen prioriteiten te stellen, 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 fysiek of via een virtuele verbinding toegang tot het apparaat of is het gedurende langere tijd geïsoleerd. Hoe dan ook, u wilt er zeker van zijn dat deze juist werkt.

• Belangrijk

  • Productiecertificaten installeren
  • Een apparaatbeheerplan hebben
  • Moby gebruiken als de container-engine

• Nuttig

  • Upstream-protocol kiezen

Productiecertificaten installeren

Op IoT Edge apparaat in productie moet een ca-certificaat (device certificate authority) zijn geïnstalleerd. Dat CA-certificaat wordt vervolgens gedeclareerd bij IoT Edge runtime in het configuratiebestand. Voor ontwikkelings- en testscenario's maakt IoT Edge tijdelijke certificaten als er geen certificaten zijn gedeclareerd in het configuratiebestand. Deze tijdelijke certificaten verlopen echter na drie maanden en zijn niet beveiligd voor productiescenario's. Voor productiescenario's moet u uw eigen CA-certificaat voor apparaten verstrekken, ofwel van een zelf-ondertekende certificeringsinstantie of aangeschaft bij een commerciële certificeringsinstantie.

Zie How Azure IoT Edge uses certificates (Hoe gebruikt Azure IoT Edge certificaten) voor meer inzicht in de rol van het CA-certificaat voor apparaten.

Zie Certificaat op een IoT Edge beheren voor meer informatie over het installeren van certificaten op een IoT Edge-apparaat en hoe u hier vanuit het configuratiebestand naar verwijst.

Een apparaatbeheerplan hebben

Voordat u een apparaat in productie gaat nemen, moet u weten hoe u toekomstige updates gaat beheren. Voor een IoT Edge kan de lijst met bij te werken onderdelen het volgende omvatten:

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

Zie Update the IoT Edge runtime (De IoT Edge runtime bijwerken) voor meer informatie. De huidige methoden voor het bijwerken IoT Edge fysieke of SSH-toegang tot het IoT Edge apparaat. Als u veel apparaten moet bijwerken, kunt u de updatestappen toevoegen aan een script of een automatiseringshulpprogramma zoals Ansible gebruiken.

Moby gebruiken als de container-engine

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

Upstream-protocol kiezen

U kunt het protocol (waarmee de gebruikte poort wordt bepaald) 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 dit wijzigen afhankelijk van uw netwerkinstallatie.

De twee runtimemodules hebben beide een upstreamProtocol-omgevingsvariabele. 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 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.

Nadat uw IoT Edge apparaat is verbonden, moet u de variabele UpstreamProtocol blijven configureren voor beide runtimemodules in toekomstige implementaties. Een voorbeeld van dit proces is te vinden in Configure an IoT Edge device to communicate through a proxy server (Een apparaat configureren om te communiceren via een proxyserver).

Implementatie

• Nuttig
  • Consistent zijn met upstream-protocol
  • Hostopslag voor systeemmodules instellen
  • Verminder de geheugenruimte die wordt gebruikt door IoT Edge hub
  • Gebruik geen foutopsporingsversies van module-afbeeldingen

Consistent zijn met upstream-protocol

Als u de IoT Edge-agent op uw IoT Edge-apparaat hebt geconfigureerd voor het gebruik van een ander protocol dan de standaard-AMQP, moet u hetzelfde protocol declareer in alle toekomstige implementaties. Als uw IoT Edge zich bijvoorbeeld achter een proxyserver die AMQP-poorten blokkeert, hebt u het apparaat waarschijnlijk geconfigureerd om via AMQP verbinding te maken 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 overschrijven de standaard-AMQP de instellingen en voorkomt u dat u opnieuw verbinding kunt maken.

U hoeft alleen de omgevingsvariabele UpstreamProtocol te configureren voor de IoT Edge agent en IoT Edge hubmodules. Alle extra modules gebruiken elk protocol dat is ingesteld in de runtimemodules.

Een voorbeeld van dit proces is te vinden in Configure an IoT Edge device to communicate through a proxy server (Een apparaat configureren om te communiceren via een proxyserver).

Hostopslag voor systeemmodules instellen

De IoT Edge hub- en agentmodules gebruiken lokale opslag voor het onderhouden van de status en het inschakelen van berichten tussen modules, apparaten en de cloud. Voor een betere betrouwbaarheid en betere prestaties configureert u de systeemmodules voor het gebruik van opslag op het hostbestandssysteem.

Zie Hostopslag voor systeemmodules voor meer informatie.

Verminder de geheugenruimte die wordt gebruikt door IoT Edge hub

Als u beperkte apparaten implementeert met beperkt geheugen beschikbaar, kunt u IoT Edge hub zodanig configureren dat deze in een meer gestroomlijnde capaciteit wordt uitgevoerd en minder schijfruimte gebruikt. Deze configuraties beperken echter wel de prestaties van IoT Edge hub, dus zoek de juiste balans die voor uw oplossing werkt.

Niet optimaliseren voor prestaties op beperkte apparaten

De IoT Edge hub is standaard geoptimaliseerd voor prestaties, dus wordt geprobeerd grote delen van het 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 biedt, maar meer geheugen toekent. De allocator werkt niet goed op 32-bits besturingssystemen of op apparaten met weinig geheugen. Daarnaast wijst RocksDb, wanneer deze is geoptimaliseerd voor prestaties, meer geheugen toe voor de rol ervan als de 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 protocolkoppen uit te schakelen voor protocollen die u niet in uw oplossing gebruikt.

Protocolkoppen worden geconfigureerd door Booleaanse omgevingsvariabelen in te stellen voor de module IoT Edge hub in uw implementatiemanifests. De drie variabelen zijn:

• amqpSettings__enabled
• mqttSettings__enabled
• httpSettings__enabled

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

De opslagtijd voor berichten verminderen

De IoT Edge hub-module slaat berichten tijdelijk op als ze om IoT Hub reden niet kunnen worden bezorgd. U kunt configureren hoelang de IoT Edge hub niet-bezorgde berichten bevat voordat ze verlopen. Als u geheugenproblemen op uw apparaat hebt, kunt u de timeToLiveSecs-waarde in de module dubbel IoT Edge hub verlagen.

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

Gebruik geen foutopsporingsversies van module-afbeeldingen

Vergeet niet om foutopsporingsconfiguraties te verwijderen uit implementatiemanifests wanneer u overstapt van testscenario's naar productiescenario's. Controleer of geen van de module-afbeeldingen in de implementatiemanifests het . foutopsporingsachtervoegsel heeft. Als u opties voor maken hebt toegevoegd om poorten in de modules beschikbaar te maken voor debuggen, verwijdert u deze opties ook.

Containerbeheer

• Belangrijk
  • Tags gebruiken om versies te beheren
• Nuttig
  • Runtimecontainers opslaan in uw privéregister

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.1 die aan het einde van een containeropslagplaats worden geplaatst. U kunt bijvoorbeeld mcr.microsoft.com/azureiotedge-agent:1.1. Tags zijn veranderlijk en kunnen op elk moment worden gewijzigd zodat ze naar een andere container wijzen, zodat uw team akkoord moet gaan met een conventie die u moet volgen wanneer u de moduleafbeeldingen verder bij te werken.

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

Tags voor de IoT Edge runtime

De IoT Edge-agent en IoT Edge hub-afbeeldingen worden getagd met de IoT Edge versie waar ze aan zijn gekoppeld. Er zijn twee verschillende manieren om tags te gebruiken met de runtime-afbeeldingen:

• Rolling tags: gebruik alleen de eerste twee waarden van het versienummer om de meest recente afbeelding op te halen die overeenkomt met die cijfers. 1.1 wordt bijvoorbeeld bijgewerkt wanneer er een nieuwe release is die naar de nieuwste versie van 1.1.x moet wijzen. Als de containerruntime op uw IoT Edge de afbeelding opnieuw op te halen, worden de runtimemodules bijgewerkt naar de nieuwste versie. Implementaties van de Azure Portal standaard naar rolling tags. Deze aanpak wordt voorgesteld voor ontwikkelingsdoeleinden.

• Specifieke tags: gebruik alle drie de waarden van het versienummer om expliciet de versie van de afbeelding in te stellen. 1.1.0 wordt bijvoorbeeld niet gewijzigd na de eerste release. U kunt een nieuw versienummer declareer in het implementatiemanifest wanneer u klaar bent om bij te werken. Deze aanpak wordt aanbevolen voor productiedoeleinden.

Runtimecontainers opslaan in uw privéregister

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

Haal de afbeeldingen op met de Docker-pull-opdracht die u in uw privéregister wilt plaatsen. U moet de containerversie opgeven tijdens de pull-bewerking, de meest recente containerversie zoeken op de containerbeschrijvingspagina zoals hieronder en indien nodig de versie vervangen in de pull-opdracht. Let op: u moet de afbeeldingen bijwerken bij elke nieuwe release van IoT Edge runtime.

Zorg er vervolgens voor dat u de afbeeldingsverwijzingen in het bestand deployment.template.json voor de edgeAgent- en edgeHub-systeemmodules bijwerkt. Vervang mcr.microsoft.com door uw registernaam en -server voor beide modules.

• edgeAgent:

  "image": "<registry name and server>/azureiotedge-agent:1.1",

• edgeHub:

  "image": "<registry name and server>/azureiotedge-hub:1.1",

Netwerken

• Nuttig
  • Uitgaande/binnenkomende configuratie controleren
  • Verbindingen vanaf IoT Edge toestaan
  • Communicatie configureren via een proxy

Uitgaande/binnenkomende configuratie controleren

Communicatiekanalen tussen Azure IoT Hub en IoT Edge zijn altijd geconfigureerd om uitgaand te zijn. Voor de IoT Edge zijn er slechts drie verbindingen nodig. De container-engine moet verbinding maken met het containerregister (of registers) dat de module-afbeeldingen bevat. De IoT Edge runtime moet verbinding maken met IoT Hub om configuratiegegevens voor apparaten op te halen en om 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 vanaf IoT Edge toestaan

Als uw netwerkinstallatie vereist dat u verbindingen die zijn gemaakt vanaf IoT Edge apparaten expliciet toe staan, controleert 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.
• IoT Edge service maakt onregelmatige HTTPS-aanroepen naar IoT Hub.

In alle drie de gevallen komt de DNS-naam overeen met het patroon * .azure-devices.net.

Daarnaast roept de containerent engine containerregisters aan via HTTPS. Voor het ophalen van de IoT Edge-container voor de runtime wordt de DNS-naam mcr.microsoft.com. De container-engine maakt verbinding met andere registers zoals geconfigureerd in de implementatie.

Deze controlelijst is een startpunt voor firewallregels:

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.

Als u uw firewall niet wilt configureren om toegang tot openbare containerregisters toe te staan, kunt u afbeeldingen opslaan in uw persoonlijke containerregister, zoals beschreven in Runtime-containersopslaan in uw privéregister.

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 de IoT Hub en containerregisters te bereiken. Zie Configure an IoT Edge device to communicate through a proxy server (Een apparaat configureren IoT Edge te communiceren via een proxyserver) voor meer informatie.

Oplossingsbeheer

• Nuttig
  • Logboeken en diagnostische gegevens instellen
  • Limieten instellen voor logboekgrootte
  • Overweeg tests en CI/CD-pijplijnen

Logboeken en diagnostische gegevens instellen

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

. {Invoke-WebRequest -useb aka.ms/iotedge-win} | Invoke-Expression; Get-IoTEdgeLog

Wanneer u een implementatie test IoT Edge, hebt u meestal toegang tot uw apparaten om logboeken op te halen en problemen op te lossen. In een implementatiescenario hebt u die optie mogelijk niet. Denk na over hoe u informatie gaat verzamelen over uw apparaten in productie. Een optie is om een logboekregistratiemodule te gebruiken die informatie verzamelt van de andere modules en deze naar de cloud verzendt. Een voorbeeld van een module voor logboekregistratie is logspout-lytics,of u kunt uw eigen module ontwerpen.

Limieten instellen voor logboekgrootte

Standaard stelt de Moby-containerent engine geen limieten voor de grootte van containerlogboek in. In de loop van de tijd kan dit ertoe leiden dat het apparaat vol is met logboeken en dat de schijfruimte op is. Overweeg de volgende opties om dit te voorkomen:

Optie: globale limieten instellen die van toepassing zijn op alle containermodules

U kunt de grootte van alle containerlogboekbestanden in de logboekopties van de container-engine beperken. In het volgende voorbeeld wordt het logboek stuurprogramma op json-file (aanbevolen) met limieten voor de grootte en het aantal bestanden:

{
    "log-driver": "json-file",
    "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:

De container-engine moet opnieuw worden opgestart om de wijzigingen door te voeren.

Optie: Logboekinstellingen voor elke containermodule aanpassen

U kunt dit doen in createOptions van elke module. Bijvoorbeeld:

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

Aanvullende opties op Linux-systemen

• Configureer de container-engine voor het verzenden van logboeken systemd naar het logboek door in te stellen als het standaard stuurprogramma voor journald 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 uw productie-implementatie 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 naar Azure IoT Edge voor meer Azure IoT Edge.

Beveiligingsoverwegingen

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

Toegang tot uw containerregister beheren

Voordat u modules implementeert op IoT Edge-apparaten, moet u ervoor zorgen dat u de toegang tot uw containerregister controleert, zodat externe gebruikers geen toegang hebben tot uw containerafbeeldingen of er wijzigingen in kunnen aanbrengen. Gebruik een privécontainerregister om containerafbeeldingen te beheren.

In de zelfstudies en andere documentatie geven we u de instructie om dezelfde containerregisterreferenties te gebruiken op uw IoT Edge-apparaat als op uw ontwikkelmachine. Deze instructies zijn alleen bedoeld om u te helpen bij het gemakkelijker instellen van test- en ontwikkelomgevingen en moet 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 zeer geschikt is voor toepassingen of services om containerafbeeldingen automatisch of anderszins zonder toezicht (headless) 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 de Azure Container Registry waarin ze zijn gemaakt en toegang hebben tot het niveau van de opslagplaats.

Als u een service-principal wilt maken, moet u de twee scripts uitvoeren 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 aan de service-principal worden toegekend. Deze kunnen indien nodig vervolgens worden uitgevoerd. U wordt aangeraden de gebruikersrol acrPull toe te passen voor de role parameter . Zie rollen en machtigingen voor Azure Container Registry 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 via 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 binnen het bereik van de opslagplaats wilt maken, volgt u een token binnen het bereik van de opslagplaats.

Als u wilt verifiëren met behulp van tokens binnen het bereik van de opslagplaats, geeft u de tokennaam en het wachtwoord op die u hebt verkregen nadat u het token binnen het bereik van de opslagplaats 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.

Containertoegang tot hostresources beperken

Als u gedeelde hostresources tussen modules wilt in balans brengen, raden we u aan limieten in te stellen voor het resourceverbruik per module. Deze limieten zorgen ervoor dat de ene module niet te veel geheugen of CPU-gebruik kan verbruiken en dat andere processen niet op het apparaat kunnen worden uitgevoerd. Het IoT Edge beperkt resources voor modules niet standaard, omdat voor het weten hoeveel resource een bepaalde module optimaal moet worden uitgevoerd, moet worden getest.

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

Deze beperkingen kunnen worden toegepast op afzonderlijke modules door gebruik te maken van opties in implementatiemanifests. Zie How to configure container create options for IoT Edge modules (Opties voor het maken van containers configureren voor IoT Edge modules) voor meer informatie.

Volgende stappen

• Meer informatie over IoT Edge automatische implementatie.
• Zie hoe IoT Edge ondersteuning biedt voor continue integratie en continue implementatie.