故障診斷 AWS Cloud9 - AWS Cloud9

AWS Cloud9 不再提供給新客戶。的現有客戶 AWS Cloud9 可以繼續正常使用服務。進一步了解

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

故障診斷 AWS Cloud9

使用下列資訊來識別和解決 的問題 AWS Cloud9。

如果您的問題未列於其中,或者,如果您需要額外協助,請參閱 AWS Cloud9 開發論壇。當您進入此論壇時,您可能需要登入。您也可以直接聯絡我們

Installer (安裝程式)

下一節概述與安裝程式相關的 AWS Cloud9 疑難排解問題。

AWS Cloud9 安裝程式掛起或失敗

問題:當您下載並執行 AWS Cloud9 安裝程式 時,會發生一或多個錯誤,而且安裝程式指令碼不會顯示 Done

原因: AWS Cloud9 安裝程式遇到一或多個錯誤,無法從中復原並因此失敗。

解決方案:如需詳細資訊,請參閱 AWS Cloud9 安裝程式疑難排解。請參閱所提供的常見問題、可能的原因,以及建議解決方案。

AWS Cloud9 安裝程式在顯示以下內容後仍未完成:「Package Cloud9 IDE 1」

問題: AWS Cloud9 安裝在現有的 Amazon EC2執行個體或您自己的伺服器上,作為建立SSH開發環境的一部分。在AWS Cloud9 安裝程式對話方塊中看到此訊息後,安裝會停止:「Package Cloud9 IDE 1」。如果您選擇 Cancel (取消),您會看到下列訊息:「安裝失敗。」 當 AWS Cloud9 套件無法安裝在客戶的SSH主機時,就會發生此錯誤。

原因:SSH主機要求您安裝 Node.js。建議您安裝最新的 Node.js 主機作業系統支援的版本。如果您有 的版本 Node.js 在 AWS Cloud9 不支援的主機上,可能會發生安裝錯誤。

建議的解決方案:在SSH主機上安裝 AWS Cloud9 支援的 Node.js 版本。

無法安裝相依性

問題: AWS Cloud9 需要網際網路存取才能下載相依性。

可能原因:

  • 如果您的 AWS Cloud9 環境使用代理來存取網際網路, AWS Cloud9 需要代理詳細資訊才能安裝相依性。如果您沒有將代理詳細資訊提供給 AWS Cloud9,則會出現此錯誤。

  • 如果您的環境不允許傳出流量,則可能是另一個原因。

建議解決方案:

  • 若要將代理詳細資訊提供給 AWS Cloud9,請將下列程式碼附加至您的環境~/.bashrc檔案:

    export http_proxy=[proxy url for http] export https_proxy=[proxy url for https] #Certificate Authority used by your proxy export NODE_EXTRA_CA_CERTS=[path_to_pem_certificate]

    例如,如果您的HTTP代理URL是 https://172.31.26.80:3128,而您的HTTP代理URL是 https://172.31.26.80:3129,請將以下行新增至您的~/.bashrc檔案,並NODE_EXTRA_CA_CERTS設定為憑證授權機構檔案的路徑PEM。如需此變數的詳細資訊,請參閱 https://nodejs.org/api/cli.html#node_extra_ca_certsfile

    export http_proxy=http://172.31.26.80:3128 export https_proxy=https://172.31.26.80:3129 export NODE_EXTRA_CA_CERTS=[path_to_pem_certificate]
  • 如果您使用的是無輸入 Amazon EC2執行個體,則必須確保已設定 Amazon S3 的 Amazon VPC端點。如需詳細資訊,請參閱為 Amazon S3 下載相依性設定 Amazon VPC端點。

SSH 環境錯誤:「需要 Python 第 3 版才能安裝 pty.js」

問題:開啟 AWS Cloud9 SSH開發環境後, 中的 AWS Cloud9 IDE終端機會顯示以「Python 第 3 版是安裝 pty.js 所需的訊息。」

原因:若要如預期般運作,SSH環境需要安裝 Python 第 3 版。

解決方案:在 環境中安裝 Python 第 3 版。若要檢查您的版本,請從伺服器的終端機執行 python --version 命令。若要在伺服器上安裝 Python 3,請參閱下列其中一項:

AWS Cloud9 環境

下一節概述與環境相關的 AWS Cloud9 疑難排解問題。

環境建立錯誤:「我們無法建立EC2執行個體...」

問題:當您嘗試建立 AWS Cloud9 開發環境時,會出現一則訊息,其中含有「我們無法在帳戶驗證和啟用期間在您的帳戶中建立EC2執行個體」一詞。

原因: AWS 目前正在驗證和啟用您的 AWS 帳戶。啟用完成前 (最多可能需要 24 小時),您都無法建立這個執行個體或其他環境。

解決方案: 嘗試稍候重新建立環境。如果您在 24 小時後仍收到此訊息,請聯絡 支援。此外,請務必了解,即使嘗試建立環境失敗, AWS CloudFormation 仍會在您的帳戶中建立相關的堆疊。這些堆疊會計入您帳戶的堆疊建立配額中。為了避免耗盡堆疊建立配額,您可以刪除這些失敗的堆疊。如需詳細資訊,請參閱 AWS CloudFormation 使用者指南中的刪除 AWS CloudFormation 主控台的堆疊

環境建立錯誤:「未授權執行 sts:AssumeRole」

問題:當您嘗試建立新環境時,您會看到此錯誤:「未授權執行 sts:AssumeRole,」,且環境未建立。

可能原因:您的 中不存在 AWS Cloud9 服務連結角色 AWS 帳戶。

建議的解決方案:在您的 中建立 AWS Cloud9 服務連結角色 AWS 帳戶。您可以在 AWS Command Line Interface (AWS CLI) 或 AWS CloudShell中執行下列命令,即可執行這項操作。

aws iam create-service-linked-role --aws-service-name cloud9.amazonaws.com # For the AWS CLI. iam create-service-linked-role --aws-service-name cloud9.amazonaws.com # For the aws-shell.

如果您無法執行此操作,請洽詢您的 AWS 帳戶 管理員。

執行上述命令後,再次嘗試建立環境。

聯合身分無法建立環境

問題:當您嘗試使用 AWS 聯合身分來建立 AWS Cloud9 開發環境時,會顯示存取錯誤訊息,而且不會建立環境。

原因:: AWS Cloud9 使用服務連結角色。在帳戶中使用 iam:CreateServiceLinkedRole 呼叫首次建立環境後,服務連結角色會隨之建立。不過,聯合使用者無法呼叫 IAM APIs。如需詳細資訊,請參閱 參考 GetFederationTokenAWS Security Token Service API中的

解決方案:請 AWS 帳戶 管理員在IAM主控台中建立服務連結角色 AWS Cloud9 ,或使用 AWS Command Line Interface (AWS CLI) 執行此命令:

aws iam create-service-linked-role --aws-service-name cloud9.amazonaws.com

或者此命令具有 AWS-shell:

iam create-service-linked-role --aws-service-name cloud9.amazonaws.com

如需詳細資訊,請參閱 IAM 使用者指南 中的使用服務連結角色

主控台錯誤:「User is not authorized to perform action on resource」(使用者未獲授權對資源執行動作)

問題:當您嘗試使用 AWS Cloud9 主控台建立或管理 AWS Cloud9 開發環境時,您會看到錯誤,其中包含類似於「使用者arn:aws:iam::123456789012:user/MyUser無權cloud9:action在資源 上執行」的片語arn:aws:cloud9:us-east-2:123456789012:environment:12a34567b8cd9012345ef67abcd890e1,其中:

  • arn:aws:iam::123456789012:user/MyUser 是請求使用者的 Amazon Resource Name (ARN)。

  • action 是接收請求之使用者的操作名稱。

  • arn:aws:cloud9:us-east-2:123456789012:environment:12a34567b8cd9012345ef67abcd890e1 是使用者請求執行操作的環境ARN的 。

原因:您使用 登入 AWS Cloud9 主控台的使用者沒有執行動作的正確 AWS 存取權限。

解決方案:確認使用者具備正確的 AWS 存取許可,然後再次嘗試執行該動作。如需詳細資訊,請參閱下列內容:

無法連線到環境

問題:使用者無法連接到環境,停滯在「連接」階段。

原因:如果您變更~/ .ssh/authorized_keys檔案的許可、從該檔案中移除 AWS Cloud9 金鑰,或完全移除檔案,可能會發生此問題。

