MS_VSKubernetesTools - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

Visual Studio Kubernetes Tools

概要

補足（本ページの読み方と、結論の先出し）: 本ページは
2019 年から 2026 年にかけての長期の検証記録であり、
「断念 → 再起 → 再び断念 → 再び再起 → …」という
試行錯誤がそのまま残されている点に価値がある。

【結論（作者が最終的に到達した評価）】★
   「この手の VS からのブラックボックス化ツールは
     デメリットが多く浸透しないと判断」
     （Visual Studio 2026 の節）

   → この評価は【業界の実態と一致している】

【現在の状況】★
 ・【Azure Dev Spaces は 2023年10月に廃止】された
     → 本ページの手順２・手順３が依拠していた基盤が
       既に存在しない
     → 後継として Bridge to Kubernetes が案内されたが、
       【それも 2025年に非推奨化】された ★
 ・Visual Studio Tools for Kubernetes 拡張も
     更新が止まっている
 ・Visual Studio の【コンテナ ツール自体】は健在
     → Dockerfile 生成、Docker Compose、
       WSL2 でのデバッグは現在も使える ★
     → 「Docker まで」は VS で、
       「K8s から」は CLI / 別ツール、
       というのが定着した棲み分け

【今、同じことをするなら】
   ・ローカル K8s   … Docker Desktop / Rancher Desktop /
                      kind / minikube
   ・マニフェスト管理 … Helm / Kustomize
   ・IDE 支援       … VS Code の【Kubernetes 拡張】★
   ・内部ループ開発  … Tilt / Skaffold / DevSpace
   ・デプロイ       … GitHub Actions / Azure Pipelines →
                      Argo CD / Flux（GitOps）★

前提環境

Visual Studio Tools for Dockerの該当節との差分

インストール

Visual Studio Tools for Dockerの該当節との差分

インストール

紆余曲折のメモ

断念

Open PaaSは、ちょっと難しいなぁと思い断念していた。

再起

しかし、Compose on Kubernetesがリリースされ、
これによって、Docker Compose（Dockerコンポーズ）を
Open PaaSで扱えるようになったらしいため、
評価をリスタートしてみる気になった。

補足（Compose on Kubernetes は終了した）: 「再起」のきっかけとなった
この技術は、その後 Docker によって開発が終了した。

【Compose on Kubernetes】★
   ・Docker が提供した
     「docker-compose.yml をそのまま K8s にデプロイする」
     ための CRD / コントローラ
   ・Docker Desktop に同梱されていた
   ・【2021年頃に非推奨化、リポジトリはアーカイブ】★

【なぜ続かなかったか】
   ・Compose と K8s は【抽象度が違いすぎる】
     → Compose：単一ホストのコンテナ群を記述する
     → K8s：分散環境の宣言的な望ましい状態を記述する
     → Ingress、ConfigMap、Secret、PVC、HPA…
       Compose に対応物がないものが多すぎる
   ・結局【K8s マニフェストを書くしかない】★
     → 本ページの手順４でも
       「K8s での実行の定義は
         docker-compose ではなく K8s マニフェストに書く」
       と作者自身が結論している

【現在の後継】
   ・【Docker Compose Bridge】（2024年〜）
       compose.yml → K8s マニフェストへの変換
   ・【Kompose】（CNCF プロジェクト）★
       → 本ページの手順９で作者が言及している
         「マイグレーション・ツールのように使う」が
         まさに正しい使い方

再び断念

手順３まで調査した結果、再び中断した（2019/12/04）。

  • Azure Dev Spaces で実行することはできた
    （ただし、パブリック・アクセスが不可能の故、明確では無い）。

  • ツールが（、まだ）、作りこまれていないっぽい。

再び再起

調査した結果、再び再起した（2019/12/06）。
※ ただし、CLI でやっているので、Visual Studio Kubernetes Tools はあまり関係ない。

  • 手順４で

    • ネットの上の Docker Compose（Dockerコンポーズ）を
      CLI で動かす事が出来た。
    • また、AKS で動かす事が出来た。

  • 手順５で

  • 手順６ : 手順５の K8s マニュフェストに Nginx を追加する。

再々の再起

調査した結果、再び再起した（2020/04/13）。

将来的には...

これらのツールが、

  • Helm Charts
  • Compose on Kubernetes
  • Kompose

辺り（後述の「参考 > OSSコンソーシアム > Wiki」を参照）を統合するのではないだろうか？

