Förbereda distributionen av IoT Edge i produktion

När du är redo att ta din IoT Edge från utveckling till produktion ser du till att den är konfigurerad för löpande prestanda.

Informationen i den här artikeln är inte alla lika. För att hjälpa dig att prioritera börjar varje avsnitt med listor som delar upp arbetet i två delar: viktigt att slutföra innan du går till produktion eller som är användbart för dig att veta.

Enhetskonfiguration

IoT Edge enheter kan vara allt från en Raspberry Pi till en bärbar dator till en virtuell dator som körs på en server. Du kan ha åtkomst till enheten antingen fysiskt eller via en virtuell anslutning, eller så kan den vara isolerad under längre tidsperioder. Hur som helst vill du se till att den är konfigurerad för att fungera korrekt.

• Viktigt

  • Installera produktionscertifikat
  • Ha en plan för enhetshantering
  • Använda Moby som containermotor

• Hjälp

  • Välj uppströmsprotokoll

Installera produktionscertifikat

Varje IoT Edge enhet i produktion måste ha ett certifikat från enhetscertifikatutfärdaren (CA) installerat på den. Certifikatutfärdaren deklareras sedan till IoT Edge i konfigurationsfilen. I utvecklings- och testningsscenarier skapar IoT Edge tillfälliga certifikat om inga certifikat deklareras i konfigurationsfilen. Dessa tillfälliga certifikat upphör dock att gälla efter tre månader och är inte säkra för produktionsscenarier. I produktionsscenarier bör du ange ett eget ca-certifikat för enheten, antingen från en själv signerad certifikatutfärdare eller köpt från en kommersiell certifikatutfärdare.

Information om rollen för ca-certifikatet för enheten finns i Hur Azure IoT Edge använder certifikat.

Mer information om hur du installerar certifikat på en IoT Edge-enhet och refererar till dem från konfigurationsfilen finns i Hantera certifikat på en IoT Edge enhet.

Ha en plan för enhetshantering

Innan du sätter en enhet i produktion bör du veta hur du kommer att hantera framtida uppdateringar. För en IoT Edge enhet kan listan över komponenter som ska uppdateras innehålla:

• Enhetens inbyggda programvara
• Operativsystembibliotek
• Containermotor, som Moby
• IoT Edge
• CA-Certifikat

Mer information finns i Uppdatera IoT Edge runtime. De aktuella metoderna för att IoT Edge kräver fysisk eller SSH-åtkomst till IoT Edge enhet. Om du har många enheter att uppdatera kan du överväga att lägga till uppdateringsstegen i ett skript eller använda ett automatiseringsverktyg som Ansible.

Använda Moby som containermotor

En containermotor är en förutsättning för alla IoT Edge enheter. Endast moby-engine stöds i produktion. Andra containermotorer, som Docker, fungerar med IoT Edge och det är ok att använda dessa motorer för utveckling. Moby-motorn kan distribueras om när den används med Azure IoT Edge och Microsoft tillhandahåller underhåll för den här motorn.

Välj uppströmsprotokoll

Du kan konfigurera protokollet (som avgör vilken port som används) för överordnad kommunikation till IoT Hub för både IoT Edge-agenten och IoT Edge hubben. Standardprotokollet är AMQP, men du kanske vill ändra det beroende på nätverkskonfigurationen.

De två körningsmodulerna har båda miljövariabeln UpstreamProtocol. Giltiga värden för variabeln är:

• MQTT
• AMQP
• MQTTWS
• AMQPWS

Konfigurera variabeln UpstreamProtocol för IoT Edge-agenten i konfigurationsfilen på själva enheten. Om din IoT Edge-enhet till exempel finns bakom en proxyserver som blockerar AMQP-portar kan du behöva konfigurera IoT Edge-agenten att använda AMQP via WebSocket (AMQPWS) för att upprätta den första anslutningen till IoT Hub.

När din IoT Edge ansluter måste du fortsätta att konfigurera variabeln UpstreamProtocol för båda körningsmodulerna i framtida distributioner. Ett exempel på den här processen finns i Konfigurera en IoT Edge enhet för att kommunicera via en proxyserver.