解決方案:不要刪除此檔案。如果您刪除它,則必須重新建立您的環境,並且可能需要將現有環境的EBS磁碟區連接到新EC2環境。這是為了擷取遺失的資料。如果缺少許可,請確保檔案具有 Read-Write 許可。這是為了允許SSH常駐程式讀取它。

無法開啟環境

問題:當您嘗試開啟環境時, IDE不會顯示超過五分鐘。

可能原因:

  • 登入 AWS Cloud9 主控台IAM的使用者沒有開啟環境所需的 AWS 存取權限。

  • 如果環境與 AWS 雲端運算執行個體 (例如 Amazon EC2執行個體) 相關聯,則可能為真:

    • 與執行個體VPC相關聯的 未設定為 的正確設定 AWS Cloud9。

    • 當 AWS Cloud9 嘗試連線至執行個體時,執行個體正在狀態之間轉換或自動狀態檢查失敗。

  • 如果環境是SSH環境,則相關聯的雲端運算執行個體或您自己的伺服器未正確設定,以允許 AWS Cloud9 存取它。

建議解決方案:

  • 確定登入 AWS Cloud9 主控台IAM的使用者具有開啟環境所需的 AWS 存取權限。然後再次嘗試開啟環境。如需詳細資訊,請參閱以下內容或洽詢您的 AWS 帳戶 管理員:

    如果登入IAM的使用者仍然無法開啟環境,請嘗試登出,然後以 AWS 帳戶 根使用者或帳戶中的管理員使用者身分重新登入。然後再次嘗試開啟環境。如果您無法以這種方式開啟環境,則使用者IAM存取許可很可能發生問題。

  • 如果環境與 AWS 雲端運算執行個體 (例如 Amazon EC2執行個體) 相關聯,請執行下列動作:

  • 如果環境是SSH環境,請確定與其或您自己的伺服器相關聯的雲端運算執行個體已正確設定, AWS Cloud9 以允許其存取。然後再次嘗試開啟環境。如需詳細資訊,請參閱SSH 環境主機需求

無法開啟 AWS Cloud9 環境:「協作者目前無法存取此環境。Please wait until the removal of managed temporary credentials is complete, or contact the owner of this environment.」(此環境目前無法供協作者存取。請等候受管臨時憑證的移除作業完成,或連絡此環境的擁有者。)

問題:如果由非環境擁有者的人員將新的協作者新增至環境,則停用受 AWS 管臨時憑證。憑證會因您刪除 ~/.aws/credentials 檔案而停用。刪除~/.aws/credentials檔案時,新協作者無法存取 AWS Cloud9 環境。

原因:在 AWS 受管臨時憑證刪除過程中防止環境遭存取是一種安全性措施。這樣可讓環境擁有者確認只有受信任的協作者才能存取受管憑證。如果環境擁有者認為協作者名單沒有問題,就可以重新啟用受管憑證,讓憑證可以共用。如需詳細資訊,請參閱控制 AWS 受管臨時憑證的存取權

建議的解決方案:等待~/.aws/credentials檔案完全刪除,然後再嘗試開啟 AWS Cloud9 環境。憑證到期的最長等待時間為 15 分鐘。或者,請要求環境擁有者重新啟用或停用受管臨時憑證。重新啟用或停用憑證之後,協作者就可以立即存取環境。透過將受管憑證的狀態切換到 ENABLED或 DISABLED,環境擁有者可確保憑證不會保持在中繼狀態。中繼統計資料可以防止協作者存取環境。

注意

假設環境擁有者和協同合作者屬於同一個 AWS 帳戶。然後,協作者可以在主控台的 Your environments (您的環境) 頁面查看環境卡片,藉此找到要聯絡的環境擁有者。環境擁有者也會列在 Environment details (環境詳細資訊) 頁面上。

環境刪除錯誤:「One or more environments failed to delete」(無法刪除一或多個環境)

問題:當您嘗試刪除 AWS Cloud9 主控台中的一或多個環境時,會顯示一則訊息,其中顯示「一或多個環境無法刪除」,而且至少有一個環境不會刪除。

可能的原因: AWS CloudFormation 刪除一或多個環境時可能會有問題。 AWS Cloud9 依賴 AWS CloudFormation 來建立和刪除環境。

建議的解決方案:嘗試使用 AWS CloudFormation 刪除每個未刪除的環境。

  1. https://console.aws.amazon.com/cloudformation 開啟 AWS CloudFormation 主控台。

  2. 在 AWS 導覽列上,選擇環境 AWS 區域 的 。

  3. 在 AWS CloudFormation 堆疊清單中,選取堆疊名稱包含未刪除環境名稱的項目,狀態DELETE_FAILED。例如,如果環境名稱為 my-demo-environment,請選擇以 name aws-cloud9-my-demo-environment 開頭的堆疊。(請選擇環境名稱旁的方塊或選項,而非環境名稱本身。)

  4. 選擇 Actions (動作)、Delete Stack (刪除堆疊)

  5. 出現提示時,選擇 Yes, Delete (是,刪除)

刪除堆疊的程序可能需要幾分鐘的時間。

如果堆疊從清單中消失,則表示環境已刪除。

如果堆疊在幾分鐘後仍顯示 DELETE_FAILED,則環境仍未刪除。您可以嘗試手動刪除已失敗堆疊的每個資源。

注意

手動刪除失敗堆疊的資源不會從您的 中移除堆疊本身 AWS 帳戶。

若要手動刪除這些資源,請執行下列動作。在 AWS CloudFormation 主控台中,選擇失敗的堆疊,然後選擇資源區段。針對此清單中 AWS 的每個資源前往 中的主控台,然後使用該主控台刪除資源。

在 中變更環境的逾時時間 AWS Cloud9 IDE

問題:使用者想要更新 Amazon EC2環境的逾時時間。

原因:預設逾時時間為 30 分鐘。對於某些使用者而言,這可能太短。

建議解決方案:

  1. 開啟您要設定的環境。

  2. AWS Cloud9 IDE的選單列中,選擇AWS Cloud9偏好設定

  3. 偏好設定視窗中,捲動至 Amazon EC2執行個體區段。

  4. 從可用清單中選取逾時值並更新。

在 AWS Toolkit 中本機執行SAM應用程式時發生錯誤,因為 AWS Cloud9 環境沒有足夠的磁碟空間

問題:當您使用 AWS Toolkit 為SAM範本定義的應用程式執行 AWS SAM CLI命令時發生錯誤。

可能原因:當您使用 AWS Toolkit 在本機執行和偵錯無伺服器應用程式時, AWS SAM 會使用 Docker 映像。這些映像提供執行時間環境和建置工具,而這些工具會模擬您計劃要部署至其中的 Lambda 環境。

不過,如果您的環境沒有足夠的磁碟空間,Docker 提供這些功能的映像無法建置,且您的本機SAM應用程式無法執行。如果發生這個問題,您可能會在 Output (輸出) 索引標籤收到錯誤,內容如下。

Error: Could not find amazon/aws-sam-cli-emulation-image-python3.7:rapid-1.18.1 image locally and failed to pull it from docker.

此錯誤與使用 Python 執行期建置SAM的應用程式有關。根據您為應用程式選擇的執行時間而定,您收到的訊息可能稍有不同。

建議的解決方案:釋放環境中的磁碟空間,讓 Docker 映像可以建置。移除任何未使用的 Docker 映像,方法是在 IDE的終端機中執行下列命令。

docker image prune -a

如果您因為磁碟空間限制而反覆遇到SAMCLI命令問題,則切換至開發環境會使用不同的執行個體類型

(回到頁首)

無法使用IDE舊版 載入 Microsoft Edge 瀏覽器

問題:嘗試使用 載入 AWS Cloud9 IDE時傳回HTTP403: FORBIDDEN錯誤 Microsoft Edge 網頁瀏覽器。

可能原因: AWS Cloud9 IDE不支援特定舊版 的 Microsoft Edge.

建議的解決方案:若要更新瀏覽器,請選擇 中的省略號 (...) 按鈕 Microsoft Edge 工具列。從功能表中,選擇設定,然後選擇關於 Microsoft Edge。 如果需要更新,會自動下載並安裝。

(回到頁首)

無法在 AWS Cloud9 IDE File Explorer 中建立子資料夾結構 /home/ec2-user/environment/home/ec2-user/environment