Visual Studio 2022

Visual Studio 2022 で動作確認。

  • 手順10
  • 手順11

CaaSのトレンド変化

「将来的には...」からの変化としては、
Open PaaS系の CaaS だけではなく、
クラウド系の CaaS も歓迎されてきた
（OSS 系がセルフ・ホストするには公開されている技術情報がショボ過ぎて、
結局クラウド・サポートが必要になっているのが現状であるため）。

補足（この観察は的確）: 「セルフ ホストは情報が足りず、
結局クラウドに頼る」という指摘は、業界の実態を言い当てている。

【なぜセルフ ホスト K8s は難しいのか】★
   ・K8s 本体は【クラスタの中身】しか面倒を見ない
     → 以下は【全部自分で選んで組む】必要がある
         ・ネットワーク（CNI）… Calico / Cilium / Flannel
         ・ストレージ（CSI）… 何を使うか
         ・Ingress          … NGINX / Traefik / Istio
         ・証明書           … cert-manager
         ・監視             … Prometheus + Grafana
         ・ログ             … Loki / Elastic
         ・認証             … OIDC 連携
         ・アップグレード     … 年 3 回のマイナー更新に追随 ★
   → 【組み合わせの正解が公開されていない】
     （各社が自社構成を持っているだけ）

【マネージド K8s が選ばれる理由】
   ・AKS / EKS / GKE は
     上記の大半に【既定の答えを用意している】★
   ・コントロール プレーンの運用が不要
   ・クラウドの LB / ストレージ / IAM と統合済み

【さらに一段抽象化した選択肢（現在の主流）】★
   ・【Azure Container Apps】（K8s を隠した CaaS）
   ・AWS App Runner / Google Cloud Run
   → 「K8s を使いたいわけではなく、
     コンテナを動かしたいだけ」なら
     【こちらの方が適切】であることが多い

Visual Studio 2026

  • 単体の開発・実行には問題なく使えるが、オーケストレーターは問題が多い。
  • この手の VS からのブラックボックス化ツールはデメリットが多く浸透しないと判断。

補足（.NET Aspire という別解）: 「VS からのブラックボックス化ツール」への
評価は妥当だが、Microsoft は別のアプローチを出している。

【.NET Aspire】★
   ・複数プロジェクト＋依存サービス（Redis、DB、
     メッセージング）の【構成を C# で記述する】
       var redis = builder.AddRedis("cache");
       builder.AddProject<Projects.Web>("web")
              .WithReference(redis);
   ・ローカルでは【自動的にコンテナを起動】して繋ぐ
   ・【ダッシュボード】でログ・トレース・メトリクスを見られる
   ・デプロイ時は
     → azd（Azure Developer CLI）経由で
       Azure Container Apps へ
     → または【K8s マニフェストを生成】（Aspir8 等）★

【本ページの批判との関係】
   ・「ブラックボックス化」という点では同じ危うさがある
   ・ただし
     → 構成が【C# のコードとして可視】である
     → 生成物（Compose / マニフェスト）を
       【出力して確認できる】
     という点で、YAML を隠す方式よりは筋がよい ★
   ・とはいえ、依然として
     【Azure への誘導が強い】ことは変わらない

手順１

しかし、結局、「Visual Studio Kubernetes Tools」が何者なのか？
イマイチ解らないので、「WebApplication1」的なモノを使用し、再び、評価してみる。

画面の確認（手順 / 結果）

試してみると、以下のような画面が表示される。

  • プロジェクト・テンプレートに Kubernetes が追加される。

手順１

  • ASP.NET Core 3.0 の MVC を選択する。

手順２

  • 新規作成したプロジェクトをソリューション・エクスプローラで確認すると
    「azds.yaml」が追加されていることが解る。

  • Azure Dev Spaces の launchSettings でデバッグ実行を開始すると、
    Azure にデプロイしようとするので、ここで止める。

手順５

ココまでで解った事。

手順２

取り敢えず、Azure Dev Spaces の手順を参考にして、
単純な構成で Azure Dev Spaces を試してみる。

手順

Azure Dev Spaces の構成

  • Azure ポータルから、K8s クラスタを使用して構成する。

  • Dev Spaces 言うだけあって、開発・デバッグ用のスペースらしい。

  • K8s クラスタは構築出来ても、
    Dev Spaces を有効にできるリージョンに制限があるので注意する。

