「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
内容 †
「コンテナのチェーン」が意味するところは、
CI/CD パイプライン（DevOpsワークフロー）に、
コンテナの
- ビルド・システム
- プロジェクト・ファイル
- Dockerfile
- ビルド・スクリプト
- IaC（compose、manifest）によるデプロイ
を含め、
開発 → UT → CT → IT → ST環境のチェーンを構築する。
背景 †
- これによって、SIでは、なかなかリーチしなかった、
辺りにリーチするようになってきた。
詳細 †
そもそも、 †
サービスのプラクティス
- 究極的にはスクリプト言語向け。
- SIだと頻繁に更新されることがない。
- テストやリリースのシナリオが再利用率が低い。
で、CI/CDから得られる効果が薄い。
どちらかと言うと †
分離環境の構築比重が高い。
- SIでは、
- UT / CT / TT / STなど環境が多段になっている。
- このため、これらの環境構築が優先される。
- 逆に、多段化されているので、CI/CDがハマらない。
（≒ CI/CD パイプラインが長すぎて構築できない。）
- Webでは、
Webサービス保守体制は、恐らく、
SIのように多段になっていない。
昨今、Docker → Docker Compose → K8sの敷居が下がってきた。 †
...と、チェーン＆リフトして行く開発方式のサポートにより、
- SIでもCI/CD的な事の有効が高まってきたと言える。
- ただ、コチラをやってみて、まだ、一部、
バカジャネーノ？と思う所はある（難し過ぎの意）
- 以下の ①～⑤ ようなチェーンがサクッと繋がる
ようになってくると実践的になって行くと思う。
① 全ローカル環境、 †
≒ 従来型の開発。
② ①のプログラムだけ、Docker化、 †
③ ②のサービス類だけ、Docker Compose化、 †
- ①のサービス類だけ、Docker ComposeでDocker化。
- 開発の対象というより、ローカル開発環境をDocker対応させるイメージ。
- Docker Composeで、ローカルと同一のポート番号でブリッジさせれば、
（portsの指定は、ホスト:コンテナなので、xxxx:xxxxにする）
このUXは、①の開発のUXと、あまり大きく変わらない。
④ ③にプログラムも加える。 †
- ③で作成した、システム一式を全てDockerにリフトする。
- プログラムをコンテナ化する。
- コンテナ化したプログラムの接続文字列類を、
ローカル・ブリッジ経由から、コンテナ直に変更する。
⑤ ④をKomposeなどでK8sに食わす。 †
XKE/XKSは高価なので、IaaSのLinuxVM（コンテナ・サーバ）があると便利かも。 †
XKE/XKSは、CaaS、PaaSに相当。
ユースケース †
ユースケースとしては、
コンテナ・イメージを起動するみたいなイメージ。
役割分担 †
これは、Docker Desktop for Windowsでもできるんですが、
Nested VirtualizationをサポートするハイスペックなVMが必要になるので、
- 各種テスト環境（IaaSベースのLinuxコンテナ・サーバ）で、
その他 †
コンテナ †
コンテナ・イメージ †
≒ Dockerイメージ
コンテナ・レジストリ †
≒ Dockerレジストリ
Windowsで開発する理由（境界分離の１要素） †
主な理由 †
結局、この辺なのかなと。
- OA環境からエディタまで、クライアントOSに、
Windowsが必要なケースは、まだ多そう。
- ビルド以降を、全てLinux化することも可能と思うケド、
まだ、ビルド～単体テスト迄は、Windowsでやるケースが多そう。
境界の設定 †
みたいな境界が何処かに
必要になるのではないか？と。
参考 †
※ とは言え、Linux開発環境の整備も進めています。
参考 †
OSSコンソーシアム †
開発基盤部会 Wiki †
開発基盤部会 Blog †
- Docker for Windows上で Docker Compose
でテストし、Open PaaSにデプロイできる
Tags: :コンテナ, :テスト, :デバッグ, .NET開発, :ツール類, :CI
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
