Förbereda distributionen av din IoT Edge-lösning i produktion

Artikel
04/11/2024

Gäller för: IoT Edge 1.4

Viktigt!

IoT Edge 1.4 är den version som stöds. Om du har en tidigare version läser du Uppdatera IoT Edge.

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

Informationen i den här artikeln är inte lika med. För att hjälpa dig att prioritera börjar varje avsnitt med listor som delar upp arbetet i två avsnitt: viktigt att slutföra innan du går till produktion, eller 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 isoleras under längre tidsperioder. Hur som helst vill du se till att det är konfigurerat 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 behöver ett certifikat för enhetscertifikatutfärdare (CA) installerat på den. Certifikatutfärdarcertifikatet deklareras sedan till IoT Edge-körningen i konfigurationsfilen. För utvecklings- och testscenarier skapar IoT Edge-körningen 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. För produktionsscenarier bör du ange ett eget certifikat för enhetscertifikatutfärdare, antingen från en självsignerad certifikatutfärdare eller köpt från en kommersiell certifikatutfärdare.

Information om rollen för certifikatutfärdarcertifikatet 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 placerar någon enhet i produktion bör du veta hur du ska 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

Enhetsuppdatering för IoT Hub är en tjänst som gör att du kan distribuera trådlösa uppdateringar (OTA) för dina IoT Edge-enheter.

Alternativa metoder för att uppdatera IoT Edge kräver fysisk eller SSH-åtkomst till IoT Edge-enheten. Mer information finns i Uppdatera IoT Edge-körningen. Om du vill uppdatera flera enheter 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 service 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 en Miljövariabel för 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 för att använda AMQP via WebSocket (AMQPWS) för att upprätta den första anslutningen till IoT Hub.

När din IoT Edge-enhet 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 kommunikation via en proxyserver.

Distribution

Hjälp
- Vara konsekvent med uppströmsprotokoll
- Konfigurera värdlagring för systemmoduler
- Minska minnesutrymmet som används av IoT Edge-hubben
- Använda rätt modulbilder i distributionsmanifest
- Tänk på storleksbegränsningar för tvilling när du använder anpassade moduler
- Konfigurera hur uppdateringar av moduler tillämpas

Vara konsekvent med uppströmsprotokoll

Om du har konfigurerat IoT Edge-agenten på din IoT Edge-enhet för att använda ett annat protokoll än standard-AMQP bör du deklarera samma protokoll i alla framtida distributioner. Om din IoT Edge-enhet till exempel finns bakom en proxyserver som blockerar AMQP-portar har du förmodligen konfigurerat enheten för att ansluta 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 AMQP standardinställningarna och förhindrar att du ansluter igen.

Du behöver bara konfigurera miljövariabeln UpstreamProtocol för IoT Edge-agenten och IoT Edge-hubbmodulerna. Alla ytterligare moduler antar det protokoll som anges i runtime-modulerna.

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

Konfigurera värdlagring för systemmoduler

IoT Edge-hubb- och agentmodulerna använder lokal lagring för att upprätthålla tillstånd 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-hubben

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

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

IoT Edge-hubben är optimerad för prestanda som standard, så den försöker allokera stora minnessegment. 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 är inställt på true använder MQTT-protokollhuvudet PooledByteBufferAllocator, som har bättre prestanda men allokerar mer minne. Allokeraren fungerar inte bra på 32-bitars operativsystem eller på enheter med lite minne. Dessutom allokerar RocksDb mer minne för sin roll som lokal lagringsprovider när det är optimerat för prestanda.

Mer information finns i Stabilitetsproblem på mindre enheter.

Inaktivera oanvända protokoll

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

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

amqp Inställningar__enabled
mqtt Inställningar__enabled
http Inställningar__enabled

Alla tre variablerna har två understreck och kan anges till antingen sant eller falskt.

Minska lagringstiden för meddelanden

IoT Edge-hubbmodulen 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 innehålla meddelanden som inte har levererats innan de upphör att gälla. Om du har minnesproblem på enheten kan du sänka värdet timeToLiveSecs i modultvillingen för IoT Edge-hubben.

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

Använda rätt modulbilder i distributionsmanifest

Om en tom eller fel modulbild används försöker Edge-agenten läsa in avbildningen igen, vilket gör att extra trafik genereras. Lägg till rätt avbildningar i distributionsmanifestet för att undvika att generera onödig trafik.

Använd inte felsökningsversioner av modulbilder