プロジェクトの構成

  • Kubernetes 用プロジェクト・テンプレートで
    「WebApplication1」的なプロジェクトを新規作成

  • Azure Dev Spaces の launchSettings でデバッグ実行を開始すると、

    • 前述（手順１）の Azure Dev Spaces のダイアログが表示される。

    • Azure サブスクリプションのアカウントで Visual Studio にログインしていると、
      構成した Azure Dev Spaces の情報が自動入力されるので
      そのまま続行する。

結果

Azure のハズだが、何故か、localhost でアプリケーションが起動する。
VS2019 から？既定でパブリック・アクセスが不可能になっているらしい。

  • Hyper-V コンテナで動いているのか？AKS 上で動いているのか？区別がつかない。

  • 調べると、内部で stdout と stderr ＋ port forward しているっぽい
    （Visual Studio の認証も通しているのでセキュアなのかもしれない）

  • 試しに Hyper-V コンテナをホストしている Hyper-V の VM を停止させてみたが、
    それでも UNIX で動作するので、AKS で動作＆
    リモートデバッグ（WSL上での.NET Core開発）
    しているものと思われる。

ココまでで解った事。

  • 実際に、Azure Dev Spaces で動作させることが出来た。
  • パブリック・アクセスが不可能だが、恐らく、AKS 上で動いている。

補足（作者の推測は正しい：kubectl port-forward 相当）: 「内部で
stdout と stderr ＋ port forward しているっぽい」という観察は正確である。

【Azure Dev Spaces / Bridge to Kubernetes の仕組み】★
   ① コードをコンテナ イメージにビルドして
      クラスタにデプロイする
   ② クラスタ内の Pod と
      【ローカルの Visual Studio を
        トンネルで繋ぐ】
   ③ ローカルにポートを転送する
      （kubectl port-forward と同じ原理）★
      → だから localhost で開く
   ④ 標準出力／標準エラーをローカルに流す
   ⑤ デバッガをアタッチする
      （リモート デバッグ）★

   → 「Hyper-V コンテナか AKS か区別がつかない」のは
     【区別がつかないように作ってある】ため
     → 作者が Hyper-V VM を止めて切り分けた手順は
       極めて的確な検証である ★

【なぜパブリック アクセスできないのか】
   Dev Spaces は【開発中のコード】を動かす場所であり、
   未完成・未検証のものが
   インターネットに露出しないよう
   【既定で Ingress を公開しない】設計だった
     → 公開したい場合は
       Ingress / Service を明示的に構成する必要があった

手順３

単純な構成で、Azure Dev Spaces でない AKS で使ってみる。

前提条件

構成

  • テンプレートの選択
    標準のプロジェクト・テンプレートで「WebApplication1」的なプロジェクトを新規作成
    （Kubernetes 用プロジェクト・テンプレートでは「Kubernetes/Helm」を
    追加できなかったタメ）

  • プロジェクトの構成
    手順２と、同様の「WebApplication1」を使用する。

手順

手順２と同様。

結果

標準のプロジェクト・テンプレートで「Kubernetes/Helm」を
追加しても Azure Dev Spaces の launchSettings になってしまう。

ココまでで解った事。

（Tools では、できないのか、まだ、実装されていないのか？）

手順４

Azure CLI で、Azure Dev Spaces でない
AKS で使ってみる。

前提条件

構成

手順

AKS の voting-app チュートリアル（Azure Kubernetes Service (AKS) を参照）を
遂行する（Azure CLI を使用する）。

ココまでで解った事。

  • 「docker-compose up -d」で躓いていたが
    再起動＆リトライなどで動作するようになる。
    （docker 自体が、そういうモノらしく、不安定であるもよう）

  • AKS は以下のコマンドで操作する。

    • Azure CLI の az コマンド
    • kubectl CLI コマンド

  • docker-compose で作成したイメージを

    • ローカルで実行・テストした後に、AKS にイメージをプッシュして実行できる。
    • ただし、K8s での実行の定義は、docker-compose ではなく
      K8s マニュフェストに書く。

手順５

  • 手順５では、複雑な構成の Docker Compose（Dockerコンポーズ）を
    AKS で使ってみる。

  • 具体的には、手順４で、docker-compose で作成したイメージを
    AKS で動かす。

前提条件

構成

Visual Studio Tools for Dockerの該当節を
VS2019 に .NET Core 3.0 アップグレードしたものを使用する
（移行後の物品は後述の「サンプル > WebApplication1」）。

