Uw IoT Edge-oplossing gereedmaken voor productieimplementatie

Van toepassing op: IoT Edge 1.5

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.

Niet alle informatie in dit artikel is even belangrijk. Om u te helpen prioriteit te geven, begint elke sectie met lijsten die het werk in twee groepen verdelen: belangrijk om te voltooien voordat u naar productie gaat of nuttig om te weten.

Apparaatconfiguratie

IoT Edge apparaten kunnen van alles zijn, van een Raspberry Pi tot een laptop of een virtuele machine die op een server wordt uitgevoerd. U kunt het apparaat fysiek of via een virtuele verbinding openen, of het kan gedurende langere perioden worden geïsoleerd. Zorg er in beide gevallen voor dat deze zo is geconfigureerd dat deze op de juiste manier werkt.

• Important

  • Productiecertificaten installeren
  • Een apparaatbeheerplan hebben
  • Gebruik Moby als containerengine. Als u Ubuntu Core-snaps gebruikt, biedt Canonical services de Docker-module en ondersteunt deze voor productiescenario's.

• Helpful

  • Upstream-protocol kiezen

Productiecertificaten installeren

Elk IoT Edge-apparaat in productie heeft een certificaat van een certificaatautoriteit (CA) nodig dat op het apparaat moet worden geïnstalleerd. Declareer dat CA-certificaat voor de IoT Edge runtime in het configuratiebestand. Voor ontwikkeling en testen maakt de IoT Edge runtime tijdelijke certificaten als u geen certificaten declareert in het configuratiebestand. Maar deze tijdelijke certificaten verlopen na drie maanden en zijn niet veilig voor productiescenario's. Geef voor productiescenario's uw eigen Edge CA-certificaat op, afkomstig van een zelfondertekende certificeringsinstantie of van een commerciële certificeringsinstantie.

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

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

Een apparaatbeheerplan hebben

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

• Apparaatfirmware
• Besturingssysteembibliotheken
• Containerengine, zoals Moby
• IoT Edge
• CA-certificaten

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

Andere manieren om IoT Edge bij te werken vereisen fysieke of SSH-toegang tot het IoT Edge-apparaat. Zie Update the IoT Edge runtime voor meer informatie. Als u meerdere apparaten wilt bijwerken, kunt u de updatestappen toevoegen aan een script of een automatiseringsprogramma zoals Ansible gebruiken.

Containerengine

Er is een containerengine vereist voor elk IoT Edge apparaat. De moby-engine wordt ondersteund in de productieomgeving. Als u Ubuntu Core-snaps gebruikt, biedt Canonical services de Docker-module en ondersteunt deze voor productiescenario's. Andere containerengines, zoals Docker, werken 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 naar IoT Hub voor zowel de IoT Edge-agent als de IoT Edge hub. Het standaardprotocol is AMQP, maar mogelijk wilt u dat protocol wijzigen, afhankelijk van uw netwerkinstallatie.

Beide runtimemodules hebben een UpstreamProtocol omgevingsvariabele. De geldige waarden voor deze 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.

Nadat uw IoT Edge apparaat verbinding maakt, gaat u door met het configureren van de variabele UpstreamProtocol voor beide runtimemodules in toekomstige implementaties. Zie bijvoorbeeld Een IoT Edge-apparaat configureren om via een proxyserver te communiceren.

Deployment

• Helpful
  • Consistent zijn met het upstream-protocol.
  • Stel hostopslag in voor systeemmodules.
  • Verminder geheugenruimte die wordt gebruikt door de IoT Edge hub.
  • Gebruik de juiste module-installatiekopieën in implementatiemanifesten.
  • Houd rekening met de limieten voor dubbelgrootte wanneer u aangepaste modules gebruikt.
  • Configureer hoe updates voor modules worden toegepast.

Consistent zijn met het upstream-protocol

Als u de IoT Edge-agent op uw IoT Edge apparaat configureert voor het gebruik van een ander protocol dan de standaard AMQP, declareert u hetzelfde protocol 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. Alle aanvullende modules erven het ingestelde protocol over van de runtime-modules.

Een voorbeeld van dit proces wordt gegeven in Configure an IoT Edge device to communicate through a proxy server.

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 mogelijk te maken. 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, configureert u IoT Edge hub om in een meer gestroomlijnde capaciteit te worden uitgevoerd en minder schijfruimte te gebruiken. Deze configuratie beperkt 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, stelt u de omgevingsvariabele OptimizeForPerformance in op false op de IoT Edge hub.