Distribution

• Hjälp
  • Vara konsekvent med överordnade protokoll
  • Konfigurera värdlagring för systemmoduler
  • Minska minnesutrymmet som används av IoT Edge hubben
  • Använd inte felsökningsversioner av modulavbildningar

Vara konsekvent med överordnade protokoll

Om du har konfigurerat IoT Edge-agenten på din IoT Edge-enhet att använda ett annat protokoll än standard-AMQP bör du deklarera samma protokoll i alla framtida distributioner. Om din IoT Edge till exempel finns bakom en proxyserver som blockerar AMQP-portar har du förmodligen konfigurerat enheten så att den ansluter via AMQP via WebSocket (AMQPWS). När du distribuerar moduler till enheten konfigurerar du samma AMQPWS-protokoll för IoT Edge-agenten och IoT Edge-hubben. Annars åsidosätter standard-AMQP inställningarna och hindrar dig från att ansluta igen.

Du behöver bara konfigurera miljövariabeln UpstreamProtocol för IoT Edge agent och IoT Edge hub-moduler. Eventuella ytterligare moduler använder det protokoll som anges i körningsmodulerna.

Ett exempel på den här processen finns i Konfigurera en IoT Edge enhet för att kommunicera via en proxyserver.

Konfigurera värdlagring för systemmoduler

Modulerna IoT Edge hubb och agent använder lokal lagring för att upprätthålla tillståndet och aktivera meddelanden mellan moduler, enheter och molnet. För bättre tillförlitlighet och prestanda konfigurerar du systemmodulerna så att de använder lagring i värdfilsystemet.

Mer information finns i Värdlagring för systemmoduler.

Minska minnesutrymmet som används av IoT Edge hubb

Om du distribuerar begränsade enheter med begränsat tillgängligt minne kan du konfigurera IoT Edge hub så att den körs i en mer effektiviserad kapacitet och använder mindre diskutrymme. Dessa konfigurationer begränsar dock prestanda för IoT Edge hubben, så hitta rätt balans som fungerar för din lösning.

Optimera inte för prestanda på begränsade enheter

Hubben IoT Edge optimerad för prestanda som standard, så den försöker allokera stora minnesdelar. Den här konfigurationen kan orsaka stabilitetsproblem på mindre enheter som Raspberry Pi. Om du distribuerar enheter med begränsade resurser kanske du vill ange miljövariabeln OptimizeForPerformance till false på IoT Edge hubben.

När OptimizeForPerformance har angetts till true använder MQTT-protokollhuvudet PooledByteBufferAllocator, som har bättre prestanda men allokerar mer minne. -atorn fungerar inte bra på 32-bitars operativsystem eller på enheter med ont om minne. När RocksDb är optimerat för prestanda allokerar det dessutom mer minne för rollen som lokal lagringsprovider.

Mer information finns i Stabilitetsproblem på mindre enheter.

Inaktivera oanvända protokoll

Ett annat sätt att optimera prestanda för IoT Edge Hub och minska minnesanvändningen är att stänga av protokollhuvudena för alla protokoll som du inte använder i din lösning.

Protokollhuvuden konfigureras genom att ange booleska miljövariabler för IoT Edge hub-modulen i dina distributionsmanifest. De tre variablerna är:

• amqpSettings__enabled
• mqttSettings__enabled
• httpSettings__enabled

Alla tre variablerna har två understreck och kan anges till antingen true eller false.

Minska lagringstiden för meddelanden

Hubbmodulen IoT Edge lagrar meddelanden tillfälligt om de inte kan levereras till IoT Hub av någon anledning. Du kan konfigurera hur länge IoT Edge hubben ska hålla på för meddelanden som inte har gått att ta emot innan de upphör att gälla. Om du har minnesproblem på enheten kan du sänka värdet för timeToLiveSecs i IoT Edge hub-modultvillingen.

Standardvärdet för parametern timeToLiveSecs är 7 200 sekunder, vilket är två timmar.

Använd inte felsökningsversioner av modulavbildningar