手順

AKS の ASP.NET Core チュートリアル（Azure Kubernetes Service (AKS) を参照）を
遂行する（Azure CLI を使用する）。

結果

ローカル

ローカルの Docker for Windows で動かしてみる。

  • 起動
>C:\Git\EvaluateAspNetCoreOnK8s\WebApplication1>docker-compose up -d 
>Starting webapplication1_postgres_1 ... done
>Starting webapplication1_redis_1    ... done
>Creating webapplication1_webapplication1_1 ... done
  • アクセス
http://localhost:5000/
  • 停止
>C:\Git\EvaluateAspNetCoreOnK8s\WebApplication1>docker-compose down
>Stopping webapplication1_webapplication1_1 ... done
>Stopping webapplication1_postgres_1        ... done
>Stopping webapplication1_redis_1           ... done
>Removing webapplication1_webapplication1_1 ... done
>Removing webapplication1_postgres_1        ... done
>Removing webapplication1_redis_1           ... done
>Removing network webapplication1_default

※ 上記の参考に習い、無事動作した。

リモート

リモートの AKS で動かしてみる。

>kubectl get service --watch
NAME              TYPE          CLUSTER-IP    EXTERNAL-IP    PORT(S)         AGE
...

ココまでで解った事。

コンテナ技術を使用すると、

  • 単体 → 結合 → システム・テスト（UT → CT → ST）と環境をチェーンさせて、
  • シームレスにステージング環境にまで持っていくことができるようになる。

補足（この「チェーン」こそがコンテナの本質的な価値）: 手順５で
作者が到達したこの結論は、本ページ全体で最も重要な発見である。

【従来の問題】★
   ・開発機、テスト機、本番機で
     【環境が微妙に違う】
     → 「私の環境では動く」問題
     → 環境差異の調査に膨大な時間が溶ける

【コンテナが解決したこと】
   ・【同じイメージ】が
     開発 → CI → ステージング → 本番 を通る ★
     → ビルドは【一度だけ】
     → 環境差は【環境変数 / ConfigMap / Secret】でのみ与える
     → これが【Twelve-Factor App】の
       「Build, release, run を分離する」原則

【現在の実践】★
   ・イメージは【イミュータブル】
     → タグを latest ではなく
       【コミット ハッシュ / セマンティック バージョン】にする
   ・環境ごとの差は
     → Kustomize の overlay
     → Helm の values-{env}.yaml
   ・昇格（プロモーション）は
     → 【同じイメージ タグを別環境のマニフェストで参照する】
     → 再ビルドしない ★

手順６

※ 本手順は未実施。

前提条件

構成

手順５の K8s マニュフェストに Nginx を追加する。

手順

  • 手順５の手順を参考にする。

  • K8s マニュフェストに Nginx を追加する。

    • Nginx
apiVersion: apps/v1
kind: Deployment
metadata:
  name: proxy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: proxy
  template:
    metadata:
      labels:
        app: proxy
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
        volumeMounts: 
        - name: proxy
          mountPath: /etc/nginx/conf.d
      volumes: 
      - name: proxy
        configMap: 
          name: proxy
---
apiVersion: v1
kind: Service
metadata:
  name: proxy
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: proxy

  • WebApplication1

    • kind: Deployment
...
spec:
...
  template:
  spec:
    containers:
      ports:
      - containerPort: 5001
- kind: Service

...
ports:
- port: 5001

※ 80 と 5001 のブリッジは、
　/etc/nginx/conf.d の proxy_pass に設定される。

結果

ローカル

未実施

リモート

未実施

ココまでで解った事。

未実施

補足（K8s では自前 Nginx より Ingress が定石）: 未実施のまま
残された手順だが、現在の作法を補っておく。

【自前で Nginx Pod を立てる場合の問題】★
   ・設定変更のたびに ConfigMap を書き換えて
     【Pod を再起動する】必要がある
   ・バックエンドの Pod が増減しても
     nginx.conf は追随しない
     （Service 名で解決すれば動くが、
      きめ細かい制御はできない）
   ・TLS 証明書の更新を自分で回す

【Ingress を使う】★
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: app
     annotations:
       cert-manager.io/cluster-issuer: letsencrypt   # ★
   spec:
     ingressClassName: nginx
     tls:
     - hosts: [app.example.com]
       secretName: app-tls
     rules:
     - host: app.example.com
       http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: webapplication1
               port: { number: 5001 }

   → Ingress Controller（ingress-nginx 等）が
     この宣言を読んで【nginx.conf を自動生成し、
     リロードまでやる】★
   → cert-manager と組み合わせれば
     証明書の取得・更新も自動