Wanneer u OptimizeForPerformance instelt op true, gebruikt de hoofdcomponent 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.

Stel booleaanse omgevingsvariabelen in voor de IoT Edge hubmodule in uw implementatiemanifesten om protocolkoppen te configureren. 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.

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 hoe lang de IoT Edge hub onbezorgde berichten vasthoudt voordat ze verlopen. Als u geheugenproblemen ondervindt op uw apparaat, verlaagt u de waarde timeToLiveSecs in de IoT Edge hubmoduledubbel.

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

Juiste module-installatiekopieën gebruiken in implementatiemanifesten

Als u een lege of verkeerde module-afbeelding gebruikt, probeert de Edge-agent de afbeelding opnieuw te laden. Dit proces voor opnieuw proberen genereert extra verkeer. Voeg de juiste afbeeldingen 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 ervoor kiezen om foutopsporingsconfiguraties uit implementatiemanifesten te verwijderen. Controleer of geen van de module-installatiekopieën in de implementatiemanifesten het achtervoegsel .debug heeft. Als u creatie-opties hebt toegevoegd om poorten in de modules beschikbaar te maken voor foutopsporing, verwijdert u deze creatie-opties 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. Controleer de limiet aan de grootte van de module twin.

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

• Sla eender welke configuratie op in de aangepaste tweelingmodule, 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 u een implementatie bijwerkt, 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, zoals wanneer er afhankelijkheden bestaan tussen modules, wilt u mogelijk eerst alle bijgewerkte module-installatiekopieën downloaden voordat u actieve modules opnieuw start. U kunt dit updategedrag van de module configureren door een omgevingsvariabele IoT Edge Agent in te stellen ModuleUpdateMode op tekenreekswaarde WaitForAllPulls. Zie IoT Edge Omgevingsvariabelen voor meer informatie.

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

Containerbeheer

• Important
  • Gebruik tags om versies te beheren.
  • Opslagvolumes beheren.
• Helpful
  • Sla runtimecontainers op in uw privéregister.
  • Configureer garbage-collection van afbeeldingen.

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 containerrepository gebruikt worden. Bijvoorbeeld mcr.microsoft.com/azureiotedge-agent:1.5. Tags zijn veranderlijk en kunnen op elk gewenst moment naar een andere container verwijzen, dus uw team moet het eens worden over een conventie die moet worden gevolgd in de toekomst bij het bijwerken van uw module afbeeldingen.

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 nieuwste moduleversie op uw apparaat op.

Tags voor de IoT Edge runtime

De IoT Edge-agent en IoT Edge hub-afbeeldingen worden gelabeld met de IoT Edge versie waaraan ze 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 image op te halen die overeenkomt 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 uit de 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 afbeeldingsversie expliciet in te stellen. 1.5.0 wordt bijvoorbeeld niet gewijzigd na de eerste release. U declareert een nieuw versienummer 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 modulecontainers. Dit gedrag is standaard, omdat hiermee de gegevens kunnen worden bewaard in containerinstanties, zoals upgradescenario's. Als deze volumes echter niet worden gebruikt, kunnen ze leiden tot uitputting van schijfruimte en daaropvolgende systeemfouten. Als u Docker-volumes in uw scenario gebruikt, gebruikt u Docker-hulpprogramma's zoals docker volume prune en docker volume rm 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 zoals de edgeAgent en edgeHub runtimemodules op te slaan. Als u strikte firewallbeperkingen hebt, moet u deze runtimecontainers mogelijk opslaan in uw privéregister, omdat ze normaal 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-afbeeldingen, zoek de edgeAgent en edgeHub afbeeldingen en kopieer hun afbeeldings-ID's.

   docker images
   

3. Tag uw edgeAgent en edgeHub afbeeldingen 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 afbeeldingsreferenties in het deployment.template.json-bestand voor de edgeAgent- en edgeHub-systeemmodules bij door 'mcr.microsoft.com' te vervangen door uw eigen 'registernaam/server' voor beide modules.

6. Open een teksteditor op uw IoT Edge-apparaat om het configuratiebestand te wijzigen, zodat het weet van uw persoonlijke registerimage.

   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 IoT Edge configuratiewijziging toe.

    sudo iotedge config apply
    

    De IoT Edge runtime wordt opnieuw opgestart.

Zie voor meer informatie:

• Configureer de IoT Edge-agent
• Azure IoT Edge Agent
• Azure IoT Edge Hub

