1.
Essentials of container
真壁 徹
日本マイクロソフト株式会社
クラウドソリューションアーキテクト
2019/3/28
コンテナー、大事なことだけ
JAZUG女子部 第14回勉強会

2.
自己紹介
{
“名前” : “真壁 徹(まかべ とおる)”,
“所属” : “日本マイクロソフト株式会社”,
“役割” : “クラウド ソリューションアーキテクト”,
“経歴” : “大和総研 → HP Enterprise”,
“特技” : “インフラ & オープンソース”,
“資格” : “CNCF Certified Kubernetes Admin.”
}

3.
お伝えしたい内容
コンテナー技術のおさらいと現状
Kubernetesって何？
マイクロソフトの取り組み
Windowsコンテナーのいま
よくあるご質問
(おまけ) Azure関連コンテンツサイト最新情報

4.
エッセンシャル
シャンプーの香りのように 爽やかにお伝えします
essential
意味: 欠くことのできない、重要な、本質的な
コンテナー技術の大事なことに絞ってお話します
「なぜ必要なの？何がうれしいの？」を中心に
網羅性は高くないので、扱わなかった話題はぜひご質問を
(注) わたしの主観とそれにもとづく表現が多く含まれます

5.
コンテナー技術の
おさらいと現状

6.
いわゆるコンテナー
でもほとんどの人は使ったことがない(*)ので いまいちピンとこない
distel2610
(*)個人でも購入できるそうです

7.
身近なコンテナー
今日はこっちで

8.
ちょっとだけ ファンタジーを

9.
印藤家の悩み
カレーが大好きな印藤さん一家
週に3回はカレー
みんな好みが違う
帰宅、食べる時間がバラバラ
帰宅後の即カレーは正義
その日に急いで作ると味が決まら
ない

10.
印藤家が実現したいこと
最終ステップが課題 素杯酢博士へ相談
週末にじっくり作って味を決める
ベースカレーとスパイス、具材を
分離する
それぞれを別に保存する
個々人が食べたいときに合成！即
カレー！！
↑これが難しそう(博士に相談)

11.
博士の発明
カレー合成ロボ “Docurry Mk-II”
• タンドリー社製CR-3型
高出力マイクロ波加熱
装置
• 具材や素材を瞬時に識
別する非ノイマン型高
性能コンピューター
• 初号機はコンテナー1年
戦争で活躍

12.
冷蔵庫
即カレー環境の実現
冷蔵庫から パーソナライズされたカレーを 即提供 味も安定
辛さにこだわる
父カレー
魚介好き
母カレー
牛好き 甘口
兄カレー
超超甘口
妹カレー
テーブル
docurry run 父カレー
docurry run 妹カレー
辛旨！ 甘旨！

13.
父コンテナー
博士の工夫 その①
レイヤー構造にすることで、共通化と多様性を両立
チキン
辛口スパイス
ベースカレー
ライス
母コンテナー
魚介
中辛スパイス
ベースカレー
ライス
兄コンテナー
ビーフ
甘口スパイス
ベースカレー
ライス
妹コンテナー
チキン
ベースカレー
ライス

14.
冷蔵庫
父コンテナー
博士の工夫 その②
保存時に冷蔵庫にすでに同じレイヤーがあれば、共有できるようにした
チキン
辛口スパイス
母コンテナー
魚介
中辛スパイス
ベースカレー
ライス
docurry push 母カレー
差分の
中辛スパイスと
魚介だけ送る
ベースカレー
ライス
同じ
冷蔵庫スペースの節約！
調理

15.
テーブル
父コンテナー
博士の工夫 その③
テーブルにすでに同じレイヤーがあれば、共有できるようにした
チキン
辛口スパイス
母コンテナー
魚介
中辛スパイス
ベースカレー
ライス
docurry run 父カレー
差分の
辛口スパイスと
チキンだけ送る
ベースカレー
ライス
同じ
ライスとベースカレーを送らなくていいので、
着席後に即カレー！
(*)共有要素でも、あたかも自分専用に見える謎技術

16.
導入効果
Docurryのいる日々
準備は充分、味の決まったカレー
(再現性が高い)
それぞれ好みのカレー (混ざらな
い)
冷蔵庫のスペースも節約
帰宅後すぐに食べられる
2人目以降はさらに早く食べられる

