Skip to content

MS_DotNetCoreDockerfile

Jump to bottom
nishi_74322014 edited this page Sep 12, 2026 · 2 revisions

.NET CoreのDockerfile

概要

.NET Core の Dockerfile について、
特に Visual Studio によって生成される Dockerfile と比較して記述した内容。

詳細

.NET Core

開発用とリリース用で異なる。

※ 各バージョンは、dotnet/dotnet-docker を参照。

移行メモ（正誤）: 元ページの「各バーション」は「各バージョン」の誤記と判断し、修正した。

開発用

  • 開発＆デバッグ用

  • Visual Studio によって生成される Dockerfile。

    • Visual Studio 経由で動作させられるが、
    • 通常の docker run や、docker-compose では動かない。

  • netcore:3.0

#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/core/runtime:3.1-buster-slim AS base
WORKDIR /app

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

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

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

リリース用

  • テスト以降用

  • 自作する必要がある。

    • 通常の docker run や、
    • docker-compose でも

    動作する。

  • netcore:3.0

FROM mcr.microsoft.com/dotnet/core/sdk:3.0 AS build
WORKDIR /app

# copy csproj and restore as distinct layers
COPY dotnetapp/*.csproj ./dotnetapp/
COPY utils/*.csproj ./utils/
WORKDIR /app/dotnetapp
RUN dotnet restore

# copy and publish app and libraries
WORKDIR /app/
COPY dotnetapp/. ./dotnetapp/
COPY utils/. ./utils/
WORKDIR /app/dotnetapp
RUN dotnet publish -c Release -o out

# test application -- see: dotnet-docker-unit-testing.md
FROM build AS testrunner
WORKDIR /app/tests
COPY tests/. .
ENTRYPOINT ["dotnet", "test", "--logger:trx"]

FROM mcr.microsoft.com/dotnet/core/runtime:3.0 AS runtime
WORKDIR /app
COPY --from=build /app/dotnetapp/out ./
ENTRYPOINT ["dotnet", "dotnetapp.dll"]

補足（イメージ名が変わっている）: 上記の mcr.microsoft.com/dotnet/core/… は
.NET 5 以降 core が外れて mcr.microsoft.com/dotnet/… になっている。

用途 現在のイメージ
ビルド mcr.microsoft.com/dotnet/sdk:8.0
実行（コンソール） mcr.microsoft.com/dotnet/runtime:8.0
実行（ASP.NET Core） mcr.microsoft.com/dotnet/aspnet:8.0
実行（最小） mcr.microsoft.com/dotnet/runtime-deps:8.0（自己完結型／AOT 用）

また、タグの -buster / -bullseye（Debian のコードネーム）は
世代とともに変わるため、
8.0 のようにコードネームを含まないタグを使う方が追随しやすい。

構成の差異

未確認だが、恐らく、ASP.NET と同じ。

ASP.NET Core

開発用とリリース用で異なる。

開発用

  • 開発＆デバッグ用

  • Visual Studio によって生成される Dockerfile。

    • Visual Studio 経由で動作させられるが、
    • 通常の docker run や、docker-compose では動かない。

  • aspnetcore:3.0

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

FROM mcr.microsoft.com/dotnet/core/sdk:3.0-buster 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"]

リリース用

  • テスト以降用

  • 自作する必要がある。

    • 通常の docker run や、
    • docker-compose でも

    動作する。

  • aspnetcore:3.0

FROM mcr.microsoft.com/dotnet/core/sdk:3.0 AS build
WORKDIR /app

# copy csproj and restore as distinct layers
COPY *.sln .
COPY WebApplication1/*.csproj ./WebApplication1/
RUN dotnet restore

# copy everything else and build app
COPY WebApplication1/. ./WebApplication1/
WORKDIR /app/WebApplication1
RUN dotnet publish -c Release -o out

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0 AS runtime
WORKDIR /app
COPY --from=build /app/WebApplication1/out ./
ENTRYPOINT ["dotnet", "WebApplication1.dll"]

補足（.csproj だけ先に COPY する理由）: 両方の「リリース用」に共通する
「*.csproj を先にコピーして dotnet restore → その後に全体をコピー」
という書き方は、Docker のレイヤー キャッシュを効かせるための定石である。
ソースを 1 行直しただけで NuGet の復元がやり直しになるのを防ぐ。
本ページのコメント # copy csproj and restore as distinct layers は
まさにこれを指している。

構成の差異

  • 開発＆デバッグ用のコンテナの /app と /src に、
    ソース・コードが含まれてるの、全く解らんわ...。

フォルダ構成の差異

  • ...と思ったら、docker run の際に、以下のようなことをしている。
docker run -dt -v "...\vsdbg\vs2017u5:/remote_debugger:rw" -v "...\WebApplication1:/app" -v "...\WebApplication1:/src/" -v ... マウントやら、環境変数やら。

  • ...って事は、AS build と、AS publish 意味あるのか？と思い、
    AS build と、AS publish の部分を全て消してみたが、...動作する。

    • /app と /src は、Windows 側を見ている。

    • 以下が、AS build と AS publish を削除した Dockerfile。

#See https://aka.ms/containerfastmode ...

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

FROM base AS final
WORKDIR /app
ENTRYPOINT ["dotnet", "WebApplication1.dll"]

コレで、デバッグ実行も問題なく動作する。

  • ...もっと言うと、以下でも動作する...。
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
ENTRYPOINT ["dotnet", "WebApplication1.dll"]
  • ...と言う事で、開発＆デバッグ用の
    Dockerfile の事は、忘れてしまってイイかも。

補足（この検証結果の裏付け）: 著者が実験で突き止めたとおりで、
Visual Studio の Fast Mode（aka.ms/containerfastmode）では、

  • base ステージまでしかビルドしない（build / publish は使われない）
  • ビルド成果物はホスト側（Windows）で作られ、
    -v でコンテナへマウントされる
  • デバッガ（vsdbg）も同様にマウントされる

という動作になる。つまり、開発用 Dockerfile の
build / publish ステージは CI や docker build 単体で使うときのために
残されているもので、F5 デバッグ時には通らない。

ただし、「忘れてしまってイイ」と言い切る前に 1 点注意がある。
Visual Studio の構成を Release に切り替える、あるいは
「コンテナー ツール」の設定で Fast Mode を無効にすると、
通常どおり全ステージがビルドされる。
そのとき build / publish を削っていると失敗するため、
消すなら開発専用と割り切る（リリース用は別 Dockerfile にする）のが安全である。
これは本ページ自身が開発用とリリース用を
分けている方針とも整合する。

参考

移行メモ: 既定ブランチが master から main に変更されているため、
上記リンクの master を main に修正した。

Microsoft Docs

dotnet/dotnet-docker

開発基盤部会 Wiki

本 Wiki 内

Tags: .NET開発, .NET Core, 仮想化

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally