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