在 Azure 應用服務中裝載 Azure 文件

概括

我有一個執行自定義容器的 Azure 應用服務。當我將路徑綁定到 Azure 文件共享時，我的容器停止工作。查看Container Issues日誌，我看到錯誤：[BYOS] Custom storage volume(s) failed to initialize: [/var/LWASFiles/Sites/my-app/a3484543-39f9-45a3-816b-9524640dfd50].

細節

• 我的自定義容器定義了一個卷/var/www/html/v3/uploads。
• 我正在嘗試將此映射到 Azure 文件共享，該共享位於與託管 ASE 相同的 vnet 中的儲存帳戶上，規則允許 ASE 的子網與埠 137、138、138 和 445 上的文件共享之間的流量.
• 託管 ASE 配置有內部負載平衡器（即它是私有 ASE）。
• 儲存帳戶配置了專用終結點。
• 卷在應用服務的設置 > 配置 > 路徑映射下映射，使用有效密鑰和與容器上的捲路徑匹配的裝載路徑。
• 在添加路徑映射之前，應用服務按預期執行。
• 添加路徑映射後，容器無法啟動/我能找到的唯一異常資訊來自Container Issues日誌，根據上面的摘要。
• 如果我刪除路徑映射，問題仍然存在，即使在強制重啟之後也是如此。解決此問題的唯一方法是刪除並重新部署應用服務。
• 它通過專用終結點成功連接到 MySql DB（Azure Database for MySQL 伺服器）。
• 使用dig {privateEndpointFqdn}我能夠證明儲存帳戶的私有端點已正確解析（與 MySQL 一樣；如您所料）
• 使用tcptraceroute {privateEndpointFqdn} {destinationPort}我能夠證明我可以連接到埠 445 上的儲存帳戶（以及埠 3306 上的 MySQL 數據庫）。
• 注意：我無法連接到埠 137、138 或 139 上的儲存帳戶，儘管通過 NSG 允許使用與上述 445 相同的入站和出站規則；儘管我懷疑 CIFS 不再需要這些埠（我只是在第一次遇到問題後才將這些埠作為以防萬一的措施添加，以防它們在某些文章中提到它們以某種方式相關）。
• 我通過 SSH 進入容器來執行上述測試，因此命令是從其上下文中執行的。注意：因為添加路徑映射後無法啟動容器，所以這些測試是在創建應用服務之後添加路徑映射之前執行的。
• 我已經增加到WEBSITES_CONTAINER_START_TIME_LIMIT它的最大值：1800
• 我的容器暴露了 80 埠（即容器應用服務支持的預設埠之一）；並且網站在路徑映射不存在時工作，所以這不應該是問題。我也設置WEBSITES_PORT為80，僅用於腰帶和大括號。
• WEBSITES_ENABLE_APP_SERVICE_STORAGE設置為false（儘管我也嘗試將其設置為true，以防萬一/它沒有任何區別，所以我恢復為false）。
• 我的文件共享有幾 GB 的數據。我嘗試創建一個沒有內容的相同文件共享並映射到該文件共享（在重新創建應用程序服務並證明它有效之後立即；以確保我的測試不受較大文件共享的影響）。這給出了與較大文件共享相同的問題。
• 我的容器的映像是從 Azure 容器儲存庫載入的。
• 該圖像基於ubuntu:21.04
• 我已經包含了azure-cli和cifs-utils包（我認為這僅在從容器執行掛載操作時才需要，而不是從 AppService 的配置中；但我想涵蓋所有假設）
• 託管 ASE 位於該UK South區域中（儲存帳戶/所有資源也是如此）。

注意：這是我在 App Service 中執行容器的第一次體驗；所以PEBKAC絕對是一種可能。

任何建議或故障排除建議將不勝感激。謝謝。

我通過將儲存帳戶的網路從selected networks（我已將 ASE 的 VNet 和 Web 應用程序的出站 IP 列入白名單）更改為all networks通過門戶解決了該問題：

https://portal.azure.com/#@<myTentantName>.onmicrosoft.com/resource/subscriptions/<mySubscrption>/resourceGroups/<myStorageAccountsResourceGroup>/providers/Microsoft.Storage/storageAccounts/<myStorageAccountName>/networking

然後我重新啟動了我的應用程序（包括刪除和重新添加安裝……不確定是否需要，但為了好的措施）：

# stop the web app
az webapp stop \
   --subscription <sub id> \
   -g <resourcegroup> \
   -n <sitename> 

# drop the existing path mapping
az webapp config storage-account delete \
   --subscription <sub id> \
   -g <resourcegroup> \
   -n <sitename> \
   --custom-id <path-mapping-name> \

# re-add the path mapping
az webapp config storage-account add \
   --subscription <sub id> \
   -g <resourcegroup> \
   -n <sitename> \
   --custom-id <path-mapping-name> \
   --storage-type AzureFiles \
   --account-name [Azure storage account name] \
   --share-name   [Azure storage share name] \
   --access-key   [storage access key] \
   --mount-path   [/path/to/mount within the container] 

# restart the web app
az webapp start \
   --subscription <sub id> \
   -g <resourcegroup> \
   -n <sitename> 

引用自：https://serverfault.com/questions/1086197