【さらに新しい選択肢】
   ・【Gateway API】★（Ingress の後継。2023年に GA）
     → ルーティング定義がより表現力が高く、
       役割分担（インフラ担当／アプリ担当）が明確

手順７

Docker Desktop for Windows に、寄り道。

K8s

これは、Docker Desktop（ローカル）の K8s
（Docker Desktop for Windows を参照）

WSL2

Docker Desktop は、Docker Desktop WSL2 Backend で、WSL2 もサポート
（Docker Desktop for Windows を参照）

Windows Serverコンテナ

Docker Desktop は、Docker Desktop for Windows で、Windows コンテナもサポート
（Docker Desktop for Windows を参照）

手順８

上記（手順５）のサンプルを MVC_Sample（後述の「サンプル」）に変更。

前提条件

結果

上手く行かなかった。

ココまでで解った事。

  • 不安定なので、「外部サービス類」と「Web アプリと Web サーバ」のコンテナは、
    別の docker-compose.yml にするのがベターユースなのではないか？という事。

    ※ Docker for Windows が不安定という話と、
    　Docker（コンテナ技術 を参照）の
    　port をマップする機能が若干不安定との情報がある。

  • その後、networks でブリッジさせると上手く行く事が解った。

補足（Compose を分割して networks で繋ぐ作法）: 作者が到達した
この解は現在も定石である。書き方を明示しておく。

# infra/compose.yml（外部サービス類）
services:
  postgres:
    image: postgres:16
    networks: [backend]
networks:
  backend:
    name: myapp_backend      # ★ 名前を固定する
# app/compose.yml（Web アプリ）
services:
  web:
    build: .
    networks: [backend]
networks:
  backend:
    name: myapp_backend
    external: true           # ★ 既存のネットワークに参加する
【分割する利点】★
 ・DB を落とさずにアプリだけ再起動できる
   → 開発の内部ループが速くなる ★
 ・DB の初期データを保ったまま試行錯誤できる
 ・複数のアプリから同じ DB を参照できる

【注意】
 ・【起動順序】は自分で担保する
   → infra を先に up する
   → external: true のネットワークが
     無いとアプリ側が起動できない
 ・依存の待ち合わせは
   depends_on の【condition: service_healthy】を使う ★
     （単なる depends_on は「起動した」だけで
      「受付可能になった」を保証しない）

手順９

上記（手順８）を、ローカルの Docker Desktop for Windows の
K8s で実行。

前提条件

手順７の「K8s」を参照。

結果

上手く行かなかった。

ココまでで解った事。

  • 「その文字は使えない」とか「ファイルをマウントしろ」とか、
    メッセージが表示され、そのままの Docker Compose では上手く動かない。

  • なので、やれるとしても、Komposeの convert 機能を
    マイグレーション・ツールのように使用して、マニフェスト・ファイルを
    新規作成する位しか、K8s へチェーンさせる方法は無さそう。

補足（この結論は完全に正しかった）: 「Kompose を
マイグレーション ツールのように使う」という到達点は、
現在の公式見解と一致している。

【「その文字は使えない」の正体】★
   K8s のリソース名は
   【RFC 1123 のラベル形式】に従う必要がある
     ・小文字英数字とハイフンのみ
     ・アンダースコア（_）は【使えない】★
     ・先頭・末尾は英数字
     ・63 文字以内

   → Compose のサービス名
     「webapplication1_postgres_1」のような名前が
     そのままでは通らない

【「ファイルをマウントしろ」の正体】
   Compose の
     volumes:
       - ./nginx.conf:/etc/nginx/conf.d/default.conf
   のような【ホストのファイルを直接マウントする書き方】は
   K8s には対応物がない
     → 【ConfigMap】に入れてマウントする ★
     → ホストのパスをマウントする hostPath は
       本番では使ってはいけない
       （どのノードに配置されるか分からないため）

【Kompose の正しい使い方】★
   kompose convert -f docker-compose.yml
     → Deployment / Service / PVC の
       【たたき台】を生成する
     → そのまま使うのではなく、
       【生成物を読んで手で仕上げる】
         ・resources（requests/limits）を足す
         ・liveness / readiness プローブを足す ★
         ・Secret を分離する
         ・Ingress を足す
   → 「変換ツール」ではなく
     「移行の出発点を作るツール」である