17.
カレーから離れて
ITの話に戻りましょう

18.
最近相談される「こうしたい」
複雑で、変化を求められる時代だから
個々の機能、責務をシンプルで分かりやすい大きさに刻みたい
シンプルな機能を組み合わせて全体を実現したい
機能を作成・変更したら素早く配備・入替したい (迅速なデプロイ)
無駄な設備は持ちたくない (共有による資源の有効利用)
設備は共有しても独立性は確保したい (依存関係の分離)

19.
油断させておいて 印藤家 再び登場
Docurryのいる日々
準備は充分、味の決まったカレー
(再現性が高い)
それぞれ好みのカレー (混ざらない)
冷蔵庫やテーブルのスペースも節約
帰宅後すぐに食べられる
2人目以降はさらに早く食べられる

20.
同じアプローチで解決できるかも？

21.
仮想マシンとコンテナーの違い
ハードウェア
ハイパーバイザー (Hyper-V、vSphereなど)
仮想マシン 仮想マシン
OSカーネル
OSカーネル
コンテナー コンテナーランタイム/ライブラリー
アプリ
ランタイム/
ライブラリー
ランタイム/
ライブラリー
アプリ アプリ
コンテナーイメージ

22.
Dockerとは
ハードウェア
ハイパーバイザー (e.g. Hyper-V)
仮想マシン
OSカーネル
コンテナー コンテナー
ランタイム/
ライブラリー
ランタイム/
ライブラリー
アプリ アプリ
+周辺ツール
• UNIX、BSD、Linuxの世界でコンテナー
技術は昔からあった
• OSの各種リソース管理機能を活用して
リソースを分離する
• dotCloud(現Docker)社が自社PaaS向け
に作ったコンテナーの仕組みをOSSにし
てブレイク
• 従来のコンテナー技術より、アプリ開
発者視点でうれしい機能、周辺ツール
に力を入れている
• イメージ作成、配布の仕組み
• 差分イメージ形式
• 標準化の勢いでDockerの影響力は弱ま
りつつあるが、広く普及している
コンテナーイメージ

23.
コンテナーの元になる「コンテナーイメージ」
レイヤーを重ねる
ベースイメージに必要なランタイム、ライブラリを重ねていく
イメージが小さいと起動が速く、取り回しやすい
(alpine linuxなど軽量なベースイメージも人気)
Dockerfileと呼ばれる定義ファイルにイメージの
作り方を指定し、ビルドする
(イメージに含めるアプリやライブラリ、
環境変数などのパラメーター、コンテナー起動時に
実行するコマンドなどを指定する)
Pyhton:3.6.2-slim
(Base Image)
wordcount.py
(User Application)
html2text, urllib3, sh
(Python Package)
debian:stretch-slim
(Base of Base Image)
イメージの例

24.
レジストリーとは
コンテナーイメージを格納するデータストア
Docker Hub
パブリックレジストリーの
代表格
Azure Container
Registry(ACR)
プライベートレジストリー
実装例
様々な公式イメージ
(ubuntu、nginx、etc)
ユーザー作成イメージ
ユーザー作成イメージ
docker push/pull/run
• レジストリーを指定しないと
Docker Hubに接続 (デフォルト)
• インターネット経由
• ユーザー個別にレジストリー
を作成し、指定
• Azureネットワークに閉じた
運用が可能

25.
コンテナーを”Run”すればいい (早い、楽、再現性が高い)
“仮想マシン、OS、ランタイム、ライブラリー、アプリの導入” vs “docker run”
依存関係地獄から解放される (混ざらない)
ひとつのOSインスタンス上で複数種、バージョンのランタイムやライブラリーを分離できる
導入先のマシンに入っているランタイムに頼らず、自ら必要なものをコンテナーに含め、持ち込む
開発のサクサク感が増し、運用を「強くする」手段も増える
時は金なり、人間の待ち時間はコストが高い
性能拡張したいときはコンテナーを複製して負荷分散できる
短時間で元の環境に戻せる、再現できる = 回復力(Resiliency)を得る
うれしいこと

26.
コンテナーと印藤家
課題に対するアプローチとその効果は
だいたい同じ