När du flyttar från testscenarier till produktionsscenarier bör du komma ihåg att ta bort felsökningskonfigurationer från distributionsmanifest. Kontrollera att ingen av modulbilderna i distributionsmanifesten har suffixet .debug . Om du har lagt till skapa-alternativ för att exponera portar i modulerna för felsökning tar du även bort dessa alternativ för att skapa.

Tänk på storleksbegränsningar för tvilling när du använder anpassade moduler

Distributionsmanifestet som innehåller anpassade moduler är en del av EdgeAgent-tvillingen. Granska begränsningen för modultvillingstorlek.

Om du distribuerar ett stort antal moduler kan du uttömma den här gränsen för tvillingstorlek. Överväg några vanliga åtgärder för den här hårda gränsen:

Lagra alla konfigurationer i den anpassade modultvillingen, som har en egen gräns.
Lagra vissa konfigurationer som pekar på en plats som inte är utrymmesbegränsad (dvs. till ett bloblager).

Konfigurera hur uppdateringar av moduler tillämpas

När en distribution uppdateras tar Edge Agent emot den nya konfigurationen som en tvillinguppdatering. Om den nya konfigurationen har nya eller uppdaterade modulbilder bearbetar Edge Agent som standard varje modul sekventiellt:

Den uppdaterade avbildningen laddas ned
Modulen som körs stoppas
En ny modulinstans startas
Nästa moduluppdatering bearbetas

I vissa fall, till exempel när det finns beroenden mellan moduler, kan det vara önskvärt att först ladda ned alla uppdaterade modulbilder innan du startar om moduler som körs. Det här moduluppdateringsbeteendet kan konfigureras genom att ange en IoT Edge Agent-miljövariabel ModuleUpdateMode till strängvärdet WaitForAllPulls. Mer information finns i IoT Edge-miljövariabler.

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

Hantering av containrar

Viktigt
- Använda taggar för att hantera versioner
- Hantera volymer
Hjälp
- Lagra körningscontainrar i ditt privata register
- Konfigurera skräpinsamling för avbildningar

Använda taggar för att hantera versioner

En tagg är ett Docker-koncept som du kan använda för att skilja mellan versioner av docker-containrar. Taggar är suffix som 1.1 som finns i slutet av en containerlagringsplats. 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 modulavbildningarna framåt.

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

Taggar för IoT Edge-körningen

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

Rullande taggar – Använd endast de två första värdena i versionsnumret för att hämta den senaste bilden 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å IoT Edge-enheten hämtar avbildningen igen uppdateras runtime-modulerna till den senaste versionen. Distributioner från Azure-portalen är standard för löpande taggar. Den här metoden föreslås 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 föreslås i produktionssyfte.

Hantera volymer

IoT Edge tar inte bort volymer som är anslutna till modulcontainrar. Det här beteendet är avsiktligt eftersom det gör att data kan bevaras mellan containerinstanser, till exempel uppgraderingsscenarier. Men om dessa volymer lämnas oanvända kan det leda till diskutrymmesöverbelastning och systemfel. Om du använder docker-volymer i ditt scenario rekommenderar vi att du använder docker-verktyg som docker-volymrensning och dockervolym rm för att ta bort de oanvända volymerna, särskilt för produktionsscenarier.

Lagra körningscontainrar i ditt privata register

Du vet hur du lagrar containeravbildningar för anpassade kodmoduler i ditt privata Azure-register, men du kan också använda det för att lagra offentliga containeravbildningar som edgeAgent - och edgeHub-körningsmoduler . Detta kan krävas om du har mycket snäva brandväggsbegränsningar eftersom dessa körningscontainrar lagras i Microsoft Container Registry (MCR).

Följande steg visar hur du hämtar en Docker-avbildning av edgeAgent och edgeHub till din lokala dator, lägger om den, push-överför den till ditt privata register och sedan uppdaterar konfigurationsfilen så att enheterna vet att de ska hämta avbildningen från ditt privata register.

Hämta edgeAgent Docker-avbildningen från Microsoft-registret. Uppdatera versionsnumret om det behövs.

# Pull edgeAgent image
docker pull mcr.microsoft.com/azureiotedge-agent:1.4

# Pull edgeHub image
docker pull mcr.microsoft.com/azureiotedge-hub:1.4

Visa en lista över alla Docker-avbildningar, hitta edgeAgent - och edgeHub-avbildningarna och kopiera sedan deras bild-ID:n.
```
docker images
```

Ändra storlek på dina edgeAgent - och edgeHub-avbildningar . Ersätt värdena inom hakparenteser med dina egna.

# Retag your edgeAgent image
docker tag <my-image-id> <registry-name/server>/azureiotedge-agent:1.4

# Retag your edgeHub image
docker tag <my-image-id> <registry-name/server>/azureiotedge-hub:1.4