Kom ihåg att ta bort felsökningskonfigurationer från distributionsmanifest när du flyttar från testscenarier till produktionsscenarier. Kontrollera att ingen av modulavbildningarna i distributionsmanifesten . har felsökningssuffixet. Om du har lagt till alternativ för att exponera portar i modulerna för felsökning tar du även bort dessa alternativ för att skapa.

Hantering av containrar

• Viktigt
  • Hantera versioner med hjälp av taggar
• Hjälp
  • Lagra körningscontainrar i ditt privata register

Hantera versioner med hjälp av taggar

En tagg är ett Docker-begrepp som du kan använda för att skilja mellan versioner av Docker-containrar. Taggar är suffix som 1.1 som hamnar i slutet av en containerdatabas. Du kan till exempel mcr.microsoft.com/azureiotedge-agent:1.1. Taggar är föränderliga och kan ändras så att de pekar på en annan container när som helst, så ditt team bör komma överens om en konvention att följa när du uppdaterar modulbilderna framöver.

Taggar hjälper dig också att framtvinga uppdateringar på IoT Edge enheter. När du push-kör en uppdaterad version av en modul till containerregistret ökar du taggen. Skicka sedan en ny distribution till dina enheter med taggen ökad. Containermotorn identifierar den inkrementerade taggen som en ny version och hämtar den senaste modulversionen till enheten.

Taggar för IoT Edge runtime

Avbildningarna IoT Edge och IoT Edge är taggade med den IoT Edge-version som de är associerade med. Det finns två olika sätt att använda taggar med körningsavbildningarna:

• Löpande taggar – Använd bara de två första värdena i versionsnumret för att hämta den senaste avbildningen som matchar dessa siffror. Till exempel uppdateras 1.1 när det finns en ny version som pekar på den senaste 1.1.x-versionen. Om containerkörningen på din IoT Edge hämtar avbildningen igen uppdateras körningsmodulerna till den senaste versionen. Distributioner från Azure Portal till löpande taggar. Den här metoden rekommenderas i utvecklingssyfte.

• Specifika taggar – Använd alla tre värdena i versionsnumret för att uttryckligen ange avbildningsversionen. Till exempel ändras inte 1.1.0 efter den första versionen. Du kan deklarera ett nytt versionsnummer i distributionsmanifestet när du är redo att uppdatera. Den här metoden rekommenderas i produktionssyfte.

Lagra körningscontainrar i ditt privata register

Du vet hur du lagrar dina containeravbildningar för anpassade kodmoduler i ditt privata Azure-register, men du kan också använda den för att lagra offentliga containeravbildningar, till exempel för edgeAgent- och edgHub-körningsmodulerna. Detta kan krävas om du har mycket nära brandväggsbegränsningar eftersom dessa körningscontainrar lagras i Microsoft Container Registry (MCR).

Hämta avbildningarna med kommandot Docker pull för att placera dem i ditt privata register. Du måste ange containerversionen under pull-åtgärden, hitta den senaste containerversionen på containerbeskrivningssidan enligt nedan och ersätta versionen i pull-kommandot om det behövs. Tänk på att du måste uppdatera avbildningarna med varje ny version IoT Edge körning.

Se sedan till att uppdatera avbildningsreferenserna i filen deployment.template.json för systemmodulerna edgeAgent och edgeHub. Ersätt mcr.microsoft.com med ditt registernamn och din server för båda modulerna.

• edgeAgent:

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

• edgeHub:

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

Nätverk

• Hjälp
  • Granska konfigurationen för utgående/inkommande
  • Tillåt anslutningar från IoT Edge enheter
  • Konfigurera kommunikation via en proxy

Granska konfigurationen för utgående/inkommande

Kommunikationskanaler mellan Azure IoT Hub och IoT Edge är alltid konfigurerade för att vara utgående. I de IoT Edge scenarier är bara tre anslutningar nödvändiga. Containermotorn måste ansluta till containerregistret (eller registren) som innehåller modulavbildningarna. Den IoT Edge körningen måste ansluta med IoT Hub för att hämta information om enhetskonfiguration och för att skicka meddelanden och telemetri. Om du använder automatisk etablering måste IoT Edge ansluta till Enhetsetableringstjänsten. Mer information finns i Brandväggs- och portkonfigurationsregler.