問題:在 File Explorer 中 AWS Cloud9 IDE建立子資料夾結構 /home/ec2-user/environment/home/ec2-user/environment 時,您會收到錯誤訊息,指出無法開啟此目錄。

可能原因:目前無法使用 的檔案系統在相同名稱的資料夾中建立子資料夾結構/home/ec2-user/environment AWS Cloud9 IDE。您將無法從 File Explorer AWS Cloud9 IDE存取此目錄中的任何檔案,但您可以使用命令列存取這些檔案。此問題只會影響檔案路徑 /home/ec2-user/environment/home/ec2-user/environment,例如 /test/home/ec2-user/environment/home/ec2-user/environment/test 等檔案路徑應正常運作。這是已知問題,只會影響 AWS Cloud9 IDE File Explorer。

建議解決方案:使用不同的檔案名稱和結構。

(回到頁首)

無法在 AWS Cloud9 IDE的 File Explorer 中建立子資料夾結構/專案/專案 CodeCatalyst。

問題:當您在 File Explorer 中 AWS Cloud9 IDE為 建立子資料夾結構/專案/專案時 CodeCatalyst,您會收到錯誤訊息,指出無法開啟此目錄。

可能原因:目前無法使用 的 File Explorer AWS Cloud9 IDE 在相同名稱的資料夾內建立子資料夾結構/專案 CodeCatalyst。您將無法從 File Explorer AWS Cloud9 IDE存取此目錄中的任何檔案,但您可以使用命令列存取這些檔案。此問題只會影響檔案路徑 /projects/projects/test/projects/projects/test 等檔案路徑應該可以運作。這是已知問題,只會影響 的 AWS Cloud9 IDE File Explorer CodeCatalyst。

建議解決方案:使用不同的檔案名稱和結構。

(回到頁首)

因為 tmux 工作階段發生錯誤,所以無法與 AWS Cloud9 中的終端機視窗互動。

問題:嘗試在 中啟動新的終端機視窗時 AWS Cloud9,無法使用預期的命令列介面。沒有命令提示字元,您無法輸入文字。系統會傳回諸如 tmux: need UTF-8 locale (LC_CTYPE)invalid LC_ALL, LC_CTYPE or LANG 等錯誤訊息。

可能原因:無回應的終端機可能是由 tmux 錯誤所造成。 AWS Cloud9 會使用 tmux 公用程式。如此,顯示在終端機中的資訊,即使在頁面重新載入或您重新連線至開發環境時也會持續存在。

tmux 工作階段中,終端機視窗中顯示的內容會由用戶端處理。用戶端會與可管理多個工作階段的伺服器通訊。伺服器和用戶端會透過位於 tmp 資料夾中的通訊端進行通訊。如果 tmp 資料夾在開發環境中遺失,或者套用了過於嚴格的許可,tmux 工作階段就無法執行。如果發生這種情況, 中的終端機視窗IDE會變得無回應。

建議的解決方案:如果 tmux 錯誤使您無法與終端機視窗互動,請使用替代方式來建立具有適當許可的 tmp 資料夾。這樣,tmux 工作階段就能執行。其中一種解決方法是在 .bash_profile.bashrc 檔案中匯出 LC_CTYPE。另一個建議的解決方案是使用 AWS Systems Manager 來設定主機管理組態。這允許透過 Amazon EC2主控台存取相關執行個體。

設定主機管理

  1. 首先,在 AWS Cloud9 主控台中尋找環境執行個體的名稱。若要這麼做,請選擇 Your environments (您的環境) 中的相關面板,並選擇 View details (檢視詳細資訊)。在 Environment details (環境詳細資訊) 頁面中,選擇 Go to Instance (前往執行個體)。在 Amazon EC2主控台中,確認您需要存取的執行個體名稱。

  2. 現在請前往 AWS Systems Manager 主控台,然後在導覽窗格中,選擇快速設定

  3. Quick Setup (快速設定) 頁面中,選擇 Create (建立)。

  4. 對於 Configuration types (組態類型),前往 Host Management (主機管理),然後選擇 Create (建立)。

  5. 對於 Customize Host Management configuration options (自訂主機管理組態選項),在 Targets (目標) 區段中,選擇 Manual (手動)。

  6. 選取您要存取的EC2執行個體,然後選擇建立

連線至執行個體並執行命令

注意

下列步驟適用於新的EC2主控台。

  1. 在 Amazon EC2主控台的導覽窗格中,選擇執行個體,然後選取您要連線的執行個體。

  2. 選擇連線

    如果 Connect (連線) 並未啟用,您可能需要先啟動該執行個體。

  3. Connect to your instance (連線至您的執行個體) 窗格中,對於 Connection method (連線方法),選擇 Session Manager (工作階段管理員),然後選擇 Connect (連線)。

  4. 在出現的終端機工作階段視窗中,輸入下列指令。這些命令會建立具有適當許可的 tmp 資料夾,讓 tmux 通訊端可供使用。

    sudo mkdir /tmp sudo chmod 777 /tmp sudo rmdir /tmp/tmux-*

(回到頁首)

Amazon EC2

下節概述與 Amazon 相關的疑難排解問題EC2。

Amazon EC2執行個體不會自動更新

問題:最近的系統更新不會自動套用至連線至 AWS Cloud9 開發環境的 Amazon EC2執行個體。

原因:自動套用最近的系統更新可能會導致程式碼或 Amazon EC2執行個體以非預期的方式運作,而無需事先了解或核准。

建議解決方案:

遵循 Amazon 使用者指南 中的更新EC2執行個體軟體指示,定期將系統更新套用至 Amazon 執行個體。 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/install-updates.html EC2

若要在執行個體上執行命令,您可以從連線至執行個體的環境使用 AWS Cloud9 IDE中的終端機工作階段。

或者,您可以使用SSH遠端存取公用程式,例如 ssh 或 PuTTY 連線到執行個體。若要這麼做,請從本機電腦使用SSH金鑰對建立公用程式,例如 ssh-keygen 或 PuTTYgen。 使用從連線至執行個體的環境中產生的 AWS Cloud9 IDE,將產生的公有金鑰存放在執行個體上。然後使用SSH遠端存取公用程式以及產生的私有金鑰來存取執行個體。如需詳細資訊,請參閱公用程式的說明文件。

AWS CLI 或 AWS-shell 錯誤:「請求中包含的安全字符無效」EC2環境中

問題:當您嘗試使用 AWS Command Line Interface (AWS CLI) 或 AWS-shell 在 AWS Cloud9 IDE 中針對EC2環境執行命令時,會顯示錯誤:「請求中包含的安全權杖無效」。

原因:如果您已啟用 AWS 受管臨時憑證,且發生下列其中一個事項,就可能產生無效的安全權杖:

  • 您嘗試執行受 AWS 管臨時憑證不允許的命令。如需允許命令的清單,請參閱 受 AWS 管臨時憑證支援的動作

  • AWS 受管臨時憑證會在 15 分鐘後自動過期。

  • 共用環境的 AWS 受管臨時憑證已停用,因為新成員是由環境擁有者以外的其他人新增。

建議解決方案:

  • 僅執行受 AWS 管臨時憑證允許的命令。如果您需要執行受 AWS 管臨時憑證不允許的命令,請在環境中使用一組永久憑證設定 AWS CLI 或 AWS殼層。這可消除此限制。如需說明,請參閱 在環境中建立並存放永久存取憑證

  • 對於停用或過期的憑證,請確保環境擁有者開啟環境,以便 AWS Cloud9 可以重新整理環境中的臨時憑證。如需詳細資訊,請參閱控制 AWS 受管臨時憑證的存取權

無法連線至EC2環境,因為 VPC的 IP 地址已由 使用 Docker

問題:對於EC2環境,如果您將EC2執行個體啟動到VPC使用無IPv4類別網域間路由 (CIDR) 區塊 的 Amazon172.17.0.0/16,則當您嘗試開啟該環境時,連線可能會停止。

原因:Docker 使用名為橋接網路的連結層裝置,可讓連接至相同橋接網路的容器進行通訊。 AWS Cloud9 建立使用預設橋接進行容器通訊的容器。預設橋接器通常會使用 172.17.0.0/16 子網路來進行容器網路連線。

如果您環境執行個體的VPC子網路使用與 已使用的相同地址範圍 Docker,可能發生 IP 地址衝突。因此, AWS Cloud9 當嘗試連線到其執行個體時,該連線會由閘道路由表路由至 Docker 橋接。這 AWS Cloud9 可防止 連線到支援開發環境的EC2執行個體。

