Menyesuaikan kontainer Docker di Visual Studio

Anda dapat menyesuaikan gambar kontainer dengan mengedit Dockerfile yang dihasilkan Visual Studio saat menambahkan dukungan Docker ke proyek Anda. Baik Anda membuat kontainer yang disesuaikan dari Visual Studio IDE, atau menyiapkan build baris perintah, Anda perlu mengetahui bagaimana Visual Studio menggunakan Dockerfile untuk membangun proyek Anda. Anda perlu mengetahui detail tersebut karena, untuk alasan performa, Visual Studio mengikuti proses khusus untuk membangun dan menjalankan aplikasi kontainer yang tidak jelas dari Dockerfile.

Misalkan Anda ingin membuat perubahan di Dockerfile dan melihat hasilnya dalam penelusuran kesalahan dan dalam kontainer produksi. Dalam hal ini, Anda dapat menambahkan perintah di Dockerfile untuk memodifikasi tahap pertama (biasanya base). Lihat Mengubah gambar kontainer untuk penelusuran kesalahan dan produksi. Tetapi, jika Anda ingin membuat perubahan hanya saat penelusuran kesalahan, tetapi bukan produksi, maka Anda harus membuat tahap lain, dan menggunakan DockerfileFastModeStage pengaturan build untuk memberi tahu Visual Studio untuk menggunakan tahap tersebut untuk build debug. Lihat Mengubah gambar kontainer hanya untuk penelusuran kesalahan.

Artikel ini menjelaskan proses build Visual Studio untuk aplikasi kontainer secara terperinci, kemudian berisi informasi tentang cara memodifikasi Dockerfile untuk memengaruhi proses debugging dan build produksi, atau hanya untuk penelusuran kesalahan.

Build Dockerfile di Visual Studio

Catatan

Bagian ini menjelaskan proses build kontainer yang digunakan Visual Studio saat Anda memilih jenis build kontainer Dockerfile. Jika Anda menggunakan jenis build .NET SDK, opsi kustomisasi berbeda, dan informasi di bagian ini tidak berlaku. Sebagai gantinya, lihat Menampung aplikasi .NET dengan dotnet publish dan gunakan properti yang dijelaskan di Menyesuaikan kontainer Anda untuk mengonfigurasi proses build kontainer.

Build multitahap

Ketika membangun proyek yang tidak menggunakan kontainer Docker, Visual Studio membatalkan MSBuild pada komputer lokal dan membuat file output dalam folder (biasanya bin) di bawah folder solusi lokal Anda. Namun, untuk proyek dalam kontainer, proses build mempertimbangkan instruksi Dockerfile untuk membangun aplikasi dalam kontainer tersebut. Dockerfile yang digunakan Visual Studio dibagi menjadi beberapa tahap. Proses ini bergantung pada fitur build multitahap Docker.

Fitur build multitahap membantu menjadikan proses pembangunan kontainer lebih efisien dan menghasilkan kontainer lebih kecil yang hanya dapat berisi bit yang dibutuhkan aplikasi Anda saat beroperasi. Build multitahap digunakan untuk proyek .NET Core, bukan proyek .NET Framework.

Build multitahap memungkinkan gambar kontainer dibuat dalam beberapa tahap yang menghasilkan citra perantara. Sebagai contoh, pertimbangkan Dockerfile yang khas. Tahap pertama dipanggil base di Dockerfile yang dihasilkan Visual Studio, meskipun alat tidak memerlukan nama tersebut.

FROM mcr.microsoft.com/dotnet/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

Garis di dalam Dockerfile dimulai dengan citra ASP.NET dari Microsoft Container Registry (mcr.microsoft.com) dan menghasilkan citra base perantara yang mengekspos port 80 dan 443, dan mengatur direktori kerja ke /app.

Tahap berikutnya adalah build, yang muncul sebagai berikut:

FROM mcr.microsoft.com/dotnet/sdk:3.1-buster-slim AS build
WORKDIR /src
COPY ["WebApplication43/WebApplication43.csproj", "WebApplication43/"]
RUN dotnet restore "WebApplication43/WebApplication43.csproj"
COPY . .
WORKDIR "/src/WebApplication43"
RUN dotnet build "WebApplication43.csproj" -c Release -o /app/build

