Azureでコンテナ化のアプリケーションを構築していく
shimakaze_softAzureには以下のようなコンテナサービスが提供されている。GCPやAWSよりも種類が多い。
コンテナイメージを保存するサービス
- Azure Container Registry（ACR）
コンテナ化アプリケーションを実行するサービス
- Azure Container Instances (ACI)
- Web App for Containers (App Service)
- Azure Kubernetes Service (AKS)
- Azure Container Apps
こちらに詳しくまとめられていた
shimakaze_softコンテナイメージを保存するサービス
Azure Container Registry (ACR)
Dockerイメージをバージョン毎に管理することのできる保管庫です。
パブリックに展開しているDockerHubと同じであり、違いはAzure上限定のプライベートなDockerレジストリであることです。
これにより、公開できないようなセキュアな情報を含むDockerイメージを一部のチームや組織に限定することができます。
DockerHub同様にレジストリにあるDockerイメージを取得(Pull)したり、作成したDockerイメージを追加(Push)したりすることができます。
shimakaze_softコンテナ化アプリケーションを実行するサービス
Azure Container Instances (ACI)
Azure Container Instancesを利用することで自前でVMなどのサーバを構築せずに、サーバレスでコンテナを実行することができる。
ACIは比較的単純なアプリケーションやバッチ処理など、単一のコンテナでアプリケーションを実行することを想定したサービスとなっています。
特徴
- コンテナオーケストレーションや自動スケーリング機能がない
-
Azure Container Instancesは料金が安価
Web App for Containers (App Service)
Web App for ContainersはAzure App Serviceの利用形態の一つで、App Service上にWebアプリケーション用途のDockerコンテナをデプロイすることができる。
App Serviceのリソースと知識を使ってコンテナ化アプリケーションを実行することができるので、App Serviceの利用経験がある場合は比較的容易に運用をすることができる。
Web アプリケーションの開発・運用に便利な機能が豊富にあり、幅広いユースケースに向いている。
特徴
- 動的なスケーリングができる
- プランの種類が豊富
- 機能が豊富
- コードからのデプロイも可能
Azure Kubernetes Service（AKS）
コンテナ化アプリケーションのデプロイやスケーリングなどの管理を自動化するためのプラットフォームであるKubernetesをAzure上で利用できる。
k8sは複数のコンテナを協調させてアプリケーションを構築する場合に有用で、その役割からコンテナオーケストレーションエンジンと呼ばれている。
Kubernetesは任意の環境に構築して利用することができるが、AKSを利用することでKubernetesの主要なコンポーネントをAzureがホスティングし管理してくれるため、煩わしい保守を軽減することができる。
-
Kubernetes APIとクラスター管理への直接アクセスができる
Azure Container Apps
フルマネージドなサーバレスコンテナサービスであり、互いに関連する複数のコンテナを実行し、イベントに応じて柔軟にスケーリングすることができる。コンテナを動かすだけでなく、以下の2つの大きな特徴があります。
- KEDA による動的なスケーリング
- Dapr によるサービス間連携の実装容易性
サーバレスなコンテナ実行のためのサービスで、Webアプリケーションやバッチアプリケーションを実行することができる。
AWSだとApp Runner、GCPでいうとCloud Runに近い位置付けのサービス。
Azure Container Appsもサービスの基盤としてKubernetesを使用しているが、KubernetesのAPIを直接使用できないようになっているため開発者はアプリケーションの実装に集中できるようになっている。
そのためAKSに比べてKubernetes関連の設定の自由度は低いですが、気軽にマイクロサービスを構築したい場合に選択肢として検討する価値があります。
KEDA による動的なスケーリング
HTTP のリクエスト数やキューのメッセージ数、 CPU 使用率など、様々なトリガーに基づいてアプリケーションをスケーリングできる。
Kubernetes ベースのイベント駆動オートスケーラである KEDA(ケーだ)によってサポートされているトリガーが利用可能。
イベントがない場合は、最小で0にスケーリングして割安のアイドル使用料金を適用することができる。
イベント駆動という点はAzure Functionsと共通ですが、 Azure Functions の従量課金プランでは 1 回の実行が 10 分までに制限されている。
Azure Container Apps には実行時間の制限がない。
Dapr によるサービス間連携の実装容易性
Dapr(ダッパー)は、マイクロサービス構築に役立つ、言語やフレームワークに依存しないイベント駆動型のランタイム。
セッションなどの状態管理、メトリックやトレースの発行、外部リソースのバインディングなどの機能を提供する。
一緒にデプロイするだけで、 HTTP と gRPC の API を呼び出して利用できる。
アプリケーションに組み込む必要は無い。
Azure Container Apps では、Daprを有効にすることでコンテナーアプリ（Kubernetes でいう Pod）にセットで Dapr をデプロイでき、サービス間連携を実現しやすくなっている。
Azure Container Apps のユースケース
Azure Container Appsは常時稼働のアプリケーションでも、イベントによって起動するアプリケーションでも実行することができる。
「Azure Container Apps プレビューの概要 | Microsoft Docs」
Azure Container Apps の一般的な用途
- API エンドポイントのデプロイ
- バックグラウンド処理アプリケーションのホスティング
- イベント 駆動型処理の処理
- マイクロサービスの実行
shimakaze_softAzure Container RegistryにDockerfileを上げる
コンテナアプリケーションを使用するためにも、まずはACRにDockerfileを上げる必要があります。
今回はHasuraのDockerfileを作成していきます。
Dockerfileをビルドする
# Dockerfileのあるディレクトリまで移動
$ docker build -t custom_hasura:0.1 .
dockerコマンドのサブコマンドであるbuildコマンドは、DockerfileからDockerイメージをビルドする。
-tオプションでイメージの名前とタグ(バージョン)を指定することができる。
今回はcustom_hasuraというイメージ名と0.1というタグを指定している。
コマンドの最後のピリオドは、Dockerfileの位置を相対パスで指定している。ここではカレントディレクトリを表す .を指定している。
docker buildコマンドの実行後は、docker imagesコマンドで作成したイメージが一覧に表示されている。
$ docker images
$ docker images|grep custom_hasura
custom_hasura 0.1 b1e1012345f0 2 minutes ago 395MB
上記のコマンドで現在のマシンに存在するDockerイメージの一覧を表示することができる。
上記のように、REPOSITORY列に先程ビルドしたcustom_hasuraという名前のイメージが表示されていればビルドは成功している。
環境変数を指定してDockerコンテナを起動する
docker runコマンドを実行することでDockerイメージからコンテナを起動することができる。
$ docker run custom_hasura:0.1
$ docker run --env-file .env
$ docker run -e hoge=$fuga -e piyo="hogera"
-
--env-fileで環境変数が記述されたファイルのパスを指定 -
-eで環境変数を指定する
shimakaze_softAzure Container Registry(ACR)へログインする
DockerイメージをACRのコンテナレジストリへPushするためには、ターミナルでAzure CLIおよびDockerコマンドを使用する。
まずは先程作成したACRのコンテナレジストリに接続する。
$ az login
$ az acr login --name hasura
Login Succeeded
まずターミナル上でAzureにログインした状態となるために、Azure CLIのaz loginコマンドを実行します。
Azureに未ログインの場合はここでブラウザが表示されてAzureの認証画面が表示されるので、認証処理を行う。
ブラウザでの認証が成功すると、ターミナルにAzureアカウント情報のJSONが出力されます。
次にACRのコンテナレジストリに対してもログインを行う。
コンテナレジストリへログインすることでイメージのPullやPushを行うことができるようになる。
az acr loginコマンドに --name オプションで先程作成したコンテナレジストリのレジストリ名を指定して実行する。
コマンド実行後、「Login Succeeded」と出力されればログインは成功。
コンテナレジストリへのログインまで完了したら、DockerイメージをレジストリへPushしていく。
Dockerイメージにタグを付与する
DockerイメージをコンテナレジストリへPushするためには、まずイメージの名称をコンテナレジストリへPushできる形式に変更する必要があり、docker tagコマンドを使うことで、Dockerイメージに別のイメージ名を付与することができる。
docker tagに続く最初の引数には参照元となるイメージの名前とタグを指定し、2つ目の引数に参照先のイメージ名とタグを指定する。
参照先のイメージ名の前に、Push先の コンテナレジストリのホスト名とスラッシュを入れることでコンテナレジストリへPushできるようになる。
コンテナレジストリのホスト名は、ACRの場合は「コンテナレジストリ名 + .azurecr.io」となる。
$ docker tag custom_hasura:0.1 hasura.azurecr.io/custom_hasura:0.1
docker imagesコマンドで、hasura.azurecr.io/custom_hasuraが指定してあることが確認できる。
$ docker images|grep custom_hasura
hasura.azurecr.io/custom_hasura 0.1 b1e1012345f0 53 minutes ago 395MB
custom_hasura 0.1 b1e1012345f0 53 minutes ago 395MB
DockerイメージをAzure Container Registry(ACR)にPush
以下のコマンドでDockerイメージをACRにpushします。
$ docker push hasura.azurecr.io/custom_hasura:0.1
Azure Container Registry(ACR)のコンテナレジストリからDockerイメージをPull
$ docker pull hasura.azurecr.io/custom_hasura:0.1
0.1: Pulling from custom_hasura
....
docker pullコマンドを実行すると、引数に指定したコンテナレジストリのホストから該当のDockerイメージ名とタグを持つDockerイメージをPull(ダウンロード)することができる。
Pullの完了後にdocker imagesコマンドを実行すると、イメージの一覧に再び該当のDockerイメージが表示されていることが確認できる。
shimakaze_softAzure Container Instances
shimakaze_softコンテナインスタンスとPostgresを備えたAzure上のHasuraGraphQLエンジン
shimakaze_softApp Serviceのログ設定
- LogAnalyticsを使う => コマンドでログを表示
- ログストリームを使う => リアルタイムで見るアクセスログ
LogAnalytics
見たいログを表示させることが出る。
KQLというSQLライクな言語を使うことで、ログの検索をすることができます。
ログストリーム
リアルタイムでアクセスログを見るときに便利。
しかし、ログを垂れ流しのためアクセスが多いと一瞬で消えてしまう。