建議的解決方案:解決 Amazon VPC和 引起的 IP 地址衝突 Docker 使用相同的IPv4CIDR地址區塊,VPC為EC2環境的執行個體備份設定新的 。對於此新的 VPC,請設定與 不同的CIDR區塊172.17.0.0/16。(您無法變更現有VPC或子網路的 IP 地址範圍。)

如需組態資訊,請參閱 Amazon VPC使用者指南中的 VPC和子網路大小調整。

無法在 AWS Cloud9 IDE File Explorer 中建立子資料夾結構 /home/ec2-user/environment/home/ec2-user/environment

問題:在 File Explorer 中 AWS Cloud9 IDE建立子資料夾結構 /home/ec2-user/environment/home/ec2-user/environment 時,您會收到錯誤訊息,指出無法開啟此目錄。

可能原因:目前無法使用 的檔案系統在相同名稱的資料夾中建立子資料夾結構 /home/ec2-user/environment AWS Cloud9 IDE。您將無法從 File Explorer AWS Cloud9 IDE存取此目錄中的任何檔案,但您可以使用命令列存取這些檔案。此問題只會影響檔案路徑 /home/ec2-user/environment/home/ec2-user/environment,例如 /test/home/ec2-user/environment/home/ec2-user/environment/test 等檔案路徑應正常運作。這是已知問題,只會影響 AWS Cloud9 IDE File Explorer。

建議解決方案:使用不同的檔案名稱和結構。

當授權組態與 Amazon EC2執行個體相關聯時, AWS License Manager 無法 AWS Cloud9 從主控台啟動

問題:當您嘗試從主控台啟動 AWS Cloud9 EC2環境時,unable to access your environment會傳回錯誤訊息。

可能原因: AWS License Manager 簡化跨 的軟體供應商授權管理 AWS 雲端。設定 License Manager 時,您可以建立授權組態,它們是以您的企業協議條款為根據的授權規則集。這些授權組態可以連接到機制,例如 Amazon Machine Image (AMI) 或 AWS CloudFormation。您可以使用其中一個機制來啟動EC2執行個體。

AWSServiceRoleForAWSCloud9 個服務連結角色 (SLR) AWSCloud9ServiceRolePolicy的舊版 目前不包含license-configuration資源條件。因此, AWS Cloud9 不允許啟動和停止其執行個體。因此, AWS Cloud9 拒絕存取其 Amazon EC2執行個體,並傳回錯誤。

建議的解決方案 :如果您無法存取現有 AWS Cloud9 環境並使用 License Manager,請將舊AWSCloud9ServiceRolePolicy的服務連結角色取代為 的版本,當 套用至執行個體時,該版本SLR明確允許 EC2動作。 license-configuration您可以透過直接刪除來取代舊角色。然後,更新過的角色會自動建立。

無法在EC2環境中執行某些命令或指令碼

問題:開啟 AWS Cloud9 EC2開發環境後,您無法安裝某些類型的套件、執行 yum或 等命令apt,或執行包含通常與其他 Linux 作業系統搭配使用之命令的指令碼。

原因: AWS Cloud9 用於EC2環境的 Amazon EC2執行個體依賴於 Amazon Linux (以 Red Hat Enterprise Linux (RHEL) 為基礎) 或 Ubuntu Server。

解決方案:如果您IDE在 中為EC2環境安裝或管理套件或執行命令或指令碼,請確定它們與 RHEL(適用於 Amazon Linux) 或 Ubuntu Server 相容,視該環境的執行個體而定。

使用 建立EC2環境時,報告「執行個體設定檔 AWSCloud9SSMInstanceProfile 不存在」的錯誤訊息 AWS CloudFormation

問題:使用 AWS::Cloud9::EnvironmentEC2 AWS CloudFormation 資源建立EC2環境時,使用者會收到錯誤訊息,指出帳戶中不存在執行個體設定檔 AWSCloud9SSMInstanceProfile。

原因:建立無輸入EC2環境時,您必須建立服務角色AWSCloud9SSMAccessRole和執行個體設定檔 AWSCloud9SSMInstanceProfile。這些IAM資源可讓 Systems Manager 管理支援開發環境的EC2執行個體。

如果您使用主控台建立無輸入環境,AWSCloud9SSMAccessRoleAWSCloud9SSMInstanceProfile 會自動建立。但在使用 AWS CloudFormation 或 AWS CLI 建立第一個無輸入環境時,您必須手動建立這些IAM資源。

建議的解決方案:如需編輯 AWS CloudFormation 範本和更新IAM許可的相關資訊,請參閱 使用 AWS CloudFormation 建立無輸入EC2環境

使用 建立EC2環境時,回報「資源perform: ssm:StartSession上未授權 」的錯誤訊息 AWS CloudFormation

問題:當使用 AWS::Cloud9::EnvironmentEC2 AWS CloudFormation 資源建立EC2環境時,使用者會收到 AccessDeniedException,並會被告知他們「無權在資源ssm:StartSession上執行:」。

原因:使用者缺少呼叫 的許可StartSessionAPI,該 是使用 Systems Manager 進行無輸入執行個體EC2之環境組態的一部分。

建議的解決方案:如需編輯 AWS CloudFormation 範本和更新IAM許可的相關資訊,請參閱 使用 AWS CloudFormation 建立無輸入EC2環境

使用 建立EC2環境時,回報未授權「在資源iam:GetInstanceProfile上執行:執行個體設定檔AWSCloud9SSMInstanceProfile」的錯誤訊息 AWS CLI

問題:使用 AWS CLI建立EC2環境時,使用者會收到 ,AccessDeniedException並會被告知其 AWS Cloud9 環境未獲得「在資源上執行 iam:GetInstanceProfile on 資源:執行個體設定檔 」的授權AWSCloud9SSMInstanceProfile

原因: AWS Cloud9 為使用 Systems Manager 進行無輸入執行個體EC2的環境,授予呼叫組態中StartSessionAPI所需 的許可。

建議的解決方案:如需將所需AWSCloud9SSMAccessRole服務角色 和 AWSCloud9SSMInstanceProfile 新增至 AWS Cloud9 環境的相關資訊,請參閱 使用 管理 Systems Manager 的執行個體設定檔 AWS CLI

將預設加密套用至 Amazon EBS磁碟區時無法建立環境

問題:嘗試建立 Amazon EC2環境時傳回Failed to create environments. The development environment '[environment-ID]' failed to create錯誤。

可能原因:如果您 AWS Cloud9 IDE使用預設加密的 Amazon EBS磁碟區,則 AWS Identity and Access Management AWS Cloud9 的服務連結角色需要存取這些EBS磁碟區的 AWS KMS keys 。如果未提供存取權, AWS Cloud9 IDE可能無法啟動,而且可能很難除錯問題。

建議的解決方案:若要提供存取權,請將 AWS Cloud9、 的服務連結角色新增至 Amazon EBS磁碟區所使用的AWSServiceRoleForAWSCloud9客戶受管金鑰。

如需此任務的詳細資訊,請參閱在規範引導模式 中建立 AWS Cloud9 使用具有預設加密之 Amazon EBS磁碟區的AWS

VPC EC2-Classic 帳戶的錯誤:「無法存取您的環境」

問題:EC2-Classic 已引入 Amazon 的原始版本EC2。如果您使用的 AWS 帳戶 是在 2013 年 12 月 4 日之前設定的,而您在建立 AWS Cloud9 EC2開發環境時未設定 Amazon VPC和子網路,則可能會發生此錯誤。

如果您接受VPC預設設定,Amazon EC2執行個體會啟動至 EC2-Classic 網路。執行個體不會在預設 的子網路中啟動VPC。當建立環境失敗時會顯示下列訊息:

環境錯誤

無法存取您的環境

建立環境失敗,出現錯誤:下列資源無法建立:[執行個體]. . 使用者請求轉返..

您可以確認錯誤是由於EC2執行個體不在預設 中所致VPC。 AWS CloudFormation 使用 檢視開發環境的堆疊事件歷史記錄。

  1. 開啟 AWS CloudFormation 主控台。如需詳細資訊,請參閱登入 AWS CloudFormation 主控台

  2. 在 AWS CloudFormation 主控台中,選擇堆疊

  3. Stacks (堆疊) 頁面上,選擇無法建立的開發環境名稱。

  4. Stack details (堆疊詳細資訊) 頁面上,選擇 Events (事件) 標籤,然後檢查下列項目:

    狀態:CREATE_FAILED

    狀態原因: AssociatePublicIpAddress 參數僅受VPC啟動支援。 【...】