27.
印藤家のカレー・バリューチェーン
調理 保存 即カレー
自慢のレシピ

28.
レジストリー
Container Image
コンテナーのバリューチェーン
Build/Ship/Run
Build Ship Run
.NET Core App
Java App
Dockerfile
Dockerfile
.NET Core App
Runtime/Lib
Container Image
Java App
Runtime/Lib 実行環境(VM上でも可)
Container
.NET Core App
Runtime/Lib
Container
Java App
Runtime/Lib
Other Lang.
Dockerfile

29.
Classified as Microsoft Confidential
Demo
Docker Containerが起動する動きを見てみよう

30.
身近なコンテナーの活用例
Azure Cloud Shell、お使いでしょうか
20秒程度で起動
ブラウザーがあれば使える
$HOME以下はAzure Filesに永続化される
利用料金はAzure Files利用量に対してのみ

31.
Azure
Azure Cloud Shellの仕組み
フロントエンドはJavaScript
ブラウザにXterm.jsがロードされる
Ubuntuコンテナーを生成
ユーザーごとにひとつのコンテナー
コンテナーイメージはユーザー共通
20分間無操作だと破棄される
永続化領域はAzure Filesへ
$HOMEの下が永続化される
ブラウザ ブラウザ
ユーザーコンテナー
Azure Files
Xterm.js Xterm.js
コンテナーイメージ
(Ubuntu 16.04 &
Tools)

32.
起動してすぐ、多様なCLIツールを使える
インストールする必要なし
Docker CLI/Docker Machine
Kubectl
Helm
DC/OS CLI
MySQL クライアント
PostgreSql クライアント
sqlcmd ユーティリティ
mssql-scripter
iPython クライアント
Cloud Foundry CLI
Terraform
Ansible
.NET Core (2.1.4)
Go (1.9)
Java (1.8)
Node.js (8.9.4)
PowerShell Core (6.0.1)

33.
Azure Cloud Shell提供の動機
ユーザーにどのような価値を提供したかったか
「踏み台サーバー」をなるべく不要に
ツールをインストール、アップデートしなくて済むように
(クラウド関連のツールは進化が早く、数も多い)
使いたいときに、すぐ、どこからでも
内部コストはなるべく低く (無料提供です)

34.
仮想マシンで実現できなかったか？
実現が難しかった理由
仮想マシンの作成と起動に時間がかかる (2分程度かかる)
ツールのインストール、アップデートに時間がかかる
ユーザーが個別に占有するリソース (特にメモリ、ディスク)が多く、
コスト高

