Azure Kubernetes Service（AKS）の公式チュートリアル「Kubernetes on Azure tutorial – Prepare an Application for Azure Kubernetes Service (AKS)」は、AKSへアプリをデプロイする前に、Docker Composeでマルチコンテナアプリを準備・ビルド・ローカル検証する手順を扱う記事です。2026年5月14日（日本時間）の公開反映で押さえるべきポイントは、AKSクラスターの仕様変更ではなく、docker-compose down から docker compose down へのコマンド表記修正、RabbitMQの名称統一、Azure Developer CLI関連の見出し整理です。既存クラスターへの直接影響は小さいものの、社内手順書、CI/CD、研修資料、開発環境のDocker Composeバージョンは確認しておくべきです。(GitHub)
Azure Kubernetes Serviceのアプリ準備チュートリアルは何をする手順なのか
このチュートリアルは、AKSクラスターを作成する前段階として、サンプルアプリを取得し、コンテナイメージを作成し、ローカルのDocker環境でマルチコンテナアプリを動かす流れを説明しています。Microsoft Learnの本文では、サンプルアプリのクローン、コンテナイメージ作成、ローカルDocker環境でのテストが学習内容として示され、その後のチュートリアルでAzure Container Registry（ACR）へのイメージ登録とAKSへのデプロイに進む構成になっています。(Microsoft Learn)
つまり、この記事を読むべきなのは「AKSにいきなりデプロイしたい人」だけではありません。むしろ、以下のような担当者が最初に確認すべき内容です。
| 対象者 | 確認すべきこと |
|---|---|
| アプリ開発者 | ローカルで複数コンテナを起動し、サービス間通信やヘルスチェックを確認できるか |
| AKS管理者 | 本番AKSに載せる前に、イメージ作成・ACR登録・Kubernetes展開の責任範囲を切り分けられるか |
| DevOps担当者 | CI/CDのDocker Composeコマンドが現在の標準構文に合っているか |
| 技術リード | サンプルの認証情報や環境変数を本番構成へ誤って流用していないか |
公式チュートリアルのサンプルアプリは、ストアフロント、商品サービス、注文サービス、RabbitMQで構成されます。Docker Composeファイルでは、RabbitMQ、order-service、product-service、store-frontなどをサービスとして定義し、ローカル環境では http://localhost:8080 から画面を確認する流れです。(Microsoft Learn)
2026年5月14日更新で確認すべき主な変更点
今回の変更は、AKSのAPI、Kubernetesバージョン、ノードプール、ネットワーク、ACR連携の仕様を変えるものではありません。実務上の影響は、チュートリアルや社内手順を実行する際のコマンド表記、用語、ページ構造にあります。
| 変更点 | 変更前 | 変更後 | 実務上の影響 |
|---|---|---|---|
| Docker Composeの停止コマンド | docker-compose down | docker compose down | Compose V2前提のコマンドに統一。古い手順書やCIジョブの見直しが必要 |
| RabbitMQの表記 | Rabbit MQ | RabbitMQ | 製品名の表記揺れを解消。運用資料や構成図の名称統一に反映 |
| 記事タイトル | Prepare an application | Prepare an Application | 表記上の修正。技術的な影響は小さい |
| Azure Developer CLI見出し | タブ形式の見出し | 通常見出しとして整理 | Azure CLI手順とazd手順の読み分けがしやすくなる |
| メタ情報 | ms.service の明示なし | azure-kubernetes-service を明示 | ドキュメント分類上の整理。利用者側の設定変更は不要 |
差分では、クリーンアップ手順の説明が docker-compose down から docker compose down に修正されています。Docker Composeの現在の標準コマンドはスペース区切りの docker compose であり、Dockerの公式ドキュメントでもスタンドアロン版の docker-compose 構文は後方互換用途として扱われています。(GitHub)
影響範囲は「AKS本体」より「開発環境と自動化手順」
今回の更新で、既存のAKSクラスターが自動的に変更されるわけではありません。ノードプール、Pod、Service、Ingress、ACR、Managed Identity、ネットワークポリシーなどの本番リソースに直接影響する変更ではないと見てよいでしょう。
ただし、開発現場では小さな表記変更が失敗の原因になります。特に次のケースでは確認が必要です。
CI/CDで docker-compose を使っている場合
GitHub Actions、Azure Pipelines、GitLab CI、社内Jenkinsなどで、古いチュートリアルを参考にして次のようなコマンドを書いている場合があります。
docker-compose -f docker-compose-quickstart.yml up -d
docker-compose down現在の手順に合わせるなら、次のように更新します。
docker compose -f docker-compose-quickstart.yml up -d
docker compose downただし、単純に置換するだけでは不十分です。実行環境にDocker Compose V2プラグインが入っていない場合、docker compose が失敗します。更新前に、CIランナーや開発端末で次の確認を行ってください。
docker compose version
docker versiondocker compose version が通らない場合は、Docker Desktop、Docker Engine、Composeプラグインの導入状況を見直します。古いLinuxサーバーや自前のビルドエージェントでは、docker 本体だけが入り、Composeプラグインが入っていないことがあります。
Azure Cloud Shellだけで完結しようとしている場合
公式チュートリアルは、ローカルのDocker開発環境でLinuxコンテナを実行できることを前提にしています。Microsoft Learnでも、Azure Cloud Shellにはチュートリアルの全手順を完了するために必要なDockerコンポーネントが含まれないため、フルのDocker開発環境を使うことが推奨されています。(Microsoft Learn)
そのため、初学者向けの研修や社内ハンズオンでは「Azureにログインできればよい」と説明しないようにしてください。事前準備として、Windows、Mac、LinuxのいずれかにDocker環境を用意し、Linuxコンテナモードで起動できることを確認する必要があります。
クリーンアップでイメージを消してしまう場合
公式チュートリアルでは、ローカル検証後にコンテナを停止・削除しますが、次のチュートリアルで使うためコンテナイメージは削除しないよう注意しています。docker compose down は標準では主にコンテナとネットワークを削除しますが、--rmi を付けるとサービスで使うイメージ削除の対象になります。(Microsoft Learn)
避けたい例は次のようなコマンドです。
docker compose down --rmi all --volumesローカル検証を完全にやり直す目的なら有効ですが、ACRへプッシュする前に実行すると、せっかく作成したイメージを再ビルドすることになります。チュートリアルの流れに沿うなら、まずは次のコマンドにとどめるのが安全です。
docker compose down管理者が確認すべき設定と運用ポイント
AKS管理者は、今回の更新を「ドキュメント上の軽微な修正」として放置するのではなく、開発からAKS展開までの入口を点検する機会として扱うと効果的です。
Docker Compose V2を標準にする
社内手順やテンプレートでは、docker-compose ではなく docker compose を基本表記に統一しましょう。理由は、現在のDocker ComposeがDocker CLIのサブコマンドとして扱われる形に移っているためです。
確認項目は次の3つです。
| 確認項目 | 判断基準 |
|---|---|
| 開発端末 | docker compose version が実行できる |
| CI/CDランナー | ビルドジョブ内で docker compose が使える |
| 手順書 | docker-compose と docker compose が混在していない |
古い環境をすぐ移行できない場合は、手順書に「この環境ではレガシー構文を使う」と明記します。何も書かずに両方を混在させると、トラブル時に原因切り分けが難しくなります。
サンプルの環境変数を本番に流用しない
チュートリアルのComposeファイルには、RabbitMQのユーザー名やパスワード、サービスURLなどの環境変数が含まれます。これは学習用のローカル実行を簡単にするための設定であり、本番AKS環境へそのまま持ち込むべきではありません。公式ページのCompose例でも、RabbitMQの認証情報が環境変数として記述されています。(Microsoft Learn)
AKSに展開する際は、少なくとも次の整理が必要です。
| Compose上の設定 | AKSでの考え方 |
|---|---|
RABBITMQ_DEFAULT_USER | Kubernetes Secretまたは外部シークレット管理へ移す |
RABBITMQ_DEFAULT_PASS | 平文のマニフェストに書かない |
| サービスURL | Kubernetes Service名、環境別ConfigMap、Helm valuesなどで管理 |
| ローカルポート公開 | Ingress、LoadBalancer、ClusterIPの用途に応じて設計 |
Kubernetesでは、パスワードやトークンなどの機密情報をSecretとして扱えます。Secretを使うことで、Pod仕様やコンテナイメージに機密情報を直接埋め込む必要を減らせます。(Kubernetes)
ローカルのヘルスチェックをAKSのProbeに置き換える
Docker Composeの healthcheck は、ローカル検証では便利です。しかし、AKSへ展開する際はKubernetesのLiveness Probe、Readiness Probe、Startup Probeとして設計し直す必要があります。Kubernetesでは、Probeの結果に基づいて不健康なコンテナを再起動したり、準備ができていないPodへのトラフィック送信を止めたりできます。(Kubernetes)
たとえば、ストアフロントやAPIサービスに /health があるなら、AKS用マニフェストでは次のような観点で分けて考えます。
| Probe | 役割 | 設定の考え方 |
|---|---|---|
| Startup Probe | 起動完了まで待つ | 初回起動が遅いサービスに設定 |
| Readiness Probe | 通信可能か判断する | 依存サービス接続後にReadyにする |
| Liveness Probe | 異常停止を検知する | デッドロックや復旧不能状態を検知 |
Composeで動いたからといって、AKS上で安定稼働するとは限りません。ローカル検証は「コンテナとして起動するか」を見る段階であり、AKS展開では「Podとして安全にスケール・再起動・公開できるか」を確認する必要があります。
開発者が展開前に確認すべきポイント
開発者は、チュートリアルのゴールを「ローカルで画面が開けた」で終わらせないことが重要です。AKSに進む前に、次の順番で確認してください。
ローカル実行の基本コマンドをそろえる
公式手順では、docker-compose-quickstart.yml を指定してアプリを起動します。実行するコマンドは次の形です。
docker compose -f docker-compose-quickstart.yml up -d起動後は、作成されたイメージと実行中コンテナを確認します。
docker images
docker ps最後に、ブラウザで次のURLを開きます。
http://localhost:8080公式チュートリアルでも、ローカルブラウザから http://localhost:8080 にアクセスし、商品閲覧、カート追加、注文操作を確認する流れが示されています。(Microsoft Learn)
ComposeのネットワークとKubernetes Serviceの違いを理解する
Docker Composeでは、同じComposeプロジェクト内のサービス名を使ってコンテナ間通信できます。一方、KubernetesではPodを直接指定するのではなく、Serviceを使って複数Podの背後にあるアプリケーションを公開します。KubernetesのServiceは、1つ以上のPodで動くネットワークアプリケーションを公開するための仕組みです。(Kubernetes)
そのため、Composeの product-service:3002 や order-service:3000 のようなローカル前提の接続設定は、AKS展開時にKubernetes Service名、名前空間、ポート設計に合わせて見直します。
depends_on を過信しない
Composeでは、サービスの起動順序をある程度制御できます。しかしAKSでは、Podの起動順序に頼るのではなく、Readiness Probe、再試行処理、依存先への接続リトライを組み合わせて設計します。
特にRabbitMQのようなメッセージキューに依存する注文サービスでは、キューが一時的に利用できない場合でもアプリが復旧できる設計が必要です。サンプルにある ORDER_QUEUE_RECONNECT_LIMIT のような値も、本番ではアプリ要件に合わせて調整します。
Azure Developer CLIを使う場合の注意点
このチュートリアルには、Gitでサンプルを取得する流れに加え、Azure Developer CLI（azd）を使う流れも含まれます。公式説明では、azd を使う場合、手動のコンテナイメージ依存関係はなく、azd up と azd down によってプロビジョニング、デプロイ、クリーンアップを扱うとされています。また、azure.yaml の infra セクションでは、既定でTerraformを使い、必要に応じてBicepへ変更できます。(Microsoft Learn)
実務では、Azure CLI手順とazd手順を混ぜないことが大切です。
| 方針 | 向いているケース | 注意点 |
|---|---|---|
| Azure CLI中心 | 既存のAKS、ACR、ネットワークを細かく管理したい | 手順が長くなりやすく、変数管理が重要 |
| azd中心 | サンプルから環境一式を素早く作りたい | Terraform/Bicepの構成、命名、権限を事前に確認する |
| 両方混在 | 学習・検証では可能 | 本番運用では責任範囲が曖昧になりやすい |
チームで使う場合は、「このプロジェクトはazdで環境を作る」「このプロジェクトは既存AKSへkubectlまたはHelmで展開する」と最初に決めておくと、手順の重複やリソースの作り直しを避けられます。
移行・展開前のチェックリスト
今回の更新を受けて、管理者と開発者は次の項目を確認しておくと安全です。
| チェック項目 | 確認方法 | 問題がある場合の対応 |
|---|---|---|
| Docker Compose V2が使える | docker compose version を実行 | Docker環境またはComposeプラグインを更新 |
| 手順書が古い構文のまま | docker-compose を検索 | docker compose へ置換し、例外環境だけ注記 |
| CI/CDでComposeが動く | ビルドジョブ内で検証 | ランナーイメージやセットアップ手順を修正 |
| Cloud Shell前提になっていない | ハンズオン資料を確認 | ローカルDocker環境を前提に書き換える |
| クリーンアップでイメージを消していない | --rmi の有無を確認 | ACRプッシュ前は docker compose down のみにする |
| サンプル認証情報を流用していない | Compose、マニフェスト、Helm valuesを確認 | SecretやKey Vault連携に置き換える |
| AKS用Probeを設計している | Deploymentマニフェストを確認 | Readiness/Liveness/Startup Probeを追加 |
| ComposeとKubernetesのネットワーク差分を理解している | Service、Ingress、DNS名を確認 | Kubernetes Service設計に合わせて環境変数を修正 |
まとめ：今回の更新は小さいが、AKS展開前の品質を上げる好機
2026年5月14日（日本時間）の公開反映で確認された「Kubernetes on Azure tutorial – Prepare an Application for Azure Kubernetes Service (AKS)」の変更は、AKS本体の破壊的変更ではありません。中心は、Docker Composeの現在の標準構文に合わせた docker compose down への修正、RabbitMQ表記の統一、Azure Developer CLI関連の見出し整理です。(GitHub)
ただし、影響が小さいから無視してよいわけではありません。古い docker-compose コマンドが社内手順、CI/CD、研修資料に残っていると、環境によっては実行エラーになります。また、ローカルComposeで動いたアプリをAKSに載せる際は、Secret、Service、Probe、ACRへのイメージ登録、クリーンアップ手順を改めて設計する必要があります。
次に取るべき行動は明確です。まず開発端末とCI/CDで docker compose version を確認し、社内手順の docker-compose 表記を洗い出してください。そのうえで、サンプルの環境変数やヘルスチェックをAKS向けのSecret、Service、Probeへ置き換える準備を進めると、ACR登録からAKS展開までの移行がスムーズになります。
コメント