原因: AWS Cloud9 開發環境必須與VPC符合特定VPC要求的 Amazon 建立關聯。對於已啟用 EC2-Classic 的帳戶,在建立EC2環境時接受預設網路設定,表示所需的EC2執行個體不會啟動到 中VPC。相反地,執行個體會啟動至 EC2-Classic 網路。

建議的解決方案:使用 EC2-Classic 帳戶時,您必須在建立EC2環境 時選取 VPC和 子網路。在設定設定頁面的網路設定 (進階) 區段中,選取您可以啟動EC2執行個體的 VPC和子網路。

AWS 其他服務

下一節概述與其他 AWS 服務相關的疑難排解問題。

無法在 的 File Explorer AWS Cloud9 IDE 中建立子資料夾結構/專案/專案 CodeCatalyst。

問題:在 File Explorer 中 AWS Cloud9 IDE建立子資料夾結構/專案/專案時 CodeCatalyst,您會收到錯誤訊息,指出無法開啟此目錄。

可能的原因:目前無法使用 的 File Explorer AWS Cloud9 IDE 在相同名稱的資料夾內建立子資料夾結構/專案 CodeCatalyst。您將無法從 File Explorer AWS Cloud9 IDE存取此目錄中的任何檔案,但您可以使用命令列存取這些檔案。此問題只會影響檔案路徑 /projects/projects/test/projects/projects/test 等檔案路徑應該可以運作。這是已知問題,只會影響 的 AWS Cloud9 IDE File Explorer CodeCatalyst。

建議解決方案:使用不同的檔案名稱和結構。

無法在 之外顯示您執行中的應用程式 IDE

問題:當您或其他人嘗試在 以外的 Web 瀏覽器索引標籤中顯示執行中的應用程式時IDE,該 Web 瀏覽器索引標籤會顯示錯誤,或該索引標籤為空白。

可能原因:

  • 應用程式未在 中執行IDE。

  • 應用程式使用 IP 127.0.0.1localhost 執行。

  • 應用程式正在開發環境中執行 AWS Cloud9 EC2。此外,與對應 Amazon EC2執行個體相關聯的一或多個安全群組不允許透過應用程式所需的通訊協定、連接埠或 IP 地址傳入流量。

  • 應用程式正在 AWS 雲端運算執行個體 (例如 Amazon EC2執行個體) 的開發環境中執行 AWS Cloud9 SSH。此外,與對應執行個體相關聯的虛擬私有雲端 (VPC) ACL子網路網路不允許透過應用程式所需的通訊協定、連接埠或 IP 地址傳入流量。

  • URL 不正確。

  • 正在請求應用程式預覽索引標籤URL中的 ,而不是執行個體的公有 IP 地址。

  • 您正嘗試前往的 IP 地址包含 127.0.0.1localhost。這些IPs嘗試存取本機電腦上的資源,而不是環境中的資源。

  • 執行個體的公有 IP 地址已變更。

  • Web 請求源自虛擬私有網路 (VPN),可封鎖應用程式所需的通訊協定、連接埠或 IP 地址上的流量。

  • 應用程式正在SSH環境中執行。此外,伺服器或相關聯的網路並不允許透過應用程式所需的通訊協定、連接埠或 IP 地址傳送流量。

建議解決方案:

  • 確保應用程式在 中執行IDE。

  • 確認應用程式未使用 IP 127.0.0.1localhost 執行。如需 Node.js 和 Python 方面的範例,請參閱執行應用程式

  • 假設應用程式正在 AWS 雲端運算執行個體 (例如 Amazon EC2執行個體) 上執行。接著,確認對應的執行個體其相關聯的所有安全群組皆允許透過應用程式所需的通訊協定、連接埠及 IP 地址傳入流量。如需相關指示,請參閱透過網際網路共用執行中的應用程式中的步驟 2:為執行個體設定安全群組。另請參閱 Amazon VPC使用者指南 中的 安全群組VPC

  • 假設應用程式正在 AWS 雲端運算執行個體上執行。此外,與對應執行個體VPC相關聯的 子網路ACL存在網路。然後,確保網路ACL允許透過應用程式所需的通訊協定、連接埠和 IP 地址傳入流量。如需相關指示,請參閱透過網際網路共用執行中的應用程式中的步驟 3:為執行個體設定子網路。另請參閱 Amazon VPC使用者指南 中的網路ACLs

  • 確保請求 正確URL,包括通訊協定 (和連接埠,如果必須指定的話)。如需詳細資訊,請參閱透過網際網路共用執行中的應用程式中的步驟 4:共用執行中應用程式的 URL

  • 我們不建議請求 格式URL為 的 https://12a34567b8cd9012345ef67abcd890e1.vfs.cloud9.us-east-2.amazonaws.com/(其中 12a34567b8cd9012345ef67abcd890e1 是 AWS Cloud9 指派給環境的 ID,而 us-east-2是環境 AWS 的區域 ID)。只有在IDE環境的 開啟,且應用程式正在相同的 Web 瀏覽器中執行時,此功能才URL有效。

  • 假設您正嘗試前往的 IP 地址包含 127.0.0.1localhost。改為嘗試前往正確的執行中應用程式非本機地址。如需詳細資訊,請參閱透過網際網路共用執行中的應用程式

  • 假設應用程式正在 AWS 雲端運算執行個體上執行。查明執行個體的公有 IP 地址是否已變更。執行個體的公有 IP 地址可能因執行個體重新啟動而隨時變更。為避免此 IP 地址發生變更,您可以配置彈性 IP 地址,然後將該地址指派給運作中的執行個體。如需詳細資訊,請參閱透過網際網路共用執行中的應用程式中的步驟 4:共用執行中應用程式的 URL

  • 如果 Web 請求來自 VPN,請確保 VPN可允許流量透過應用程式所需的通訊協定、連接埠和 IP 地址。如果您無法變更您的 VPN,請洽詢您的網路管理員。或者如果可行,從其他網路提出 Web 請求。

  • 假設應用程式正在您自己的伺服器SSH環境中執行。確認您的伺服器和相關聯的網路允許透過應用程式所需的通訊協定、連接埠及 IP 地址傳送流量。若您無法對伺服器或相關聯的網路進行變更,請洽詢您的伺服器或網路管理員。

  • 透過執行 curl命令,然後執行 ,嘗試從環境中的終端機執行應用程式URL。如果此命令顯示錯誤訊息,則可能有與 無關的其他問題 AWS Cloud9。

執行 AWS Toolkit 時發生錯誤:「您的環境已用盡 inodes,請提高 'fs.inotify.max_user_watches' 限制。」

問題: AWS Toolkit 使用的檔案監看器公用程式正在接近其可監看檔案的目前限制或配額。

Cause: AWS Toolkit 使用檔案監看器公用程式來監控檔案和目錄的變更。當公用程式幾乎達到目前可監看的檔案數量配額時,會顯示警告訊息。

建議解決方案:若要增加檔案監看員可處理的最大檔案數量,請執行下列動作:

  1. 在選單列上選擇 Window (視窗)、New Terminal (新增終端機),啟動終端機工作階段。

  2. 輸入以下命令。

    sudo bash -c 'echo "fs.inotify.max_user_watches=524288" >> /etc/sysctl.conf' && sudo sysctl -p

Lambda 本機函數執行錯誤:無法安裝SAM本機

問題:嘗試在 中執行本機版本的 AWS Lambda 函數後 AWS Cloud9 IDE,會顯示對話方塊。該對話方塊指出在安裝 SAM Local. AWS Cloud9 needs SAM Local 時 AWS Cloud9 遇到問題,無法在 中執行本機版本的 AWS Lambda 函數IDE。在本機安裝SAM之前,您無法在 中執行本機版本的 Lambda 函數IDE。

原因: AWS Cloud9 在環境中的預期路徑找不到 SAM Local,也就是 ~/.c9/bin/sam。這是因為尚未安裝 SAM Local,或者如果已安裝,則 AWS Cloud9 在該位置找不到它。

建議的解決方案:您可以等待 AWS Cloud9 嘗試完成 SAM Local 安裝,也可以自行安裝。

若要查看嘗試安裝 SAM Local AWS Cloud9 時的運作方式,請在選單列上選擇 Window、 Installer

