在 Azure 容器執行個體中針對常見問題進行疑難排解

發行項
08/29/2024

本文說明如何針對管理或將容器部署到 Azure 容器執行個體的常見問題，進行疑難排解。另請參閱常見問題集。

如果您需要更多支援，請參閱 Azure 入口網站中的可用 [說明 + 支援] 選項。

容器群組部署期間的問題

命名規範

定義您的容器規格時，特定參數需要遵循命名限制。下表顯示容器群組屬性的特定需求。如需詳細資訊，請參閱 Azure 架構中心的命名慣例和 Azure 資源的命名規則和限制。

範圍	長度	大小寫	有效字元	建議模式	範例
容器名稱 ¹	1-63	小寫	除了第一個或最後一個字元以外，都可以使用英數字元和連字號	`<name>-<role>-container<number>`	`web-batch-container1`
容器連接埠	介於 1 到 65535 之間	整數	介於 1 到 65535 之間的整數	`<port-number>`	`443`
DNS 名稱標籤	5-63	不區分大小寫	除了第一個或最後一個字元以外，都可以使用英數字元和連字號	`<name>`	`frontend-site1`
環境變數	1-63	不區分大小寫	除了第一個或最後一個字元以外，都可以使用英數字元和底線 (_)	`<name>`	`MY_VARIABLE`
磁碟區名稱	5-63	小寫	除了第一個或最後一個字元以外，都可以使用英數字元和連字號。不能包含兩個連續連字號。	`<name>`	`batch-output-volume`

¹當未指定獨立於容器執行個體時，容器群組名稱也會受到限制，例如 az container create 命令部署。

不支援映像的 OS 版本

如果您指定 Azure 容器執行個體不支援的映像，則會傳回 OsVersionNotSupported 錯誤。錯誤會類似下面內容，其中 {0} 是您嘗試部署的映像名稱：

{
  "error": {
    "code": "OsVersionNotSupported",
    "message": "The OS version of image '{0}' is not supported."
  }
}

部署以半年通道版本 1709 或 1803 (已不支援) 為基礎的 Windows 映像時，最常發生此錯誤。如需 Azure 容器執行個體中支援的 Windows 映像，請參閱常見問題集。

無法提取映像

如果 Azure 容器執行個體一開始無法提取映像，則會重試一段時間。如果映像提取作業持續發生失敗，ACI 最終會停止部署，而且您可能會看到 Failed to pull image 錯誤。

若要解決此問題，請刪除容器執行個體並重試您的部署。請確定此映像存在在登錄中，而且您已輸入正確的映像名稱。

如果無法提取映像，便會在 az container show 輸出中顯示如下事件：

"events": [
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "Pulling",
    "type": "Normal"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "Failed to pull image \"mcr.microsoft.com/azuredocs/aci-hellowrld\": rpc error: code 2 desc Error: image t/aci-hellowrld:latest not found",
    "name": "Failed",
    "type": "Warning"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:20+00:00",
    "lastTimestamp": "2017-12-21T22:57:16+00:00",
    "message": "Back-off pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "BackOff",
    "type": "Normal"
  }
],

資源無法使用錯誤

Azure 中有各種不同的地區資源負載，因此您在嘗試部署容器執行個體時，可能會收到下列錯誤訊息：

The requested resource with 'x' CPU and 'y.z' GB memory is not available in the location 'example region' at this moment. Please retry with a different resource request or in another location.

此錯誤訊息表示您嘗試執行部署產品的地區負載過重，因此當時無法配置您為容器指定的資源。執行下列一或多個風險降低步驟有助於解決問題。

確認容器部署設定是否位於 Azure Container Instances 地區可用性所定義的參數範圍內
為容器指定較低階的 CPU 和記憶體設定
部署至其他 Azure 地區
過一段時間再部署

容器群組執行階段期間的問題

容器已隔離重新開機，且沒有明確的使用者輸入

