Microsoft AZ-204: Azure コンテナーソリューション — 学習ガイド

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

こちらの一部です： Microsoft Azure Developer Associate AZ-204 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Azureは、単一コンテナの実行、オーケストレーションされたクラスター、そしてセキュアなエンタープライズグレードのイメージサプライチェーンにわたる、幅広いコンテナオプションを提供します。Azure Container Instances (ACI) は、サーバーを管理することなくLinuxまたはWindowsコンテナを実行するための最も迅速な方法です。Azure Kubernetes Service (AKS) は、高度なスケジューリング、ネットワーキング、セキュリティ、DevOps統合を備えたマイクロサービスをスケーリングする、マネージドKubernetesコントロールプレーンです。Azure Container Registry (ACR) は、ビルド、タグ付け、プッシュ/プル、Helm配布フローの基盤となる、プライベートで地理的に複製されたレジストリです。Dockerイメージの構築とライフサイクル管理を習得することは、これらのいずれのプラットフォームにおいても信頼性の高いデプロイを行うための基礎となります。このセクションでは、YAMLによるデプロイ、Helmパッケージング、サービスの公開、アイデンティティ/セキュリティパターンなど、各要素がどのように連携するかについて、実践的で開発者中心の視点から解説します。

DockerとAzure Container Registry (ACR)

信頼性の高いコンテナデリバリーは、堅実なDockerの基礎から始まります。各イメージはDockerfileの命令によって形成されるレイヤーで構成されており、レイヤーの再利用とキャッシュヒットは、ビルドの高速化に不可欠です。

• 一般的なDockerfileの命令とガイダンス:
  • FROMはベースイメージを定義します。攻撃対象領域とサイズを削減するために、最小限のイメージ（例：distroless、適切な場合はalpine）を推奨します。
  • RUNは依存関係をインストールするコマンドを実行します。関連するコマンドを組み合わせてレイヤー数を減らしますが、障害を隠蔽するようなモノリシックなRUN行は避けてください。
  • COPYとADDはアプリケーションのアーティファクトを配置します。.dockerignoreを使用してコンテキストの肥大化を避け、COPYは明示的なパスに固定します。
  • WORKDIRは作業ディレクトリを設定します。RUNでcdを連鎖させる代わりにこれを使用します。
  • EXPOSEは意図したリスニングポートを文書化します（ファイアウォールではありません）。
  • ENVとARGは環境変数とビルド時変数を設定します。ARGのデフォルト値を固定するか、明示的な値を渡すことで、ビルド時の決定性を高めます。
  • ENTRYPOINTはメインの実行可能ファイルを定義します。CMDはデフォルトの引数に使用します。シグナルハンドリングを維持して正常なシャットダウンを行うために、exec形式（JSON配列）を推奨します。
  • HEALTHCHECKはオーケストレーターが対応できるように、活性評価を有効にします。
• マルチステージビルドは、ビルドステージとランタイムステージを分離し、必要なアーティファクトのみをクリーンなランタイムイメージにコピーすることで、サイズとCVEフットプリントを大幅に削減します。例えば、SDKでビルドし、バイナリをパブリッシュした後、ランタイムベースにコピーします。
• イメージレイヤーはイミュータブル（不変）で、コンテンツアドレス指定です。命令の順序を変更すると、キャッシュの動作が変わります。頻繁に変更される命令（例：COPYソース）はDockerfileの後半に配置して、キャッシュヒットを最大化します。

ACRを使用して、イメージとHelmチャートをプライベートに保存および配布します:

• リポジトリとタグ付け: <registry>.azurecr.io/<repo>:<tag>としてイメージをプッシュします。セマンティックまたはGitベースのタグ（例：1.4.0、ビルドSHA）を推奨し、本番環境のデプロイでは再現性のために不変のダイジェストを使用します。
• プッシュとプル:
  • az acr login -n <acr-name>またはAzure ADトークンを使用したdocker loginでACRに認証します。本番環境でACRの管理者ユーザーを有効にすることは避けてください。
  • タグ付けとプッシュ: docker tag app:1.0 <acr>.azurecr.io/apps/app:1.0; docker push <acr>.azurecr.io/apps/app:1.0。docker pullまたはKubernetesのイメージ参照を介してプルします。
  • 上流のイメージをACRにインポートしてサプライチェーンを制御します: az acr import -n <acr> --source docker.io/library/nginx:1.25 --image base/nginx:1.25。