若要自行安裝 SAM Local,請遵循 開發人員指南中的在 Linux AWS SAMCLI上安裝 中的指示。 AWS Serverless Application Model

AWS Control Tower 嘗試使用 建立 Amazon EC2環境時出現錯誤 AWS Cloud9:「建立環境失敗並出現錯誤:下列 hook(s) 失敗:【ControlTower:Guard::Hook】。」

問題:與 AWS Cloud9 和 AWS Control Tower 主動控制 CT 存在相容性問題EC2。PR.8. 如果啟用此控制項,您就無法在 中建立EC2環境 AWS Cloud9。

Cause: AWS Control Tower 預期AssociatePublicIpAddress參數在 AWS CloudFormation 範本中。目前無法新增此參數。

建議的解決方案:停用 controlCTEC2。從主控台取得 PR.8,然後在 中重新建立環境 AWS Cloud9。 AWS Control Tower

將預設加密套用至 Amazon EBS磁碟區時無法建立環境

問題:嘗試建立 Amazon EC2環境時傳回Failed to create environments. The development environment '[environment-ID]' failed to create錯誤。

可能原因:如果您 AWS Cloud9 IDE使用預設加密的 Amazon EBS磁碟區,則 AWS Identity and Access Management AWS Cloud9 的服務連結角色需要存取這些EBS磁碟區的 AWS KMS keys 。如果未提供存取權, AWS Cloud9 IDE可能無法啟動,而且可能很難除錯問題。

建議的解決方案:若要提供存取權,請將 AWS Cloud9、 的服務連結角色新增至 Amazon EBS磁碟區所使用的AWSServiceRoleForAWSCloud9客戶受管金鑰。

如需此任務的詳細資訊,請參閱在規範引導模式 中建立 AWS Cloud9 使用具有預設加密之 Amazon EBS磁碟區的AWS

(回到頁首)

當授權組態與 Amazon EC2執行個體相關聯時, AWS License Manager 無法 AWS Cloud9 從主控台啟動

問題:當您嘗試從主控台啟動 AWS Cloud9 EC2環境時,unable to access your environment會傳回錯誤訊息。

可能原因: AWS License Manager 簡化跨 的軟體供應商授權管理 AWS 雲端。設定 License Manager 時,您可以建立授權組態,它們是以您的企業協議條款為根據的授權規則集。這些授權組態可以連接到機制,例如 Amazon Machine Image (AMI) 或 AWS CloudFormation。您可以使用其中一個機制來啟動EC2執行個體。

AWSServiceRoleForAWSCloud9 個服務連結角色 (SLR) AWSCloud9ServiceRolePolicy的舊版 目前不包含license-configuration資源條件。因此, AWS Cloud9 不允許啟動和停止其執行個體。因此, AWS Cloud9 拒絕存取其 Amazon EC2執行個體,並傳回錯誤。

建議的解決方案 :如果您無法存取現有 AWS Cloud9 環境並使用 License Manager,請將舊AWSCloud9ServiceRolePolicy的服務連結角色取代為 的版本,當 套用至執行個體時,該版本SLR明確允許 EC2動作。 license-configuration您可以透過直接刪除來取代舊角色。然後,更新過的角色會自動建立。

(回到頁首)

應用程式預覽

下一節概述與應用程式預覽相關的疑難排解問題。

重新載入環境後,您必須重新整理應用程式預覽

問題:在您重新載入顯示應用程式預覽標籤的環境後,該標籤並未顯示應用程式預覽。

原因:有時使用者編寫的程式碼會執行無限迴圈。或者,其程式碼可以使用太多記憶體,當應用程式預覽執行時, AWS Cloud9 IDE可能會暫停或停止。為了防止這種情況發生, AWS Cloud9 每當環境重新載入時,請勿重新載入應用程式預覽索引標籤。

解決方案:在您重新載入顯示應用程式預覽標籤的環境後,從該標籤上選擇 Click to load the page (按一下以載入頁面) 按鈕,即可顯示應用程式預覽。

應用程式預覽或檔案預覽通知:「Third-party cookies disabled」(已停用第三方 Cookie)

問題: 當您嘗試預覽應用程式檔案時,畫面會通知下列訊息:「Preview functionality is disabled because your browser has third-party cookies disabled.」(已停用預覽功能,因為您的瀏覽器已停用第三方 Cookie。)

原因:開啟 不需要第三方 Cookie AWS Cloud9 IDE。不過,您必須啟用第三方 Cookie,才能使用「應用程式預覽」或「檔案預覽」功能。

解決方案:在您的 Web 瀏覽器中啟用第三方 Cookie、重新載入您的 IDE,然後嘗試再次開啟預覽。

您的 Web 瀏覽器必須允許此資料粒度,您才能為 AWS Cloud9啟用第三方 Cookie。若要執行此操作,請根據您使用 AWS Cloud9的支援 AWS 區域 ,指定下列網域。

AWS 區域 網域

美國東部 (維吉尼亞北部)

*.vfs.cloud9.us-east-1.amazonaws.com

vfs.cloud9.us-east-1.amazonaws.com

美國東部 (俄亥俄)

*.vfs.cloud9.us-east-2.amazonaws.com

vfs.cloud9.us-east-2.amazonaws.com

美國西部 (加利佛尼亞北部)

*.vfs.cloud9.us-west-1.amazonaws.com

vfs.cloud9.us-west-1.amazonaws.com

美國西部 (奧勒岡)

*.vfs.cloud9.us-west-2.amazonaws.com

vfs.cloud9.us-west-2.amazonaws.com

非洲 (開普敦)

*.vfs.cloud9.af-south-1.amazonaws.com

vfs.cloud9.af-south-1.amazonaws.com

亞太區域 (香港)

*.vfs.cloud9.ap-east-1.amazonaws.com

vfs.cloud9.ap-east-1.amazonaws.com

亞太區域 (孟買)

*.vfs.cloud9.ap-south-1.amazonaws.com

vfs.cloud9.ap-south-1.amazonaws.com

亞太區域 (大阪)

*.vfs.cloud9.ap-northeast-3.amazonaws.com

vfs.cloud9.ap-northeast-3.amazonaws.com

亞太區域 (首爾)

*.vfs.cloud9.ap-northeast-2.amazonaws.com

vfs.cloud9.ap-northeast-2.amazonaws.com

亞太區域 (新加坡)

*.vfs.cloud9.ap-southeast-1.amazonaws.com

vfs.cloud9.ap-southeast-1.amazonaws.com

亞太區域 (雪梨)

*.vfs.cloud9.ap-southeast-2.amazonaws.com

vfs.cloud9.ap-southeast-2.amazonaws.com

亞太區域 (東京)

*.vfs.cloud9.ap-northeast-1.amazonaws.com

vfs.cloud9.ap-northeast-1.amazonaws.com

加拿大 (中部)

*.vfs.cloud9.ca-central-1.amazonaws.com

vfs.cloud9.ca-central-1.amazonaws.com

歐洲 (法蘭克福)

*.vfs.cloud9.eu-central-1.amazonaws.com

vfs.cloud9.eu-central-1.amazonaws.com

歐洲 (愛爾蘭)

*.vfs.cloud9.eu-west-1.amazonaws.com

vfs.cloud9.eu-west-1.amazonaws.com

歐洲 (倫敦)

*.vfs.cloud9.eu-west-2.amazonaws.com

vfs.cloud9.eu-west-2.amazonaws.com

歐洲 (米蘭)

*.vfs.cloud9.eu-south-1.amazonaws.com

vfs.cloud9.eu-south-1.amazonaws.com

歐洲 (巴黎)

*.vfs.cloud9.eu-west-3.amazonaws.com

vfs.cloud9.eu-west-3.amazonaws.com

歐洲 (斯德哥爾摩)

*.vfs.cloud9.eu-north-1.amazonaws.com

vfs.cloud9.eu-north-1.amazonaws.com

中東 (巴林)

*.vfs.cloud9.me-south-1.amazonaws.com

vfs.cloud9.me-south-1.amazonaws.com

南美洲 (聖保羅)

*.vfs.cloud9.sa-east-1.amazonaws.com

vfs.cloud9.sa-east-1.amazonaws.com

應用程式預覽標籤顯示錯誤或一片空白

問題:在 的選單列上IDE,當您選擇預覽、預覽執行中應用程式工具、預覽、預覽執行中應用程式,嘗試在 的預覽索引標籤上顯示應用程式時IDE,索引標籤會顯示錯誤,或索引標籤為空白。