Afvalverzameling van afbeeldingen configureren

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

De aziot-edged-service, het IoT Edge hostonderdeel, implementeert deze functie en schakelt deze standaard in. Het opschoningsproces wordt elke dag om middernacht uitgevoerd (lokale tijd van het apparaat) en verwijdert ongebruikte Docker-installatiekopieën die zeven dagen geleden zijn gebruikt. U stelt de parameters in het bestand config.toml in om het opschoongedrag te beheren, en in deze sectie worden deze parameters uitgelegd. Als u geen parameters opgeeft in het configuratiebestand, zijn de standaardwaarden van toepassing.

In de volgende config.toml-sectie ziet u bijvoorbeeld de instellingen voor het opruimen van afbeeldingen met 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 garbage collection van de afbeeldingen beschreven. Alle parameters zijn optioneel. Stel ze afzonderlijk in om de standaardinstellingen te wijzigen.

Networking

• Helpful
  • Uitgaande en binnenkomende configuratie controleren
  • Verbindingen vanaf IoT Edge apparaten toestaan
  • Communicatie configureren via een proxy
  • DNS-server instellen in instellingen voor containerengine

Uitgaande en binnenkomende configuratie controleren

U configureert altijd communicatiekanalen tussen Azure IoT Hub en IoT Edge 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) waarin de module images worden opgeslagen. De IoT Edge runtime moet verbinding maken met IoT Hub om apparaatconfiguratiegegevens op te halen en berichten en telemetrie te verzenden. 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 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- of 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 gevallen komt de FQDN (Fully Qualified Domain Name) overeen met het patroon \*.azure-devices.net.

Containerregisters

De containerengine roept containerregisters via HTTPS aan. De FQDN voor het ophalen van de IoT Edge runtime-containerimages is mcr.microsoft.com. De containerengine maakt verbinding met andere registers zoals geconfigureerd in de implementatie.

Deze controlelijst is een startpunt voor firewallregels:

¹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 veranderen, gebruikt u altijd de FQDN voor de configuratie van de toestemmingslijst. Zie Onderstaand ip-adres van uw IoT Hub voor meer informatie.

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

U kunt toegewezen gegevenseindpunten inschakelen in uw Azure Containerregister om het toestaan van jokertekens van de *.blob.core.windows.net FQDN te voorkomen. Zie Toegewezen gegevenseindpunten inschakelen 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.

Communicatie configureren via een proxy

Als u uw apparaten implementeert in een netwerk dat gebruikmaakt van een proxyserver, moeten ze communiceren via de proxy om IoT Hub en containerregisters te bereiken. Zie Een IoT Edge-apparaat configureren om via een proxyserver te communiceren 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 worden gestart.

1. Bewerk het /etc/docker bestand in de daemon.json 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 DNS-serveradres dat toegankelijk is in uw netwerk. Voorbeeld:

   {
       "dns": ["1.1.1.1"]
   }
   

   Voor bedrijfsnetwerken of privénetwerken die externe DNS blokkeren, gebruikt u in plaats daarvan uw interne DNS-server:

   {
       "dns": ["10.0.0.53"]
   }
   

Oplossingsbeheer

• Helpful
  • 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. Gebruik het opdrachtregelprogramma journalctl om een query uit te voeren op de daemon-logboeken.

Vanaf versie 1.2 is IoT Edge afhankelijk van meerdere daemons. U kunt de logboeken van elke daemon individueel opvragen met behulp van journalctl. Gebruik de iotedge system opdrachten om de gecombineerde logboeken op te vragen.

• 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 verzamelt. Een optie is het gebruik van een logboekmodule waarmee gegevens uit andere modules worden verzameld en naar de cloud worden verzonden. Gebruik bijvoorbeeld logspout-loganalytics of ontwerp uw eigen logspout-loganalytics.

Standaardstuurprogramma voor logboekregistratie instellen

De Moby-containerengine stelt standaard geen limieten in voor de grootte van containerlogboeken. Na verloop van tijd kan deze standaardinstelling ertoe leiden dat het apparaat volloopt met logboeken en onvoldoende schijfruimte heeft. Stel uw containerengine in om het local stuurprogramma voor logboekregistratie te gebruiken als het mechanisme voor logboekregistratie. Het local logboekstuurprogramma biedt een standaardlimiet voor logboekgrootte, voert standaard logboekrotatie uit en maakt gebruik van een efficiëntere bestandsindeling, waardoor schijfruimteuitputting wordt voorkomen. U kunt ook verschillende stuurprogramma's voor logboekregistratie gebruiken en verschillende groottelimieten instellen op basis van uw behoeften.