Push-överför edgeAgent- och edgeHub-avbildningar till ditt privata register. Ersätt värdet inom hakparenteser med ditt eget.

# Push your edgeAgent image to your private registry
docker push <registry-name/server>/azureiotedge-agent:1.4

# Push your edgeHub image to your private registry
docker push <registry-name/server>/azureiotedge-hub:1.4

Uppdatera avbildningsreferenserna i deployment.template.json-filenför systemmodulerna edgeAgent och edgeHub genom att mcr.microsoft.com ersätta med ditt eget "registernamn/server" för båda modulerna.
Öppna en textredigerare på din IoT Edge-enhet för att ändra konfigurationsfilen så att den känner till din privata registerbild.
```
sudo nano /etc/aziot/config.toml
```
I textredigeraren ändrar du dina bildvärden under [agent.config]. Ersätt värdena inom hakparenteser med dina egna.
```
[agent.config]
image = "<registry-name/server>/azureiotedge-agent:1.4"
```

Om ditt privata register kräver autentisering anger du autentiseringsparametrarna i [agent.config.auth].

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

Spara ändringarna och avsluta textredigeraren.
Tillämpa konfigurationsändringen för IoT Edge.
```
sudo iotedge config apply
```
IoT Edge-körningen startas om.

Mer information finns i:

Konfigurera skräpinsamling för avbildningar

Skräpinsamling av avbildningar är en funktion i IoT Edge v1.4 och senare för att automatiskt rensa Docker-avbildningar som inte längre används av IoT Edge-moduler. Den tar bara bort Docker-avbildningar som hämtades av IoT Edge-körningen som en del av en distribution. Om du tar bort oanvända Docker-avbildningar sparar du diskutrymme.

Funktionen implementeras i IoT Edge-värdkomponenten aziot-edged , tjänsten och aktiveras som standard. Rensningen görs varje dag vid midnatt (enhetens lokala tid) och tar bort oanvända Docker-avbildningar som senast användes för sju dagar sedan. Parametrarna för att styra rensningsbeteendet anges i config.toml och förklaras senare i det här avsnittet. Om parametrar inte anges i konfigurationsfilen tillämpas standardvärdena.

Följande är till exempel avsnittet för skräpinsamling av config.toml bilder med standardvärden:

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

I följande tabell beskrivs parametrar för skräpinsamling av bilder. Alla parametrar är valfria och kan anges individuellt för att ändra standardinställningarna.

Parameter	Beskrivning	Obligatoriskt	Standardvärde
`enabled`	Aktiverar avbildningens skräpinsamling. Du kan välja att inaktivera funktionen genom att ändra den här inställningen till `false`.	Valfritt	true
`cleanup_recurrence`	Styr upprepningsfrekvensen för rensningsaktiviteten. Måste anges som flera dagar och får inte vara mindre än en dag. Till exempel: 1d, 2d, 6d osv.	Valfritt	1 dag
`image_age_cleanup_threshold`	Definierar minimiålderströskeln för oanvända bilder innan du överväger att rensa och måste anges i dagar. Du kan ange som 0d för att rensa avbildningarna så snart de har tagits bort från distributionen. Avbildningar anses vara oanvända när de har tagits bort från distributionen.	Valfritt	7 d
`cleanup_time`	Tid på dagen, i enhetens lokala tid, när rensningsaktiviteten körs. Måste vara i 24-timmarsformatet HH:MM.	Valfritt	00:00

Nätverk

Hjälp
- Granska utgående/inkommande konfiguration
- Tillåt anslutningar från IoT Edge-enheter
- Konfigurera kommunikation via en proxy
- Ange DNS-server i inställningar för containermotorn

Granska utgående/inkommande konfiguration

Kommunikationskanaler mellan Azure IoT Hub och IoT Edge är alltid konfigurerade för utgående trafik. För de flesta IoT Edge-scenarier krävs endast tre anslutningar. Containermotorn måste ansluta till containerregistret (eller register) som innehåller modulavbildningarna. IoT Edge-körningen måste ansluta till IoT Hub för att hämta information om enhetskonfiguration och skicka meddelanden och telemetri. Och 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ätverkskonfigurationen kräver att du uttryckligen tillåter anslutningar från IoT Edge-enheter läser 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 enda 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 alla tre fallen skulle det fullständigt kvalificerade domännamnet (FQDN) matcha mönstret \*.azure-devices.net.

Containerregister

Containermotorn anropar containerregister via HTTPS. FQDN är mcr.microsoft.comför att hämta IoT Edge-körningscontaineravbildningarna . Containermotorn ansluter till andra register som konfigurerats i distributionen.

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