Tillåt anslutningar från IoT Edge enheter

Om nätverksinstallationen kräver att du uttryckligen tillåter anslutningar från IoT Edge enheter granskar du följande lista över IoT Edge-komponenter:

• IoT Edge agenten öppnar en beständig AMQP/MQTT-anslutning till IoT Hub, eventuellt via WebSockets.
• IoT Edge hubben öppnar en enskild beständig AMQP-anslutning eller flera MQTT-anslutningar till IoT Hub, eventuellt via WebSockets.
• IoT Edge tjänsten gör tillfälliga HTTPS-anrop till IoT Hub.

I samtliga tre fall skulle DNS-namnet matcha mönstret * .azure-devices.net.

Dessutom gör containermotorn anrop till containerregister via HTTPS. Dns-namnet IoT Edge hämta containeravbildningarna för körningskörningen mcr.microsoft.com. Containermotorn ansluter till andra register enligt konfiguration i distributionen.

Den här checklistan är en startpunkt för brandväggsregler:

Vissa av dessa brandväggsregler ärvs från Azure Container Registry. Mer information finns i Konfigurera regler för åtkomst till ett Azure-containerregister bakom en brandvägg.

Om du inte vill konfigurera brandväggen så att den tillåter åtkomst till offentliga containerregister kan du lagra avbildningar i ditt privata containerregister enligt beskrivningen i Lagra körningscontainrar i ditt privata register.

Konfigurera kommunikation via en proxy

Om dina enheter ska distribueras i ett nätverk som använder en proxyserver måste de kunna kommunicera via proxyn för att nå IoT Hub och containerregister. Mer information finns i Konfigurera en IoT Edge att kommunicera via en proxyserver.

Lösningshantering

• Hjälp
  • Konfigurera loggar och diagnostik
  • Placera gränser för loggstorlek
  • Överväg tester och CI/CD-pipelines

Konfigurera loggar och diagnostik

I Linux använder IoT Edge journaler som standardloggningsdrivrutin. Du kan använda kommandoradsverktyget för att journalctl köra frågor mot daemonloggarna.

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

När du testar en distribution IoT Edge kan du vanligtvis komma åt dina enheter för att hämta loggar och felsöka. I ett distributionsscenario kanske du inte har det alternativet. Fundera över hur du ska samla in information om dina enheter i produktion. Ett alternativ är att använda en loggningsmodul som samlar in information från de andra modulerna och skickar den till molnet. Ett exempel på en loggningsmodul är logspout-tieralytics,eller så kan du utforma en egen.

Placera gränser för loggstorlek

Som standard anger Moby-containermotorn inte storleksgränser för containerloggar. Detta kan med tiden leda till att enheten fylls med loggar och får slut på diskutrymme. Överväg följande alternativ för att förhindra detta:

Alternativ: Ange globala gränser som gäller för alla containermoduler

Du kan begränsa storleken på alla containerloggfiler i loggalternativen för containermotorn. I följande exempel anges loggdrivrutinen json-file till (rekommenderas) med gränser för storlek och antal filer:

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

Lägg till (eller lägg till) den här informationen i en fil daemon.json med namnet och placera den på följande plats:

Containermotorn måste startas om för att ändringarna ska börja gälla.

Alternativ: Justera logginställningarna för varje containermodul

Du kan göra det i createOptions för varje modul. Exempel:

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

Ytterligare alternativ i Linux-system

• Konfigurera containermotorn för att skicka loggar till systemd journalen genom att ange journald som standardloggningsdrivrutin.

• Ta regelbundet bort gamla loggar från enheten genom att installera ett logrotate-verktyg. Använd följande filspecifikation:

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

Överväg tester och CI/CD-pipelines

För det mest effektiva IoT Edge bör du överväga att integrera produktionsdistributionen i dina test- och CI/CD-pipelines. Azure IoT Edge stöder flera CI/CD-plattformar, inklusive Azure DevOps. Mer information finns i Kontinuerlig integrering och kontinuerlig distribution till Azure IoT Edge.