容器群組在沒有明確的使用者輸入情況下，重新開機的原因有兩種廣泛類別。首先，容器可能會遇到應用程式程序當機所造成的重新開機。 ACI 服務建議利用 Application Insights SDK、容器群組計量和容器群組記錄等可檢視性解決方案，以判斷應用程式發生問題的原因。其次，客戶可能會因為維護事件而遇到 ACI 基礎結構所起始的重新開機。若要增加應用程式的可用性，請在輸入元件後面執行多個容器群組，例如應用程式閘道或流量管理員。

容器不斷結束又重新啟動 (沒有長時間執行的程序)

容器群組的重新啟動原則預設為 [一律]，因此容器群組中的群組在執行完成後一律會重新啟動。如果您要執行以工作為基礎的容器，則可能需要將此設定變更為 [OnFailure] 或 [永不]。如果指定 OnFailure 後仍持續重新啟動，可能是容器中執行的應用程式或指令碼的問題。

如果執行的容器群組不含長時間執行的程序，您可能會看到 Ubuntu 或 Alpine 之類的映像重複地結束並重新啟動。透過 EXEC 連線是不可行的，因為容器沒有任何程序可維持其存留狀態。若要解決此問題，請依照下列範例加入啟動命令，使您的容器群組部署讓容器持續執行。

## Deploying a Linux container
az container create -g MyResourceGroup --name myapp --image ubuntu --command-line "tail -f /dev/null"

## Deploying a Windows container
az container create -g myResourceGroup --name mywindowsapp --os-type Windows --image mcr.microsoft.com/windows/servercore:ltsc2019
 --command-line "ping -t localhost"

容器執行個體 API 和 Azure 入口網站都包含 restartCount 屬性。若要檢查容器的重新啟動次數，可以在 Azure CLI 中使用 az container show 命令。在下列範例輸出中 (為簡潔起見已截斷畫面)，您可以在輸出的結尾看到 restartCount 屬性。

...
 "events": [
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:06+00:00",
     "lastTimestamp": "2017-11-13T21:20:06+00:00",
     "message": "Pulling: pulling image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Pulled: Successfully pulled image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Created: Created container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Started: Started container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   }
 ],
 "previousState": null,
 "restartCount": 0
...
}

注意

Linux 散發套件的大部分容器映像都會設定殼層 (例如 bash) 來作為預設命令。因為殼層本身不是長時間執行的服務，當設定為預設的 Always 重新啟動原則時，這些容器會立即結束並落入重新啟動迴圈。

容器要等很久才會啟動

在 Azure 容器執行個體中，影響容器啟動時間的三個主要因素如下：

映像大小
映像位置
快取的映像

Windows 映像有進一步的考量。

影像大小

如果您的容器要等很久才會啟動，但最終還是會啟動成功，請先看看您的容器映像大小。因為 Azure Container Instances 會視需要來提取您的容器映像，因此啟動時間的長短會與其大小直接相關。

您可以在 Docker CLI 中使用 docker images 命令來檢視容器映像的大小：

docker images

REPOSITORY                                    TAG       IMAGE ID        CREATED          SIZE
mcr.microsoft.com/azuredocs/aci-helloworld    latest    7367f3256b41    15 months ago    67.6MB

讓映像不會變得太大的關鍵在於，確保最終的映像不會包含執行階段所不需要的任何項目。若要做到這一點，有一種方式是使用多階段建置。多階段建置可讓您輕鬆地確保最終映像只包含應用程式所需的構件，而不會包含建置階段所需的任何額外內容。

映像位置

另一種可在容器啟動階段降低對於映像提取作業影響的方式，是在您想要部署容器執行個體的相同區域中，將容器映像裝載在 Azure Container Registry 中。這種方式會縮短容器映像需要經過的網路路徑，從而大幅縮短下載時間。

快取的映像

