チュートリアル - Azure Kubernetes Service (AKS)用にアプリケーションを準備する

このチュートリアルでは、Kubernetes で使用するマルチコンテナー アプリケーションを準備します。 このチュートリアルは、新しいサンプル アプリから始める場合でも、Azure Kubernetes Service (AKS)に移行する予定のアプリに対して Docker Compose の概念を適応させる場合でも使用できます。 Docker Compose などの既存の開発ツールを使用して、アプリケーションをローカルでビルドしてテストします。 次のことを学びます。

完了後、次のアプリケーションがローカル開発環境で実行されます。

後のチュートリアルでは、コンテナー イメージを Azure Container Registry (ACR) にアップロードし、AKS クラスターにデプロイします。

開始する前に

このチュートリアルの前提として、コンテナー、コンテナー イメージ、docker コマンドなど、Docker のコア概念を基本的に理解している必要があります。 Docker の入門に関するドキュメントでコンテナーの基礎についての入門情報を参照してください。

このチュートリアルを完了するには、Linux コンテナーを実行するローカルの Docker 開発環境が必要です。 Docker には、Mac、Windows、または Linux システムで Docker を構成するパッケージが用意されています。

アプリケーションのコードを入手する

このチュートリアルで使用するサンプル アプリケーションは、次の Kubernetes デプロイとサービスを含む基本的なストア フロント アプリです。

• ネットショップ: 顧客が製品を見て注文するための Web アプリケーション。
• 製品サービス: 製品情報が表示されます。
• 注文サービス: 注文を行います。
• RabbitMQ: 注文キュー用のメッセージキュー。

Docker Compose ファイルを確認する

このチュートリアルで作成するサンプルアプリケーションは、あなたが複製したリポジトリ内のdocker-compose-quickstart YAML ファイルを使用します。

次の表は、サンプルの Compose ファイルのキーの既定値をまとめたものです。このチュートリアルで使用するサービス、ポート、依存関係をすばやく確認できます。