35.
仮想マシンでも実現不可能ではないですが…
Azure Cloud Shellに限らず 仮想マシンデプロイの一般的課題
カスタムVM
Image
アプリ、ライ
ブラリ、ラン
ライム
セットアップ
物理サーバー
VM
デプロイ
• カスタムVM Imageのサイズが大きく、デプロイに時
間がかかる
事前セットアップ方式 デプロイ時セットアップ方式
VM Image
アプリ、ライ
ブラリ、ラン
ライム
セットアップ
(スクリプトなど)
物理サーバー
VM
デプロイ
• セットアップが必要なのでデプロイが遅い
• セットアップ後のテストが難しい (スクリプ
トでアプリは期待通りに導入されたのか？設
定は間違ってないか？）
(共通)すべてのVMに同じようなOS領
域、システムデータがあり、大部分
重複しているのが無駄

36.
Azure Cloud Shellとコンテナー
仮想マシンとカーネル、イメージを共有しているため、個々のコンテナーは軽量
仮想マシン
OSカーネル
コンテナーイメージ (Ubuntu 16.04、ライブラリー、ランタイム、ツール)
読み取りのみ
ユーザー領域
書き込み可
ユーザー領域
書き込み可
ユーザー領域
書き込み可
ユーザーA
コンテナー
ユーザーB
コンテナー
ユーザーC
コンテナー 1度コンテナーホスト
にダウンロードされれ
ば、あとは差分のみ取
得する
ユーザー個別のリソー
スを小さくすることで、
速い起動と低コストを
実現できた
ツールが期待通り導入
されたことを検証済み
のコンテナーイメージ
を配布

37.
SmartHotel360
マイクロソフトが考える「いまどきの」システム リファレンス実装
https://github.com/Microsoft/SmartHotel360-Mobile

38.
じゃあコンテナーは、もう常識なのかしら…
事例もよく目にするようになりましたし

39.
「みんなやってるよ！」
という状況では まだない という印象

40.
レジストリー
Container Image
どこが課題になりがちか
Build/Shipのステップがあるから Run できるのですが…
Build Ship Run
.NET Core App
Java App
Dockerfile
Dockerfile
.NET Core App
Runtime/Lib
Container Image
Java App
Runtime/Lib 実行環境
Container
.NET Core App
Runtime/Lib
Container
Java App
Runtime/Lib
ここだけ注目する人が多い
「VMより軽いんでしょ？」
「じゃあ設備コストが下がる？」
準備が必要
Other Lang.
Dockerfile

41.
コンテナー導入あるある
動機が大事です
どこかの誰かが「コンテナーは
サーバー仮想化を置き換える技
術」とか耳元でささやく
危機感を感じたインフラチームが
独立先行、アプリチームがついて
こない (誰がBuildするの？)
なぜならアプリチームは手間に見
合うだけの価値をまだ感じていな
い
ｺﾞｺﾞｺﾞｺﾞｺﾞｺﾞｺﾞｺﾞｺﾞｺﾞｺﾞｺﾞｺﾞｺﾞｺﾞ

42.
多くの企業システムの現場では
あくまで現状の私見です
仮想マシンの単純な移行先にはならないと 最近気づきはじめる
リソース効率はいいが、コンテナー固有の仕組み作りが必要
それに見合うメリットがあるか
アプリ開発チームのモチベーションが成功のカギ
素早くアプリケーションを配備、再現したいというニーズがあるか
本番だけでなくテスト、検証環境の高度化にも有用 (必要な時に必要なテスト環境を素早く作る)
新規開発での検討は自然だが、いかに既存アプリで活かせるかを模索
既存アプリを大きく変更せず、テクノロジーリフレッシュしたいという要望
多くのユーザーが手を動かして試行錯誤をはじめている

43.
例: アプリの「プチ」モダナイゼーション
VM
コンテナーグループ
コンテナー
新機能アプリ
(HTTPS Proxy)
ランタイム/
ライブラリ
コンテナー
既存アプリ
ランタイム/
ライブラリ
コンテナーグループ
コンテナー
新機能アプリ
(API Adapter)
ランタイム/
ライブラリ
コンテナー
既存アプリ
ランタイム/
ライブラリ

44.
もしコンテナーに価値を感じたら
取り組むなら、いかに時間を作り出すかがポイントです
いまと同じ仕事量に加えて試行錯
誤なんて、できない
どうやって仕事を減らして、時間
を作り出すか
仕事を減らすコツは「やめる」こ
と (退職をすすめているわけではあ
りません)

45.
コンテナーに取り組む時間を作る
向かなそうな他のシステムでは 何かを「やめる」
アジリティ
移行のインパクト
既存アプリ
IaaS
VMs
Rehost
Containers
Refactor
Microservices
Rearchitect
Serverless
Rebuild
New
SaaS apps
Replace
App Modernization
Lift & Shiftでもいい
から「設備のお守
り」から解放される
自前で運用するシステ
ムをなくしてしまう
うまくいきそうなアプリを
選んで、小さくはじめる
そして知見を得る
手段はコンテナーだけじゃない
ことも意識する

46.
Kubernetesって何？

47.
再び ファンタジーを

48.
印藤家の目覚め
カレー愛が高まる印藤さん一家
正直、我が家のカレーは旨い
親族や友達にも食べて欲しい
よしカレーパーティーだ
でも、パーティーって難しい

49.
パーティーあるある
主催者は大変ですよね
急に大勢くる
(提供のタイミングが読めない)
手土産のフグが水を吐く
(テーブルが使えなくなる)

50.
印藤家が実現したいこと
再び 素杯酢博士に相談
急に大勢きても耐えられるよう、
カレー供給能力を上げたい
もしテーブルでフグが水を吐いて
も、参加者に他のテーブルへ移っ
てもらい、引き続きカレーをふる
まいたい
複数のテーブルに分散したDocurry
の指揮役がいるとよさそう

51.
博士の発明
カレーパーティー オーケストレーター “Keemanetes”
• 複数テーブルのDocurry
のまとめ役
• 需要に合わせてカレー
の提供を指示
• トラブル時はそのテー
ブルにあったカレーと
同じものを他テーブル
で提供
• カレーの味変や戻しも
テーブル間の整合性を
保ちつつ実施レストランから問い合わせが殺到
業界標準になりつつある

52.
パーティーから離れて
ITの話に戻りましょう

53.
最近相談される「こうしたい」
複雑で、変化を求められる時代だから
個々の機能、責務をシンプルで分かりやすい大きさに刻みたい
シンプルな機能を組み合わせて全体を実現したい
機能を作成・変更したら素早く配備・入替したい (迅速なデプロイ)
無駄な設備は持ちたくない (共有による資源の有効利用)
設備は共有しても独立性は確保したい (依存関係の分離)
急に処理量が増えても楽に拡張したい (拡張性の確保)
どこかが壊れても人の手を介さず復旧してほしい (自己復旧)

54.
油断したところで いまどきのカレーパーティー
複雑で、変化を求められるカレーパーティーだから
具材やベース素材をシンプルで分かりやすい大きさに刻みたい
それらを組み合わせてカレーを実現したい
カレーを作成・味変したら素早く配備・入替したい (迅速なデプロイ)
無駄なテーブルは持ちたくない (共有による資源の有効利用)
テーブルは共有しても独立性は確保したい (依存関係の分離)
急にゲストが増えても楽に拡張したい (拡張性の確保)
フグが水を吐いても人の手を介さずパーティーを続けたい (自己復旧)

55.
コンテナー実行基盤とカレーパーティー
課題に対するアプローチとその効果は
だいたい同じ

56.
Kubernetes (k8s)
コンテナーオーケストレーターの事実上標準
オープンソースソフトウェア
CNCF (Cloud Native Computing foundation)が開発を主導
マイクロソフトはCNCFのプラチナメンバー
多くのベンダーがオープンソースをベースに製品・サービス化
Azure Kubernetes Serviceで採用
他Azureサービスでも内部基盤として使われている

57.
Kubernetes アーキテクチャー概要
AKSの実装例
MasterとNodeに分かれる
Masterが全体を制御
Nodeにアプリコンテナーを配置
API Serverに管理系操作を集約
API Serverを中心に、各コンポー
ネントが自律的に動く
管理系のアクセス
• アプリの配備
• 管理系操作
ユーザーからのアクセス

58.
すごく多機能ですが
今日は主要な機能のみご紹介

59.
主要機能 (スケジューリング)
必要なリソースやもろもろの条件を考慮し、コンテナーを最適なNodeに配置する
Node 0
Master
Node 1 Node 2
Container A(Pod) Container A(Pod) Container B(Pod)
Container B(Pod)
• CPUはこのくらい
• メモリはこのくらい
• そのほか条件
マニフェスト
(あるべき姿を宣言)
Node 2が
最適

60.
主要機能 (複製)
コンテナーの複製を作成し、負荷分散や可用性向上
Node 0
Master
Node 1 Node 2
Container A(Pod) Container A(Pod)
Container B(Pod)
Container B(Pod)
• CPUはこのくらい
• メモリはこのくらい
• 複製を2つ
• そのほか条件
複製を作るぞ
Container B(Pod)
複製に向けるトラフィックをまとめた
り、散らす仕組みもあります (Service)
マニフェスト
(あるべき姿を宣言)

61.
主要機能 (自己復旧)
障害時に残存Nodeでコンテナーを再作成
Node 0
Master
Node 1 Node 2
Container A(Pod) Container A(Pod)
Container B(Pod)
Container B(Pod)
• CPUはこのくらい
• メモリはこのくらい
• 複製を2つ
• そのほか条件
Node 2から活動報告がない
Node 0でコンテナーを再作成だ
Container B(Pod)Container B(Pod)
マニフェスト
(あるべき姿を宣言)
常にあるべき姿と現状の
突合せループを回している

62.
主要機能 (バージョン管理)
クラスター全体でコンテナーのバージョン整合性を保つ (戻しもできる)
Node 0
Master
Node 1 Node 2
Container A(Pod) Container A(Pod)
Container B
v2(Pod)
Container B(Pod) v2
• CPUはこのくらい
• メモリはこのくらい
• 複製を2つ
• そのほか条件
コンテナーを新バージョン
で入れ替えるぞ
Container B
v2(Pod)
再デプロイ
マニフェスト
(あるべき姿を宣言)
じわじわローリングアップグレードす
ることもできます

63.
Classified as Microsoft Confidential
Demo
Kubernetesの動きを見てみよう

64.
Kubernetesクラスター作成に必要な作業
やること多すぎ
etcdの起動
Kubernetes設定ファイルの作成と配布
Kubernetesコンポーネント(バイナリー)
の配布
Kubernetesコンポーネントの起動
Kubernetesアドオンコンポーネントの作
成
などなど
Node間ネットワークの作成
Masterサーバーの作成
Masterサーバー向けロードバランサーの
作成
Nodeサーバーの作成
Pod間ネットワークの作成
証明書の作成と配布
etcd設定ファイルの作成と配布

65.
めんどくせぇ！

66.
Azure Kubernetes Service (AKS)
API server
Controller
ManagerScheduler
etcd
Store
Cloud
Controller
Self-managed master node(s)
• Kubernetesは構築や維持の負担が
大きい
• Azureはコントロールプレーン(マ
スター)部分をマネージドサービス
として提供
• アップストリームに追従 (独自の
Kubernetesを作らない)
• MasterノードはAzureがサービスと
して管理しており、不可視
• 他Azureサービスとの連携や組み合
わせが容易(ロードバランサー、仮
想ネットワーク、Azure AD、Azure
Monitor、etc)
Customer VMs
App/
workload
definitionUser
Docker
Pods
Docker
Pods
Docker
Pods
Docker
Pods
Docker
Pods
Schedule pods over
private tunnel
Kubernetes
API endpoint
Azure managed control plane

67.
AKS 物理/論理配置
Node
Node
Master (物理サーバー、仮想マシン) Node (物理サーバー、仮想マシン)
API Server
etcd
ロードバランサー ロードバランサー
Controller
Manager
Scheduler
kubelet kube-proxy(*)
Container
Runtime
アドオンコン
ポーネント(**)
(*) Nodeのネットワークを制御 (iptables操作など)
(**) DNS、Metrics Serverなど (Podとして動く)
不可視
API エンドポイント
(例: hogehoge.hcp.japaneast.azmk8s.io)

68.
Kubernetesを支える周辺機能
AKSの例

69.
Kubernetesは奥深い沼
いい本があります

70.
マイクロソフトの取り組み
少し視野を広げて

71.
マイクロソフトのキーマン
Brendan Burns
Kubernetesの生みの親 (Co-
founder)
2016年にマイクロソフトへ加わる
いまやコンテナー関連サービスの
みならず、Azure Resource
Manager、Azure Cloud Shellなど
Azureの開発を広くリード
Brendan Burns
Distinguished Engineer, Microsoft

72.
Containers in Azure
Choice of developer tools and clients
Azure Container Registry Docker Hub
App Service
Azureの歴史ある
PaaSサービス
GitやVisual Studio
に限らずDockerコ
ンテナーでのデプ
ロイにも対応
Service Fabric
マイクロソフトの
開発する分散処理
基盤
.NETアプリケー
ションとの相性が
いい
Kubernetes Service Container Instance
コンテナーオーケスト
レーターの事実上標準
Ecosystem
パートナーとの
協業
コンテナー1つから
使えるマネージド
サービス
AKSの仮想ノードと
しても利用可能

73.
Azureでコンテナーが使えるサービスの特徴
位置づけ 汎用/特化 課金リソース 特記事項
Container Instances シンプルなコンテ
ナー実行基盤
汎用 コンテナー利用
CPU・メモリ (秒)
KubernetesのNodeと
して利用可能
部分的にKubernetes
マニフェストをサ
ポート
App Service (Web
App for Containers)
WebアプリPaaS 特化(Webアプリ) App Service Plan (秒) 部分的にKubernetes
マニフェストをサ
ポート
Service Fabric 分散アプリ基盤 汎用 クラスター構成リ
ソース(主にVM) (分)
.NETアプリとの親和
性が高い
Kubernetes Service コンテナーオーケス
トレーター
汎用 クラスター構成リ
ソース(主にVM) (分)
事実上の業界標準

74.
誤解をおそれずに一言で
一言
Container Instances 使い捨てるコンテナーに (バッチや期間限定アプリ)
App Service (Web App for Containers) シンプルなWebアプリならKubernetesより断然手軽
Service Fabric .NETで、がっつり分散アプリを作るなら
Kubernetes Service 数多く、複数の種類のコンテナーを組み合わせて動かすなら

75.
やっぱりコンテナーは、もう常識なのかしら…
多くのベンダーが注力しているようだし

76.
レジストリー
Container Image
(再掲) どこが課題になりがちか
Build/Shipのステップがあるから Run できるのですが…
Build Ship Run
.NET Core App
Java App
Dockerfile
Dockerfile
.NET Core App
Runtime/Lib
Container Image
Java App
Runtime/Lib 実行環境
Container
.NET Core App
Runtime/Lib
Container
Java App
Runtime/Lib
準備が必要
Other Lang.
Dockerfile

77.
多くの企業システムの現場では
あくまで現状の私見です
コンテナーをビルドする前提が整っていないことも
そもそもソースコード管理の仕組みが散らかっている
管理されていてもビルドシステムと連携できない (機能的、セキュリティポリシー的に)
まず小さくはじめて実績を作ったほうがうまくいく
新規もしくは既存アプリで「コンテナー化しやすい、うまくいきそう」なものから
パイプラインは新しく作る方が楽
既存のパイプラインやツールは並行して維持する (いきなり全面移行を考えない)
新しいパイプラインで小さく始め、成功体験を得てから本格化、横展開する
パイプラインを構成するツールはクラウドであれば簡単に試せる (リポジトリ、ビルド/テストパイ
プライン、デプロイ/リリース管理、etc)

78.
コンテナーCI/CDパイプラインのイメージ
AKSの場合
Source
code control
Helm
chart
Inner loop
Azure
Container
Registry
Azure Pipeline/
DevOps Project
Auto-
build
Azure
Monitor
CI/CD
Test
Debug
Azure
DevSpaces
AKS dev
cluster
AKS production cluster
Pods
ACI instances
Pods

79.
例: Azure DevOps CI/CDパイプライン
あくまで実装例です 入れ替え、組み合わせられるツールは数多くあります
Azure Repo
Git互換リポジトリ
Azure Pipeline
パイプライン管理
Azure Container Registry
プライベートコンテナーレジストリ
Kubernetes
参考資料: チュートリアル: Azure DevOps プロジェクトを使用して ASP.NET Core アプリを Azure Kubernetes
Service (AKS) にデプロイする
GitHubも
いいですね

80.
Windowsコンテナーのいま

81.
2つの課題
ベースのコンテナーイメージサイズがまだ大きい (Nano Server 350MB, Server Core 4.2GB)
事実上標準であるKubernetes対応が遅れた (今週リリースされたKubernetes 1.14で Windows Node
がGA)
本格的な普及には至っていない
2つの課題を解決せねば
サイズの問題はホストへのキャッシュを活かすのが短期的な解決策
既存アプリ(.NET Framework)への適用に期待する声が多い
新規であれば.NET Core on Linuxという手もあり、Windowsである必然性は小さい
.NET Frameworkを動かすならServer Coreが必要 -> サイズ問題
Windowsコンテナーの現状

82.
KubernetesのWindows対応に時間がかかった理由
Linuxの世界で生まれたKubernetesへの追従
KubernetesはLinuxの機能を大いに
活用している (代表例: iptables)
WindowsもOSレベルでの対応が必
要
対応している間にもKubernetesは
どんどん進化する
過去からの経緯にご興味があれば
Windows SIGの議事録を
https://github.com/kubernetes/community/tree/master/sig-windows > Meeting notes and Agenda

83.
徹底してカレーに例えると
ライス前提で作った仕組みに、ナンを適用するようなチャレンジ
ﾊﾐﾀﾞｼ ﾁｬｳﾈ… ﾍﾞﾁｬｯﾄ ｼﾁｬｳﾈ…
ナンのサイズをなるべく小さく
(Windowsベースイメージの継続的
縮小)
べちゃっとしないように素材を工
夫 (Windows OSに機能追加)
オーケストレーターやコンテナー
ランタイムにもナンに合わせた工
夫をしてもらう

84.
Linux Nodeとの違いや制約を理解して使う
育ってきた環境が違うから
理解、把握してから使いましょう
いまできること、制約
今後解決しそうな制約
根本的な制約
リスクや緩和策
https://github.com/kubernetes/enhancements/blob/master/keps/sig-windows/20190103-windows-
node-support.md

85.
将来を見据えて 現在のおすすめアプローチ
Windowsアプリのコンテナー実行基盤 代表的な選択肢
シングルコンテナーのWebアプリ -> Web App for Containers
まだプレビュー段階ですが、ベースは実績あるAzure Web Apps
運用が楽です
シングルコンテナーにおさまるASP .NETアプリであれば強くおすすめ
マルチコンテナーアプリ -> AKS Engine からの AKS
AKSのデプロイメントエンジン(AKS Engine)はOSSとして公開されており、Windowsに対応済み
AKSのWindows Node対応はロードマップにありますが、急ぎであれば/いま検証して知見を得た
い場合はAKS Engineを

86.
よくあるご質問

87.
Windowsの上でLinuxコンテナーが動く？
混乱しやすいですよね
前提とするOSカーネルが違うコンテナーは動きません
(Windows上でLinuxコンテナーは動かない、逆もまたしかり)
ただし、仮想マシンの機能を使って工夫しているケースがあります
たとえばDocker Desktop for Windows/MacではLinuxコンテナーが使
えますが、Hyper-Vやxhyveを使ってLinux仮想マシンを作り、その上
でLinuxコンテナーを動かしています

88.
WindowsのGUIアプリをコンテナー化したい
残念ながらサポートされていません
Does Docker for Windows Server 2016 support GUI-based
applications?
At this time, no, Docker for Windows Server 2016 does not support
GUI-based applications. This is because Windows containers are based
on either Nano or Core Server, which do not allow users to start up a
GUI-based interface nor RDP into the container.
https://success.docker.com/article/does-docker-for-windows-server-2016-support-gui-based-applications

89.
Kubernetesの仕組みをもっと理解したい
いい本があります

90.
まとめ

91.
まとめ
技術や仕組みだけでなく、コンテ
ナーを使うと「どのように幸せに
なれるか」を考えましょう
焦る必要はありません、小さくは
じめて試行錯誤し、知見を得ま
しょう
カレーのことは忘れてください

92.
Azure関連コンテンツサイト
最新情報
おまけ

93.
公開コンテンツの充実はAzureの重要課題
docs.microsoft.com
自ら手を動かすユーザーが増え、
公開されているコンテンツの量と
質はクラウド活用を支えるカギに
サイトを抜本的に改善
技術者目線のメンバーが集結
(Developer AdvocateやStack
Overflowの元PMなど)
https://docs.microsoft.com/ja-jp/azure/

94.
改善例: GitHubによるフィードバック
広く意見を募る
ドキュメントに関する意見や要望、
指摘、修正依頼はGitHubと連動し
ている
わかりやすさ、正しさを客観的に
評価し、継続的に改善する

95.
改善例: Microsoft Learn
docs.microsoft.comと連動したセルフトレーニングサイト
ブラウザさえあれば一人で学習で
きる無償トレーニングサイト
試用がAzure無料利用枠におさまら
ない/所属企業で使っている環境を
汚したくない、という要望に応え
る
つど専用のサンドボックス環境が
用意され、のびのびと演習できる
https://docs.microsoft.com/ja-jp/learn/
コンテナー関連トレーニングもあります

96.
戦略策定者やアーキテクト向けにも
アーキテクチャー センター
サービス個別の機能のみならず、
Azure活用における戦略策定、アー
キテクチャー設計の参考になる情
報も充実
Azureに限らずクラウド全般に適用
できるアイデアやチェック項目も
豊富
https://docs.microsoft.com/ja-jp/azure/#pivot=architecture

97.
ベストプラクティスなども
Azureの製品グループだけでなく、
ユーザーに接しているメンバーが
その知見をコンテンツとして提供
手を動かす前に目を通してもよし、
振り返り/改善のチェックに読むも
よし

98.
© Copyright Microsoft Corporation. All rights reserved.