• ACR Tasks: Azureネイティブでイメージのビルド、テスト、パッチ適用を行います。オンデマンドビルドにはaz acr build -r <acr> -t apps/app:1.0 .を使用します。az acr task createで更新を自動化し、Gitコミットやベースイメージの更新をトリガーにして、アプリコードを変更せずにCVEの修正を可能にします。
• 地理的レプリケーション（Premium SKU）は、複数リージョンでのプルにおける局所性と回復性を提供します。AKSクラスターに近いリージョンにレプリカを構成し、プルレイテンシとリージョン間のエグレスを削減します。
• アクセス制御:
  • Azure ADと統合し、AcrPullのような組み込みロールをAKSのkubeletアイデンティティに、AcrPushをCIパイプラインに割り当てます。リポジトリスコープの権限は、トークンとスコープマップを介して利用可能で、きめ細かい制御が可能です。
  • プライベートエンドポイント、サービスエンドポイント、ファイアウォールルールでネットワークアクセスを制限します。本番環境ではプライベートエンドポイントを推奨します。
  • az aks update --attach-acr <acr>でACRをAKSにアタッチし、AcrPullロールの割り当てを簡素化します。

Azure Container Instances (ACI)

ACIは、クラスター管理なしでオンデマンドでコンテナを実行します。主要な単位はコンテナグループで、これは同じホストOSカーネル、ライフサイクル、IP、ボリュームを共有する、共同でスケジュールされたコンテナのセットです。コンテナグループを使用して、サイドカーパターン（例：ログシッパー、プロキシ）を実装したり、メインプロセスとヘルパーを組み合わせたりします。

• マルチコンテナグループはネットワーク名前空間を共有し、localhost経由でのコンテナ間通信を可能にします。また、マウントされたボリューム（Azure Files, emptyDir）とライフサイクルも共有するため、密接な結合を必要とする、まとまりのある一度きりのタスクに適しています。
• 再起動ポリシーは実行セマンティクスを制御します:
  • Alwaysは、コンテナが終了すると常に再起動します。長時間実行されるサービスに最適です。
  • OnFailureは、ゼロ以外の終了コードの場合にのみ再起動します。失敗時に再試行すべきバッチタスクに適しています。
  • Neverは、コンテナを一度実行し、再起動しません。冪等なジョブに最適です。
• ネットワーク統合には、DNSラベル付きのパブリックIP、委任されたAzure VNetサブネット内のプライベートIP、NATまたはファイアウォール経由のセキュアなエグレスが含まれます。VNetにインジェクトされたACIは、パブリックに公開することなく、サービス（データベース、ストレージ）へのプライベートアクセスを可能にします。
• 運用上の考慮事項:
  • セキュアな環境変数を使用するか、Azure Filesをマウントしてシークレットを注入します。より強力なセキュリティ体制のためには、マネージドアイデンティティを介して実行時にKey Vaultからシークレットを取得します。
  • az container logsとaz container attachで監視し、az container execでインタラクティブなコマンドを実行します。
  • 課金はvCPUとGiBメモリに対して秒単位です。コンテナは迅速に起動し、Kubernetesのオーバーヘッドが不要な、バースト的なワークロード、CIヘルパータスク、統合テスト、キューによってトリガーされるジョブに適しています。

Azure Kubernetes Service (AKS)

AKSは、ノードプール、自動スケーリング、そして詳細なネットワーク/IDオプションを備えたマネージドコントロールプレーンを提供します。

ノードプールは、キャパシティとワークロードの配置を構成します。システムノードプールはコアサービスを実行し、ユーザーノードプールはアプリケーションPodを実行します。複数のプールを使用して、CPU/メモリ/GPUの要件、OS (Linux/Windows)、VMサイズ、アベイラビリティゾーンによってワークロードを分離します。taint/tolerationを使用してシステムプールを保護し、ラベルで選択を行い、クラスターオートスケーラーで保留中のPodに基づいてノードを追加/削除します。サイジングの際には、ノードごとのmaxPodsとPod密度を考慮してください。

Podのスケジューリングは、リソース要求/制限、QoSクラス (Guaranteed/Burstable/BestEffort)、および制約によって駆動されます。nodeSelector/affinityとanti-affinityを使用してPodを適切なプールに配置し、レプリカをゾーンや障害ドメインに分散させます。Topology spread constraintsは、均等な分散を改善します。重要なサービスには、PodDisruptionBudgetsとPriorityClassesを定義して、自発的な中断やプリエンプションの振る舞いを制御します。DaemonSetsはノードごとのエージェント（ロギング、モニタリング）を配置し、CronJobsは定期的なタスクのためにコンテナをスケジュールします。

