マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

  • 何気に名称が、Visual Studio Tools for Kubernetesに変更されている?

前提環境

コチラとの差分

インストール

コチラとの差分

  • Visual Studio Kubernetes Tools
  • 以下からインストール(VS2019の場合)
    インストール

紆余曲折のメモ

断念

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

再起

しかし、Compose on K8sがリリースされ、これによって、
Docker ComposeOpen PaaSで扱えるようになった
らしいため、評価をリスタートしてみる気になった。

再び断念

手順3まで調査した結果、再び中断した(2019/12/04)。

  • Azure Dev Spacesで実行することはできた
    (ただし、パブリック・アクセスが不可能の故、明確では無い)。
  • ツールが(、まだ)、作りこまれていないっぽい。

再び再起

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

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

再々の再起

調査した結果、再び再起した(2020/04/13)。

将来的には...

これらのツールが、

  • Helm Charts
  • Compose on Kubernetes
  • Kompose

辺りを統合するのではないだろうか?

Visual Studio 2022

Visual Studio 2022で動作確認。

CaaSのトレンド変化

将来的には...」からの変化としては、
Open PaaS系のCaaSだけではなく、
クラウド系のCaaSも歓迎されてきた。

手順1

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

画面の確認(手順 / 結果)

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

  • プロジェクト・テンプレートにKubernetesが追加される。
    手順1
  • ASP.NET Core 3.0 の MVCを選択する。
    手順2
  • 新規作成したプロジェクトをソリューション・エクスプローラで確認すると「azds.yaml」が追加されていることが解る。
  • Azure Dev SpacesのlaunchSettingsでデバッグ実行を開始すると、Azureにデプロイしようとするので、ここで止める。
    手順5

ココまでで解った事。

  • Kubernetes用プロジェクト・テンプレートでは、
    「azds.yaml」が追加され、Azure Dev SpacesのlaunchSettingsが構成されるらしい。

手順2

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

手順

Azure Dev Spacesの構成

  • Azure ポータルから、K8sクラスタを使用して構成する。
  • Dev Spaces言うだけあって、開発・デバッグ用のスペースらしい。
  • K8sクラスタは構築出来ても、
    Dev Spacesを有効にできるリージョンに制限があるので注意する。

プロジェクトの構成

  • Kubernetes用プロジェクト・テンプレートで「WebApplication1」的なプロジェクトを新規作成
  • 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で動作&リモートデバッグしているものと思われる。

ココまでで解った事。

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

手順3

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

前提条件

構成

  • テンプレートの選択
    標準のプロジェクト・テンプレートで「WebApplication1」的なプロジェクトを新規作成
    (Kubernetes用プロジェクト・テンプレートでは「Kubernetes/Helm」を追加できなかったタメ)
  • プロジェクトの構成
    手順2と、同様の「WebApplication1」を使用する。

手順

手順2と同様。

結果

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

ココまでで解った事。

(Toolsでは、できないのか、まだ、実装されていないのか?)

手順4

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

前提条件

構成

  • AKSの構成
    Azureのポータルと、Azure CLIのazコマンドを使用する。

手順

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

ココまでで解った事。

  • 「docker-compose up -d」で躓いていたが
    再起動&リトライなどで動作するようになる。
    (docker自体が、そういうモノらしく、不安定であるもよう)
  • docker-composeで作成したイメージを
    • ローカルで実行・テストした後に、AKSにイメージをプッシュして実行できる。
    • ただし、K8sでの実行の定義は、docker-composeではなくK8sマニュフェストに書く。

手順5

前提条件

構成

こちらをVS2019に.NET Core3.0アップグレード
したものを使用する(移行後の物品はコチラ)。

手順

AKSのASP.NET Coreチュートリアルを遂行する(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)と環境をチェーンさせて、
  • シームレスにステージング環境にまで持っていくことができるようになる。

手順6

※ 本手順は未実施。

前提条件

構成

手順5K8sマニュフェストに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 に設定される。

結果

ローカル

未実施

リモート

未実施

ココまでで解った事。

未実施

手順7

Docker Desktop for Windowsに、寄り道。

K8s

これは、Docker Desktop(ローカル)のK8s

WSL2

Docker Desktopは、Docker Desktop WSL2 Backendで、WSL2もサポート

Windows Serverコンテナ

Docker Desktopは、Docker Desktop for Windowsで、Windowsコンテナもサポート

手順8

上記(手順5)のサンプルをMVC_Sampleに変更。

前提条件

結果

上手く行かなかった。

ココまでで解った事。

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

    Docker for Windowsが不安定という話と、
     Dockerのportをマップする機能が若干不安定との情報がある。

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

手順9

上記(手順8)をローカルのDocker Desktop for WindowsのK8sで実行。

前提条件

結果

上手く行かなかった。

ココまでで解った事。

  • 「その文字は使えない」とか「ファイルをマウントしろ」とか、
    メッセージが表示され、そのままのDocker Composeでは上手く動かない。
  • なので、やれるとしても、Kompose のconvert機能を
    マイグレーション・ツールのように使用して、マニフェスト・ファイルを
    新規作成する位しか、K8sへチェーンさせる方法は無さそう。

手順10

Visual Studio 2022でやってみる。

前提条件

Docker for WindowsではなくWSL2で実行。

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

結果

コンソールアプリ

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

Webアプリ

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

ココまでで解った事。

手順11

Visual Studio 2022でDocker Composeを試してみる。

前提条件

Docker for WindowsとWSL2を併用

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

※ ただし、Docker Desktop WSL2 Backendを有効化しない。

結果

コンソールアプリ

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

Webアプリ

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

ココまでで解った事。

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

サンプル

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で動かす方法。

参考

Qiita

ASK を使いこなす

Kubernetes on Docker for Windows

Microsoft Docs

Kubernetes

Azure Dev Spaces

OSSコンソーシアム

Blog

Wiki


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


添付ファイル: file5.png 469件 [詳細] file2.png 467件 [詳細] file1.png 435件 [詳細] fileinstall.png 451件 [詳細]

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2022-02-21 (月) 13:36:33 (788d)