Tampak tahap build dimulai dari citra asli yang berbeda dari registri (sdk, bukannya aspnet), tidak melanjutkan dari dasar. Citra sdk memiliki semua alat build, sehingga jauh lebih besar dari citra aspnet, yang hanya berisi komponen runtime. Alasan penggunaan citra terpisah menjadi jelas ketika Anda melihat bagian Dockerfile lainnya:

FROM build AS publish
RUN dotnet publish "WebApplication43.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication43.dll"]

Tahap akhir dimulai lagi dari base, dan mencakup COPY --from=publish untuk menyalin output yang diterbitkan ke citra akhir. Proses ini dapat menghasilkan citra akhir yang jauh lebih kecil, karena tidak perlu menyertakan semua alat build yang ada dalam citra sdk.

MSBuild

Catatan

Bagian ini menjelaskan bagaimana Anda dapat menyesuaikan kontainer Docker saat Anda memilih jenis build kontainer Dockerfile. Jika Anda menggunakan jenis build .NET SDK, opsi kustomisasi berbeda, dan informasi dalam artikel ini tidak berlaku. Sebagai gantinya, lihat Menampung aplikasi .NET dengan penerbitan dotnet.

Dockerfiles yang dibuat oleh Visual Studio untuk proyek .NET Framework (dan untuk proyek .NET Core yang dibuat dengan versi Visual Studio sebelum Visual Studio 2017 Update 4) bukan Dockerfiles multistage. Langkah-langkah dalam Dockerfiles ini tidak mengkompilasi kode Anda. Namun, jika membangun Dockerfile .NET Framework, Visual Studio mengompilasi proyek Anda menggunakan MSBuild. Bila berhasil, Visual Studio kemudian membangun Dockerfile, yang hanya menyalin output build dari MSBuild ke dalam citra Docker yang dihasilkan. Karena langkah untuk mengompilasi kode tidak disertakan dalam Dockerfile, Anda tidak dapat membangun Dockerfile .NET Framework menggunakan baris perintah docker build. Anda harus menggunakan MSBuild untuk membangun proyek ini.

Untuk membangun gambar untuk proyek kontainer Docker tunggal, Anda dapat menggunakan MSBuild dengan /t:ContainerBuild opsi perintah. Perintah ini memberi tahu MSBuild untuk membangun target ContainerBuild daripada target Builddefault . Contohnya:

MSBuild MyProject.csproj /t:ContainerBuild /p:Configuration=Release

Anda melihat output yang mirip dengan apa yang Anda lihat di jendela Output saat anda membangun solusi dari Visual Studio IDE. Selalu gunakan /p:Configuration=Release, karena ketika Visual Studio menggunakan pengoptimalan build multitahap, hasil yang didapat saat membangun konfigurasi Debug mungkin tidak sesuai harapan. Lihat Penelusuran Kesalahan.

Jika Anda menggunakan proyek Docker Compose, gunakan perintah ini untuk membuat gambar:

msbuild /p:SolutionPath=<solution-name>.sln /p:Configuration=Release docker-compose.dcproj

Awakutu

Catatan

Bagian ini menjelaskan bagaimana Anda dapat menyesuaikan kontainer Docker saat Anda memilih jenis build kontainer Dockerfile. Jika Anda menggunakan jenis build .NET SDK, opsi kustomisasi berbeda, dan sebagian besar informasi di bagian ini tidak berlaku. Sebagai gantinya, lihat Menampung aplikasi .NET dengan penerbitan dotnet.

Saat Anda membuat konfigurasi Debug , ada beberapa pengoptimalan yang dilakukan Visual Studio yang membantu performa proses build untuk proyek kontainer. Proses build untuk aplikasi dalam kontainer tidak mudah karena hanya mengikuti langkah-langkah yang diuraikan dalam Dockerfile. Membangun dalam kontainer lebih lambat daripada membangun di komputer lokal. Jadi, ketika Anda membangun konfigurasi Debug, Visual Studio sebenarnya membangun proyek Anda di komputer lokal, lalu membagikan folder output ke kontainer menggunakan pemasangan volume. Build dengan pengoptimalan yang diaktifkan ini disebut build mode Cepat.