可能原因:

  • 您的應用程式未在 中執行IDE。

  • 您的應用程式未使用 執行HTTP。

  • 您的應用程式透過多個連接埠執行。

  • 您的應用程式透過 808080818082 以外的連接埠執行。

  • 您的應用程式使用 127.0.0.1localhost0.0.0.0 以外的 IP 執行。

  • 在預覽索引標籤URL的 中未指定連接埠 80808081、 或 8082)。

  • 您的網路封鎖了對連接埠 808080818082 的傳入流量。

  • 您正嘗試前往的 IP 地址包含 127.0.0.1localhost0.0.0.0。根據預設, AWS Cloud9 IDE會嘗試前往您的本機電腦。它不會嘗試移至連線至環境的執行個體或您自己的伺服器。

建議解決方案:

  • 確保應用程式在 中執行IDE。

  • 確保應用程式使用 執行HTTP。如需 Node.js 和 Python 方面的範例,請參閱執行應用程式

  • 確認應用程式只透過單一連接埠執行。如需 Node.js 和 Python 方面的範例,請參閱執行應用程式

  • 確認應用程式是透過連接埠 808080818082 執行。如需 Node.js 和 Python 方面的範例,請參閱執行應用程式

  • 確認應用程式是使用 IP 127.0.0.1localhost0.0.0.0 執行。如需 Node.js 和 Python 方面的範例,請參閱執行應用程式

  • :8080:8081:8082 新增至預覽標籤上URL的 。

  • 確認您的網路允許透過連接埠 808080818082 傳入流量。若您無法對網路進行變更,請洽詢您的網路管理員。

  • 如果您嘗試移至包含 IP 127.0.0.1localhost0.0.0.0 的地址,請嘗試改為移至以下地址:https://12a34567b8cd9012345ef67abcd890e1.vfs.cloud9.us-east-2.amazonaws.com/。在這個地址中,12a34567b8cd9012345ef67abcd890e1 是 AWS Cloud9 指派給環境的 ID。us-east-2 是 AWS 區域 指派給環境的 ID。您也可以嘗試前往 以外的此地址IDE。不過,只有在IDE環境的 開啟,且應用程式正在相同的 Web 瀏覽器中執行時,此功能才有效。

  • 確認符合上述所有條件後,嘗試停止應用程式並將其重新啟動。

  • 如果您已停止應用程式並將其重新啟動,請再次嘗試從選單列選擇 Preview、Preview Running Application (預覽、預覽執行中的應用程式) 或 Tools、Preview、Preview Running Application (工具、預覽、預覽執行中的應用程式)。或者,若已能夠看到相應的應用程式預覽標籤,則由該標籤上選擇 Refresh (重新整理) 按鈕 (圓形箭頭)。

無法預覽 中的 Web 內容,IDE因為與網站的連線不安全

問題:當您嘗試存取 Web 內容時,例如託管在 AWS Cloud9 EC2環境中 WordPress 的網站,IDE預覽視窗無法顯示它。

可能原因:根據預設,您在 的應用程式預覽索引標籤中存取的所有網頁都會 AWS Cloud9 IDE自動使用HTTPS通訊協定。如果頁面URI具有不安全的http通訊協定,則會自動以 取代https。而且您無法藉由手動將 https 改回 http 來存取不安全的內容。

建議的解決方案 :從您嘗試在 中預覽的網站中移除不安全的HTTP指令碼或內容IDE。請遵循 Web 伺服器或內容管理系統的指示,以取得實作 的指引HTTPS。

預覽檔案時傳回 499 錯誤

問題:當您嘗試使用 AWS Cloud9 IDE來預覽包含包含 src 屬性的<script>元素,並將 type 屬性設為 時module,會發生 499 錯誤,且指令碼未如預期執行。

原因: AWS Cloud9 IDE中的檔案預覽擷取請求需要 Web 瀏覽器傳送 Cookie 以進行身分驗證。根據預設,Web 瀏覽器會針對一般指令碼請求傳送 Cookie。它們不會針對模組指令碼請求傳送 Cookie,除非您新增 crossorigin 屬性。

解決方案:crossorigin 屬性新增至 <script> 元素。例如:<script type="module" src="index.js" crossorigin></script>。然後,儲存已變更的檔案,並嘗試再次進行預覽。

效能

下一節概述與效能相關的疑難排解問題。

AWS Cloud9 IDE 長時間凍結

問題:啟動期間和執行重新整理時, AWS Cloud9 IDE終端機會凍結大量的時間,並變得無法使用。

原因:您的環境中可能有大量檔案,這些檔案會由 的檔案觀察模組進行遞迴監控 AWS Cloud9。

建議的解決方案:您可以減少檔案監看深度 (最小值為 1),並考慮將與原始程式碼 (建置輸出/成品、第三方套件) 無關的大型資料夾或資料夾新增至忽略的模式。若要執行此操作,請導覽至偏好設定 > 使用者設定 > 檔案觀看 。請注意,這會導致 AWS Toolkit CodeLenses 中的 無法正常運作。

另一個可能的解決方案是考慮透過減少要搜尋的檔案數目上限,忽略與原始碼無關的大型檔案和資料夾。若要執行此操作,請導覽至檔案 中的偏好設定 > 專案設定 > 尋找。請注意,這會導致被忽略的資料夾不會顯示在檔案搜尋中。

主控台警告:「Switching to the minimal code completion engine...」(切換到最少程式碼完成引擎…)

問題:在 AWS Cloud9 主控台中工作時 (例如,開啟 IDE或重新整理 IDE的網頁時),您會看到此訊息:「一或多個工作階段或協作者在此環境中處於作用中狀態。切換到最少程式碼完成引擎以節省記憶體。」 與此訊息相互關聯的程式碼完成行為可能會變慢或斷斷續續。

原因:執行程式碼完成引擎需要環境中的記憶體和CPU週期。此外,每個協作者和每個額外的工作階段都需要個別的程式碼完成引擎。為了避免使用過多的資源,特別是在小型執行個體上,例如 t2.nano 以及 t2.micro, AWS Cloud9 切換至最小程式碼完成引擎。

建議的解決方案:如果您計劃經常且長時間地協作,請在建立EC2環境時選擇較大的 Amazon EC2執行個體。或者,將您的SSH環境連接到容量更大的執行個體。

注意

選擇較大的 Amazon EC2執行個體可能會導致您的 AWS 帳戶 產生額外費用。如需詳細資訊,請參閱 Amazon EC2 Pricing

IDE 警告:「此環境記憶體不足」或「此環境CPU負載很高」

問題:當 執行IDE時,您會看到一則訊息,其中包含「此環境記憶體不足」或「此環境具有高CPU負載」。

原因: IDE可能沒有足夠的運算資源可供繼續執行,而不會延遲或掛起。

建議解決方案:

  • 停用一或多個執行程序以便釋放可用記憶體。若要這麼做,請在 環境IDE的選單列上,選擇工具、程序清單 。針對您想要停用的每個程序,選擇程序後,在選取 Force Kill (強制終止)​。

  • 在環境中建立置換檔。置換檔為環境中的檔案,可供作業系統當做虛擬記憶體。

    若要確認環境目前是否正在使用交換記憶體,請在環境的終端機工作階段中執行 top 命令。如果正在使用置換記憶體,輸出顯示為非零的 Swap 記憶體統計資料 (例如:Swap: 499996k total, 1280k used, 498716 free, 110672k cached)。若要停止顯示即時記憶體資訊,請按 Ctrl + C

    若要建立置換檔,請在環境中執行如下命令。

    sudo fallocate --length 512MB /var/swapfile && sudo chmod 600 /var/swapfile && sudo mkswap /var/swapfile && echo '/var/swapfile swap swap defaults 0 0' | sudo tee -a /etc/fstab > /dev/null

    上述命令執行以下事項:

    1. /var 目錄中,建立稱為 swapfile 的 512 MB 檔案。

    2. 變更 swapfile 檔的存取許可,僅限擁有者讀取或寫入。

    3. swapfile 檔設定為置換檔。

    4. 將資訊寫入 /etc/fstab file。這使得每當系統重新啟動時都可以使用此置換檔。

    您執行上述命令後,若要立即讓置換檔可用,請執行下列命令。

    sudo swapon /var/swapfile
  • 使用多個運算資源將環境移動到 (或先調整環境的大小再移動) 執行個體或伺服器,。若要移動或調整 Amazon EC2執行個體的大小,請參閱 從 AWS Cloud9 IDEAmazon EBS磁碟區移動。其他執行個體或伺服器類型,請參閱您的執行個體或伺服器文件。

