第 9 章 Azure のコンピューティングリソースをデプロイおよび管理する（20〜25%）
コンテナー
この章で学ぶこと
- Azure Container Registry の作成と管理
- Azure Container Instances を使用してコンテナーをプロビジョニングする
- Azure Container Apps を使用してコンテナーをプロビジョニングする
- Azure Container Instances や Azure Container Apps など、コンテナーのサイズ設定とスケーリングを管理する
この章に出てくる用語
- コンテナー
- アプリと、その動作に必要なライブラリや設定をひとまとめにした実行単位。 OS まるごとを持つ仮想マシンより軽く、起動も速い。ひな形を「イメージ」と呼び、それを動かしたものが「コンテナー」。Azure では、イメージを置く場所（ACR）と、動かす場所（ACI / Container Apps / AKS）が別のサービスに分かれている。
- Azure Container Registry（ACR）
- 自分たちのコンテナーイメージを保管する private なレジストリ。 Docker Hub のような公開レジストリと違い、自組織だけがアクセスでき、Entra ID の認証と RBAC で制御できる。
コンテナーイメージを置くプライベートレジストリ。SKU は Basic / Standard / Premium の 3 つで、違いは含まれるストレージ量と機能だ。
試験では
geo レプリケーション、プライベートエンドポイント、コンテンツ信頼はすべて Premium 限定。 この 3 つのどれかが要件に出てきたら Premium を選ぶ。Basic と Standard の違いはストレージ量と転送量だけだと思っておけばよい。
geo レプリケーションは、1 つのレジストリを複数リージョンに複製し、同じログインサーバー名のまま最寄りのリージョンから取得できるようにする機能だ。複数リージョンに展開したアプリのイメージ取得を速くできる。
補足
ACR タスクは、ソースコードのコミットやベースイメージの更新をきっかけに、クラウド側でイメージをビルドする機能。手元に Docker を用意しなくてよい。
# レジストリを作る （PowerShell: New-AzContainerRegistry）
az acr create -g rg -n myacr --sku Premium
# クラウド側でイメージをビルドする
az acr build --registry myacr \
--image app:v1 .
# geo レプリケーションを追加する （Premium のみ）
az acr replication create --registry myacr \
--location westusコンテナーを動かす場所は 3 つある。問題文のどこを見て選ぶかを決めておく。
| サービス | こう書かれていたら選ぶ |
|---|---|
| Azure Container Instances（ACI） | 1 つのコンテナーを最速・最小構成で／短時間のバッチ処理／秒単位の課金 |
| Azure Container Apps（ACA） | サーバーレスで自動スケール／ゼロまで縮めたい／リビジョンでトラフィックを分割したい |
| Azure Kubernetes Service（AKS） | 本格的なオーケストレーション（AZ-104 の中心ではない） |
コンテナーグループ
ACI では、同じホスト・ネットワーク・ストレージを共有する複数のコンテナーをコンテナーグループとしてまとめられる。
試験では
Linux では複数コンテナーを 1 つのグループに入れられるが、Windows では 1 コンテナーだけ。「サイドカーを並べたい」といった要件は Windows では成立しない。
再起動ポリシー
コンテナーが終了したときの挙動を決める。既定は Always だ。
試験では
バッチ処理なら OnFailure か Never を指定する。既定の Always のままだと、処理が正常に終わっても再起動され続け、課金も止まらない。「一度だけ実行したいのに繰り返し動いてしまう」という設問の答えがこれ。
# コンテナーを単発で動かす （PowerShell: New-AzContainerGroup）
az container create -g rg -n job1 \
--image myacr.azurecr.io/batch:v1 \
--restart-policy OnFailure
# ログを見る
az container logs -g rg -n job1サーバーレスでコンテナーを動かすサービス。HTTP トラフィックやイベントに応じて自動スケールし、ゼロインスタンスまで縮められるのが特徴だ。使われていない時間の課金を抑えられる。
リビジョンとトラフィック分割
リビジョンはアプリの不変のバージョンで、複数を同時に動かせる。受信トラフィックを割合で振り分けられるので、段階的な切り替えができる。
試験では
「新しいバージョンにまず 20% だけ流して様子を見たい」→ リビジョンのトラフィック分割。App Service のデプロイスロット（第 10 章）と役割が似ているので、どちらのサービスの話かを問題文で確認する。
補足
自動スケールを担当しているのは KEDA というイベント駆動のスケーラーだ。CPU やメモリだけでなく、キューの長さなどのイベントでもスケールできる。「キューに溜まった分だけ増やしたい」という要件に対応できる。
複数の Container Apps は Container Apps 環境という境界にまとめられる。同じ環境のアプリは同じ仮想ネットワークと Log Analytics ワークスペースを共有する。
この章のまとめ
- ACR で geo レプリケーションが使える SKU
- ACR でプライベートエンドポイントが使える SKU
- geo レプリケーションしてもログインサーバー名は変わるか
- コミットをきっかけにクラウドでイメージをビルドする機能
- 1 つのコンテナーを最速・最小構成で動かすサービス
- ゼロインスタンスまで縮められるサービス