FQDN (`*` = jokertecken)	Utgående TCP-portar	Användning
`mcr.microsoft.com`	443	Microsoft Container Registry
`*.data.mcr.microsoft.com`	443	Dataslutpunkt som tillhandahåller innehållsleverans
`*.cdn.azcr.io`	443	Distribuera moduler från Marketplace till enheter
`global.azure-devices-provisioning.net`	443	Åtkomst till enhetsetableringstjänsten (valfritt)
`*.azurecr.io`	443	Personliga containerregister och containerregister från tredje part
`*.blob.core.windows.net`	443	Ladda ned Azure Container Registry-avbildningsdelta från Blob Storage
`*.azure-devices.net`	5671, 8883, 443¹	IoT Hub-åtkomst
`*.docker.io`	443	Docker Hub-åtkomst (valfritt)

¹Öppna port 8883 för säker MQTT eller port 5671 för säker AMQP. Om du bara kan upprätta anslutningar via port 443 kan något av dessa protokoll köras via en WebSocket-tunnel.

Eftersom IP-adressen för en IoT-hubb kan ändras utan förvarning använder du alltid FQDN för att tillåtalistekonfiguration. Mer information finns i Förstå IP-adressen för din IoT Hub.

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.

Du kan aktivera dedikerade dataslutpunkter i Azure Container-registret för att undvika jokertecken för tillåtna *.blob.core.windows.net FQDN. Mer information finns i Aktivera dedikerade dataslutpunkter.

Kommentar

Om du vill tillhandahålla ett konsekvent fullständigt domännamn mellan REST- och dataslutpunkterna ändras dataslutpunkten från och med den 15 juni 2020 från och med den 15 juni 2020 från *.cdn.mscr.io till *.data.mcr.microsoft.com
Mer information finns i Konfiguration av brandväggsregler för Microsoft Container Registry-klienten

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 Store Runtime-containrar i ditt privata register.

Azure IoT Identity Service

IoT Identity Service tillhandahåller etablerings- och kryptografiska tjänster för Azure IoT-enheter. Identitetstjänsten kontrollerar om den installerade versionen är den senaste versionen. Kontrollen använder följande FQDN för att verifiera versionen.

FQDN	Utgående TCP-portar	Användning
`aka.ms`	443	Url för fåfänga som ger omdirigering till versionsfilen
`raw.githubusercontent.com`	443	Versionsfilen för identitetstjänsten som finns i GitHub

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-enhet för kommunikation via en proxyserver.

Ange DNS-server i inställningar för containermotorn

Ange DNS-servern för din miljö i inställningarna för containermotorn. DNS-serverinställningen gäller för alla containermoduler som startas av motorn.

/etc/docker Redigera filen i katalogen på enhetendaemon.json. Skapa filen om den inte finns.
Lägg till dns-nyckeln och ange DNS-serveradressen till en offentligt tillgänglig DNS-tjänst. Om gränsenheten inte kan komma åt en offentlig DNS-server använder du en tillgänglig DNS-serveradress i nätverket. Till exempel:
```
{
    "dns": ["1.1.1.1"]
}
```

Lösningshantering

Hjälp
- Konfigurera loggar och diagnostik
- Konfigurera standardloggningsdrivrutin
- Överväg tester och CI/CD-pipelines

Konfigurera loggar och diagnostik

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

Från och med version 1.2 förlitar sig IoT Edge på flera daemoner. Även om varje daemons loggar kan frågas individuellt med journalctl, iotedge system ger kommandona ett bekvämt sätt att fråga de kombinerade loggarna.

Konsoliderat iotedge kommando:
```
sudo iotedge system logs
```

Motsvarande journalctl kommando:

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

När du testar en IoT Edge-distribution 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 på 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-loganalytics, eller så kan du utforma din egen.

Konfigurera standardloggningsdrivrutin

Moby-containermotorn anger som standard inte storleksgränser för containerloggar. Med tiden kan detta leda till att enheten fylls med loggar och att diskutrymmet börjar ta slut. Konfigurera containermotorn så att loggningsdrivrutinen local används som loggningsmekanism. Local Loggningsdrivrutinen erbjuder en standardgräns för loggstorlek, utför loggrotation som standard och använder ett effektivare filformat som hjälper till att förhindra att diskutrymmet överbelastas. Du kan också välja att använda olika loggningsdrivrutiner och ange olika storleksgränser baserat på dina behov.

Alternativ: Konfigurera standardloggningsdrivrutinen för alla containermoduler

