コンテナー、大事なことだけ

思い出すシリーズ

Transcript

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 Manager Scheduler etcd Store Cloud Controller Self-managed master node(s) • Kubernetesは構築や維持の負担が 大きい • Azureはコントロールプレーン(マ スター)部分をマネージドサービス として提供 • アップストリームに追従 (独自の Kubernetesを作らない) • MasterノードはAzureがサービスと して管理しており、不可視 • 他Azureサービスとの連携や組み合 わせが容易(ロードバランサー、仮 想ネットワーク、Azure AD、Azure Monitor、etc) Customer VMs App/ workload definition User 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.