無法在 中上傳檔案 AWS Cloud9 IDE

問題:使用者無法在 中上傳大型檔案 AWS Cloud9 IDE。這些上傳失敗。

Cause: AWS Cloud9 調節上傳速度至 AWS Cloud9 IDE,因此檔案上傳請求逾時。

建議的解決方案:我們建議您將檔案上傳至 Amazon S3,然後使用 Amazon S3 將檔案下載至 CLI中的 環境 AWS Cloud9 IDE。如需將物件上傳至 Amazon S3 的詳細資訊,請參閱 Amazon S3 使用者指南 中的上傳物件

在 中慢速下載 AWS Cloud9 IDE

問題:嘗試從 下載檔案時,使用者正在處理緩慢的下載速度 AWS Cloud9 IDE。

原因:當您將檔案從 下載IDE至本機檔案系統時,傳輸速度將限制為每秒 0.1 MB 的速度。

建議的解決方案:若要提高檔案傳輸速度,請使用 CLI AWS Cloud9 IDE中的 將檔案上傳至 Amazon S3,然後使用 Amazon S3 從該處下載檔案。

無法預覽 中的 Web 內容,IDE因為與網站的連線不安全

問題:當您嘗試存取 Web 內容,例如託管在 AWS Cloud9 EC2環境中 WordPress 的網站時,IDE預覽視窗無法顯示它。

可能的原因:根據預設,您在 的應用程式預覽索引標籤 AWS Cloud9 IDE中存取的所有網頁都會自動使用HTTPS通訊協定。如果頁面URI具有不安全的http通訊協定,則會自動以 取代https。而且您無法藉由手動將 https 改回 http 來存取不安全的內容。

建議的解決方案 :從您嘗試在 中預覽的網站中移除不安全的HTTP指令碼或內容IDE。請遵循 Web 伺服器或內容管理系統的指示,以取得實作 的指引HTTPS。

(回到頁首)

第三方應用程式和服務

下節概述與第三方應用程式和服務相關的疑難排解問題。

因為 tmux 工作階段發生錯誤,所以無法與 AWS Cloud9 中的終端機視窗互動。

問題:當您嘗試在 中啟動新的終端機視窗時 AWS Cloud9,預期的命令列介面無法使用。沒有命令提示字元,您無法輸入文字。系統會傳回諸如 tmux: need UTF-8 locale (LC_CTYPE)invalid LC_ALL, LC_CTYPE or LANG 等錯誤訊息。

可能原因:沒有回應的終端機可能是由 tmux 錯誤所造成。 AWS Cloud9 會使用 tmux 公用程式。如此,顯示在終端機中的資訊,即使在頁面重新載入或您重新連線至開發環境時也會持續存在。

tmux 工作階段中,終端機視窗中顯示的內容會由用戶端處理。用戶端會與可管理多個工作階段的伺服器通訊。伺服器和用戶端會透過位於 tmp 資料夾中的通訊端進行通訊。如果 tmp 資料夾在開發環境中遺失,或者套用了過於嚴格的許可,tmux 工作階段就無法執行。如果發生這種情況, 中的終端機視窗IDE會變得無回應。

建議的解決方案:如果 tmux 錯誤使您無法與終端機視窗互動,請使用替代方式來建立具有適當許可的 tmp 資料夾。這樣,tmux 工作階段就能執行。其中一種解決方法是在 .bash_profile.bashrc 檔案中匯出 LC_CTYPE。另一個建議的解決方案是使用 AWS Systems Manager 來設定主機管理組態。這允許透過 Amazon EC2主控台存取相關執行個體。

設定主機管理

  1. 首先,在 AWS Cloud9 主控台中尋找環境執行個體的名稱。若要這麼做,請選擇 Your environments (您的環境) 中的相關面板,並選擇 View details (檢視詳細資訊)。在 Environment details (環境詳細資訊) 頁面中,選擇 Go to Instance (前往執行個體)。在 Amazon EC2主控台中,確認您需要存取的執行個體名稱。

  2. 現在前往 AWS Systems Manager 主控台,然後在導覽窗格中,選擇快速設定

  3. Quick Setup (快速設定) 頁面中,選擇 Create (建立)。

  4. 對於 Configuration types (組態類型),前往 Host Management (主機管理),然後選擇 Create (建立)。

  5. 對於 Customize Host Management configuration options (自訂主機管理組態選項),在 Targets (目標) 區段中,選擇 Manual (手動)。

  6. 選取您要存取的EC2執行個體,然後選擇建立

連線至執行個體並執行命令

注意

下列步驟適用於新的EC2主控台。

  1. 在 Amazon EC2主控台的導覽窗格中,選擇執行個體,然後選取您要連線的執行個體。

  2. 選擇連線

    如果 Connect (連線) 並未啟用,您可能需要先啟動該執行個體。

  3. Connect to your instance (連線至您的執行個體) 窗格中,對於 Connection method (連線方法),選擇 Session Manager (工作階段管理員),然後選擇 Connect (連線)。

  4. 在出現的終端機工作階段視窗中,輸入下列指令。這些命令會建立具有適當許可的 tmp 資料夾,讓 tmux 通訊端可供使用。

    sudo mkdir /tmp sudo chmod 777 /tmp sudo rmdir /tmp/tmux-*

無法使用IDE舊版 載入 Microsoft Edge 瀏覽器

問題:嘗試使用 載入 AWS Cloud9 IDE時傳回HTTP403: FORBIDDEN錯誤 Microsoft Edge 網頁瀏覽器。

可能原因: AWS Cloud9 IDE不支援某些舊版 的 Microsoft Edge.

建議的解決方案:若要更新瀏覽器,請選擇 中的省略號 (...) 按鈕 Microsoft Edge 工具列。從功能表中,選擇設定,然後選擇關於 Microsoft Edge。 如果需要更新,會自動下載並安裝。

偵錯gdb時 發生錯誤 C++ 專案

問題:嘗試在 中gdb偵錯 C++ 專案時,偵錯器報告錯誤IDE。

可能的原因:假設您的 AWS Cloud9 環境使用某些EC2執行個體類型 (例如 t3.smallm5.large)。然後,當您嘗試執行和偵錯 C++ 使用 內建執行器IDE的專案。可能會發生此錯誤,因為為您的環境預先安裝的 gdb(GNUProject Debugger) 版本無法在某些處理器平台上運作。您可能會看到下列錯誤代碼。

GDB server terminated with code 1

建議解決方案:gdb 不支援某些處理器平台的問題從版本 3.0 起已經修正。請解除安裝舊版的除錯器並升級到較新版本的 gdb

  1. 在 AWS Cloud9 終端機中執行下列命令,以移除現有版本的偵錯工具。

    sudo yum -y remove gdb
  2. 擷取 gdb 的封存檔,加以解壓縮,然後執行下列命令,以便導覽到含有解壓縮檔案的目錄:

    wget "http://ftp.gnu.org/gnu/gdb/gdb-8.3.tar.gz" tar xzf gdb-8.3.tar.gz cd gdb-8.3
  3. 執行下列命令來建置除錯器。若要這麼做,請將下列文字複製並貼上為單一區塊,然後按下 Return (傳回) 執行 make

    ./configure --prefix=/usr \ --with-system-readline \ --with-python=/usr/bin/python3 && make
  4. 安裝除錯器。

    sudo make -C gdb install
  5. 確認已安裝除錯器的更新版本。

    gdb --version

中的PHP執行器問題 AWS Cloud9

問題:使用者無法檢視PHPCLI執行器終端機中的任何輸出。

原因:CLI執行器需要設定為 ,PHP且偵錯器模式需要啟用。

建議的解決方案:將CLI執行器設定為 ,PHP並確保已啟用偵錯器模式。

GLIBC 與 Node.js 相關的錯誤

問題:使用者無法執行 Node.js 且發生錯誤GLIBC。這些錯誤訊息的範例概述如下:

node: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by node) node: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by node)

原因:這可能是與正在使用的執行個體相關的 Node.js 版本問題。

建議的解決方案:請參閱 步驟 1:安裝必要工具一節,了解如何安裝適用於 的 Node.js AWS Cloud9。