Dalam mode Cepat, Visual Studio memanggil docker build dengan argumen yang memberi tahu Docker untuk hanya membuat tahap pertama di Dockerfile (biasanya tahap).base Anda dapat mengubahnya dengan mengatur properti MSBuild, DockerfileFastModeStage, yang dijelaskan di properti MSBuild Container Tools. Visual Studio menangani kelanjutan prosesnya tanpa memperhatikan konten Dockerfile. Jadi, jika Anda memodifikasi Dockerfile, misalnya menyesuaikan lingkungan kontainer atau menginstal dependensi tambahan, lakukan modifikasi di tahap pertama. Setiap langkah kustom yang ditempatkan di tahap Dockerfile build, , publishatau final tidak dijalankan.

Pengoptimalan performa ini hanya terjadi saat Anda membangun dalam konfigurasi Debug. Dalam konfigurasi Rilis, build terjadi dalam kontainer seperti yang ditentukan dalam Dockerfile.

Jika Anda ingin menonaktifkan pengoptimalan performa dan membangun seperti yang ditentukan Dockerfile, atur properti ContainerDevelopmentMode ke Reguler dalam file proyek sebagai berikut:

<PropertyGroup>
   <ContainerDevelopmentMode>Regular</ContainerDevelopmentMode>
</PropertyGroup>

Untuk memulihkan pengoptimalan performa, hapus properti dari file proyek.

Saat Anda mulai menelusuri kesalahan (F5), kontainer yang dimulai sebelumnya digunakan kembali, jika memungkinkan. Jika tidak ingin menggunakan kembali kontainer sebelumnya, Anda dapat menggunakan perintah Bangun Ulang atau Bersihkan di Visual Studio untuk memaksa Visual Studio menggunakan kontainer baru.

Proses menjalankan debugger tergantung pada jenis proyek dan sistem operasi kontainer:

Skenario	Proses debugger
Aplikasi .NET Core (kontainer Linux)	Visual Studio mengunduh vsdbg dan memetakannya ke kontainer, kemudian akan dipanggil dengan program dan argumen Anda (yaitu, dotnet webapp.dll), lalu debugger melekat ke proses.
Aplikasi .NET Core (Kontainer Windows)	Visual Studio menggunakan onecoremsvsmon dan memetakannya ke kontainer, menjalankannya sebagai titik masuk lalu Visual Studio terhubung dan melampirkannya ke program. Ini mirip dengan cara Anda biasanya mengatur penelusuran kesalahan jarak jauh pada komputer atau komputer virtual lainnya.
Aplikasi .NET Framework	Visual Studio menggunakan msvsmon dan memetakannya ke kontainer, menjalankannya sebagai bagian dari titik masuk tempat terhubungnya Visual Studio, dan melampirkannya ke program.

Untuk informasi tentang vsdbg.exe, lihat Penelusuran kesalahan Offroad .NET Core di Linux dan OS X dari Visual Studio.

Mengubah gambar kontainer untuk penelusuran kesalahan dan produksi

Untuk memodifikasi gambar kontainer untuk penelusuran kesalahan dan produksi, ubah tahap.base Tambahkan kustomisasi Anda ke Dockerfile di bagian tahap dasar, biasanya bagian pertama di Dockerfile. Lihat referensi Dockerfile dalam dokumentasi Docker untuk informasi tentang perintah Dockerfile.

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
# <add your commands here>

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["WebApplication3/WebApplication3.csproj", "WebApplication3/"]
RUN dotnet restore "WebApplication3/WebApplication3.csproj"
COPY . .
WORKDIR "/src/WebApplication3"
RUN dotnet build "WebApplication3.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "WebApplication3.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication3.dll"]

Ubah gambar kontainer hanya untuk penelusuran kesalahan

Skenario ini berlaku ketika Anda ingin melakukan sesuatu dengan kontainer Anda untuk membantu Anda dalam proses penelusuran kesalahan, seperti menginstal sesuatu untuk tujuan diagnostik, tetapi Anda tidak ingin yang diinstal dalam build produksi.