Du kan konfigurera containermotorn så att den använder en specifik loggningsdrivrutin genom att ange värdet log driver för till namnet på loggdrivrutinen i daemon.json. I följande exempel anges standardloggningsdrivrutinen till local loggdrivrutinen (rekommenderas).

{
    "log-driver": "local"
}

Du kan också konfigurera dina log-opts nycklar så att de använder lämpliga värden i daemon.json filen. I följande exempel anges loggdrivrutinen till local och alternativen och max-file angesmax-size.

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

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

/etc/docker/

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. Till exempel:

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

Ytterligare alternativ för Linux-system

Konfigurera containermotorn för att skicka loggar till journal genom att systemdange 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-distributionsscenariot 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äkerhetsfrågor

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-produktionsenheter ska du kontrollera åtkomsten till containerregistret så att utomstående inte kan komma åt eller göra ändringar i dina containeravbildningar. 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-enhet som du använder på utvecklingsdatorn. De här instruktionerna ä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 säkrare åtkomst till registret kan du välja mellan autentiseringsalternativ. En populär och rekommenderad autentisering är att använda ett Active Directory-tjänstens huvudnamn 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 med lagringsplatsomfattning, vilket gör att du kan skapa långa eller kortlivade identiteter som bara finns i Azure Container Registry som de skapades i och omfångsåtkomst till lagringsplatsnivån.

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. Dessa skript utför följande uppgifter:

Det första skriptet skapar tjänstens huvudnamn. Det matar ut tjänstens huvudnamns-ID 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 acrPull-användarrollen för parametern role . En lista över roller finns i Roller och behörigheter för Azure Container Registry.

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

För användarnamnet eller klient-ID:t anger du tjänstens huvudnamns-ID.
Ange lösenordet för tjänstens huvudnamn för lösenordet eller klienthemligheten.

Om du vill skapa token med lagringsplatsomfattning följer du skapa en token med lagringsplatsomfattning.

Om du vill autentisera med token med lagringsplatsomfattning anger du det tokennamn och lösenord som du fick när du skapade din token med lagringsplatsomfattning. 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.

Kommentar

När du har implementerat en förbättrad säkerhetsautentisering inaktiverar du inställningen Administratörsanvändare så att standardåtkomsten för användarnamn/lösenord inte längre är tillgänglig. I containerregistret i Azure-portalen går du till menyn till vänster under Inställningar och väljer Åtkomstnycklar.

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 gränser säkerställer att en modul inte kan förbruka för mycket minne eller CPU-användning och förhindrar att andra processer körs på enheten. IoT Edge-plattformen begränsar inte resurser för moduler som standard, eftersom det krävs testning för att veta hur mycket resurser en viss modul behöver för att köras 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 Konfigurera alternativ för att skapa containrar för IoT Edge-moduler.

Nästa steg

Läs mer om automatisk distribution av IoT Edge.
Se hur IoT Edge stöder kontinuerlig integrering och kontinuerlig distribution.

Förbereda distributionen av din IoT Edge-lösning i produktion

Enhetskonfiguration

Installera produktionscertifikat

Ha en plan för enhetshantering

Använda Moby som containermotor

Välj uppströmsprotokoll

Distribution

Vara konsekvent med uppströmsprotokoll

Konfigurera värdlagring för systemmoduler

Minska minnesutrymmet som används av IoT Edge-hubben

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

Inaktivera oanvända protokoll

Minska lagringstiden för meddelanden

Använda rätt modulbilder i distributionsmanifest

Använd inte felsökningsversioner av modulbilder

Tänk på storleksbegränsningar för tvilling när du använder anpassade moduler

Konfigurera hur uppdateringar av moduler tillämpas

Hantering av containrar

Använda taggar för att hantera versioner

Taggar för IoT Edge-körningen

Hantera volymer

Lagra körningscontainrar i ditt privata register

Konfigurera skräpinsamling för avbildningar

Nätverk

Granska utgående/inkommande konfiguration

Tillåt anslutningar från IoT Edge-enheter

Containerregister

Azure IoT Identity Service

Konfigurera kommunikation via en proxy

Ange DNS-server i inställningar för containermotorn

Lösningshantering

Konfigurera loggar och diagnostik

Konfigurera standardloggningsdrivrutin

Alternativ: Konfigurera standardloggningsdrivrutinen för alla containermoduler

Alternativ: Justera logginställningarna för varje containermodul

Ytterligare alternativ för Linux-system

Överväg tester och CI/CD-pipelines

Säkerhetsfrågor

Hantera åtkomst till ditt containerregister

Begränsa containeråtkomst till värdresurser

Nästa steg

Ytterligare resurser