AKSでのデプロイは宣言的です。YAMLマニフェストは、Deployments、StatefulSets、Jobs、Services、IngressのapiVersion、kind、metadata、specを定義します。マニフェストはソース管理に保管し、環境差分はKustomizeオーバーレイでパラメータ化し、kubectl apply -fで適用します。サーバーサイドApplyと適切なラベル/アノテーションは、所有権の管理とドリフト検出に役立ちます。再利用可能なアプリをパッケージ化するには、Helm 3がテンプレートと値をバンドルします。HelmチャートをACRにOCIアーティファクトとしてホストし、helm upgrade –install <release> oci://<acr>.azurecr.io/helm/<chart> -f values.yamlでインストールします。環境ごとにvaluesファイルを使用し、チャートのバージョンを追跡し、迅速な復旧のためにhelm rollbackでロールバックします。

日常的に使用するkubectlコマンド：

• クラスターコンテキストへのアクセス：az aks get-credentials -g <rg> -n <cluster>はkubeconfigをマージします。Azure ADに参加したマシンでkubectlを使用すれば十分で、マニフェストをデプロイするためにDockerは不要です。
• 調査と操作：kubectl get nodes,pods,deploy,svc -A; kubectl describe pod <name>; kubectl logs -f <pod>; kubectl exec -it <pod> – sh; kubectl rollout status deploy/<name>; kubectl set image deploy/<name> container=<image>:<tag>; kubectl top pods; メンテナンスのためのノードのcordon/drain; kubectl auth can-iによるRBACの検証。
• 適用/パッチ：kubectl apply -f k8s/; kubectl patch deploy <name> –type merge -p ‘{…}’。

AKSのネットワークは、明確な責務を持ってPodとServiceを公開します：

• ClusterIPは、サービスディスカバリのために内部専用のクラスター有効範囲の仮想IPとDNSを提供します。これはマイクロサービス間の東西トラフィック（east-west traffic）のデフォルトです。
• NodePortは各ノードで同じポートを開きます。直接利用するよりも、Ingressや外部LBの背後で使用するのが最適です。
• LoadBalancerは、NodePortをターゲットとするAzure Load Balancerのフロントエンドをプロビジョニングします。service.beta.kubernetes.io/azure-load-balancer-internal: “true"というアノテーションを付けてサービスを内部向けとしてマークするか、安定したDNSのために静的パブリックIPを割り当てます。
• Ingressコントローラーは、L7ルーティング、TLS終端、パス/ホストベースのルールを提供します。NGINX Ingress Controllerは、豊富なアノテーションを持つ汎用的なデフォルトです。Application Gateway Ingress Controller (AGIC)は、Azure Application Gatewayと統合し、WAF、自動スケーリング、エンタープライズレベルのL7機能を提供しつつ、Kubernetesネイティブなマニフェストを維持します。cert-managerを使用してACMEでTLSを自動化するか、CSI Secret StoreでKey Vaultの証明書をKubernetesのSecretに同期します。

IDと認可は、クラスター内のシークレットなしでAzure ADを統合します：

• AKSのマネージドIDは、クラスター/コントロールプレーンIDとkubelet IDで構成されます。ノードが安全にイメージをプルできるように、kubeletにACRに対するAcrPullを付与します（az aks update –attach-acr <acr>）。
• ワークロードIDは、KubernetesのサービスアカウントにマッピングされたフェデレーションAzure AD資格情報を使用して、PodがAzureリソースにアクセスできるようにします。ノードレベルの資格情報やサイドカーは不要です。クラスターでOIDC発行者を有効にし、ユーザー割り当てマネージドIDを作成し、サービスアカウント/名前空間に対してFederatedIdentityCredentialを構成し、アプリでAzure Identity SDKを使用します。これは古いAAD Pod Identityモデルに代わるもので、オープンスタンダードに準拠しています。
• RBACはKubernetes APIの権限を管理します。AKSがAzure ADと統合されている場合、RoleBindings/ClusterRoleBindingsを介してKubernetesのRoles/ClusterRolesをAzure ADのユーザーやグループにバインドします。あるいは、Azure RBAC for Kubernetes Authorizationを有効にして、Azure Kubernetes Service RBAC Reader、Writer、AdminなどのAzure RBACロールでアクセスを管理します。最小権限の原則に従い、チームやワークロードごとに名前空間を分離し、グループベースのバインディングを介して本番環境へのアクセスを制御します。

AKSへのエンドツーエンドのイメージフローは、シンプルかつ安全です。マルチステージイメージをビルドし、不変のバージョンでタグ付けし、ACRにプッシュし、マニフェストやHelmでAKSにデプロイします。AKSはkubeletマネージドIDを使用してACRからプルし、PodはワークロードIDを介してAzureリソースを利用します。サービスはClusterIP/LoadBalancerを介して公開され、TLSとルーティングを一元化するIngressコントローラーで洗練されます。

