作成日：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を選択するしかなさそうです。