WEB問題集
計画しているレジストリの要件は次のとおりです。
| 要件 | 内容 |
|---|---|
| 配置 | 3 リージョンへイメージを複製する |
| アクセス | vnet1 からのみ到達を許可する |
| 運用 | 既存のビルド パイプラインは変更しない |
解説
【正解: C】の理由
geo レプリケーションとプライベート リンク (プライベート エンドポイント) は、どちらも Premium レベルでのみ提供される機能です。Premium ではレジストリの内容を複数のリージョンへ複製でき、各リージョンのワークロードは同一のログイン サーバー名のまま最も近いレプリカからイメージを取得するため、プル待機時間とリージョン間のデータ転送を抑えられます。さらに Premium では、プライベート エンドポイントによる閉域アクセス、リポジトリ スコープのアクセス許可、より大きな既定ストレージとスループットが利用できます。要件の 2 つがいずれも Premium 専用の機能であるため、他のレベルでは構成そのものが行えません。
【他選択肢が違う理由】
- A: Basic はコストを抑えた入門向けのレベルで、geo レプリケーションもプライベート エンドポイントも利用できません。
- B: Standard は Basic よりストレージとスループットが大きいだけで、geo レプリケーションの機能自体を持ちません。
- D: geo レプリケーションは後から追加するアドオンではなく Premium レベルの機能のため、Standard のままでは有効化できません。
【参考】
解説
【正解: A / B】の理由
マネージド ID を使用すると、Microsoft Entra ID が発行するトークンでレジストリに認証されるため、パスワードやサービス プリンシパルの資格情報をクラスター側に保存する必要がなくなります。構成は 2 段階で、まずクラスターに ID を割り当てて呼び出し元の識別子を用意し、次にその ID へ ACR1 のスコープで AcrPull ロールを割り当てて、イメージの取得だけを許可します。AcrPull は読み取り専用のため、最小権限の原則にも合致します。資格情報のローテーションや失効の管理が不要になる点も、シークレットを用いる方式に対する利点です。
【他選択肢が違う理由】
- C: 管理者ユーザーはレジストリ全体に対する共有資格情報であり、シークレットの保存とローテーションが必要になるため要件に反します。
- D: 匿名プルは認証なしで誰でもイメージを取得できる構成であり、内部の推論イメージの保護という観点で不適切です。
- E: サービス プリンシパルのパスワードをマニフェストに埋め込むことは、資格情報を保存しないという要件に直接違反します。
【参考】
az acr build --registry ACR1 --image inference-api:v1 --file Dockerfile .解説
【正解: D】の理由
az acr build はクイック タスクを実行するコマンドで、指定したビルド コンテキストをレジストリ側へ送り、Azure Container Registry Tasks のクラウド上のビルド環境でイメージをビルドします。ローカルに Docker Engine は必要ありません。ビルドが成功すると、生成されたイメージは既定でそのまま対象のレジストリへプッシュされるため、ビルドと格納を 1 コマンドで完了できます。実行内容はコミットやスケジュールに紐づかない一度きりの処理で、ログはストリーミングで確認できます。この特性により、開発時の反復や、ビルド環境を用意できない CI からの利用に適しています。
【他選択肢が違う理由】
- A: ビルドはローカルではなくレジストリ側のクラウド環境で実行されるため、ローカルの Docker Engine は使用しません。
- B: タグの付け替えだけを行うコマンドではなく、ソースからイメージを実際にビルドする処理を伴います。
- C: トリガーの登録は az acr task create で行う自動タスクの構成であり、クイック タスクとは目的が異なります。
【参考】
解説
【正解: B】の理由
ロールバックできるかどうかは、過去のバージョンを一意に指し示せるかどうかで決まります。ビルド ID やコミット ハッシュのような一意で不変のタグを付けておけば、各デプロイがどのイメージを使用したかが記録として残り、問題が起きたときは直前のタグを指定して戻すだけで復旧できます。一方、可変タグを上書きする運用では、同じタグが時点によって別の内容を指すため、戻したい実体そのものが失われるか特定できなくなります。運用環境では可変タグを参照せず、デプロイのたびに一意タグを明示する方法が推奨されます。
【他選択肢が違う理由】
- A: latest は上書きされる可変タグで、過去のビルドを指し示せなくなるためロールバックの基準になりません。
- C: stable も内容が入れ替わる可変タグであり、以前のイメージが特定できず戻す対象を指定できません。
- D: タグを付けない運用ではマニフェストが未タグ付けとなり、対象の特定もリテンションからの保護も難しくなります。
【参考】
version: v1.1.0
steps:
- build: -t $Registry/inference-api:$ID .
- cmd: $Registry/inference-api:$ID python -m pytest
- push: ["$Registry/inference-api:$ID"]- push ステップでイメージを発行する
- Git のコンテキストからソースを取得する
- cmd ステップでテストを実行する
- build ステップでイメージをビルドする
解説
【正しい順序】
- Git のコンテキストからソースを取得する
- build ステップでイメージをビルドする
- cmd ステップでテストを実行する
- push ステップでイメージを発行する
【ポイント】
マルチステップ タスクは YAML に記述した steps を上から順に実行し、あるステップが失敗した時点で以降の処理を中止します。最初にビルド コンテキストが取得され、build ステップでイメージが作成されます。作成されたイメージはタスクの実行環境に存在するため、続く cmd ステップではそのイメージをコンテナーとして起動し、テストを実行して品質を検証できます。push は最後に置かれ、直前までのステップがすべて成功した場合にのみ実行されます。この順序にすることで、テストを通過していないイメージがレジストリに発行されることを防げます。ビルドからテスト、発行までを 1 つのタスクにまとめられるため、外部のビルド サーバーを用意せずにパイプラインを構成できます。