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

Artikel
07/22/2022

Gäller för: IoT Edge 1.1

Viktigt

IoT Edge 1.1 slutdatum var den 13 december 2022. I informationen om Microsoft-produktens livscykel hittar du fler uppgifter om vilken support som gäller för denna produkt, tjänst, teknik eller detta API. Mer information om hur du uppdaterar till den senaste versionen av IoT Edge finns i 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 vara isolerad 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
Användbart
- 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örning 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.

Anteckning

För närvarande förhindrar en begränsning i libiothsm användningen av certifikat som upphör att gälla den 1 januari 2038 eller senare.

Information om rollen för certifikatutfärdarcertifikatet för enheten finns i Så här använder Azure IoT Edge 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 (förhandsversion) ä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 den 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, arbetar 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 UpstreamProtocol-miljövariabel . 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 IoT Edge enheten 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

Användbart
- 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 tvillingen 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 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 standard-AMQP inställningarna och förhindrar att du ansluter igen.

Du behöver bara konfigurera miljövariabeln UpstreamProtocol för IoT Edge-agenten och IoT Edge hubbmoduler. Eventuella ytterligare moduler antar 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å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 hubb

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

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

Den IoT Edge hubben är optimerad för prestanda som standard, så den försöker allokera stora mängder minne. 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 den lokala lagringsprovidern när den är optimerad för prestanda.

Mer information finns i Stabilitetsproblem på mindre enheter.

Inaktivera oanvända protokoll

Ett annat sätt att optimera prestandan för IoT Edge hubben 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 modulen IoT Edge hubb i distributionsmanifesten. De tre variablerna är:

amqpSettings__enabled
mqttSettings__enabled
httpSettings__enabled

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

Minska lagringstiden för meddelanden

Modulen IoT Edge hubb 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 håller fast vid 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 IoT Edge hubbmodultvilling.

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 tvillingen när du använder anpassade moduler

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

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 sin egen gräns.
Lagra vissa konfigurationer som pekar på en plats som inte är utrymmesbegränsad (det vill: till ett bloblager).

Hantering av containrar

Viktigt
- Använda taggar för att hantera versioner
- Hantera volymer
Användbart
- 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 dina modulavbildningar framöver.

Taggar hjälper dig också att framtvinga uppdateringar på dina IoT Edge-enheter. När du push-överför 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 inkrementella taggen som en ny version och hämtar den senaste modulversionen till enheten.

Taggar för IoT Edge-körning

De IoT Edge agent- 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 körningsmodulerna till den senaste versionen. Distributioner från Azure Portal standard till 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 det möjligt att spara data över containerinstanser, till exempel uppgraderingsscenarier. Men om dessa volymer lämnas oanvända kan det leda till diskutrymmesöverbelastning och efterföljande systemfel. Om du använder Docker-volymer i ditt scenario rekommenderar vi att du använder Docker-verktyg som docker volume prune och docker volume rm för att ta bort oanvända volymer, 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-runtime-modulerna. Det 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 illustrerar hur du hämtar en Docker-avbildning av edgeAgent och edgeHub till din lokala dator, omtagar den, push-överför den till ditt privata register och sedan uppdaterar konfigurationsfilen så att enheterna vet att den hämtar 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.1

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

Visa en lista över alla Docker-avbildningar, leta upp 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.1

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

Push-överför edgeAgent - och edgeHub-avbildningarna 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.1

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

Uppdatera avbildningsreferenserna i filen deployment.template.json för edgeAgent - och edgeHub-systemmodulerna 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.1"
```

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.
Använd IoT Edge konfigurationsändringen.
```
sudo iotedge config apply
```
Din IoT Edge runtime startas om.

Mer information finns i:

Nätverk

Användbart
- Granska utgående/inkommande konfiguration
- Tillåt anslutningar från IoT Edge enheter
- Konfigurera kommunikation via en proxy

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 är endast tre anslutningar nödvändiga. 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 för att 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 hubb ö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.

Dessutom gör containermotorn anrop till containerregister via HTTPS. FQDN är mcr.microsoft.comför att hämta IoT Edge runtime-containeravbildningar. Containermotorn ansluter till andra register enligt konfigurationen 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öregående meddelande 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 Ditt Azure Container-register för att undvika tillåtna jokertecken för *.blob.core.windows.net FQDN. Mer information finns i Aktivera dedikerade dataslutpunkter.

Anteckning

För att tillhandahålla ett konsekvent FQDN 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.

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.

Lösningshantering

Användbart
- 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.

I Windows använder IoT Edge-daemon PowerShell-diagnostik. Använd Get-IoTEdgeLog för att fråga efter loggar från daemonen. IoT Edge moduler använder JSON-drivrutinen för loggning, vilket är standardinställningen.

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

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. Överväg 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 storleksbegränsningar 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 loggningsdrivrutinenlocal används som loggningsmekanism. Local Loggningsdrivrutinen erbjuder en standardgräns för loggstorlek, utför loggrotation som standard och använder ett mer effektivt filformat som hjälper till att förhindra överbelastning av diskutrymme. 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 loggningsdrivrutinen som standard 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 max-size och max-file anges.

{
    "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:

Plattform	Location
Linux	`/etc/docker/`
Windows	`C:\ProgramData\iotedge-moby\config\`

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

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

Ytterligare alternativ på Linux-system

Konfigurera containermotorn så att loggar skickas till journalen genom att systemd 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 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ä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 produktionsenheter IoT Edge enheter kontrollerar du å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 anvisningarna är bara avsedda att hjälpa dig att konfigurera test- och utvecklingsmiljöer enklare och bör inte följas i ett produktionsscenario.

För en mer säker åtkomst till registret kan du välja mellan autentiseringsalternativ. 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 med lagringsplatsomfång, vilket gör att du kan skapa långa eller kortlivade identiteter som bara finns i Azure Container Registry 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. Tjänstens huvudnamns-ID och lösenordet för tjänstens huvudnamn matas ut. 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 Azure Container Registry roller och behörigheter.

Om du vill autentisera med tjänstens huvudnamn 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 ID:t för tjänstens huvudnamn.
Ange lösenordet för tjänstens huvudnamn för lösenordet eller klienthemligheten.

Om du vill skapa token med lagringsplatsomfång följer du skapa en token med lagringsplatsomfång.

Om du vill autentisera med token med lagringsplatsomfång anger du det tokennamn och lösenord som du fick när du skapade din token med lagringsplatsomfång. Ange dessa autentiseringsuppgifter i distributionsmanifestet.

Ange tokens användarnamn för användarnamnet.
Ange ett av tokens lösenord för lösenordet.

Anteckning

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

Begränsa containeråtkomst till värdresurser

För att 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örhindra att andra processer körs på enheten. Den IoT Edge plattformen begränsar 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 containerskapande för IoT Edge moduler.

Nästa steg

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

Dela via

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 hubb

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 tvillingen när du använder anpassade moduler

Hantering av containrar

Använda taggar för att hantera versioner

Taggar för IoT Edge-körning

Hantera volymer

Lagra körningscontainrar i ditt privata register

Nätverk

Granska utgående/inkommande konfiguration

Tillåt anslutningar från IoT Edge enheter

Konfigurera kommunikation via en proxy

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 på Linux-system

Överväg tester och CI/CD-pipelines

Säkerhetsöverväganden

Hantera åtkomst till ditt containerregister

Begränsa containeråtkomst till värdresurser

Nästa steg

Ytterligare resurser