作成日：2024年7月15日(月)
１．はじめに
AzureでDocker Composeを使用して様々なアプリケーションを手軽に動作させる環境を構築するため、ACI(Azure Container Instances)を調べていました。
しかし、ACIをクライアントPCから構築する際に、個人環境では問題ありませんが、企業プロキシ環境でも同じ手順で動作するのか不安になってきました。
そこで、調べを進めたところACIはAzure Cloud Shellからも構築できることが分かりました。
Azure Cloud ShellはAzureポータル上でCloudShell用マシンを立ち上げ、そのマシンからAzure CLIやAzure Developer CLIなどのAzureの操作を行える環境です。
このページではAzure Cloud ShellでDocker Composeを動作させるまでを前提に調べた内容を整理します。
２．Azure Cloud Shellとは
Azure Cloud Shellは、Azureポータルから直接アクセスできるブラウザベースのシェル環境です。
Azureポータルの右上の「プロンプトアイコン」をクリックすることでAzure Cloud Shellを起動することができます。
Azure Cloud Shellを使用するとローカルPCでAzure CLIなどの環境を設定することなく、Azureの管理やスクリプトの実行が可能です。
Cloud ShellにはBashとPowerShellの2つの環境があり、用途に応じて使い分けることができます。
正直に言うと、Visual Studio Codeの拡張機能のAzure AccountやAzure App Serviceなどのツールの方が使いやすいですが、
Visual Studio Codeの拡張機能のAzure Accountは何故か企業プロキシ環境で正しく動作してくれません。
従って、企業プロキシ環境に依存しない、Azure Cloud Shellは選択肢としてはありです。
３．特徴
| No | 特徴 | 説明 |
|---|---|---|
| 1 | ブラウザベース | Azure Cloud Shellはブラウザ上で、インターネットに接続された任意のデバイスからAzureポータル経由でアクセスできます。インストール不要で、どこからでもAzureリソースの管理が可能です。 |
| 2 | 統合シェル | BashシェルとPowerShellの両方をサポートしています。ユーザーは自身のニーズに合わせてシェル環境を選択できます。 |
| ３ | 永続ストレージ | Azure Cloud Shellに永続的なクラウドストレージ（Azure File Share）を割り当てると、ユーザーのファイルやスクリプトを保存して再利用できます。このストレージはシェル環境を再起動してもデータが保持されます。 |
| 4 | Azureツールのプリインストール | Azure CLI、Azure PowerShellモジュール、Terraform、Kubernetes CLI (kubectl)など、さまざまなAzure管理ツールが事前にインストールされています。これにより、ユーザーはすぐに作業を開始できます。 |
| 5 | セキュリティ | Azure Cloud ShellはAzureの認証メカニズムを使用しており、セキュアなアクセスを提供します。また、ブラウザ上のセッションは自動的にタイムアウトし、セキュリティが強化されています。 |
４．機能
Azure Cloud Shellにプリインストールされているツールの最新は「Azure Cloud Shell の機能とツール」ページで確認が可能です。
Docker Composeでアプリケーションを構築する際は、通常GitHubなどからGitコマンドでデプロイし、Docker Composeコマンドでコンテナーを実行するため、必要なコンポーネントは予め揃っているようです。
| No | カテゴリ | プリインストールされているツール | 備考 |
|---|---|---|---|
| 1 | Azure ツール | Azure CLI, Azure PowerShell, Azure Functions Core Tools | |
| 2 | プログラミング言語 | .NET Core, Python, Node.js, Java, Ruby, Go | |
| 3 | データベースツール | MySQL クライアント, PostgreSQL クライアント, SQL Server クライアント | |
| 4 | 開発ツール | Git, Visual Studio Code (Cloud Shell エディター) | |
| 5 | コンテナツール | Docker, Kubernetes (kubectl) | Docker Composeも含まれているようです |
| 6 | テキストエディタ | vim, nano, emacs | |
| 7 | ユーティリティ | jq (JSONプロセッサ), sed, grep, awk | |
| 8 | その他 | Terraform, Ansible |
ストレージ アカウントを使用するように Cloud Shell を構成した場合は、独自のツールをインストールできます。 ルート アクセス許可を必要としない任意のツールをインストールできます。 たとえば、Python モジュール、PowerShell モジュール、Node.js パッケージ、およびwget を使用してインストールできるほとんどのパッケージをインストールできます。
５．設定
| No | 項目 | 説明 | 備考 |
|---|---|---|---|
| 1 | シェル環境 | Cloud Shell では、 Bash または PowerShell を選択できます。 | この設定はCloud Shell ツール バーの環境セレクターを使用していつでも変更できます。直近で使用した環境が、次のセッションの既定になります。 |
| 2 | ストレージアカウント | ストレージ アカウントは、BLOBやファイル、キュー、テーブルなどのAzure Storageデータオブジェクトを含む、一意の名前空間を提供するクラウドストレージの管理単位です | |
| 3 | ファイル共有 | ファイル共有は、クラウド上でSMBプロトコルを使用してアクセス可能な共有ファイルストレージサービスです |
Azure Cloud Shell設定後に作成されるリソース
| No | 項目 | 例 | 説明 |
|---|---|---|---|
| 1 | ストレージアカウント | Production-cs | [Azureポータル]⇒[ストレージアカウント]で確認できます。 |
| 2 | 共有ファイル | pft-cloud-shell | [Azureポータル]⇒[ストレージアカウント]⇒＜作成したストレージアカウント＞⇒[データストレージ]⇒[ファイル共有]で確認できます。 |
5.1 シェル環境
5.2 ストレージアカウントと仮想ネットワーク
Azure Cloud Shellでは永続ストレージを割り当てることでShellスクリプトやdocker-compose.yamlファイルなどの永続維持が可能となります。
永続ストレージを割り当てる際には「ストレージアカウントをマウント」するを選択する必要があります。
ここで「既存のプライベート仮想ネットワークを使用する」にチェックを入れると、ストレージアカウント名、仮想ネットワーク、ネットワークプロファイル、リレー名前空間の選択を求められます。
新規の場合は「既存のプライベート仮想ネットワークを使用する」のチェックはいれないことをお勧めします。
5.3 ストレージアカウント
Azure Cloud Shellのウィザードでストレージアカウントを作成すると「ストレージアカウント」配下にSMBプロトコルを使用してアクセス可能な「ファイル共有」という「共有ファイルストレージサービス」を作成します。
| No | 項目 | 記入例 | 説明 | 備考 |
|---|---|---|---|---|
| 1 | サブスクリプション | Azure subscription | サブスクリプション名を選択します。 | ー |
| 2 | リソースグループ | Producetion-RG | リソースグループ名を選択します。 | ー |
| 3 | リージョン | (アジア太平洋)東南アジア | リージョンは以下の７つから選択する必要があります。 アメリカ合衆国 ①米国東部、②米国中南部、③米国西部 ヨーロッパ ④北ヨーロッパ、⑤西ヨーロッパ アジア太平洋 ⑥インド中部、⑦東南アジア |
ー |
| 4 | ストレージアカウント名 | ptfcloudshell | Cloud Shell用のストレージアカウント名を指定します。 | ハイフンやアンダースコアは指定できません |
| 5 | 共有ファイル | pft-cloud-shell | Cloud Shell用の共有ファイル名を指定します。 | 共有ファイルには[Azureポータル]⇒[ストレージアカウント]⇒＜作成したストレージアカウント＞⇒[データストレージ]⇒[ファイル共有]⇒＜作成した共有ファイル＞⇒左側ペインの[参照]からアクセスできます。 |
| 参照画面でアップロードも可能です。 |
hogehoge [ ~ ]$ pwd
/home/hogehoge
hogehoge [ ~ ]$ df -k
Filesystem 1K-blocks Used Available Use% Mounted on
overlay 51606304 604 48967876 1% /
tmpfs 65536 0 65536 0% /dev
shm 65536 0 65536 0% /dev/shm
/dev/sdc 51606304 604 48967876 1% /etc/hosts
tmpfs 1843444 0 1843444 0% /sys/fs/cgroup
//ptfcloudshell.file.core.windows.net/ptf-cloud-shell 6291456 5242880 1048576 84% /usr/csuser/clouddrive
/dev/loop0 5150368 132 4888092 1% /home/portfolio997
hogehoge [ ~ ]$
hogehoge [ ~ ]$ ls -l
total 0
lrwxrwxrwx 1 hogehoge hogehoge 22 Jul 14 02:07 clouddrive -> /usr/csuser/clouddrive
hogehoge[ ~ ]$
この例では/home/hogehoge/clouddriveに6,291,456 K blocks＝約6 GiB(6,291,456 ÷ 1024 ÷ 1024)のストレージが割り当たりました。
１か月の維持費はPerplexity AIで以下のように約20円と算出できました。
6GiBは約6.44GB（1GiB = 1.074GB）なので、計算すると:
6.44GB * 0.02 USD/GB/月 ≈ 0.13 USD/月
したがって、6GiBのストレージを1か月維持するための概算コストは約0.13 USD（約20円）となります。
６．使い方
Azure Cloud ShellでAzure App Serviceのプレビュー版の複数コンテナー(multi-container)を操作することができます。
ここではAzure App Serviceの複数コンテナー(multi-container)でDockerイメージベースのDocker Composeを動作させる方法をまとめます。
6.1 Azure App Service プランの作成
①App Serviceプランの作成
az appservice plan create --name ptfappplan2 --resource-group Production-RG --sku B1 --is-linux --location japaneast
| No | 項目 | 引数 | 説明 | 備考 |
|---|---|---|---|---|
| 1 | サブコマンド | appservice plan create | App Service プランを作成する。 | |
| 2 | アプリプラン名 | --name ptffafppplan2 | 新しい App Service プランの名前。 | |
| 3 | リソースグループ名 | --resource-group Production-RG | リソース グループの名前。 az group list --output tableのNameで確認できるリソースグループ名 |
|
| 4 | SKU | --sku B1 | 価格レベル (例: F1(Free)、D1(Shared)、B1(Basic Small)、B2(Basic Medium)、B3(Basic Large)、S1(Standard Small)、P1V2(プレミアム V2 Small)、PC2 (プレミアム Container Small)、PC3 (プレミアム Container Medium)、PC 4 (プレミアム Container Large)、I1 (Isolated Small)、I2 (Isolated Large)、I3 (Isolated Large)、I1v2 (Isolated V2 Small)、I2v2 (Isolated V2 Medium)、I3v2(Isolated V2 Large) K1(Kubernetes)。 | B2の趣味レーションで月額27.01 USDと表示されます。 |
| 5 | プラットフォーム | --is-linux | --hyper-v WindowsコンテナーでWebアプリをホストします。 --is-linux Linux workerでWebアプリをホストします。 |
|
| 6 | リージョン | --location japaneast | az account list-locations --output tableのNameで確認できるリージョンを指定 |
②作成したApp Serviceプランの確認
az appservice plan list --output table
portfolio997 [ ~/clouddrive/growi ]$ az appservice plan list --output table
ElasticScaleEnabled FreeOfferExpirationTime HyperV IsSpot IsXenon Kind Location MaximumElasticWorkerCount MaximumNumberOfWorkers Name NumberOfSites NumberOfWorkers PerSiteScaling Reserved ResourceGroup Status TargetWorkerCount TargetWorkerSizeId ZoneRedundant
--------------------- -------------------------- -------- -------- --------- ------ ---------- --------------------------- ------------------------ ----------- --------------- ----------------- ---------------- ---------- --------------- -------- ------------------- -------------------- ---------------
False 2024-08-13T09:21:09.360000 False False False linux Japan East 1 3 ptfappplan 1 1 False True Production-RG Ready 0 0 False
False 2024-08-13T09:42:51.883333 False False False linux Japan East 1 3 ptfappplan2 0 1 False True Production-RG Ready 0 0 False
portfolio997 [ ~/clouddrive/growi ]$
6.2 Docker Composeアプリの作成
ここではMicrosoftの「Docker Compose 構成を使用してマルチコンテナー (プレビュー) アプリを作成する」ページで紹介されている複数コンテナーのWordPressを動作させてみます。
①git clone
AzureポータルのAzure Cloud Shellの共有ファイル(/home/hogehoge/clouddrive)にGitHubのhttps://github.com/Azure-Samples/multicontainerwordpressをデプロイします。
コマンド
**git clone https://github.com/Azure-Samples/multicontainerwordpress**
実行例
hogehoge [ ~/clouddrive ]$ pwd
/home/hogehoge/clouddrive
hogehoge [ ~/clouddrive ]$ git clone https://github.com/Azure-Samples/multicontainerwordpress
Cloning into 'multicontainerwordpress'...
remote: Enumerating objects: 83, done.
remote: Counting objects: 100% (33/33), done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 83 (delta 25), reused 23 (delta 23), pack-reused 50
Receiving objects: 100% (83/83), 28.49 KiB | 162.00 KiB/s, done.
Resolving deltas: 100% (35/35), done.
hogehoge [ ~/clouddrive ]$
②Docker Compose Webアプリの作成
AzureポータルのAzure Cloud ShellのAzure CLIを使用してAzure App Serviceの複数コンテナー(multi-container)を作成します。
コマンド
**az webapp create --resource-group Production-RG --plan ptgappplan2 --name ptf-wordpress --multicontainer-config-type compose --multicontainer-config-file docker-compose-wordpress.yml**
実行例
portfolio997 [ ~/clouddrive ]$ pwd
/home/portfolio997/clouddrive
portfolio997 [ ~/clouddrive ]$ cd multicontainerwordpress
portfolio997 [ ~/clouddrive/multicontainerwordpress ]$ az webapp create --resource-group Production-RG --plan ptgappplan2 --name ptf-wordpress --multicontainer-config-type compose --multicontainer-config-file docker-compose-wordpress.yml
※Azure App Serviceの複数コンテナーアプリを作成するとアプリケーションは自動起動されるのですが、これには数分の時間を要します。
※https://github.com/Azure-Samples/multicontainerwordpressの場合、最初にMySQLより先にWordPressサービスが立ち上がってくるため、最初はDB接続エラーとなりますが、しばらくすると正常に動作します。
6.3 Docker Composeの動作確認
Azure App ServiceのマネージドサービスであるKuduに接続してLog stream、Bashで確認
※Kuduにアクセスするさいにパスワード認証を求められる場合は[Azureポータル]⇒[App Service]⇒<作成したサービス>⇒[デプロイセンター]⇒[発行プロファイルの管理]で「発行プロファイルのダウンロード」を行い
ダウンロードしたprofile.publishsettingsのXML中に書かれているuserName、userPWDを用いてKuduサイトにアクセスします。
[https://ptf-wordpress.scm.azurewebsites.net/](https://ptf-wordpress.scm.azurewebsites.net/api/logs/docker)
ブラウザの別タグでhttps://ptf-wordpress.azurewebsites.net/にアクセス後
Kuduサイト(https://ptf-wordpress.scm.azurewebsites.net/api/logs/docker)のLog streamで起動されたことをLogで確認します。
Kuduサイト(https://ptf-wordpress.scm.azurewebsites.net/api/logs/docker)のBashでサインインできます。
但し/home/LogFilesでDockerのログは確認できるものの、Docker
6.4 Azure-Samples/multicontainerwordpressへの接続確認
実際に登録したhttps://github.com/Azure-Samples/multicontainerwordpressのサービスにアクセスして接続確認を行います。
①サービスサイトにアクセスします。
https://ptf-wordpress.azurewebsites.net/
「日本語」を選択して「次へ」をクリックします。
ユーザ登録を行い「ログイン」をクリックします。
登録したユーザでログインします。
７．その他の複数コンテナーアプリケーション
Microsoftのサンプルが動作したので、目的のGrowiやDifyを動かしたみました。
結果は以下の通りで残念な結果となりました。
| No | アプリケーション | 状況 | 備考 |
|---|---|---|---|
| 1 | Growi | DockerFileによるbuildが必要なため、動作せず | |
| 2 | Dify | docker-compose.yamlファイルの4,000文字制限に引っ掛かり動作せず | コメントや不要な定義を削ってみましたが、4,000文字 |
８．制限事項
- Azure App Serviceの複数コンテナー(プレビュー)の制限
「Azure App Service のカスタム コンテナーを構成する」の「プレビューの制限事項」を参照
| No | 制限 | 説明 | 備考 |
|---|---|---|---|
| 1 | 認証/認可 | IDプロバイダーを登録する「認証」メニューは非活性となっていいます。 | ー |
| 2 | マネージドID | ー | ー |
| 3 | CORS | ー | ー |
| 4 | 仮想ネットワーク統合(VNet統合) | App ServiceからVnetへの通信を司るVNet統合機能は利用不可です。 | |
| ログサーバやAIの知識データベースなどをVNetに配置することができません。 | |||
| 5 | Docker Compose構成ファイルの4,000文字制限 | docker-compose.ymlファイルの文字数が4,000文字に制限されています。 | Difyはdocker-compose.yamlファイルが4000文字を超えるため、「Linux Version is too long. It cannot be more than 4000 characters.」エラーとなりました(*1) |
| 6 | DockerFileによるbuild | Dockerイメージの作成は未サポートです。 | growiなどはbuildがあるためApplication Errorとなりました |
| 7 | Docker Compose構成ファイルのdepend_on | 無視されます | ー |
| 8 | Docker Compose構成ファイルのnetwork | 無視されます | ー |
| 9 | Docker Compose構成ファイルのsecrets | 無視されます | ー |
| 10 | Docker Compose構成ファイルのports | 無視されます | ー |
| 11 | Docker Compose構成ファイルの環境変数 | docker とは異なる、$variable and ${variable} のような既定の環境変数 | ー |
(*1)GitHubのissues#22022での見解
https://github.com/Azure/azure-cli(GitHub)のissues#22022ではこの問題を現状の仕様としてクローズしています。
https://github.com/Azure/azure-cli/issues/22022
８．感想
-
Azure App Serviceの複数コンテナーは１アプリケーション
Azure App Serviceの単一コンテナーでは１サービスあたり、１コンテナーだったのに対し、複数コンテナーは１サービスあたり、複数コンテナーを実現しています。
従って、Azure App Serviceの課金も１サービスとしての課金となります。
１つのアプリケーションを複数の単一コンテナーで起動することも検討しましたが、これではApp Serviceの低価格というメリットが半減してしまいます。
このことはメリットに感じました。 -
Azure Cloud ShellのDocker Clientについて
Azure App Serviceの複数コンテナーはプレビューなので今後に期待ですが、
Azureポータル経由でセキュリティを確保しているAzure Cloud ShellでDocker Clientが実装されているのにも関わらず宝の持ち腐れ感があります。
Dockerはサーバー・クライアントモデルですので、App Service内のDocker Daemon(Docker Engine)にAzure Cloud Shellから接続させて欲しかったです。
期待はAzure Cloud ShellでDOCKER_HOSTで指定したApp Service内のDocker Daemonを「docker compose ps」などで状態確認したかったです。
実際にDOCKER_HOSTをApp Serviceに向けて接続をここと見ましたが接続できませんでした。（証明書やアクセスコントロールの課題があるのだと思います）
DockerコマンドやDocker Composeコマンドが利用できないことでアプリが動作しなかったときのデバッグの難易度が上がります。 -
Azure App Serviceの複数コンテナーについて
制限事項が多すぎます。
致命的なのはDockerFileによるbuildの未サポート、Docker Compose構成ファイルの4,000文字制限です。
Dockerイメージでの配布も多くなってきましたが、GitHubの多くのアプリケーションはDockerFileによるbuildを伴うものです。
Azure Cloud Shellでbuildができないため、クライアントPCなどでbuildしたDockerイメージをACR(Azure Container Registry)などにアップしなければ実行できません。
結局のとことローカルPC環境が必要となります。
私はDify-0.6.13を動作させたかったのですが、Docker Compose構成ファイルの4,000文字制限にひっかかり動作を断念しています。 -
クローズド環境での動作
Azure App Serviceの閉域化にはプライベートエンドポイントと仮想ネットワーク統合(VNet統合)が必要不可欠ですが、2024年7月15日時点で仮想ネットワーク統合(VNet統合)が制限で使用できません。
これでは会社の環境で使用できないため、残念で仕方がありません。 -
認証/認可
Azure App Serviceの利点である、App Service内臓のリバースプロキシによる認証/認可機能が使用できないため、IDプロバイダーを指定したアクセスコントロールができません。
アプリケーション層での認証/認可の実装はかなり面倒なプログラム開発となるため、この機能が使えないと非常に困ります。
現状はアプリケーション層でIDaaS（IDプロバイダー）に対応しているアプリに限定されてしまいそうです。
９．留意事項
- プレビュー版のApp Serviceの複数コンテナーは現状用途を限定されてしまう
Azure Cloud ShellのDocker Clientの問題、Azure App Serviceの複数コンテナーの制限事項、VNet統合・認証プロバイダーの未サポートといった理由によりまだまだ発展途上です。
AWS Lightsail程度の動作を期待していただけに残念でした。
PaaSはOSセキュリティパッチなどの作業を低減できるため、活用していきたいのですが、Azureでは現状IaaSを選択するしかなさそうです。