針對根據常見 Windows 基礎映像 (包含 nanoserver:1809、servercore:ltsc2019 和 servercore:1809) 建立的映像，Azure 容器執行個體使用的快取機制有助於加快容器啟動時間。常用的 Linux 映像，例如 ubuntu:1604 和 alpine:3.6 也會快取。針對 Windows 和 Linux 映像，請避免使用 latest 標籤。如需指引，請參閱 Container Registry 的映像標籤最佳做法。如需快取映像和標記的最新清單，請使用清單快取映像 API。

注意

在 Azure 容器執行個體中使用以 Windows Server 2019 為基礎的映像是預覽功能。

Windows 容器會降低網路整備速度

在初始建立時，Windows 容器可能最多 30 秒 (或更長，但很罕見) 沒有任何輸入或輸出連線。如果您的容器應用程式需要網際網路連線，請新增延遲，然後重試邏輯，以允許有 30 秒的時間來建立網際網路連線。初始安裝之後，容器網路應該就可以正常繼續運作。

無法連線到基礎 Docker API 或執行具有特殊權限的容器

Azure 容器執行個體不會公開基礎結構 (其中裝載容器群組) 的直接存取。這包括存取容器執行階段、協調流程技術，以及執行特殊權限容器作業。若要查看 ACI 支援哪些作業，請查看 REST 參考文件。如果有遺漏的項目，請在 ACI 意見反應論壇上提交要求。

容器群組 IP 位址可能因為連接埠不相符而無法存取

Azure 容器執行個體尚不支援連接埠對應，例如使用一般 Docker 組態。如果您發現容器群組的 IP 位址無法存取 (但您認為應可存取)，請確定已將容器映像設定為接聽您在容器群組中使用 ports 屬性公開的相同連接埠。

如果您想要確認 Azure 容器執行個體可以接聽您在容器映像中設定的連接埠，請測試公開端口的 aci-helloworld 映像部署。也請執行 aci-helloworld 應用程式，使其接聽連接埠。 aci-helloworld 接受選擇性環境變數 PORT 來覆寫其接聽的預設連接埠 80。例如，若要測試連接埠 9000，請在建立容器群組時設定環境變數：

設定容器群組以公開連接埠 9000，並將連接埠號碼傳遞為環境變數的值。範例會針對 Bash Shell 加以格式化。如果您慣用其他殼層，例如 PowerShell 或是命令提示字元，您需要相應調整變數指派。
```
az container create --resource-group myResourceGroup \
--name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld \
--ip-address Public --ports 9000 \
--environment-variables 'PORT'='9000'
```
在 az container create 的命令輸出中尋找容器群組的 IP 位址。尋找 ip 值。
成功佈建容器之後，瀏覽至瀏覽器中容器應用程式的 IP 位址和連接埠，例如：192.0.2.0:9000。

您應該會看到 Web 應用程式所顯示的「歡迎使用 Azure 容器執行個體！」訊息。
當容器使用完畢後，使用 az container delete 命令來移除容器：
```
az container delete --resource-group myResourceGroup --name mycontainer
```

機密容器群組部署期間的問題

使用自訂 CCE 原則時的原則錯誤

必須透過 Azure CLI confcom 延伸模組產生自訂 CCE 原則。產生原則之前，請確定 ARM 範本中指定的所有屬性都是有效的，且符合您在機密計算原則中預期呈現的內容。要驗證的某些屬性包括容器映像、環境變數、磁碟區掛接和容器命令。

原則中遺漏的雜湊

Azure CLI confcom 延伸模組會在本機機器上使用快取的映像，這些映像可能與可從遠端取得的映像不符，而可能會在驗證原則時造成圖層不相符。確定您移除所有舊的映像，並將最新的容器映像提取至本機環境。確定擁有最新的 SHA 之後，您應該重新產生 CCE 原則。

程序/容器已中止，結束代碼：139

因為 Ubuntu 22.04 版基礎映像的限制，因此會出現此結束代碼。建議使用不同的基礎映像以解決此問題。

下一步

深入了解如何擷取容器記錄和事件，以協助針對您的容器進行偵錯。

共用方式為