Azure_Container_as_a_Service_v0.2.24.0301.pdf

これからコンテナ技術に取り組むアプリケーション開発者向けの勉強会スライドです。
コンテナの基礎からクラウドサービス（Azure）へのデプロイまでを紹介しています。

Transcript

1. Ayumu Inaba Technical Specialist Microsoft Japan Microsoft Azure Container as a Services 1
2. Agenda コンテナ技術の概要 Azure のコンテナサービス DEMO : ASP.NET on Web App for Container Appendix コンテナアプリ開発のお作法 オーケストレーターを意識した開発 2
3. コンテナ技術の概要 3
4. Why Container ？ 4 ‘Write-once, Run-anywhere’ マイクロサービス アーキテクチャ対応 Dev/Test の効率化 確実な Production 環境の配置 Developer Community の成長 アプリケーションのポータビリティ 開発, QA, 運用環境の標準化 OS やインフラ環境の抽象化 リソース配分の最適化 高速起動、スケーラビリティの確保 DevOps Developers Operations
5. Container ? 5
6. Container ? 6 シンプルな機能を組み合わせ 責務を分離してシンプルに 変更を迅速にデプロイ 設備の共有 依存関係の分離 資源の有効活用 需要に応じた柔軟な拡張
7. コンテナと仮想マシンの違い 7 ハードウェア ハイパーバイザー (Hyper-V、vSphereなど) 仮想マシン 仮想マシン OSカーネル OSカーネル コンテナー コンテナー ランタイム/ ライブラリー アプリ ランタイム/ ライブラリー ランタイム/ ライブラリー アプリ アプリ 分離 コンテナーイメージ 軽量 再利用 ランタイム/ ライブラリー アプリ
8. Docker コンテナー UNIX、BSD、Linuxの世界でコンテナー技術は昔からあった OSの各種リソース管理機能を活用してリソースを分離する dotCloud (現 Docker) 社が自社 PaaS 向けに作ったコンテナー の仕組みを OSS にしてブレイク アプリ開発者視点でうれしい機能、周辺ツールに力を入れている イメージ作成、配布の仕組み、差分イメージ形式など 標準化の勢いで Docker の影響力は 弱まりつつあるが広く普及している 8 OS カーネル コンテナー コンテナー ランタイム/ ライブラリー ランタイム/ ライブラリー アプリ アプリ 分離 コンテナーイメージ
9. コンテナーイメージ コンテナーは コンテナー“イメージ” を元に生成・実行される コンテナーイメージはベースイメージにライブラリやランタ イムを重ねて作る（レイヤー） 重ねるレイヤーは Dockerfile と呼ばれる定義ファイルに 記載してソースコードとして管理 Dockerfile にはイメージに含めるライブラリ、アプリ、環 境変数、実行コマンドなどを指定 Dockerfile をビルドすると新しいイメージが作成される このレイヤのすべてを開発する必要は ない Weｂ サーバー、ランタイム、アプリなどがインストール済 みの様々なイメージがベンダー各社から公開されている 「自分で開発したアプリ」の動作要件を満たすコンテナイ メージがあればすぐに動かすことが出来る 9 debian:stretch-slim Python:3.6.2-slim html2test, urllib3, sh wordcount.py build build build
10. Dockerfile サンプル FROM mcr.microsoft.com/dotnet/core/sdk:3.0 WORKDIR /src COPY . . RUN dotnet publish -c Release -o /app WORKDIR /app ENV ASPNETCORE_URLS http://+:80 EXPOSE 80 ENTRYPOINT ["dotnet", "docker-demo.dll"] 10 Dockerfile は単なるテキストファイル > ソースコードとセットでバージョン管理と共有が良い ＞ 開発者間や各種実行環境間での再現性の悩みが減る Dockerfile のイメージを紹介するために、ソースコー ドのビルドから実行までを単一コンテナにしているが、 これ自体は良い例ではないので注意 SDK 入りのイメージをベースに ソースをコンテナ内にコピー 実行環境を整えて 起動方法を指示しておく ソースをビルドしてアプリを生成
11. コンテナーイメージはレジストリで格納・管理 ビルドしたイメージをレジストリに Push することで別の環境へデプ ロイできるようになる デバッグ、テスト、本番など用途にあった環境へデプロイ コンテナのポータビリティ（移植性）を活用 11 開発環境 docker build docker push コンテナレジストリ docker pull docker run docker run docker run 標準化されたアプリケーション配信の仕組み
12. Public / Private Container Registry Docker Hub Docker 社が運営するコンテナを公開・共有するた めのサービス 各企業が提供する公式イメージなども多く公開され ている https://hub.docker.com Azure Container Registry コンテナイメージを共有するための Azure の 1 サー ビス（有償） アクセスコントロールによって非公開のレジストリとし て使用する https://myreg.azurecr.io 12 Basic Standard Premium エンタープライズ用途
13. 開発からデプロイまで 13 ubuntu:17.04 FROM ubuntu:17.04 RUN apt-get –y update RUN apt-get install nginx MyWeb:1.0 MyApp:1.0 FROM MyWeb:1.0 RUN git clone https://... RUN dotnet build … RUN dotnet run … From Push Dockerfile Dockerfile Private Registry オンプレミス Azure Virtual Machine Kubernates Service Service Fabric Web App for Container Container Instances Functions Laptop Mobile Servers Azure Stack IoT Edge Any Clouds From Push 宣言的な記述 再実行が容易 Deploy Anywhere 再現性が保証されたイメージを管理 Public Registry Build Build
14. コンテナアプリの保守 コンテナのバージョンアップは新しいコンテナ イメージを作り 直して「タグ」で区別して世代管理 運用中のコンテナの中を弄ったり、既存のイメージを修正するのではない（してはならない） バグ修正や新機能の追加など、アプリを修正したら、同じ Dockerfile を使ってビルド ランタイムやミドルウェア等のバージョンアップは Dockerfile の修正で表現してビルド 14 FROM ベースイメージ RUN 各種インストール COPY アプリコンテンツ ENTRYPOINT 起動処理 Dockerfile Source Source Source Source アプリとランタイム等の一貫性 MyApp:v1 MyApp:v2 Build ＆ Push Deploy (Pull) イメージが不変⇒整合性や再現性を担保 Registry SCM
15. アプリ開発者からみたメリット アプリの起動が速く、簡単で、再現性が高い 仮想マシンだと OS、ランタイム、ライブラリ、アプリのバージョンを一致させてインストール コンテナなら docker run の 1 行 インストールが混じらないので依存関係地獄から解放される マシンインスタンス上で複数種・複数バージョンのアプリやライブラリを分離できる 導入先のマシンの環境を壊さない（コンテナにすべて含まれている） 開発のスピードが速く、運用も楽になる 性能拡張をしたいときは同じイメージからコンテナを複製して負荷分散 短時間で元の環境に戻せるので回復性も高く 15
16. コンテナの利用例 : スケーラブル アプリケーション コンテナのポータビリティやステートレス特性は、スケーラブル なクラウド環境と相性が良い WebUI や API のエンドポイントとして、バックグラウンド ジョブやイベント駆動型処理として、 高集約性とオーケストレーションを求められるマイクロサービスとして、etc… 16 Public API endpoints Background processing Event-driven processing Microservices HTTP TRAFFIC REVISION 2 REVISION 1 80% 20% MICROSERVICE B MICROSERVICE C MICROSERVICE A データベース内のデータを 変換する連続実行バック グラウンドプロセスなど メッセージがキューに到着 したときにメッセージを処 理するキュー・リーダー・ア プリケーションなど Dapr と統合するオプショ ンを使用してマイクロサー ビスアーキテクチャをデプロ イおよび管理 Web Applications 頻繁なスケールアウト／スケールインを求められる HTTP(S) ベースの Web アプリや API の実行環境 として
17. コンテナの利用例 ： Dev Container アプリ開発に必要な Runtime だけでなく SDK や各種ツール群も 含めてコンテナ化して開発環境を綺麗に保つ Visual Studio Code をコンテナに接続することで、１端末で複数の開発環境の共存が容易に コンテナ自体は GitHub Codespaces 上で動かせば端末そのものはさらにクリーンに 17 Visual Studio Code Windows / MacOS /Linux 占有 Runtime SDK, Tool Source Code Source Code Runtime SDK, Tool Source Code Source Code Container Runtime Runtime SDK, Tool Source Code Source Code GitHub Codespaces
18. コンテナの利用例 ： Azure Cloud Shell Web ブラウザ上で実行できるコマンドラインインタフェース Azure や各種アプリの管理操作に必要な各種ツールの最新版が常にセットアップ済み 永続化したいファイルは Azure Files に保存することで、コンテナはステートレスに 18 ブラウザ ユーザー コンテナ Azure Files コンテナ イメージ From Ubuntu Bash, sh, tmux, dig, Azure CLI, AzCopy, vim, nano, git, make, maven, kubectl, sqlcmd, iPython client, .NET core, Go, Java, Node.js, Ansible, etc… アタッチ マウント Pull ホストマシン不要 ＝ 保守・運用コストが不要
19. コンテナー導入の主なメリットとチャレンジ メリット 起動時間が早くなる。 ⇒ パフォーマンス改善につながる ソフトウェアのライフサイクル管理が容易になる。⇒ アプリ運用が楽になる 可搬性と移植性が高く、開発の自由度が高まる。 ⇒ 移動が楽になる 個別に専有するリソースが少なくて済む。⇒ インフラコストが下がる チャレンジ コンテナー環境導入や新たな技術習得に伴う必要なリソースとコスト インフラ運用体制の見直し (アプリチームとインフラチームの役割分担の再考） 既存アプリケーションのリファクタリング (コンテナー環境変数への変換) 19
20. [補足]アプリ配布における仮想マシンの課題 事前セットアップ方式 あらかじめアプリ等をセットアップ済みの VM イ メージを作成（面倒） イメージサイズが大きく、デプロイに時間がかかる デプロイ後セットアップ方式 VM起動後に毎回セットアップが行われるので利 用開始までに時間がかかる セットアップ後のテストが難しい 20 ホストマシン 仮想マシン アプリ、ライブ ラリ、ランタイム、 etc… カスタム VM イメージ セットアップ デプロイ マスター VM イメージ ホストマシン 仮想マシン デプロイ アプリ、ライブ ラリ、ランタイム、 etc… セットアップ コンテナ技術によって緩和可能なアプローチ コンテナではあまりやらないアプローチ
21. [補足]構成管理における秘伝のタレ問題 差分ベースの構成管理によるシステム再現性の低下 構成管理が属人化・ブラックボックス化するほどリスクが高まる→保守の負担 スケール変更や移行性にも問題が起こりやすい デプロイ失敗時に巻き戻しが困難 21 初期 保守 保守 保守 保守 保守 OS MW App v1 V2 Update V3 update Ubuntu 20 Ubuntu 22 MW v1 MW v2 App v1 App v2 App :v1.0 App :v1.1 App :v1.2 App :v2.0 App :v2.1 App :v2.2 docker build
22. Azure のコンテナ サービス 22
23. Container ？ 23 シンプルな機能を 責務を分離してシンプルに 迅速にデプロイ 依存関係の分離 資源の有効活用 需要に応じた柔軟な
24. コンテナ技術だけでは解決できない課題 相互の独立性を維持しつつ、コストに直結しやすいスケールと 可用性を共有したい、が・・・ 24 アプリケーション共有クラスタ コンテナの 正常性 インスタンス の数と配置 データの 永続化 負荷分散と スケール 障害時の 再配置 リソース配分 コンテナ間の 通信
25. CaaS Container Platform Container as a Service PaaS Application Platform FaaS Serverless Platform IaaS Infrastructure Platform More Control of execution environment Less Agile development & deployment Less Control of execution environment More Agile development & deployment
26. コンテナー（標準デプロイ単位）と Azure CaaS 26 Azure App Service Azure Container Instances Azure Functions Azure Spring Apps Azure Red Hat OpenShift Azure Kubernetes Service Azure Container Apps Container Apps と他の Azure コンテナー オプションの比較 | Microsoft Docs Azure Batch
27. コンテナ オーケストレーター デファクトの Kubernates をマネージド サービスとして提供 AKS : Azure Kubernates Service 27 コンテナのノードへの 自動配置 コンテナの(再)スケジュール 障害ノード上のコンテナ復旧 手動スケール/オートスケール サービスを DNS 名で解決 自動的な負荷分散 シークレット文字列・設定管理 バッチ実行の管理 自動ローリングアップデート ロールバック Azure 等クラウドストレージ NFS/iSCSI/Gluster 等のマウント Kubernetes core concepts for AKS https://docs.microsoft.com/azure/aks/concepts-clusters-workloads コンテナアプリ
28. [余談] Microsoft のキーマン 28 Brendan Burns Kubernetesの生みの親 (Co-founder) 2016年にマイクロソフトへ加わる コンテナー関連サービスのみならず、 Azure Resource Manager、Azure Cloud ShellなどAzureの開発を広く リード Brendan Burns Distinguished Engineer, Microsoft
29. IaaS の自由度 ＋ PaaS の利便性 29 Infrastructure Host OS Container Runtime Infrastructure Host OS Container Runtime Infrastructure Host OS Container Runtime ストレージ サーバー ネットワーク OS ミドルウエア ハイパバイザ ランタイム アプリケーション データ ストレージ サーバー ネットワーク OS ハイパバイザ ランタイム アプリケーション データ ミドルウエア Container Platform IaaS PaaS ミドルウェア ランタイム アプリケーション データ Container Scalability, Reliability, Portability, etc… 依存関係地獄 からの解放 開発制約条件 からの解放
30. Backend as a Service と一緒に （不可能ではないが）コンテナにデータを保持すべきではない 永続性の必要な “データ” はコンテナ エコシステムを活かした CI/CD やクラウドとしてのス ケーラビリティと相性が悪い せっかくクラウドを使うならば PaaS 系のデータサービスに任せてしまった方が良い 30 Application Platform Virtual Machine Kubernates Service Service Fabric Web App for Container Container Instances Functions Data Services SQL DB MySQL PostgreSQL Storage Cosmos DB ステートレス ステートフル
31. Container DevOps を支えるサービス 31 Azure Container Registry Defender for Container Azure Monitor Azure DevOps GitHub Visual Studio (Code)
32. Production QA DevOps 32 ソースコード レポジトリ ビルド＆リリース 公式イメージ コンテナレジストリ IDE Local Git IDE Local Git git push docker push docker pull Redis cache Web App for Containers Azure Database CDN Application Insights バグ報告 ユーザー FB トレース・性 能・例外 バックログ docker buiｌｄ 再現
33. Demo ASP.NET on Web App for Container 33
34. DEMO : ASP.NET on Web App for Container 内容は下記を参照 コンテナアプリ開発と Azure サービスへのデプロイ（初学者向け） 34
35. Appendix コンテナ アプリ 開発のお作法 35
36. コンテナイメージの構築は Dockerfile で行う Dockerfile で明示的に定義した構成をもとにコンテナイメー ジを構築すべき Dockerfile は誰でも再構築と再現が可能となるように、明確な構成管理と自動構築を可能 にするテキストファイル 技術的にはコンテナ内で手動で変更したファイルや設定を docker commit コマンドでイ メージとして固めることも可能だが、構成管理が秘伝のタレになるため避けるべき 実行環境の構築が「パラメーターシートと設定手順書」で行われているアプリの場合は、スク リプトで自動化する方式変更が必要になる 36 設定手順書 構築 マニュアル 属人的な ノウハウ 一子相伝 Windows 界隈は GUI ベースの手順書で成立している ケースが多く、Dockerfile 化が困難な場合も多い FROM BaseImage:v1 RUN Install-Commands COPY . . ENV XXX=YYY EXPOSE ZZZ ENTRYPOINT [“run”] docker build 再現性、説明責任、 構築容易、共有可能、 変更管理、一貫性、 レビュー、etc… Dockerfile
37. コンテナ イメージはイミュータブル（不変）に リポジトリに Push したイメージは基本的に削除せず、実行環 境でそのまま利用し、修正を行わない コンテナイメージはタグでバージョン管理され、それを基盤として品質管理とリリース判定が 行われるため、「変更」すること自体が危険（再現性を失う） アプリや Dockerfile でバグが発見された場合も、修正後に新たなコンテナイメージとしてビ ルドし、品質評価と出荷判定を行う イメージの構築（Build）と同様にデプロイと実行（Run）も容易であるため、コンテナそのもの を大事に保守・運用して育てることなく使い捨てる 37 リポジトリ タグ 更新日 テスト Pass 出荷判定 本番展開 MyApp v1 2023-12-25 70% × - MyApp v2 2024-01-22 98% ◦ 済 MyApp v3 2024-02-24 85% × - YourApi v1 2023-11-13 100% ◦ 済 YourApi v2 2024-02-11 96% ◦ 未 build & push Deploy
38. タグの名前はルールを定めて明確に イメージにつける“タグ”はバージョン管理として重要な意味を持つ ため明確なルールを定めておく タグはそのコンテナに含まれるベースイメージ ＋ 追加パッケージ + アプリのバージョンなどの一貫性 を含んだバージョンを表す文字列 ある環境に配置されているバージョン、あるバグが発見されたバージョン、修正が行われたバージョン など、品質管理の観点からきわめて重要な情報 特に最新版を表し既定値でもある “latest” タグは使用しないこと（実質的にバージョン不明にな る） タグの命名規則として保守・運用で分かりやすいルールを定めると よい セマンティック バージョニング ： v1.0.0 > v1.1.0 > v1.2.0 > v1.2.1 日付ベースのバージョニング ： 2023-12-01 > 2024-01-12-preview > 2024-02-01 タグ自体の表現能力は弱いので、git のコミット ID や タグ、ビルドシステムのビルド ID などと関連 付けておくとよい 38
39. コンテナイメージはなるべく小さくしよう コンテナの生成・破棄が頻繁に行われるスケーラブルな環境 では小さいイメージが正義 この傾向はサーバーレス環境で特に顕著になり、大きなイメージは Pull ＞ Run に時間がか かるためコールドスタート問題を引き起こす コンテナサイズや実行時サイズに対する従量課金の場合は、大きいというだけで余分にお金 がかかる コンテナイメージを小さく保つテクニックは様々だが、代表的な ものを押さえておくと良い 小さなベースイメージを選択する レイヤー数を少なく維持する 実行時に必要最低限のモノをインストールする マルチステージビルドを使用する 39
40. ベースイメージから小さく Build して生成したコンテナイメージが FROM 命令で指定する ベースイメージのサイズを下回ることはない スタート地点となるベースイメージから小さなものを使用して肥大化を抑えるとよい ベースが小さい＝余分なものが少ない＝アタックサーフェスが狭く脆弱性が見つかるリスクも小さい アプリ実行に必要な依存関係やデバッグに必要になるツール類などを別途インストールする必要はあ るので、利便性とサイズのバランスを取ること 40 REPOSITORY TAG IMAGE ID CREATED SIZE mcr.microsoft.com/dotnet/aspnet 8.0 c39d0b5b530f 7 weeks ago 217MB redis latest 3ceffe93e5ee 7 weeks ago 138MB debian latest 52f537fe0336 2 weeks ago 117MB ubuntu latest 3db8720ecbf5 2 weeks ago 77.9MB alpine latest 05455a08881e 5 weeks ago 7.38MB gcr.io/distroless/static-debian12 latest 2d37d84052a6 N/A 1.99MB distroless は非常にサイズが小さいが、シェルやパッケージマネージャーすら含まれていない
41. イメージのレイヤーは少なく イメージを小さく維持するためには、なるべくレイヤーの数を少 なくすることが重要 差分ファイルシステムによってレイヤーは積みあがる一方なので、「ファイル削除」はコンテナ イメージ サイズを削減しない 過去のイメージにパッチを当てて新しいイメージを生成すると、レイヤーが歴史として積みあ がってしまうので、なるべくベンダー提供のオリジナル イメージから新規に作成すること 41 FROM Ubuntu Runtime App Ubuntu FROM Ubuntu Runtime App Upgrade Ubuntu Runtime App Upgrade FROM App Fix FROM Ubuntu Runtime App Ubuntu Ubuntu Upgraded Runtime App Ubuntu Upgraded Runtime Fixed App
42. マルチ ステージ ビルドを使おう アプリをビルドするための SDK やツール類は実行時には必 要ないので含めないこと マルチ ステージ ビルドというテクニックを使用することで、ビルドシステムにもコンテナのメリッ トを適用することが出来る 障害調査やデバッグに必要なツールは後からインストールしても持ち込むことが可能な場合 もあるので、「事前インストールすべきか」は考慮するとよい 42 FROM mcr.microsoft.com/dotnet/core/sdk:3.0 WORKDIR /src COPY . . RUN dotnet publish -c Release -o /app WORKDIR /app ENV ASPNETCORE_URLS http://+:80 EXPOSE 80 ENTRYPOINT ["dotnet", "docker-demo.dll"] FROM mcr.microsoft.com/dotnet/core/sdk:3.0 AS build WORKDIR /src COPY . . RUN dotnet publish -c Release -o /app FROM mcr.microsoft.com/dotnet/core/aspnet:3.0 WORKDIR /app COPY --from=build /app ./ ENV ASPNETCORE_URLS http://+:80 EXPOSE 80 ENTRYPOINT ["dotnet", "docker-demo.dll"] Dockerfile Dockerfile（マルチステージ） SDK ツール、ソースコード、コン パイル時の一時ファイルなどが コンテナイメージ内に残存 SDK ツール、ソースコード、コン パイル時の一時ファイルなどは ビルド用のコンテナに ランタイムとアプリコンテンツ のみのイメージを作成
43. Appendix オーケストレーターを意識した開発 43
44. オーケストレーターを意識した開発 運用環境ではコンテナは各種オーケストレーターの配下で稼 働することが多く、それを見越した開発をすると良い オーケストレーターとして代表的なものは Kubernetes だが、Azure の各種コンテナ系の サービスもオーケストレーターとしての役割を持つ コンテナのライフサイクルはオーケストレーターによって管理（＝起動・終了・監視など）が行わ れるので、そのお作法に則ることは運用効率の観点から理にかなっている 移植性も重要なので特定のオーケストレーターに過度に依存するべきではないが、ある程度 汎用的なお作法や Tips も存在するため以降で紹介する 非コンテナ環境向けに開発されたアプリはこれらのお作法に則っていないことも多く、コンテ ナ化の際には多少のリファクタリングは必要になる 44
45. １コンテナ：１プロセスの原則を守ろう １つのコンテナ内で複数のプロセスを起動すべきではない コンテナは Entrypoint や CMD で起動された最初のプロセス(PID=1)とライフサイクルが一致す る仕組みになっている オーケストレーターは基本的に PID１のプロセスが実行されているか否かで、コンテナが正常に実行 されている状態か否かを判断する またオーケストレーターがスケールインが必要と判断した場合は、PID1のプロセスに SIGTERM が 送信されコンテナを終了させようとする（＝それ以外は完治しない） マルチプロセス コンテナの場合は PID1のプロセスがサブプロセスのライフサイクルを管理する責務 を担うことになり、実装が複雑化してしまう 45 PID＝1 PID＝X PID＝Y コンテナ オーケストレーター 管理 大丈夫？
46. 適切な終了ステータスを返そう PID1 のプロセスは正常に（意図して）終了する場合はステー タス０（ゼロ）で終わるべき 終了ステータスなし、または１以上の値で終了した場合はオーケストレーターは異常終了と判 断するため、設定によっては再起動を試みる Web サーバーのような常駐型のプロセスは「終了しない」のが正常な動作だが、１回限りの ジョブなどで（正常に処理が完了したのに）意図せず再起動が行われると問題 終了ステータス（あるいはリターンコード）の指定方法はフレームワークやプログラミング言語 による、各々のリファレンスを参照のこと 46 static int Main(string[] args) { try { //処理を実行 return 0; } catch (Exceptin ex) { return 1; } } ExitStatus 再起動 する？
47. 標準出力／標準エラー出力にログを出そう アプリケーションのログは標準出力（stdout）や標準エラー 出力（stderr）に出すと良い 多くのオーケストレーターは stdout/stderr に出力されたテキストを収集しログとして保持 する機能を持ち、トラブルシュート時に有用 ログといえばログ“ファイル”に出力しがちだが、コンテナは本質的にステートレスであるため、 従来通りファイルに保存しても消えてしまう可能性がある コンテナ独自にログを収集する外部の監視サービスを使用する場合でも、同時に stdout/stderr にログ出力することで、さまざまなオーケストレーターに対応しやすい 47 void run() { // 出力先はフレームワークのログシステムに任せるとよい logger.LogInformation("処理が開始しました"); … … logger.LogInformation(“処理が終了しました"); } … 10：12：30 処理が開始しました … … 11:27:43 処理が終了しました stdout Log
48. 正常性プローブに対応しよう オーケストレーターは正常性プローブを使用してコンテナアプリが 「正常な状態か」をより詳しく判定することが出来る 前述の通りプロセスの生死判定だけでは、アプリとしての正常性を的確に判断することは出来ないこ とが多く、オーケストレーターに追加の情報を与えてやる必要がある オーケストレーターによって正常性の判定方法は様々だが、以下は Kubernetes および（その亜種） で利用可能な判定方法 Liveness Prove : アプリが正常に動作可能な状態か否か（フリーズやデッドロックしていないかなど） Readiness Prove : アプリがイングレスなどの負荷分散から処理を受け付けられる状態か否か Startup Prove : 開始処理が終了して Liveness/Readiness Prove を受け付けられるか否か 48 PID＝1 起動終わった？ 終了コード 開始 元気？ 生きてる？ 仕事振っていい？ 各プローブは HTTP/TCP/コマ ンドを定期的に実行する
49. 新しいコンテナを増やして5つにするよ １つ足りない！ ５つが正常 コンテナアプリはステートレスに実装しよう コンテナ内で動作するアプリは、コンテナ内にデータを保持せずに 外部に永続化すること オーケストレーターは障害時のリトライの際には常にイメージからコンテナを新規起動するため、コンテ ナ内に永続化したデータは引き継がれない ファイル出力する必要がある場合はオーケストレーターからマウントされた永続化ボリュームを使用す ること クラウドの場合は外部のデータベースサービス（PaaS）を利用する方が可用性の観点からも有利 49 ボリューム マウント DBアクセス File
50. Graceful Shutdown に対応しよう オーケストレーターからの終了指示を受けて、安全にプロセス を終了するように実装する オーケストレーターはスケールイン、再配置、メンテナンスなどが必要と判断した場合、コンテ ナに対して SIGERM + SIGKILL を送信してコンテナを終了する 実行中のアプリからすれば外部から勝手に強制終了させられることになるため、仕掛かり中 の処理や永続化していないデータがあると問題になる 終了指示を適切にハンドリングすることで安全に終了（Graceful Shutdown）できるように 備えておくべき 50 Σ(ﾟДﾟ) !! オーケストレーター SIGTERM SIGKILL さよなら～
51. 設定ファイル DB＝LOCAL 環境依存設定は環境変数から取得する コンテナはデプロイ先の環境に設定された環境変数から各種設定 を読み込むことで適応的に動作すると良い 開発・テスト・本番の各環境において、外部 API のエンドポイント URL 、データベースの接続文字 列、ログ出力の詳細度などが代表的な環境依存の設定値 従来は配置時に「設定ファイル」を入れ替えることで対応していたケースも多いが、コンテナ環境では この設定ファイルもコンテナイメージに固められてしまい修正が容易ではない（すべきでもない） 多くのオーケストレーターは各コンテナに対して環境変数を差し込む機能を持っているため、環境変数 から読み込んだ設定値を最優先するようにアプリを開発する 51 Source 設定 ファイル Source build コンテナイメージ Deploy Deploy ENV DB＝Test ENV DB＝Prod 開発環境
52. 必要な CPU とメモリを宣言しよう 各コンテナが必要とする最低・最大のリソース量を指定することで、 配置先を適切に判定することが出来る 何も設定しない場合は各コンテナが必要として CPU とメモリを割り当ててしまうため、以下のような 問題が起こりうる リソースを大量消費するコンテナと同じノードで動作するコンテナが性能的な影響を受ける（ノイジーネイバー） コンテナが動作するために最低限必要なメモリが確保できないノードにデプロイされてしまい、起動に失敗する CPU やメモリに対して Request/Limit を指定することでオーケストレーターがコンテナのスケジュー ルを管理できるようになる 52 4core/12GB 欲しい 2core/4GB 欲しい 1core/2GB 欲しい 8core/32GB 8core/32GB 8core/32GB OK NG OK NG
53. Microsoft Confidential ◼ 本資料は情報提供のみを目的としており、本資料に記載されている情報は、本資料作成時点でのマイクロソフトの見解を示したものです。状況等の変化により、内容は変更される場合があります。本資料 に特別条件等が提示されている場合、かかる条件等は、貴社との有効な契約を通じて決定されます。それまでは、正式に確定するものではありません。従って、本資料の記載内容とは異なる場合がありま す。また、本資料に記載されている価格はいずれも、別段の表記がない限り、参考価格となります。貴社の最終的な購入価格は、貴社のリセラー様により決定されます。マイクロソフトは、本資料の情報に対 して明示的、黙示的または法的な、いかなる保証も行いません。 © 2018 Microsoft Corporation. All rights reserved. Microsoft, Windows, その他本文中に登場した各製品名は、Microsoft Corporation の米国およびその他の国における登録商標または商標です。 その他、記載されている会社名および製品名は、一般に各社の商標です。