Säkerhetsöverväganden

• Viktigt
  • Hantera åtkomst till ditt containerregister
  • Begränsa containeråtkomst till värdresurser

Hantera åtkomst till ditt containerregister

Innan du distribuerar moduler till IoT Edge-enheter måste du kontrollera åtkomsten till containerregistret så att externa användare inte kan komma åt eller göra ändringar i containeravbildningarna. Använd ett privat containerregister för att hantera containeravbildningar.

I självstudierna och annan dokumentation instruerar vi dig att använda samma autentiseringsuppgifter för containerregistret på din IoT Edge som du använder på utvecklingsdatorn. De här anvisningarna är endast avsedda att hjälpa dig att konfigurera test- och utvecklingsmiljöer enklare och bör inte följas i ett produktionsscenario.

Om du vill ha en mer säker åtkomst till registret kan du välja mellan autentiseringsalternativen. En populär och rekommenderad autentisering är att använda ett Active Directory-tjänsthuvudnamn som passar bra för program eller tjänster för att hämta containeravbildningar på ett automatiserat eller på annat sätt obevakat (huvudlöst) sätt, som IoT Edge enheter gör. Ett annat alternativ är att använda token som är begränsade till lagringsplatsen, vilket gör att du kan skapa långa eller korta live-identiteter som bara finns i den Azure Container Registry som de skapades i och begränsa åtkomsten till lagringsplatsens nivå.

Om du vill skapa ett huvudnamn för tjänsten kör du de två skripten enligt beskrivningen i skapa ett huvudnamn för tjänsten. De här skripten utför följande uppgifter:

• Det första skriptet skapar tjänstens huvudnamn. Den matar ut ID:t för tjänstens huvudnamn och lösenordet för tjänstens huvudnamn. Lagra dessa värden på ett säkert sätt i dina poster.

• Det andra skriptet skapar rolltilldelningar som ska tilldelas tjänstens huvudnamn, som kan köras senare om det behövs. Vi rekommenderar att du använder användarrollen acrPull för role parametern . En lista över roller finns i Azure Container Registry roller och behörigheter.

Om du vill autentisera med hjälp av ett huvudnamn för tjänsten anger du id och lösenord för tjänstens huvudnamn som du fick från det första skriptet. Ange dessa autentiseringsuppgifter i distributionsmanifestet.

• Ange ID för tjänstens huvudnamn som användarnamn eller klient-ID.

• För lösenordet eller klienthemligheten anger du lösenordet för tjänstens huvudnamn.

Om du vill skapa token som är begränsade till lagringsplatsen följer du skapa en token som är begränsad till lagringsplatsen.

Om du vill autentisera med token som är begränsade till lagringsplatsen anger du det tokennamn och lösenord som du fick när du skapade din token som är begränsad till lagringsplatsen. Ange dessa autentiseringsuppgifter i distributionsmanifestet.

• För användarnamnet anger du tokens användarnamn.

• För lösenordet anger du ett av tokens lösenord.

Begränsa containeråtkomst till värdresurser

Om du vill balansera delade värdresurser mellan moduler rekommenderar vi att du begränsar resursförbrukningen per modul. Dessa begränsningar säkerställer att en modul inte kan använda för mycket minne eller CPU-användning och förhindra att andra processer körs på enheten. Plattformen IoT Edge inte resurser för moduler som standard, eftersom det krävs testning för att veta hur mycket resurs en viss modul behöver köra optimalt.

Docker innehåller vissa begränsningar som du kan använda för att begränsa resurser som minne och CPU-användning. Mer information finns i Körningsalternativ med minne, processorer och GPU:er.

Dessa begränsningar kan tillämpas på enskilda moduler med hjälp av skapa-alternativ i distributionsmanifest. Mer information finns i Så här konfigurerar du alternativ för att skapa containrar IoT Edge moduler.

Nästa steg

• Läs mer om IoT Edge automatisk distribution.
• Se hur IoT Edge har stöd för kontinuerlig integrering och kontinuerlig distribution.