次の方法で共有

Azure でコンテナーをデプロイする

  • [アーティクル]

ヒント

このコンテンツは eBook の「Azure 向けクラウド ネイティブ .NET アプリケーションの設計」からの抜粋です。.NET Docs で閲覧できるほか、PDF として無料ダウンロードすると、オンラインで閲覧できます。

PDF のダウンロード

Cloud Native .NET apps for Azure eBook cover thumbnail.

この章と第 1 章では、コンテナーについて説明しました。 コンテナーには、移植性など、クラウドネイティブ アプリケーションにとって多くの利点があることがわかりました。 Azure クラウドでは、ステージング環境と運用環境の両方に同じコンテナー化されたサービスをデプロイできます。 Azure には、コンテナー化されたワークロードをホストするためのいくつかのオプションがあります

  • Azure Kubernetes Services (AKS)
  • Azure Container Instance (ACI)
  • Azure Web App for Containers

Azure Container Registry

マイクロサービスをコンテナー化する場合、まずコンテナー "image" をビルドします。このイメージは、サービス コード、依存関係、ランタイムのバイナリ表現です。 Docker API から Docker Build コマンドを使用してイメージを手動で作成することもできますが、さらによい方法は、自動化されたビルド プロセスの一部として作成することです。

作成されたコンテナー イメージは、コンテナー レジストリに格納されます。 それを使用して、コンテナー イメージを作成、格納、管理することができます。 パブリックとプライベートの両方で、多くのレジストリを使用できます。 Azure Container Registry (ACR) は、Azure クラウドでのフル マネージドのコンテナー レジストリ サービスです。 Azure ネットワーク内にイメージが保持されるため、Azure コンテナー ホストにデプロイする時間が短縮されます。 また、他の Azure リソースに使用するのと同じセキュリティと ID の手順を使用して、それらをセキュリティで保護することもできます。

Azure コンテナー レジストリを作成するには、Azure portal、Azure CLI、または PowerShell ツールを使用します。 Azure でレジストリを作成するのは簡単です。 それには、Azure サブスクリプション、リソース グループ、一意の名前が必要です。 図 3-10 は、registryname.azurecr.io でホストされるレジストリを作成するための基本的なオプションを示したものです。

Create container registry

図 3-10 コンテナー レジストリを作成する

レジストリを作成したら、それを使用する前に認証を行う必要があります。 通常は、Azure CLI コマンドを使用してレジストリにログインします。

az acr login --name *registryname*

認証が済めば、docker コマンドを使用してコンテナー イメージをプッシュできます。 ただし、それを行う前に、ACR ログイン サーバーの完全修飾名 (URL) でイメージにタグを付けておく必要があります。 <レジストリ名>.azurecr.io という形式を使用します。

docker tag mycontainer myregistry.azurecr.io/mycontainer:v1

イメージにタグを付けた後、docker push コマンドを使用して、ACR インスタンスにイメージをプッシュします。

docker push myregistry.azurecr.io/mycontainer:v1

イメージをレジストリにプッシュした後、次のコマンドを使用して、Docker のローカル環境からイメージを削除することをお勧めします。

docker rmi myregistry.azurecr.io/mycontainer:v1

ベスト プラクティスとして、イメージをコンテナー レジストリに手動でプッシュしないでください。 代わりに、GitHub や Azure DevOps などのツールで定義されたビルド パイプラインを使います。 詳細については、クラウドネイティブ DevOps に関する章を参照してください。

ACR タスク

ACR タスクは、Azure Container Registry から使用できる機能のセットです。 それによって Azure クラウド内でコンテナー イメージがビルドおよび管理され、内部ループ開発サイクルが拡張されます。 開発用コンピューター上のローカル環境で docker build と docker push を呼び出すのではなく、クラウド内の ACR タスクによって自動的に処理されます。

次の AZ CLI コマンドのどちらでも、コンテナー イメージがビルドされて ACR にプッシュされます。