実践的な問題シナリオ

AdobeのCreative Cloudチームは、モノリシックなメディア処理サービスをマイクロサービスに分解し、低レイテンシーでのグローバル配信と強化されたサプライチェーンを目指しています。

1. CIでマルチステージDockerfileを使用してイメージをビルド・保存する

• Dockerのマルチステージビルドを使用してメディアコーデックをコンパイルし、ランタイムバイナリのみをスリムなベースイメージにコピーすることで、サイズとCVEを最小限に抑えます。イメージは<acr>.azurecr.io/processing/encoder:<git-sha>としてACRにプッシュします。これにより、デプロイの固定に使用する不変のダイジェストを持つ、再現可能で安全なアーティファクトが保証されます。

2. レジストリを強化し、パッチ適用を自動化する

• AKSをホストする各仮想ネットワークにプライベートエンドポイントを持つACR Premiumレジストリを作成します。North EuropeとEast USへのgeoレプリケーションを有効にして、イメージのプルをローカルに保ちます。ACR Tasksを構成して、上流のベースイメージの更新時に再ビルドをトリガーし、パッチが適用されたレイヤーを自動的に伝播させます。これにより、パフォーマンスとセキュリティのバランスを取り、エグレスを削減します。

3. 分離されたノードプールとIDを持つAKSを構築する

• Azure CNIとシステム/ユーザーノードプールを持つAKSをデプロイします。コントロールプレーンアドオン用の小さなシステムプール、トランスコーディング用のGPU対応ユーザープール、API用の汎用プールを設けます。Azure AD統合、OIDC発行者、ワークロードIDを有効にします。az aks update –attach-acrを介してkubelet IDにAcrPullを割り当てます。これにより、ワークロードが分離され、効率的にスケーリングし、シークレットベースのイメージプルが不要になります。

4. 宣言的なデプロイとパッケージングを定義する

• Deployments、永続性が必要な場合はStatefulSets、Services、HorizontalPodAutoscaler、PodDisruptionBudgetsのKubernetes YAMLを作成します。エンコーダーサービスとAPIゲートウェイをHelmチャートとしてパッケージ化し、ACRにOCIアーティファクトとして公開し、環境固有のvaluesを使用してhelm upgrade –installでデプロイします。これにより、一貫性のあるバージョン管理されたリリースと簡単なロールバックが可能になります。

5. サービスを公開し、L7セキュリティを適用する

• 内部マイクロサービスにはClusterIPを使用し、公開APIにはApplication Gateway Ingress Controllerを備えたLoadBalancerサービスを使用します。Application GatewayでWAFポリシーを適用してTLSを終端し、ACMEチャレンジのためにAzure DNSと統合されたcert-managerを使用して証明書を管理し、ホスト/パスによってバックエンドにルーティングします。これにより、Kubernetesネイティブな構成でエンタープライズグレードのL7セキュリティが実現します。

6. Azureリソースへの安全なワークロードアクセスを実装する

• Blob Storageに書き込み、シークレットを読み取るサムネイル作成サービスのために、ユーザー割り当てマネージドIDを作成し、ワークロードIDを介してサービスアカウントとフェデレーションさせ、Storage Blob Data ContributorとKey Vault Secrets Userロールを付与します。PodはAzure ADで認証するため、シークレットのマウントが不要になり、きめ細かく監査可能なアクセスが可能になります。

7. ACIでバッチ処理のオーバーフローを処理する

• 散発的で優先度の高いバッチ処理のオーバーフローに対しては、VNetにインジェクトされたサブネット内でrestartPolicy: Neverを設定したACIのマルチコンテナグループ（エンコーダー + サイドカーのメトリクスコレクター）をトリガーします。これにより、AKSをピークまでスケールさせることなくスパイクを吸収し、ストレージアカウントへのプライベートなデータパスを維持します。

これらの各選択肢は、Adobeの目標を直接サポートします。geoレプリケーションとプライベートエンドポイントを備えたACR Premiumは、イメージのプルを安全かつ高速化します。専門のノードプールとワークロードIDを持つAKSは、分離と最小権限アクセスを強制します。Helmと宣言的YAMLは、デプロイとロールバックを標準化します。WAFを備えたAGICは、回復力のある安全なL7イングレスを提供します。そしてACIは、永続的なクラスターコストなしでバースト的なバッチ処理を処理します。

← Azure Cosmos DB · すべてのドメイン · Azure の認証、承認、およびセキュリティ →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Microsoftを閲覧 →