Untuk memodifikasi kontainer hanya untuk penelusuran kesalahan, buat tahap lalu gunakan properti DockerfileFastModeStage MSBuild untuk memberi tahu Visual Studio untuk menggunakan tahap yang disesuaikan saat penelusuran kesalahan. Lihat referensi Dockerfile dalam dokumentasi Docker untuk informasi tentang perintah Dockerfile.

Dalam contoh berikut, kami menginstal paket procps-ng, tetapi hanya dalam mode debug. Paket ini menyediakan perintah pidof, yang diperlukan Visual Studio tetapi tidak ada dalam gambar Mariner yang digunakan di sini. Tahap yang kita gunakan untuk debugging mode cepat adalah debug, tahap kustom yang ditentukan di sini. Tahap mode cepat tidak perlu mewarisi dari build tahap atau publish , itu dapat mewarisi langsung dari base panggung, karena Visual Studio memasang volume yang berisi semua yang diperlukan untuk menjalankan aplikasi, seperti yang dijelaskan sebelumnya dalam artikel ini.

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.

FROM mcr.microsoft.com/dotnet/aspnet:6.0-cbl-mariner2.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM base AS debug
RUN tdnf install procps-ng -y

FROM mcr.microsoft.com/dotnet/sdk:6.0-cbl-mariner2.0 AS build
WORKDIR /src
COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
RUN dotnet restore "WebApplication1/WebApplication1.csproj"
COPY . .
WORKDIR "/src/WebApplication1"
RUN dotnet build "WebApplication1.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "WebApplication1.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]

Dalam file proyek, tambahkan pengaturan ini untuk memberi tahu Visual Studio untuk menggunakan tahap debug kustom Anda saat penelusuran kesalahan.

  <PropertyGroup>
     <!-- other property settings -->
     <DockerfileFastModeStage>debug</DockerfileFastModeStage>
  </PropertyGroup>

Bagian berikutnya berisi informasi yang mungkin berguna dalam kasus tertentu, seperti saat Anda ingin menentukan titik masuk yang berbeda, atau jika aplikasi Anda diaktifkan SSL dan Anda mengubah sesuatu yang mungkin memengaruhi cara sertifikat SSL ditangani.

Membangun dari baris perintah

Jika Anda ingin membuat proyek kontainer dengan Dockerfile di luar Visual Studio, Anda dapat menggunakan docker build, , MSBuilddotnet build, atau dotnet publish untuk membangun dari baris perintah.

Jika Anda menggunakan jenis build .NET SDK, Anda tidak memiliki Dockerfile, sehingga Anda tidak dapat menggunakan docker build; sebagai gantinya, gunakan MSBuild, dotnet build atau dotnet publish untuk membangun pada baris perintah.

Menggunakan build Docker

Untuk membangun solusi dalam kontainer dari baris perintah, biasanya Anda dapat menggunakan perintah docker build <context> untuk setiap proyek dalam solusi. Berikan argumen konteks build. Konteks build untuk Dockerfile adalah folder pada komputer lokal yang digunakan sebagai folder kerja untuk menghasilkan citra. Misalnya, folder tempat asal Anda menyalin file saat menyalin ke kontainer. Dalam proyek .NET Core, gunakan folder yang berisi file solusi (.sln). Jika dinyatakan sebagai jalur relatif, argumen ini biasanya ".." untuk Dockerfile dalam folder proyek dan file solusi dalam folder induknya. Untuk proyek .NET Framework, konteks build adalah folder proyeknya, bukan folder solusi.

docker build -f Dockerfile ..

Warmup proyek

Warmup proyek mengacu pada serangkaian langkah yang terjadi ketika profil Docker dipilih untuk suatu proyek (yaitu ketika proyek dimuat atau dukungan Docker ditambahkan) untuk meningkatkan performa pengoperasian berikutnya (F5 atau Ctrl+F5). Perilaku ini dapat dikonfigurasi di bawah Alat>Opsi>Alat Alat Kontainer. Berikut tugas yang beroperasi di latar belakang:

• Periksa apakah Docker Desktop telah terinstal dan berjalan.
• Pastikan Docker Desktop telah diatur ke sistem operasi yang sama dengan proyek.
• Tarik citra pada tahap pertama Dockerfile (tahap base pada sebagian besar Dockerfile).
• Bangun Dockerfile dan mulai kontainernya.

Pemanasan hanya terjadi dalam mode Cepat , sehingga kontainer yang sedang berjalan memiliki folder aplikasi yang dipasang volume. Itu berarti bahwa setiap perubahan pada aplikasi tidak membatalkan kontainer. Perilaku ini meningkatkan performa penelusuran kesalahan secara signifikan dan mengurangi waktu tunggu untuk tugas yang berjalan lama seperti menarik gambar besar.

Pemetaan volume

Agar penelusuran kesalahan berfungsi dalam kontainer, Visual Studio menggunakan pemetaan volume untuk memetakan folder debugger dan NuGet dari komputer host. Pemetaan volume dijelaskan dalam dokumentasi Docker di sini. Anda dapat melihat pemetaan volume untuk kontainer menggunakan Jendela Kontainer di Visual Studio.

Berikut adalah volume yang dipasang dalam kontainer Anda. Apa yang Anda lihat di kontainer Anda mungkin berbeda tergantung pada versi minor Visual Studio 2022 yang Anda gunakan.

Volume	Deskripsi
Folder aplikasi	Berisi folder proyek tempat Dockerfile berada.
HotReloadAgent	Berisi file untuk agen isi ulang panas.
HotReloadProxy	Berisi file yang diperlukan untuk menjalankan layanan yang memungkinkan agen muat ulang host berkomunikasi dengan Visual Studio di host.
Folder paket NuGet	Berisi paket NuGet dan folder fallback yang dibaca dari file obj{project}.csproj.nuget.g.props dalam proyek.
Debugger jarak jauh	Berisi bit yang diperlukan untuk menjalankan debugger dalam kontainer, tergantung jenis proyeknya. Ini dijelaskan secara lebih rinci di bagian Penelusuran kesalahan.
Folder sumber	Berisi konteks build yang diteruskan ke perintah Docker.
TokenService.Proxy	Berisi file yang diperlukan untuk menjalankan layanan, memungkinkan VisualStudioCredential untuk berkomunikasi dengan Visual Studio di host.

Untuk .NET 8, titik pemasangan tambahan di root dan untuk pengguna aplikasi yang berisi rahasia pengguna dan sertifikat HTTPS mungkin juga ada. Dan dalam pratinjau Visual Studio 17.10, volume Hot Reload dan Token Service, bersama dengan komponen lain, Distroless Helper, dikombinasikan di bawah satu titik pemasangan, /VSTools.

Catatan

Pratinjau Visual Studio 17.10 Jika Anda menggunakan Docker Engine di Subsistem Windows untuk Linux (WSL) tanpa Docker Desktop, atur variabel VSCT_WslDaemon=1 lingkungan agar Visual Studio menggunakan jalur WSL saat membuat pemasangan volume. Paket NuGet Microsoft.VisualStudio.Azure.Containers.Tools.Targets 1.20.0-Preview 1 juga diperlukan.

Untuk aplikasi web ASP.NET Core, terdapat dua folder tambahan untuk sertifikat SSL dan rahasia pengguna, yang dijelaskan secara lebih rinci di bagian berikutnya.

Mengaktifkan log alat kontainer terperinci

Untuk tujuan diagnostik, Anda dapat mengaktifkan log Container Tools tertentu. Anda dapat mengaktifkan log ini dengan mengatur variabel lingkungan tertentu. Untuk proyek kontainer tunggal, variabel lingkungan adalah MS_VS_CONTAINERS_TOOLS_LOGGING_ENABLED, yang kemudian masuk %tmp%\Microsoft.VisualStudio.Containers.Tools. Untuk proyek Docker Compose, ini adalah MS_VS_DOCKER_TOOLS_LOGGING_ENABLED, yang kemudian masuk %tmp%\Microsoft.VisualStudio.DockerCompose.Tools.

Perhatian