# create a container registry
az acr create --resource-group myResourceGroup --name myContainerRegistry008 --sku Basic

# build container image in ACR and push it into your container registry
az acr build --image sample/hello-world:v1  --registry myContainerRegistry008 --file Dockerfile .

前のコマンド ブロックからわかるように、開発用コンピューターに Docker Desktop をインストールする必要はありません。 また、ソース コードと基本イメージのどちらが更新されてもコンテナー イメージがリビルドされるように、ACR タスク トリガーを構成できます。

Azure Kubernetes Service

この章では、Azure Kubernetes Service (AKS) について説明しました。 それが、コンテナー化されたクラウドネイティブ アプリケーションを管理する事実上のコンテナー オーケストレーターであることがわかりました。

ACR などのレジストリにイメージをデプロイすると、それを自動的にプルおよびデプロイするように AKS を構成できます。 CI/CD パイプラインを設けると、カナリア リリース戦略を構成して、更新を迅速に展開するときのリスクを最小限に抑えることができます。 アプリの新しいバージョンは、最初に、トラフィックをルーティングされずに運用環境で構成されます。 その後、システムにより、ごく一部のユーザーが新しくデプロイされたバージョンにルーティングされます。 新しいバージョンに問題がないことをチームが確認したら、より多くのインスタンスをロールアウトし、古いものの使用を止めることができます。 AKS を使用すると、このスタイルのデプロイを簡単にサポートできます。

Azure のほとんどのリソースと同様に、ポータル、コマンド ライン、または Helm や Terraform などの自動化ツールを使用して、Azure Kubernetes Service クラスターを作成できます。 新しいクラスターの使用を開始するには、次の情報を提供する必要があります。

  • Azure サブスクリプション
  • リソース グループ
  • Kubernetes クラスター名
  • リージョン
  • Kubernetes バージョン
  • DNS 名プレフィックス
  • ノード サイズ
  • ノード数

使い始めるには、この情報で十分です。 Azure portal での作成プロセスの一環として、クラスターの次の機能についてのオプションを構成することもできます。

  • スケール
  • 認証
  • ネットワーク
  • 監視
  • Tags

このクイックスタートでは、Azure portal を使用して AKS クラスターをデプロイする手順が説明されています。

Azure Bridge to Kubernetes

クラウドネイティブ アプリケーションの規模と複雑さが拡大し、実行のために大量のコンピューティング リソースが必要になる可能性があります。 このようなシナリオでは、アプリケーション全体を開発用コンピューター (特にノート PC) でホストすることはできません。 Azure Bridge to Kubernetes によって、この欠点を解決できます。 開発者は、サービスのローカル バージョンで作業を行いながら、AKS 開発クラスターでアプリケーション全体をホストできます。

準備ができたら、開発者は、依存関係をレプリケートすることなく、AKS クラスター内の完全なアプリケーションに対して実行しながら、その変更をローカルでテストします。 内部では、ブリッジによってローカル コンピューターのコードと AKS のサービスがマージされます。 開発者は、Visual Studio または Visual Studio Code を使用して、Kubernetes 内で直接コードの迅速な反復処理とデバッグを実行できます。

Microsoft の以前の製品管理担当副社長である Gabe Monroy は、それについても説明します。

自分が新しい従業員で、それぞれに独自の構成とバッキング サービスがある何十ものコンポーネントで構成される複雑なマイクロサービス アプリケーションのバグを修正しようとしているところを想像してみてください。 最初に、ローカル開発環境を構成して、IDE のセットアップ、ツール チェーンの構築、コンテナー化されたサービスの依存関係、ローカル Kubernetes 環境、バッキング サービスのモックなど、運用環境を模倣できるようにする必要があります。 開発環境の設定に必要なすべての時間を考えると、最初のバグを修正するのに何日もかかるおそれがあります。 あるいは、Bridge to Kubernetes と AKS を使用すればいいだけです。

前へ次へ