Översikt över skapande av .NET SDK-container

Även om det är möjligt att containerisera .NET-appar med en Dockerfile-finns det övertygande skäl till att containerisera appar direkt med .NET SDK-. Den här artikeln innehåller en översikt över funktionen för att skapa .NET SDK-containrar med information om telemetri, publiceringsöverväganden, byggegenskaper och autentisering till containerregister.

Att tänka på när du publicerar projekt

Nu när du har en .NET-app kan du publicera den som en container. Innan du gör det finns det flera viktiga saker att tänka på. Innan .NET SDK version 8.0.200 behövde du 📦 Microsoft.NET.Build.Containers NuGet-paketet. Det här paketet krävs inte för .NET SDK version 8.0.200 och senare, eftersom containersupporten ingår som standard.

För att aktivera publicering av en .NET-app som en container krävs följande byggegenskaper:

• IsPublishable: Ange till true. Den här egenskapen är implicit inställd på true för körbara projekttyper, till exempel console, webappoch worker.
• EnableSdkContainerSupport: Ställ in på true när projekttypen är en konsolapp.

Om du uttryckligen vill aktivera stöd för SDK-container bör du överväga följande projektfilfragment:

<PropertyGroup>
  <IsPublishable>true</IsPublishable>
  <EnableSdkContainerSupport>true</EnableSdkContainerSupport>
</PropertyGroup>

Publicera växlar och byggegenskaper

Precis som med alla .NET CLI-kommandon kan du ange MSBuild-egenskaper på kommandoraden. Det finns många giltiga syntaxformulär tillgängliga för att tillhandahålla egenskaper, till exempel:

• /p:PropertyName=Value
• -p:PropertyName=Value
• -p PropertyName=Value
• --property PropertyName=Value

Du kan använda vilken syntax du vill, men i dokumentationen visas exempel med hjälp av formuläret -p.

Publicera profiler och mål

När du använder dotnet publishkan du ange en profil med -p PublishProfile=DefaultContainer som kan ange en egenskap som gör att SDK:t utlöser ett annat mål efter publiceringsprocessen. Detta är ett indirekt sätt att uppnå önskat resultat. Å andra sidan anropar dotnet publish /t:PublishContainer direkt PublishContainer målet och uppnår samma resultat men på ett enklare sätt.

Med andra ord följande .NET CLI-kommando:

dotnet publish -p PublishProfile=DefaultContainer

Vilket anger egenskapen PublishProfile till DefaultContainer, motsvarar följande kommando:

dotnet publish /t:PublishContainer

Skillnaden mellan de två metoderna är att den förra använder en profil för att ange egenskapen, medan den senare direkt anropar målet. Anledningen till att detta är viktigt är att profiler är en funktion i MSBuild, och de kan användas för att ange egenskaper på ett mer komplext sätt än att bara ställa in dem direkt.

Ett viktigt problem är att inte alla projekttyper stöder profiler eller har samma uppsättning profiler tillgängliga. Dessutom finns det en skillnad i stödnivån för profiler mellan olika verktyg, till exempel Visual Studio och .NET CLI. Därför är användning av mål i allmänhet en tydligare och mer allmänt stödd metod för att uppnå samma resultat.

Autentisera till containerregister

Att interagera med privata containerregister kräver autentisering med dessa register.

Docker har ett etablerat mönster med detta via kommandot docker login, vilket är ett sätt att interagera med en Docker-konfigurationsfil som innehåller regler för autentisering med specifika register. Den här filen och de autentiseringstyper som den kodar stöds av Microsoft.Net.Build.Containers för registerautentisering. Detta bör säkerställa att det här paketet fungerar sömlöst med alla register som du kan docker pull från och docker push. Den här filen lagras normalt på ~/.docker/config.json, men den kan också anges via variabeln DOCKER_CONFIG, som pekar på en katalog som innehåller en config.json fil.

Typer av autentisering

Filen config.json innehåller tre typer av autentisering:

• Explicit användarnamn/lösenord
• hjälpverktyg för autentiseringsuppgifter
• Systemnyckelring

Explicit användarnamn/lösenord

Avsnittet auths i filen config.json är en nyckel/värde-mappning mellan registernamn och Base64-kodade användarnamn:lösenordssträngar. I ett vanligt Docker-scenario skapar körning docker login <registry> -u <username> -p <password> nya objekt i den här kartan. Dessa autentiseringsuppgifter är populära i system för kontinuerlig integrering (CI), där inloggning görs med hjälp av token vid start av en körning. De är dock mindre populära för slutanvändarutvecklingsdatorer på grund av säkerhetsrisken att ha endast autentiseringsuppgifter i en fil.

Hanterare av autentiseringsuppgifter

Avsnittet credHelpers i filen config.json är en nyckel/värde-mappning mellan registernamn och namnen på specifika program som kan användas för att skapa och hämta autentiseringsuppgifter för registret. Detta används ofta när vissa register har komplexa autentiseringskrav. För att den här typen av autentisering ska fungera måste du ha ett program med namnet docker-credential-{name} på systemets PATH. Den här typen av autentiseringsuppgifter brukar vara säkra, men kan vara svåra att konfigurera på utvecklings- eller CI-datorer.