手順10

Visual Studio 2022 でやってみる。

前提条件

前述の「前提環境」のとおり、Docker for Windows ではなく WSL2 で実行。

  • WSL2 インストール済み
  • Docker for Windows 未インストール

結果

コンソールアプリ

  • Docker サポートを追加し、デバッグ・プロパティから WSL を選択しデバッグ実行。
  • （初回は、.NET 未インストールのエラーが表示され、自動的に .NET インストールが進む）
  • 問題なく実行できた。ただし、結果はデバッグ出力に出力される。

Webアプリ

  • Docker サポートを追加し、デバッグ・プロパティから WSL を選択しデバッグ実行。
  • （初回は、ASP.NET 未インストールのエラーが表示され、自動的に .NET インストールが進む）
  • 問題なく実行できた。ただし、結果はブラウザ経由で表示される。

ココまでで解った事。

  • 問題なく実行できた。
  • ただし、Docker Compose には、Docker for Windows が必要
    （Visual Studio Tools for Dockerの該当節を参照）

移行メモ（誤字）: 移行元の「デバック実行」を「デバッグ実行」に統一した。

手順11

Visual Studio 2022 で
Docker Compose（Dockerコンポーズ）を試してみる。

前提条件

前述の「前提環境」のとおり、Docker for Windows と WSL2 を併用

  • WSL2 インストール済み
  • Docker for Windows 再インストール

※ ただし、Docker Desktop WSL2 Backend
（Docker Desktop for Windows を参照）を有効化しない。

結果

コンソールアプリ

  • 問題なく実行できた。
  • ただし、同様に、結果はデバッグ出力に出力される。

Webアプリ

  • 問題なく実行できた。
  • ただし、ポートの指定をどうやっているかが不明だった。

ココまでで解った事。

  • 問題なく実行できた。
  • これで１環境で双方の手順作成を確認可能。

補足（「ポートの指定をどうやっているかが不明」への回答）: これは
Visual Studio のコンテナ ツールが意図的に隠している部分である。

【VS のコンテナ デバッグでのポート決定】★
 ・Dockerfile の EXPOSE は【宣言でしかない】
   → 実際の公開ポートは決めない
 ・VS は起動時に
   → 【ホスト側のポートをランダムに割り当てて】
     コンテナの 8080（旧 80）/ 8081（旧 443）に繋ぐ
   → だから起動のたびに URL のポート番号が変わる
 ・ブラウザは
   launchSettings.json の launchUrl と
   実際に割り当てられたポートを
   VS が突き合わせて開く

【固定したい場合】★
   ・単一プロジェクト（Docker）
       launchSettings.json の
       "docker" プロファイルに
         "httpPort": 5000, "sslPort": 5001
       を明示する
   ・Docker Compose
       docker-compose.override.yml で
         ports:
           - "5000:8080"
       と明示する ★
       → VS はこの override を読んで起動する

【.NET 8 以降の変更点】★
   公式の ASP.NET Core コンテナ イメージの
   既定ポートが【80 → 8080】に変わった
     → 非 root ユーザーで動かすため
       （1024 未満のポートは特権が要る）
     → 古い Dockerfile / マニフェストを
       使い回すと繋がらない原因になる

サンプル

github.com

WebApplication1

https://github.com/daisukenishino2/EvaluateAspNetCoreOnK8s/tree/master/WebApplication1

WebApplication2

https://github.com/daisukenishino2/EvaluateAspNetCoreOnK8s/tree/master/WebApplication2

MVC_Sample

https://github.com/daisukenishino2/EvaluateAspNetCoreOnK8s/tree/master/MVC_Sample

git clone後にDocker Composeで動かす方法。

Visual Studio Tools for Dockerの該当節を参照。

参考

Qiita

AKS を使いこなす

Azure Kubernetes Service (AKS) の該当節を参照。

移行メモ（誤字）: 移行元では見出しが「ASK を使いこなす」と
なっていたため、「AKS」に修正した。

Kubernetes on Docker for Windows

Microsoft Docs

Kubernetes

Azure Dev Spaces

Azure Dev Spaces の該当節を参照。

OSSコンソーシアム

Blog

Wiki

Tags: 移行, コンテナ, .NET開発, .NET Core, Hyper-V, 仮想化, IaC

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

⚠️ **GitHub.com Fallback** ⚠️