Optie: Het standaardstuurprogramma voor logboekregistratie configureren voor alle containermodules

Stel uw containerengine in om een specifiek stuurprogramma voor logboekregistratie te gebruiken door de waarde van log driver in te stellen op de naam van het logstuurprogramma in het daemon.json-bestand. 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 ingesteld op local en worden de max-size en max-file opties ingesteld.

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

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

• /etc/docker/

Start de containerengine opnieuw om de wijzigingen van kracht te laten worden.

Optie: Logboekinstellingen voor elke containermodule aanpassen

Stel deze opties in de createOptions van elke module in. Voorbeeld:

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

Aanvullende opties op Linux-systemen

• Configureer de containerengine om logs naar systemdjournal te verzenden door journald als het standaard logstuurprogramma in te stellen.

• 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 de meest efficiënte IoT Edge implementatie integreert u uw productie-implementatie in uw test- en CI/CD-pijplijnen. Azure IoT Edge ondersteunt meerdere CI/CD-platforms, waaronder Azure DevOps. Zie Continuous-integratie en continue implementatie voor Azure IoT Edge voor meer informatie.

Beveiligingsoverwegingen

• Important
  • Toegang tot uw containerregister beheren.
  • Beperk containertoegang tot host-systeembronnen.

Toegang tot uw containerregister beheren

Voordat u modules implementeert op productie-IoT Edge-apparaten, moet u de toegang tot uw containerregister beheren, zodat externen geen toegang hebben tot uw containerinstallatiekopieën of deze kunnen wijzigen. Gebruik een privé-containerregister om containerafbeeldingen te beheren.

In de zelfstudies en andere documentatie gebruikt u dezelfde containerregisterreferenties op uw IoT Edge apparaat als op uw ontwikkelcomputer. Met deze instructies kunt u eenvoudiger test- en ontwikkelomgevingen instellen en niet voor productiegebruik.

Kies uit verschillende verificatieopties voor een veiligere toegang tot uw register. Gebruikmaken van een Active Directory-serviceprinciëel is een populaire en aanbevolen methode voor apps of services om containerafbeeldingen automatisch en onbeheerd op te halen, zoals IoT Edge-apparaten dat doen. U kunt ook tokens met opslagplaatsbereik gebruiken, waarmee u lange of korte identiteiten kunt maken die alleen bestaan in de Azure Container Registry waar u ze maakt en toegang tot het niveau van de opslagplaats beperkt.

Als u een service-principal wilt maken, voert u de twee scripts uit die worden beschreven in het maken van een service-principal. Deze scripts voeren de volgende stappen uit:

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

• Met het tweede script worden roltoewijzingen gemaakt die aan de service-principal moeten worden verleend. Voer deze vervolgens zo nodig uit. Gebruik de acrPull-gebruikersrol voor de role parameter. 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 id en wachtwoordreferenties van de service-principal op uit het eerste script 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 de instructies in een token met opslagplaatsbereik maken.

Als u wilt authenticeren met opslagplaats-scoped tokens, geeft u de tokennaam en wachtwoordgegevens op die u krijgt nadat u uw opslagplaats-scoped token in het implementatiemanifest hebt gemaakt.

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

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

Containertoegang tot hostbronnen beperken

Als u gedeelde hostresources in verschillende modules wilt verdelen, stelt u limieten in voor resourcegebruik voor elke module. Deze limieten zorgen ervoor dat één module niet te veel geheugen of CPU kan gebruiken en voorkomen dat andere processen op het apparaat worden uitgevoerd. Het IoT Edge-platform beperkt standaard geen resources voor modules, omdat u moet testen hoeveel resources een module goed moet uitvoeren.

Met Docker kunt u resources beperken, zoals geheugen en CPU-gebruik. Zie Runtime-opties met geheugen, CPU's en GPU's voor meer informatie.

U kunt deze beperkingen toepassen op afzonderlijke modules met behulp van maakopties in implementatiemanifesten. Zie Het configureren van opties voor het maken van containers voor IoT Edge modules voor meer informatie.

Als u bijvoorbeeld een module wilt beperken tot 256 MB geheugen en 1 CPU-kern:

"createOptions": {
    "HostConfig": {
        "Memory": 268435456,
        "NanoCPUs": 1000000000
    }
}

Volgende stappen

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