-
Notifications
You must be signed in to change notification settings - Fork 0
MS_ContainerChain
- 戻る（CI/CD パイプライン、.NETアプリをコンテナにデプロイ（
MS_DeployDotNetAppToContainer.md））- コンテナのチェーン
-
コンテナ技術（
MS_ContainerTechnology.md）も進歩してきて、比較的、容易に、
「コンテナのチェーン」を構築できるようになってきた。 -
これによって、SIでは、なかなかリーチしなかった、
- CI/CD パイプライン
- DevOpsワークフロー
辺りにリーチするようになってきた。
「コンテナのチェーン」が意味する所は、
CI/CD パイプライン（DevOpsワークフロー）に、
コンテナの
- ビルド・システム
- プロジェクト・ファイル
- Dockerfile
- ビルド・スクリプト
- コンテナ・レジストリへの登録スクリプト
- IaCによるコンテナのデプロイ自動化
- compose
- manifest
を含め、
開発 → UT → CT → IT → ST環境のチェーンを構築する。
的な（目標）。
サービスのプラクティス
- 究極的にはスクリプト言語向け。
- SIだと頻繁に更新されることがない。
- テストやリリースのシナリオが再利用率が低い。
で、CI/CDから得られる効果が薄い。
分離環境の構築比重が高い。
- SIでは、
- UT / CT / TT / STなど環境が多段になっている。
- このため、これらの環境構築が優先される。
- 逆に、多段化されているので、CI/CDがハマらない。
（≒ CI/CD パイプラインが長すぎて構築できない。）
- Webでは、
Webサービス保守体制は、恐らく、SIのように多段になっていない。 - 実際に、
AKSをセキュアに利用するためのテクニカルリファレンス（MS_AKSSecureReference.md）の、
「詳細 > 構成のポイント > 開発～デプロイ」でも、- 「環境分離（セキュリティ境界）」の話が中心になっている。
- 実際にやってみて、「こりゃ無理だわ。」と思ったりする所も。
- 更なるコンテナ技術の進歩による「コンテナのチェーン」構築の簡素化が必要。
結局、この辺（WSL → WSL2: MS_WSLToWSL2.md）なのかなと。
- OA環境から開発環境まで、クライアントOSに、Windowsが必要なケースは、まだ多そう。
- ビルド以降を、全てLinux化することも可能と思うケド、まだ、ビルド～単体テスト迄は、Windows でやるケースが多そう。
-
なので、
- Windows で開発して、
- Linux で実行・テスト
みたいな境界が何処かに
必要になるのではないか？と。 -
以下の様なパターンが考えられる。
- エディタだけ Windows、ビルド以降全て Linux
- 単体テストだけ Windows、結合テスト以降が Linux
-
MosP も
- Windows で開発してるらしい（Java）。
- サポートのある実行環境はCentOSとのこと。
- twitter.com
※ とは言え、Linux開発環境の整備も進めています。
...と、チェーン＆リフトして行く開発方式のサポートにより、
- SIでもCI/CD的な事例が有効に機能するケースが増えてきたと言える。
- ただ、AKSをセキュアに利用するためのテクニカルリファレンスをやってみて、まだ、一部、バカジャネーノ？と思う所はある（難し過ぎの意）
- 以下の ①～⑤ ようなチェーンがサクッと繋がるようになってくると実践的になって行くと思う。
≒ 従来型の開発。
- ① のプログラムだけDocker化。
- ローカルのサービス群に対しては、
10.0.75.1でブリッジ（最新の環境では変更されている）（Docker for Windowsのネットワーク設定:MS_DockerForWindowsNetwork.md）。 - 参考
- ① のサービス類だけ、Docker ComposeでDocker化。
- 開発の対象というより、ローカル開発環境をDocker対応させるイメージ。
- Docker Composeで、ローカルと同一のポート番号でブリッジさせれば、
（portsの指定は、ホスト:コンテナなので、xxxx:xxxxにする）
このUXは、① の開発のUXと、あまり大きく変わらない。 - 参考
- ③ で作成した、システム一式を全てDockerにリフトする。
- プログラムをコンテナ化する。
- コンテナ化したプログラムの接続文字列類を、
ローカル・ブリッジ経由から、コンテナ直に変更する。
- 最後に、④ のシステムをK8sにリフトする。
- この際、Kompose や Compose on Kubernetes（Docker Desktop for Windows:
MS_DockerDesktopForWindows.md）を使用する。
※ Compose on Kubernetes は Docker Desktop から削除済み。 現行は Kompose、または Helm / Kustomize でマニフェストを管理するのが一般的。
XKE/XKSは、CaaS、PaaSに相当。
ユースケースとしては、
- Windows の開発環境から、
コンテナ・イメージをコンテナ・レジストリにプッシュして、 - IaaSベースの Linux コンテナ・サーバで
コンテナ・レジストリからコンテナ・イメージをプルして、
コンテナ・イメージを起動するみたいなイメージ。
これは、Docker Desktop for Windows（MS_DockerDesktopForWindows.md）でもできるんですが、
Nested VirtualizationをサポートするハイスペックなVMが必要になるので、
- 一般開発者は、
- Windows 開発環境で開発・テスト。
- 必要なら、WSL(1)（
MS_WSL.md）を使用して開発・テスト。
- SI担当者が、
- Docker Desktop for Windows でビルドとテスト。
- 結果をコンテナ・レジストリに登録する。
- 各種テスト環境（IaaSベースの Linux コンテナ・サーバ）で、
- コンテナ・レジストリからコンテナ・イメージをプルして、
- コンテナ・イメージを起動する。
Dockerコマンド が記述された Dockerファイル で Dockerイメージ をビルドする。
Dockerコマンド で Dockerレジストリ に Dockerイメージ を登録する。
- コンテナ技術（
MS_ContainerTechnology.md） - Docker for Windows（
MS_DockerForWindows.md） - Visual Studio Tools for Docker（
MS_VSToolsForDocker.md） - .NET CoreのDockerfile（
MS_DotNetCoreDockerfile.md）
- Dockerファイル
- ASP.NET Coreを
- Github - CI / CD関連
- VM起動後の開発環境のセットアップ
- Docker for Windows上で Docker Compose でテストし、Open PaaSにデプロイできる
- Docker→Docker Compose→K8sと、チェーン＆リフトして行く開発のサポート方式
Tags: コンテナ, テスト, デバッグ, .NET開発, ツール類, CI
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。