Saat pengelogan diaktifkan dan Anda menggunakan proksi token untuk autentikasi Azure, kredensial autentikasi dapat dicatat sebagai teks biasa. Lihat Mengonfigurasi autentikasi Azure.

Titik masuk kontainer

Visual Studio menggunakan titik masuk kontainer kustom tergantung jenis proyek dan sistem operasi kontainer, berikut berbagai kombinasinya:

Jenis kontainer	Titik Masuk
Kontainer Linux	Titik masuknya adalah tail -f /dev/null, yang merupakan waktu tunggu tanpa batas untuk menjaga kontainer tetap berjalan. Ketika aplikasi diluncurkan melalui debugger, ini adalah debugger yang bertanggung jawab untuk menjalankan aplikasi (yaitu, dotnet webapp.dll). Jika diluncurkan tanpa penelusuran kesalahan, alat akan menjalankan docker exec -i {containerId} dotnet webapp.dll untuk menjalankan aplikasi.
Kontainer Windows	Titik masuk adalah sesuatu seperti C:\remote_debugger\x64\msvsmon.exe /noauth /anyuser /silent /nostatus yang menjalankan debugger, sehingga mendengarkan koneksi. Metode ini berlaku saat debugger menjalankan aplikasi. Saat diluncurkan tanpa penelusuran kesalahan, docker exec perintah digunakan. Untuk aplikasi web .NET Framework, titik masuk sedikit berbeda, dengan menambahkan ServiceMonitor ke perintah.

Titik entri kontainer hanya dapat dimodifikasi dalam proyek Docker Compose, bukan dalam proyek kontainer tunggal.

Aplikasi ASP.NET Core dengan SSL yang diaktifkan

Alat kontainer di Visual Studio mendukung penelusuran kesalahan aplikasi ASP NET core dengan SSL yang diaktifkan dengan sertifikat dev, dengan cara yang sama seperti kinerjanya tanpa kontainer. Untuk mewujudkannya, Visual Studio menambahkan beberapa langkah lagi untuk mengekspor sertifikat dan membuatnya tersedia untuk kontainer. Berikut alur yang ditangani Visual Studio saat menelusuri kesalahan dalam kontainer:

1. Memastikan sertifikat pengembangan lokal ada dan dipercaya pada komputer host melalui alat dev-certs.

2. Mengekspor sertifikat ke %APPDATA%\ASP.NET\Https dengan kata sandi aman yang disimpan di penyimpanan rahasia pengguna untuk aplikasi khusus ini.

3. Memasang volume untuk direktori berikut:

   • *%APPDATA%\Microsoft\UserSecrets
   • *%APPDATA%\ASP.NET\Https

ASP.NET Core mencari sertifikat yang cocok dengan nama rakitan di bawah folder Https , itulah sebabnya sertifikat dipetakan ke kontainer di jalur tersebut. Jalur sertifikat dan kata sandi dapat didefinisikan secara alternatif menggunakan variabel lingkungan (yaitu, ASPNETCORE_Kestrel__Certificates__Default__Path dan ASPNETCORE_Kestrel__Certificates__Default__Password) atau dalam file json rahasia pengguna, misalnya:

{
  "Kestrel": {
    "Certificates": {
      "Default": {
        "Path": "c:\\app\\mycert.pfx",
        "Password": "strongpassword"
      }
    }
  }
}

Jika konfigurasi Anda mendukung build dalam kontainer dan luar kontainer, Anda harus menggunakan variabel lingkungan, karena jalurnya khusus untuk lingkungan kontainer.

Untuk informasi selengkapnya tentang menggunakan SSL dengan aplikasi ASP.NET Core dalam kontainer, lihat Menghosting gambar ASP.NET Core dengan Docker melalui HTTPS.

Untuk sampel kode yang menunjukkan pembuatan sertifikat kustom untuk aplikasi multi-layanan yang tepercaya pada host dan dalam kontainer untuk komunikasi layanan ke layanan HTTPS, lihat CertExample.

Konten terkait

• Properti MSBuild untuk proyek kontainer.
• MSBuild
• Dockerfile di Windows
• Kontainer Linux di Windows