services:
  rabbitmq:
    image: rabbitmq:4.3.2-management-alpine
    container_name: 'rabbitmq'
    restart: always
    environment:
      - "RABBITMQ_DEFAULT_USER=username"
      - "RABBITMQ_DEFAULT_PASS=password"
    ports:
      - 15672:15672
      - 5672:5672
    healthcheck:
      test: ["CMD", "rabbitmqctl", "status"]
      interval: 30s
      timeout: 10s
      retries: 5
    networks:
      - backend_services
  order-service:
    build: src/order-service
    container_name: 'order-service'
    restart: always
    ports:
      - 3000:3000
    healthcheck:
      test: ["CMD", "wget", "-O", "/dev/null", "-q", "http://order-service:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 5
    environment:
      - ORDER_QUEUE_HOSTNAME=rabbitmq
      - ORDER_QUEUE_PORT=5672
      - ORDER_QUEUE_USERNAME=username
      - ORDER_QUEUE_PASSWORD=password
      - ORDER_QUEUE_NAME=orders
    networks:
      - backend_services
    depends_on:
      rabbitmq:
        condition: service_healthy
  product-service:
    build: src/product-service
    container_name: 'product-service'
    restart: always
    ports:
      - 3002:3002
    healthcheck:
      test: ["CMD", "wget", "-O", "/dev/null", "-q", "http://product-service:3002/health"]
      interval: 30s
      timeout: 10s
      retries: 5
    environment:
      - AI_SERVICE_URL=http://ai-service:5001/
    networks:
      - backend_services
  store-front:
    build: src/store-front
    container_name: 'store-front'
    restart: always
    ports:
      - 8080:8080
    healthcheck:
      test: ["CMD", "wget", "-O", "/dev/null", "-q", "http://store-front:80/health"]
      interval: 30s
      timeout: 10s
      retries: 5
    environment:
      - VUE_APP_PRODUCT_SERVICE_URL=http://product-service:3002/
      - VUE_APP_ORDER_SERVICE_URL=http://order-service:3000/
    networks:
      - backend_services
    depends_on:
      - product-service
      - order-service
networks:
  backend_services:
    driver: bridge

コンテナー イメージを作成してアプリケーションを実行する

Docker Compose を使用して、コンテナー イメージの構築とマルチコンテナー アプリケーションのデプロイを自動化できます。

次のコマンドを実行する前に、Docker が Linux コンテナー モードで実行されていることを確認します。

1. 複製された aks-store-demo リポジトリのルートから、コンテナー イメージを作成し、RabbitMQ イメージをダウンロードして、 docker compose コマンドを使用してアプリケーションを起動します。

   docker compose -f docker-compose-quickstart.yml up -d
   

2. docker images コマンドを使用して、作成されたイメージを表示します。

   docker images
   

   次の要約された出力例は、作成されたイメージを示しています：

   REPOSITORY                        TAG                          IMAGE ID
   aks-store-demo-product-service    latest                       72f5cd7e6b84
   aks-store-demo-order-service      latest                       54ad5de546f9
   aks-store-demo-store-front        latest                       1125f85632ae
   ...
   

3. docker ps コマンドを使用して、実行中のコンテナーを表示します。

   docker ps
   

   次の要約された出力例は、実行中の 4 つのコンテナーを示しています：

   CONTAINER ID        IMAGE
   f27fe74cfd0a        aks-store-demo-product-service
   df1eaa137885        aks-store-demo-order-service
   b3ce9e496e96        aks-store-demo-store-front
   31df28627ffa        rabbitmq:4.3.2-management-alpine
   

ローカルでアプリケーションをテストする

実行中のアプリケーションを表示するには、ローカルの Web ブラウザーで http://localhost:8080 に移動します。 次の例で示すように、サンプル アプリケーションが読み込まれます。

このページでは、製品を表示し、カートに追加して注文することができます。

独自の Compose ファイルを移行する

Docker Compose ファイルでアプリケーションが既に定義されている場合は、このチュートリアルをローカル検証の参照として使用し、既存の Compose 構成を Kubernetes マニフェストに変換できます。 Kompose、Move2Kube、Docker Compose Bridge、Podman などのツールを使用して、Docker Compose 定義を Kubernetes リソースに変換します。 完全なエンドツーエンドの変換パスについては、 Docker Compose を Kubernetes に移行するための Kubernetes ドキュメントと、別のオーケストレーターまたはモダン化ワークフローから移行する場合の AKS 移行の概要 を参照してください。

変換ツールを選択する

この表は、最も一般的な Compose-to-Kubernetes オプションの高速比較が必要な場合に使用します。

どのツールを選択する必要がありますか?

• 概念実証やスターター マニフェストをすばやく作成する場合は、 Kompose を使用します。
• Docker Desktop を使用していて、Docker ネイティブ パスが必要な場合は、 Docker Compose Bridge を使用します。
• より大規模なマルチサービス移行またはモダン化作業がある場合は、 Move2Kube を使用します。
• 実行中のコンテナーまたはポッドからエクスポートする場合は、 Podman を使用します。
• マニフェストが既にあり、パッケージ化またはオーバーレイが必要な場合は、 Helm または Kustomize を使用します。
• 変換後にローカルの Kubernetes 開発ループが必要な場合は、 Skaffold または Tilt を使用します。
• マニフェストのドラフトまたは移行の説明が必要な場合は、AI アシスタンスを使用し、公式の Kubernetes と AKS ガイダンスに照らして結果を検証します。

考慮すべきその他のツール:

• 8gwifi.org Kubernetes YAML コンバーター: 小さな Compose ファイルを使用した簡単なオンライン実験に役立ちます。
• Okteto: アプリケーション チームのクラウドまたはリモート Kubernetes 開発ループが必要な場合に便利です。
• Devtron: 変換後の Kubernetes 配信に関するプラットフォーム ワークフローが必要な場合に便利です。
• Portainer: UI ドリブン コンテナーと Kubernetes 管理エクスペリエンスが必要な場合に便利です。

Compose ファイルを変換する

次のコピー可能なコマンドを開始点として使用します。

kompose convert
move2kube plan -s ./path && move2kube transform
docker compose bridge convert -o ./k8s/
podman kube generate mypod > k8s.yaml
skaffold init

Kompose 変換の例

オープンソースの Kompose ツールは、一般的な Docker Compose 設定をデプロイやサービスなどの Kubernetes オブジェクトに変換します。

1. Windowsで、次のコマンドを使用して Kompose をインストールします。

   curl -L https://github.com/kubernetes/kompose/releases/latest/download/kompose-windows-amd64.exe -o kompose.exe
   

   その他のインストール オプションについては、 Kompose のインストール手順を参照してください。

2. docker-compose.yml ファイルを含むディレクトリから Kompose を実行します。

   kompose convert
   

3. 生成された Kubernetes YAML ファイルを AKS にデプロイする前に確認します。

AI支援変換

AI アシスタントを使用して、Kubernetes マニフェストのドラフト作成、Compose 設定と Kubernetes の同等の設定の比較、または変換で手動で変更が必要な理由を説明できます。

一般的なプロンプトの例:

Convert this docker-compose.yml into production-ready Kubernetes manifests. Use Apps/v1, move secrets to Kubernetes Secret objects, map local volumes to PersistentVolumeClaims, and add readiness and liveness probes for the web service.

AKS を対象とするサンプル プロンプト:

Convert this docker-compose.yml into AKS-ready Kubernetes manifests. Target an AKS cluster, push images to Azure Container Registry, use Apps/v1 objects, move secrets to Kubernetes Secret objects, map local volumes to Azure Files or Azure Disks-backed PersistentVolumeClaims, and add readiness and liveness probes for the web service.

AI 出力を適用する前に、必ず確認してください。 apiVersion値、リソースの要求と制限、ストレージ クラス、サービス公開、正常性プローブを検証します。

翻訳に関する一般的な問題を処理する

ボリュームはどのように処理されますか?

Compose volumes には、多くの場合、Kubernetes 永続ボリュームとストレージ クラスが必要です。 AKS では、ローカル専用マウントを Azure ディスクや Azure Files などのサービスに置き換えます。

depends_onに代わるものは何ですか?

Compose depends_on は、Kubernetes におけるランタイムの準備完了を保証しません。 必要に応じ、準備プローブ、スタートアップ プローブ、または init コンテナー ロジックに置き換えます。

シークレットと環境の値を処理する方法

Compose の環境変数の値は、多くの場合、Kubernetes のConfigMapまたはSecretリソース、または Azure Key Vault との統合に変換されます。

ポートとイングレスはどうなりますか?

Compose ports は、アプリケーションの公開方法に応じて、Kubernetes Service オブジェクトに、また場合によっては Ingress または Gateway API リソースにマッピングされます。

ヘルスチェックはどのように訳されますか?

Compose の healthcheck 設定は通常、Kubernetes の liveness プローブと readiness プローブに変換されます。

Compose ネットワークはどうなりますか?

Compose ネットワークは、通常、カスタム ブリッジ ネットワークではなく、サービスとクラスター DNS を介した Kubernetes サービス検出に変換されます。

Kubernetes を使用してローカルでテストする方法

変換後、生成されたマニフェストを kind や minikube などのローカル Kubernetes 環境にデプロイし、より高速な edit-build-deploy ループが必要な場合は 、Skaffold または Tilt を使用します。

変換後に AKS 固有の調整を適用する

Kompose には出発点がありますが、通常は AKS に対して手動で変更する必要があります。

• イメージ参照が Azure Container Registry (ACR) を参照するように更新してください。
• ローカル専用ストレージとバインド マウントを、ワークロードのニーズに応じて、Azure ディスクやAzure Filesなどの永続的なストレージに置き換えます。
• Compose のシークレットまたは環境固有の値を、Kubernetes Secrets、ConfigMaps、または Azure Key Vault との統合に置き換えます。
• AKS でアプリを発行する方法に基づいて、ネットワークと公開の設定 ( LoadBalancer、イングレス、ゲートウェイの構成など) を確認します。
• 安定した ID またはストレージの動作が必要な場合に、ステートフル コンポーネントをデプロイとして維持するか、StatefulSets などのパターンに移行するかを確認します。
• depends_onなどの Compose 動作は Kubernetes ランタイム動作に直接変換されないため、リソース要求、プローブ、およびスタートアップ順序の前提条件を検証します。

変換後のワークフロー

1. Kompose、Move2Kube、Docker Compose Bridge、Podman、AI でレビューされたドラフトなどのツールを使用して Compose ファイルを変換します。
2. ストレージ、シークレット、サービスの公開設定、プローブ、イメージ参照を修正して、マニフェストを見直し、堅牢化してください。
3. Kustomize を使用して、Helm またはレイヤー環境固有の変更を含むマニフェストをパッケージ化します。
4. イメージを ACR などのレジストリにプッシュし、GitOps、CI/CD、または直接 kubectl ワークフローを使用してデプロイします。

シーケンスの例: -kompose convert レビュー マニフェスト>->イメージを ACR にプッシュ>イメージ参照を更新する ->kubectl apply または helm install。

リソースをクリーンアップする

Docker Compose ワークフローに従った場合は、実行中のコンテナーを停止および削除できます。 コンテナー イメージは次の チュートリアルで使用するため、削除しないでください。 Azure Developer CLI ワークフローに従った場合は、azd downではなくdocker compose downを使用します。

docker compose down コマンドを使用して、コンテナー インスタンスとリソースを停止して削除します。

docker compose down

Azure Developer CLI のコマンド

azd を使用する場合、手動のコンテナー イメージの依存関係はありません。 azd は、Docker と同様に、アプリケーションとクラスターのプロビジョニング、デプロイ、およびクリーンアップを azd up および azd down コマンドを使用して処理します。

infra の azure.yaml セクション内にクラスターをデプロイする前に、Terraform または Bicep を使用するように準備手順をカスタマイズできます。 既定では、このプロジェクトでは Terraform が使用されます。

infra:
  provider: terraform
  path: infra/terraform

プロバイダーを Bicep に変更する場合は、次のように azure.yaml ファイルを更新します。

infra:
  provider: bicep
  path: infra/bicep

次のステップ

Azure CLI

このチュートリアルでは、サンプル アプリケーションを作成し、アプリケーションのコンテナー イメージを作成してから、アプリケーションをテストしました。 以下の方法を学習しました。

次のチュートリアルでは、ACR にコンテナー イメージを保存する方法について説明します。

Azure Developer CLI

このチュートリアルでは、azd を使用してサンプル アプリケーションを複製しました。 以下の方法を学習しました。

次のチュートリアルでは、複製した azd テンプレートを使用してクラスターを作成する方法について説明します。