Systemnyckelringar

Avsnittet credsStore är en enskild strängegenskap vars värde är namnet på ett hjälpprogram för docker-autentiseringsuppgifter som vet hur man interagerar med systemets lösenordshanterare. För Windows kan detta till exempel vara wincred. Dessa är populära bland Docker-installationsprogram för macOS och Windows.

Autentisering via miljövariabler

I vissa scenarier räcker den standardmekanism för Docker-autentisering som beskrivs ovan inte till. Det här verktyget har ytterligare en mekanism för att tillhandahålla autentiseringsuppgifter till register: miljövariabler. Om miljövariabler används används inte mekanismen för autentiseringsuppgifter alls. Följande miljövariabler stöds:

• DOTNET_CONTAINER_REGISTRY_UNAME: Detta bör vara användarnamnet för registret. Om lösenordet för registret är en token ska användarnamnet vara "<token>".
• DOTNET_CONTAINER_REGISTRY_PWORD: Detta bör vara lösenordet eller token för registret.

Den här mekanismen är potentiellt sårbar för läckage av autentiseringsuppgifter, så den bör endast användas i scenarier där den andra mekanismen inte är tillgänglig. Om du till exempel använder SDK-containerverktyget i en Docker-container. Dessutom är den här mekanismen inte namnrymd – den försöker använda samma autentiseringsuppgifter för både källregistret (där basavbildningen finns) och målregistret (där du push-överför den slutliga avbildningen).

Använda osäkra register

De flesta registeråtkomst antas vara säker, vilket innebär att HTTPS används för att interagera med registret. Alla register är dock inte konfigurerade med TLS-certifikat , särskilt i situationer som ett privat företagsregister bakom ett VPN. För att stödja dessa användningsfall tillhandahåller containerverktyg sätt att deklarera att ett visst register använder osäker kommunikation.

Från och med .NET 8.0.400 förstår SDK dessa konfigurationsfiler och format och använder den konfigurationen automatiskt för att avgöra om HTTP eller HTTPS ska användas. Konfigurationen av ett register för osäker kommunikation varierar beroende på vilket containerverktyg du väljer.

Docker

Docker lagrar konfigurationen för sin registreringsdatabas i daemon-konfigurationen. För att lägga till nya osäkra register läggs nya värdar till i egenskapen "insecure-registries" i matrisen.

{
  "insecure-registries": [
    "registry.mycorp.net"
  ]
}

Podman

Podman använder en registries.conf TOML-fil för att lagra registeranslutningsinformation. Den här filen finns vanligtvis på /etc/containers/registries.conf. Om du vill lägga till nya osäkra register läggs ett TOML-avsnitt till för att lagra inställningarna för registret. Sedan måste alternativet insecure anges till true.

[[registry]]
location = "registry.mycorp.net"
insecure = true

Miljövariabler

Från och med 9.0.100 identifierar .NET SDK osäkra register som skickas via miljövariabeln DOTNET_CONTAINER_INSECURE_REGISTRIES. Den här variabeln tar en kommaavgränsad lista över domäner för att behandla som osäkra på samma sätt som Exemplen Docker och Podman ovan.

$Env:DOTNET_CONTAINER_INSECURE_REGISTRIES=localhost:5000,registry.mycorp.com; dotnet publish -t:PublishContainer -p:ContainerRegistry=registry.mycorp.com -p:ContainerBaseImage=localhost:5000/dotnet/runtime:9.0

DOTNET_CONTAINER_INSECURE_REGISTRIES=localhost:5000,registry.mycorp.com dotnet publish -t:PublishContainer -p:ContainerRegistry=registry.mycorp.com -p:ContainerBaseImage=localhost:5000/dotnet/runtime:9.0

Telemetri

När du publicerar en .NET-app som en container samlar .NET SDK-containerverktyget in och skickar användningstelemetri om hur verktygen används. De insamlade data är utöver den telemetri som skickas av .NET CLI-, men använder samma mekanismer och följer, vilket är viktigt, samma opt-out-kontroller.

Den insamlade telemetrin är avsedd att vara allmän och inte läcka någon personlig information – syftet är att hjälpa till att mäta:

• Användning av .NET SDK-containeriseringsfunktionen överlag.
• Framgångs- och felfrekvenser, tillsammans med allmän information om vilka typer av fel som inträffar oftast.
• Användning av specifika funktioner i tekniken, till exempel publicering till olika registertyper eller hur publiceringen anropades.

Om du vill välja bort telemetri anger du miljövariabeln DOTNET_CLI_TELEMETRY_OPTOUT till true. Mer information finns i .NET CLI-telemetri.

Slutsatsdragningstelemetri

Följande information om hur grundavbildningens slutsatsdragningsprocess inträffade loggas:

Telemetri för bildskapande

Följande information om hur processen för att skapa och publicera containrar har loggats:

Om olika typer av fel inträffar under processen samlas dessutom data in om vilken typ av fel det var:

Se även

• Publicera .NET-appar som containrar
• Kontejnerisera en .NET-appreferens