トラブルシューティング AWS Cloud9 - AWS Cloud9
Installer (インストーラ)AWS Cloud9 環境Amazon EC2その他の AWS サービスアプリケーションプレビューパフォーマンスサードパーティのアプリケーションとサービス

AWS Cloud9 は、新しいお客様では利用できなくなりました。 AWS Cloud9 の既存のお客様は、通常どおりサービスを引き続き使用できます。詳細はこちら

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

トラブルシューティング AWS Cloud9

以下の情報を使用して、 に関する問題を特定して対処します AWS Cloud9。

該当する問題が以下に示されていない場合や、追加のヘルプが必要な場合は、AWS Cloud9 ディスカッションフォーラムを参照してください。このフォーラムにアクセスするには、サインインが必要になることがあります。当社に直接お問い合わせいただくこともできます。

Installer (インストーラ)

次のセクションでは、 AWS Cloud9  インストーラーに関連する問題のトラブルシューティングについて概説します。

AWS Cloud9 インストーラがハングまたは失敗する

問題： AWS Cloud9 インストーラ をダウンロードして実行すると、1 つ以上のエラーが発生し、インストーラスクリプトに が表示されませんDone。

原因： AWS Cloud9 インストーラは、復旧できない 1 つ以上のエラーを検出し、その結果失敗します。

解決策: 詳細については、「AWS Cloud9 インストーラのトラブルシューティング」を参照してください。一般的な問題、考えられる原因、および推奨される解決策を参照してください。

AWS Cloud9 インストーラーは、「Package Cloud9 IDE 1」を表示した後で終了しません。

問題： AWS Cloud9 SSH開発環境を作成するプロセスの一環として、既存の Amazon EC2インスタンスまたは独自のサーバーにインストールされます。AWS Cloud9 Installer ダイアログボックス「Package Cloud9 1」にこのメッセージが表示されたらIDE、インストールは停止します。［キャンセル］を選択すると、「インストールに失敗しました」というメッセージが表示されます。このエラーは、 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 ファイルに追加し、 PEM 形式の認証機関ファイルのパスNODE_EXTRA_CA_CERTSに設定します。この変数の詳細については、「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 環境エラー: pty.js をインストールするには「Python バージョン 3 が必要です」

問題： 開発環境を開くと 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 フェデレーティッド ID を使用して AWS Cloud9 開発環境を作成しようとすると、アクセスエラーメッセージが表示され、環境は作成されません。

原因： : サービスにリンクされたロール AWS Cloud9 を使用します。サービスにリンクされたロールは、iam:CreateServiceLinkedRole コールを使用してアカウントで初めて環境を作成したときに作成されます。ただし、フェデレーティッドユーザーは IAM を呼び出すことはできませんAPIs。詳細については、「 リファレンスGetFederationToken」の「」を参照してください。 AWS 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「 ユーザーガイド」の「サービスにリンクされたロールの使用」を参照してください。

コンソールエラー: 「ユーザーにはリソースでアクションを実行する権限がありません」

問題： AWS Cloud9 コンソールを使用して AWS Cloud9 開発環境を作成または管理しようとすると、「ユーザーがリソース cloud9:action で実行する権限arn:aws:iam::123456789012:user/MyUserがない」などのフレーズを含むエラーが表示されますarn:aws:cloud9:us-east-2:123456789012:environment:12a34567b8cd9012345ef67abcd890e1。

  • arn:aws:iam::123456789012:user/MyUser は、リクエストするユーザーの Amazon リソースネーム (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は 5 分以上表示されません。

考えられる原因:

  • AWS Cloud9 コンソールにサインインしているIAMユーザーには、環境を開くために必要な AWS アクセス許可がありません。

  • 環境が AWS クラウドコンピューティングインスタンス (Amazon EC2インスタンスなど) に関連付けられている場合、次の可能性があります。

    • インスタンスVPCに関連付けられている は、 の正しい設定に設定されていません AWS Cloud9。

    • がインスタンスに接続しようとしているときに、インスタンスが状態間で移行しているか AWS Cloud9 、自動ステータスチェックに失敗しています。

  • 環境がSSH環境の場合、関連付けられたクラウドコンピューティングインスタンスまたは独自のサーバーが、 AWS Cloud9 がアクセスできるように正しく設定されていません。

推奨される解決策:

AWS Cloud9 環境を開くことができません: 「この環境には、現在共同作業者がアクセスできません。マネージド一時認証情報の削除が完了するまでお待ちください。または、この環境の所有者にお問い合わせしてください。」

問題： 環境所有者ではないユーザーが新しい共同作業者を環境に追加した場合、 AWS マネージド一時認証情報は無効になります。~/.aws/credentials ファイルを削除すると、認証情報は無効になります。~/.aws/credentials ファイルの削除中は、新しい共同作業者は AWS Cloud9 環境にアクセスできません。

原因: AWS マネージド一時認証情報の削除中に環境へのアクセスができないのは、セキュリティ対策です。これにより、環境所有者は、信頼できる共同作業者だけがマネージド認証情報報にアクセスできることを確認できます。共同作業者のリストが有効であることが確認できたら、環境所有者はマネージド認証情報を再度有効にして共有することができます。詳細については、「マネージド一時認証情報へのアクセスのコントロール AWS」を参照してください。

推奨される解決策： ~/.aws/credentials ファイルが完全に削除されるのを待ってから、 AWS Cloud9 環境をもう一度開いてみます。認証情報待機時間の有効期限は最大 15 分です。または、マネージド一時認証情報を再度有効または無効にするよう、環境所有者に依頼します。認証情報が再び有効または無効になると、共同作業者はすぐに環境にアクセスできます。マネージド認証情報の状態を ENABLEDまたは に切り替えることでDISABLED、環境所有者は認証情報が中間状態のままにならないようにします。中間状態では、共同作業者が環境にアクセスできない可能性があります。

注記

環境所有者と共同作業者が同じ AWS アカウントに属しているとします。この場合、共同作業者は、コンソールの [Your environments] (自分の環境) ページで環境カードを確認し、連絡先の環境所有者を特定できます。環境所有者も、環境の詳細ページにあがっています。

環境の削除エラー:「1 つ以上の環境を削除できませんでした」

問題： AWS Cloud9 コンソールで 1 つ以上の環境を削除しようとすると、「1 つ以上の環境が削除に失敗し、」と表示され、少なくとも 1 つの環境が削除されないというメッセージが表示されます。

考えられる原因： AWS CloudFormation 1 つ以上の環境の削除に問題がある可能性があります。環境の作成と削除 AWS CloudFormation は AWS Cloud9 に依存します。

推奨される解決策： AWS CloudFormation を使用して、削除されていない各環境を削除してみてください。

  1. AWS CloudFormation コンソールを https://console.aws.amazon.com/cloudformation で開きます。

  2. AWS ナビゲーションバーで、環境 AWS リージョン の を選択します。

  3. AWS CloudFormation スタックのリストで、スタック名に削除されていない環境名が含まれ、ステータスが DELETE_FAILED であるエントリを選択します。例えば、環境名が の場合my-demo-environment、aws-cloud9-my-demo-environment という名前で始まるスタックを選択します。(環境名の横にあるボックスまたはオプションを選択してください。環境名自体は選択しないでください)。

  4. ［アクション］、［スタックの削除］の順に選択します。

  5. プロンプトが表示されたら、［はい、削除します］を選択します。

スタックの削除処理には数分かかる場合があります。

スタックがリストから消えた場合、環境は削除されています。

数分後にスタックに DELETE_FAILED が表示されても、環境は削除されません。この場合、障害が発生した各スタックのリソースを手動で削除できます。

注記

失敗したスタックのリソースを手動で削除しても、スタック自体は から削除されません AWS アカウント。

これらのリソースを手動で削除するには、次の手順に従います。 AWS CloudFormation コンソールで、失敗したスタックを選択し、リソースセクションを選択します。このリスト内の各リソース AWS の コンソールに移動し、そのコンソールを使用してリソースを削除します。

での環境のタイムアウト時間の変更 AWS Cloud9 IDE

問題： ユーザーは Amazon EC2環境のタイムアウト時間を更新したいと考えています。

原因: デフォルトのタイムアウト時間は 30 分です。これは一部のユーザーには短すぎるかもしれません。

推奨される解決策:

  1. 設定する環境を開きます。

  2. AWS Cloud9 IDEのメニューバーで、 AWS Cloud9 設定 を選択します。

  3. 設定ウィンドウで Amazon EC2インスタンスセクションにスクロールします。

  4. 使用可能なリストからタイムアウト値を選択し、更新します。

AWS Cloud9 環境に十分なディスク容量がないため、 AWS Toolkit でSAMアプリケーションをローカルで実行する際のエラー

問題： テンプレートで定義されたアプリケーションのコマンドを実行する AWS SAM CLIために AWS Toolkit を使用するとエラーが発生しますSAM。

考えられる原因： Toolkit を使用してサーバーレスアプリケーションをローカルで実行およびデバッグする場合 AWS 、 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 などのファイルパスは機能します。これは既知の問題であり、File Explorer にのみ影響します AWS Cloud9 IDE。

推奨される解決策： 別のファイル名と構造を使用してください。

(先頭に戻ります)

for の File Explorer AWS Cloud9 IDE 内にサブフォルダ構造 /projects/projects を作成することはできません CodeCatalyst。

問題： の File Explorer で AWS Cloud9 IDEサブフォルダ構造 /projects/projects を作成すると CodeCatalyst、このディレクトリを開くことができないことを示すエラーメッセージが表示されます。

考えられる原因： 現在、 for の 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 エラーによって引き起こされる可能性があります。 は tmux ユーティリティ AWS Cloud9 を使用します。これにより、ページがリロードされたり、開発環境に再接続しても、ターミナルに表示される情報は保持されます。

tmux セッションでは、ターミナルウィンドウの表示内容はクライアントによって処理されます。クライアントは、複数のセッションを管理できるサーバーと通信します。サーバーとクライアントは、tmp フォルダにあるソケットを介して通信します。開発環境に tmp フォルダがないか、過度に制限的なアクセス許可が適用されている場合、tmux セッションは実行できません。この場合、 のターミナルウィンドウは応答しIDEなくなります。

推奨される解決策: tmux エラーによってターミナルウィンドウと対話できない場合は、別の方法を使用して適切な許可を持つ tmp フォルダを作成する必要があります。これにより、tmux セッションを実行できます。1 つの解決策は、.bash_profile または .bashrc ファイルの LC_CTYPE をエクスポートすることです。もう 1 つの推奨ソリューションは、 AWS Systems Manager を使用してホスト管理設定をセットアップすることです。これにより、Amazon EC2コンソールを介して関連するインスタンスにアクセスできます。

ホスト管理の設定

  1. まず、 AWS Cloud9 コンソールで、環境のインスタンスの名前を見つけます。これを行うには、[Your environments] (自分の環境) ページで該当するパネルを選択し、[View details] (詳細を表示) を選択します。[環境の詳細] ページで [インスタンスに移動] を選択します。Amazon EC2コンソールで、アクセスする必要があるインスタンスの名前を確認します。

  2. AWS Systems Manager コンソールに移動し、ナビゲーションペインでクイックセットアップ を選択します。

  3. [クイックセットアップ] ページで [作成] を選択します。

  4. [設定タイプ] では、[ホスト管理] に移動し、[登録] を選択します。

  5. [ホスト管理構成オプションのカスタマイズ] の [ターゲット]セクションで、[手動]を選択します。

  6. アクセスするEC2インスタンスを選択し、「 の作成」を選択します。

インスタンスに接続してコマンドを実行する

注記

次の手順は、新しいEC2コンソール用です。

  1. Amazon EC2コンソールのナビゲーションペインで、インスタンスを選択し、接続するインスタンスを選択します。

  2. [接続]を選択します。

    [Connect] (接続) がアクティブ化されていない場合は、最初にインスタンスを起動する必要があります。

  3. [Connect to your instance] (インスタンスへ接続) ペインの [Connection method] (接続方法) で、[Session Manager]、[Connect] (接続) の順に選択します。

  4. 表示されたターミナルセッションウィンドウで、次のコマンドを入力します。これらのコマンドは、tmux ソケットを使用するための適切なアクセス許可を持つ tmp フォルダを作成します。

    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 インスタンスにシステム更新EC2を定期的に適用します。

インスタンスでコマンドを実行するには、インスタンスに接続されている環境から AWS Cloud9 IDEでターミナルセッションを使用できます。

または、ssh SSH や PuTTY インスタンスに接続します。これを行うには、ローカルコンピュータから、ssh-keygen SSH や PuTTYgen。 インスタンスに接続されている環境の を使用して AWS Cloud9 IDE、生成されたパブリックキーをインスタンスに保存します。次に、SSHリモートアクセスユーティリティと生成されたプライベートキーを使用してインスタンスにアクセスします。詳細については、ユーティリティのドキュメントを参照してください。

AWS CLI または AWS- シェルエラー: 「リクエストに含まれるセキュリティトークンは、EC2環境内で無効です」

問題： AWS Command Line Interface （AWS CLI) または AWS-shell を使用して EC2環境でコマンド AWS Cloud9 IDEを実行しようとすると、「リクエストに含まれるセキュリティトークンが無効です」というエラーが表示されます。

原因: AWS マネージド一時認証情報があり、以下のいずれかが発生すれば、セキュリティトークンが無効二なる可能性があります。

  • AWS マネージド一時認証情報では許可されていないコマンドを実行しようとしました。許可されたコマンドの一覧については、「AWS マネージド一時認証情報でサポートされているアクション」を参照してください。

  • AWS マネージド一時認証情報は 15 分後に自動的に期限切れになります。

  • 共有環境の AWS マネージド一時認証情報は、新しいメンバーが環境所有者以外の誰かによって追加されたため、非アクティブ化されました。

推奨される解決策:

  • AWS マネージド一時認証情報で許可されているコマンドのみを実行します。 AWS マネージド一時認証情報で許可されていないコマンドを実行する必要がある場合は、環境内の AWS CLI または AWS-shell を永続的な認証情報のセットで設定します。これにより、この制限がなくなります。手順については、環境に永続的アクセス認証情報を作成して保存する を参照してください。

  • 無効化または期限切れの認証情報については、 が環境内の一時的な認証情報 AWS Cloud9 を更新できるように、環境所有者が環境を開いていることを確認してください。詳細については、「マネージド一時認証情報へのアクセスのコントロール AWS」を参照してください。

VPCの IP アドレスが によって使用されているため、EC2環境に接続できません Docker

問題： EC2環境の場合、IPv4Classless Inter-Domain Routing (CIDR) ブロック VPC を使用する Amazon でEC2インスタンスを起動すると172.17.0.0/16、その環境を開くと接続が停止する可能性があります。

原因： Docker は、同じブリッジネットワークに接続されたコンテナが通信できるようにするブリッジネットワークと呼ばれるリンクレイヤーデバイスを使用します。 は、コンテナ通信にデフォルトのブリッジを使用するコンテナ AWS Cloud9 を作成します。デフォルトのブリッジは、コンテナのネットワークに通常 172.17.0.0/16 サブネットを使用します。

環境のインスタンスのVPCサブネットで、 が既に使用しているのと同じアドレス範囲が使用されている場合 Docker、IP アドレスの競合が発生する可能性があります。したがって、インスタンスへの接続 AWS Cloud9 を試みると、その接続はゲートウェイルートテーブルによって にルーティングされます。Docker ブリッジ。これにより、 が開発環境をバックアップするEC2インスタンスに接続 AWS Cloud9 できなくなります。

推奨される解決策: Amazon VPCと によって引き起こされる IP アドレスの競合を解決するには Docker 同じIPv4CIDRアドレスブロックを使用して、EC2環境をサポートするインスタンスVPCに新しい を設定します。この新しい では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 などのファイルパスは機能します。これは既知の問題であり、File Explorer にのみ影響します AWS Cloud9 IDE。

推奨される解決策： 別のファイル名と構造を使用してください。

ライセンス設定が Amazon EC2インスタンスに関連付けられている場合、 AWS License Manager コンソール AWS Cloud9 から起動できません

問題： コンソールから環境を起動 AWS Cloud9 EC2しようとすると、エラーメッセージunable to access your environmentが返されます。

考えられる原因： AWS License Manager 全体でソフトウェアベンダーライセンスの管理を合理化します AWS クラウド。License Manager を設定するときは、エンタープライズ契約の条項に基づくライセンスルールのセットであるライセンス設定を作成します。これらのライセンス設定は、Amazon マシンイメージ (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 オペレーティングシステムで通常機能するコマンドを含むスクリプトを実行したりすることはできません。

原因： EC2環境で AWS Cloud9 を使用する Amazon EC2インスタンスは、Amazon Linux (Red Hat Enterprise Linux (RHEL) に基づく) または Ubuntu Server のいずれかに依存します。

解決策： EC2環境IDEの にパッケージをインストールまたは管理したり、コマンドやスクリプトを実行したりする場合は、その環境のインスタンスに応じて、 RHEL (Amazon Linux の場合) または Ubuntu Server のいずれかと互換性があることを確認してください。

を使用してEC2環境を作成する場合、エラーメッセージレポート「インスタンスプロファイル AWSCloud9SSMInstanceProfile は account」に存在しません AWS CloudFormation

問題： AWS::Cloud9::EnvironmentEC2 AWS CloudFormation リソースを使用してEC2環境を作成すると、ユーザーはインスタンスプロファイル AWSCloud9SSMInstanceProfileがアカウントに存在しないというエラーメッセージを受け取ります。

原因： no-ingress EC2環境を作成するときは、サービスロールAWSCloud9SSMAccessRoleとインスタンスプロファイル を作成する必要がありますAWSCloud9SSMInstanceProfile。これらのIAMリソースにより、Systems Manager は開発環境をサポートするEC2インスタンスを管理できます。

コンソールで no-ingress 環境を作成する場合、AWSCloud9SSMAccessRole および AWSCloud9SSMInstanceProfile は自動的に作成されます。ただし AWS CLI 、 AWS CloudFormation または を使用して最初の非進入環境を作成する場合は、これらのIAMリソースを手動で作成する必要があります。

推奨される解決策: AWS CloudFormation テンプレートの編集とIAMアクセス許可の更新については、「」を参照してください。 AWS CloudFormation を使用してイングレスなしEC2環境を作成する

を使用してEC2環境を作成するときに、「リソースperform: ssm:StartSessionで への許可なし」というエラーメッセージの報告 AWS CloudFormation

問題： AWS::Cloud9::EnvironmentEC2 AWS CloudFormation リソースを使用してEC2環境を作成するAccessDeniedExceptionと、ユーザーは を受け取り、「リソースssm:StartSessionに対して実行する権限がない」ことが通知されます。

原因： ユーザーは、Systems Manager を使用して侵入しないインスタンスに使用するEC2環境の設定の一部としてStartSessionAPI必要な を呼び出すアクセス許可がありません。

推奨される解決策: AWS CloudFormation テンプレートの編集とIAMアクセス許可の更新については、「」を参照してくださいAWS CloudFormation を使用してイングレスなしEC2環境を作成する。

を使用してEC2環境を作成するときに「実行する権限がないと報告するエラーメッセージ: iam:GetInstanceProfile リソース: インスタンスプロファイルAWSCloud9SSMInstanceProfileAWS CLI」

問題： を使用してEC2環境AWS CLIを作成するAccessDeniedExceptionと、ユーザーは を受け取り、環境 AWS Cloud9 が「iam:GetInstanceProfile on resource: instance profile を実行する権限がない」ことが通知されます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は起動に失敗し、問題のデバッグが困難になる可能性があります。

推奨されるソリューション : アクセスを提供するには、Amazon EBSボリュームで使用されるカスタマーマネージドキーに AWS Cloud9、AWSServiceRoleForAWSCloud9、 のサービスにリンクされたロールを追加します。

このタスクの詳細については、「規範ガイダンスパターン」の「デフォルトの暗号化で Amazon EBSボリューム AWS Cloud9 を使用する を作成する」を参照してください。 AWS

VPC EC2-Classic アカウントのエラー：「環境にアクセスできません」

問題： EC2-Classic は Amazon の元のリリースで導入されましたEC2。2013 年 12 月 4 日より前に AWS アカウント 設定された を使用する場合、 AWS Cloud9 EC2開発環境の作成時に Amazon VPCとサブネットを設定しないと、このエラーが発生する可能性があります。

VPC デフォルト設定を受け入れると、Amazon EC2インスタンスは EC2-Classic ネットワークで起動されます。インスタンスはデフォルトの のサブネットでは起動されませんVPC。環境の作成に失敗すると、次のメッセージが表示されます。

環境エラー

環境にアクセスできません

環境の作成はエラーで失敗しました: 次のリソースの作成に失敗しました:［インスタンス］。ユーザーからロールバックがリクエストされました。

エラーの原因がEC2インスタンスがデフォルトの にないことであることが確認できますVPC。 AWS CloudFormation を使用して、開発環境のスタックイベント履歴を表示します。

  1. AWS CloudFormation コンソールを開きます。詳細については、「AWS CloudFormation コンソールにログイン」を参照してください。

  2. AWS CloudFormation コンソールで、スタック を選択します。

  3. ［スタック］ページで、作成に失敗した開発環境の名前を選択します。

  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  サービスに関連する問題のトラブルシューティングについて概説します。

for の File Explorer AWS Cloud9 IDE 内にサブフォルダ構造 /projects/projects を作成することはできません CodeCatalyst。

問題： の File Explorer で AWS Cloud9 IDEサブフォルダ構造 /projects/projects を作成すると CodeCatalyst、このディレクトリを開くことができないことを示すエラーメッセージが表示されます。

考えられる原因： 現在、 for の File Explorer AWS Cloud9 IDE を使用して、同じ名前のフォルダ内にサブフォルダ構造/プロジェクトを作成することはできません CodeCatalyst。File Explorer から AWS Cloud9 IDEこのディレクトリ内のファイルにアクセスすることはできませんが、コマンドラインを使用してアクセスできます。この問題は /projects/projects のファイルパスにのみ影響します。/test/projects や /projects/test などのファイルパスは正常に機能します。これは既知の問題であり、 の AWS Cloud9 IDE File Explorer にのみ影響します CodeCatalyst。

推奨される解決策： 別のファイル名と構造を使用してください。

実行中のアプリケーションを の外部に表示できない IDE

問題： あなたや他のユーザーが の外部にあるウェブブラウザタブに実行中のアプリケーションを表示しようとするとIDE、そのウェブブラウザタブにエラーが表示されるか、タブが空白になります。

考えられる原因:

  • アプリケーションで が実行されていませんIDE。

  • アプリケーションが 127.0.0.1 または localhost の IP で実行しています。

  • アプリケーションは開発環境で実行されています AWS Cloud9 EC2。さらに、対応する Amazon EC2インスタンスに関連付けられている 1 つ以上のセキュリティグループは、アプリケーションが必要とするプロトコル、ポート、または IP アドレスに対するインバウンドトラフィックを許可しません。

  • アプリケーションは、 AWS Cloud9 SSH AWS クラウドコンピューティングインスタンス (Amazon EC2インスタンスなど) の開発環境で実行されています。さらに、対応するインスタンスに関連付けられている仮想プライベートクラウド (VPC) 内のサブネットACLのネットワークでは、アプリケーションが必要とするプロトコル、ポート、または IP アドレスを介したインバウンドトラフィックは許可されません。

  • URL が正しくありません。

  • アプリケーションプレビュータブURLの は、インスタンスのパブリック IP アドレスの代わりにリクエストされています。

  • 127.0.0.1 または localhost の IP を含むアドレスに移動しようとしています。これらは、環境内のリソースではなく、ローカルコンピュータ上のリソースへのアクセスIPsを試みます。

  • インスタンスのパブリック IP アドレスが変更されています。

  • ウェブリクエストは、アプリケーションが必要とするプロトコル、ポート、または IP アドレス経由のトラフィックをブロックする仮想プライベートネットワーク (VPN) から発信されます。

  • アプリケーションは SSH環境で実行されています。ただし、サーバーまたは関連付けられたネットワークが、アプリケーションで必要とするプロトコル、ポート、または IP アドレスを介したインバウンドトラフィックを許可していません。

推奨される解決策:

  • アプリケーションで が実行されていることを確認しますIDE。

  • アプリケーションが 127.0.0.1 または localhost の IP を使用して実行されていないことを確認します。Node.js および Python の例については、「アプリケーションの実行」を参照してください。

  • アプリケーションが AWS クラウドコンピューティングインスタンス (Amazon EC2インスタンスなど) で実行されているとします。この場合、対応するインスタンスに関連付けられているすべてのセキュリティグループが、アプリケーションで必要とするプロトコル、ポート、および IP アドレスを介したインバウンドトラフィックを許可していることを確認します。指示については、実行中のアプリケーションをインターネット上で共有するの ステップ 2: インスタンスのセキュリティグループを設定する を参照してください。Amazon VPCユーザーガイドの「 のセキュリティグループVPC」も参照してください。

  • アプリケーションが AWS クラウドコンピューティングインスタンスで実行されているとします。さらに、対応するインスタンスVPCに関連付けられている のサブネットにネットワークACLがあります。次に、アプリケーションが必要とするプロトコル、ポート、IP アドレスを介したインバウンドトラフィックがネットワークでACL許可されていることを確認します。指示については、実行中のアプリケーションをインターネット上で共有するの ステップ 3: インスタンスのサブネットをセットアップする を参照してください。Amazon ユーザーガイドの「NetworkACLs」も参照してください。 VPC

  • プロトコル (およびポートを指定する必要がある場合はポート) URLを含むリクエストする が正しいことを確認します。指示については、実行中のアプリケーションをインターネット上で共有するの ステップ 4: 実行中のアプリケーションの を共有する URL を参照してください。

  • 形式 https://12a34567b8cd9012345ef67abcd890e1.vfs.cloud9.us-east-2.amazonaws.com/ ( 12a34567b8cd9012345ef67abcd890e1は環境 AWS Cloud9 に割り当てる ID、 us-east-2 は環境の AWS リージョンの ID) URLで をリクエストすることはお勧めしません。これは、 環境IDEの が開いていて、アプリケーションが同じウェブブラウザで実行されている場合にのみURL機能します。

  • 127.0.0.1 または localhost の IP を含むアドレスに移動しようとしているとします。代わりに、実行中のアプリケーションの正しい非ローカルアドレスに移動してみてください。詳細については、「実行中のアプリケーションをインターネット経由で共有する」を参照してください。

  • アプリケーションが AWS クラウドコンピューティングインスタンスで実行されているとします。インスタンスのパブリック IP アドレスが変更されているかどうかを確認します。インスタンスのパブリック IP アドレスは、インスタンスが再起動されると変更される可能性があります。この IP アドレスの変更を防ぐには、Elastic IP アドレスを割り当てて、それを実行中のインスタンスに割り当てます。指示については、実行中のアプリケーションをインターネット上で共有するの ステップ 4: 実行中のアプリケーションの を共有する URL を参照してください。

  • ウェブリクエストが から発信されている場合はVPN、 がアプリケーションに必要なプロトコル、ポート、IP アドレス経由のトラフィックVPNを許可していることを確認します。を変更できない場合はVPN、ネットワーク管理者にお問い合わせください。または、可能であれば、別のネットワークからウェブリクエストを行います。

  • アプリケーションが独自のサーバーの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 Local をインストールできません

問題： で AWS Lambda 関数のローカルバージョンを実行しようとすると AWS Cloud9 IDE、ダイアログボックスが表示されます。ダイアログボックス AWS Cloud9 には、 でローカルバージョンの AWS Lambda 関数を実行するために SAM Local. AWS Cloud9 needs SAM Local のインストールに問題があると表示されますIDE。SAM Local がインストールされるまで、 でローカルバージョンの Lambda 関数を実行することはできませんIDE。

Cause: AWS Cloud9 環境内の想定されるパスに SAM Local が見つかりません。これは です~/.c9/bin/sam。これは、SAMLocal がまだインストールされていないか、インストールされている場合は、その場所に AWS Cloud9 見つからないためです。

推奨される解決策： Local のインストール AWS Cloud9 が完了するまで待機するかSAM、自分でインストールできます。

Local のインストールの試みがどのように AWS Cloud9 行われているかを確認するにはSAM、メニューバーの「Window」、「Installer」を選択します。

SAM Local を自分でインストールするには、「 デベロッパーガイド」の「Linux CLI AWS SAMでの のインストール」の手順に従います。 AWS Serverless Application Model

AWS Control TowerAWS Cloud9を使用して Amazon EC2環境を作成しようとすると、エラーが発生します。「環境の作成が失敗しましたが、エラー: 次のフック (複数可) が失敗しました:[ControlTower::Guard::Hook]」。

問題： AWS Cloud9 と AWS Control Tower プロアクティブコントロール CT との互換性の問題がありますEC2。PR.8。このコントロールが有効になっている場合、 でEC2環境を作成することはできません AWS Cloud9。

Cause: AWS Control Tower は、 AssociatePublicIpAddressパラメータが AWS CloudFormation テンプレートに存在することを期待しています。現在、このパラメータは追加できません。

推奨される解決策: controlCT を無効にしますEC2。コンソールから 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は起動に失敗し、問題のデバッグが困難になる可能性があります。

推奨される解決策 : アクセスを提供するには、Amazon AWS Cloud9 EBSボリュームで使用されるカスタマーマネージドキーにAWSServiceRoleForAWSCloud9、、 のサービスにリンクされたロールを追加します。

このタスクの詳細については、「規範的ガイダンスパターン」の「デフォルトの暗号化で Amazon EBSボリューム AWS Cloud9 を使用する を作成する」を参照してください。 AWS

(先頭に戻ります)

ライセンス設定が Amazon EC2インスタンスに関連付けられている場合、 AWS License Manager コンソール AWS Cloud9 から起動できません

問題： コンソールから環境を起動 AWS Cloud9 EC2しようとすると、エラーメッセージunable to access your environmentが返されます。

考えられる原因： AWS License Manager 全体でソフトウェアベンダーライセンスの管理を合理化します AWS クラウド。License Manager を設定するときは、エンタープライズ契約の条項に基づくライセンスルールのセットであるライセンス設定を作成します。これらのライセンス設定は、Amazon マシンイメージ (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 (クリックしてページをロード)］ボタンを選択します。

アプリケーションプレビューまたはファイルプレビュー通知:「サードパーティーの Cookie が無効になっています」

問題: アプリケーションまたはファイルをプレビューしようとすると、次のメッセージと通知が表示されます。「ブラウザでサードパーティーの Cookie が無効になっているため、プレビュー機能が無効になっています。」

原因： サードパーティーの Cookie は、 を開くためには必要ありません AWS Cloud9 IDE。ただし、アプリケーションプレビュー機能またはファイルプレビュー機能を使用するには、サードパーティーの Cookie を有効にする必要があります。

解決策： ウェブブラウザでサードパーティーの Cookie を有効にし、 を再ロードしてからIDE、プレビューを再度開いてみます。

お使いのウェブブラウザでこの精度が許容される場合は、 AWS Cloud9に対してのみサードパーティーの Cookie を有効にできます。そのためには、 AWS Cloud9を使用するサポート対象のドメインに応じて、次のドメインを指定します。

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。

  • アプリケーションが複数のポート経由で実行されている。

  • アプリケーションが 8080、8081、または 8082 以外のポート経由で実行されている。

  • アプリケーションが 127.0.0.1、localhost、または 0.0.0.0 以外の IP で実行されている。

  • ポート (8080、8081、または 8082) は、プレビュータブURLの で指定されていません。

  • ネットワークがポート 8080、8081、または 8082 へのインバウンドトラフィックをブロックしています。

  • 127.0.0.1、localhost、または 0.0.0.0 の IP を含むアドレスに移動しようとしています。デフォルトでは、 は AWS Cloud9 IDEローカルコンピュータに移動しようとします。環境に接続されているインスタンスや独自のサーバーに移動しようとはしません。

推奨される解決策:

  • アプリケーションで が実行されていることを確認しますIDE。

  • アプリケーションが を使用して実行されていることを確認しますHTTP。Node.js および Python の例については、「アプリケーションの実行」を参照してください。

  • アプリケーションが 1 つのポート経由のみで実行されていることを確認します。Node.js および Python の例については、「アプリケーションの実行」を参照してください。

  • アプリケーションがポート 8080、8081、または 8082 経由で実行されていることを確認します。Node.js および Python の例については、「アプリケーションの実行」を参照してください。

  • アプリケーションが IP 127.0.0.1、localhost、または 0.0.0.0 を使用して実行されていることを確認します。Node.js および Python の例については、「アプリケーションの実行」を参照してください。

  • プレビュータブURLの :8082に:8080:8081、、または を追加します。

  • ネットワークがポート 8080、8081、または 8082 経由のインバウンドトラフィックを許可していることを確認します。ネットワークを変更できない場合は、ネットワーク管理者にお問い合わせください。

  • 127.0.0.1、localhost、または 0.0.0.0 の IP を含むアドレスに移動しようとしている場合は、代わりに https://12a34567b8cd9012345ef67abcd890e1.vfs.cloud9.us-east-2.amazonaws.com/ のアドレスに移動してみてください。このアドレスの場合、12a34567b8cd9012345ef67abcd890e1 は AWS Cloud9 が環境に割り当てる ID です。us-east-2 は環境の AWS リージョン の ID です。また、 の外部でこのアドレスに移動することもできますIDE。ただし、これは、環境IDEの が開いていて、アプリケーションが同じウェブブラウザで実行されている場合にのみ機能します。

  • 上記の条件がすべて満たされていることを確認した後で、アプリケーションを停止してから再度起動してみてください。

  • アプリケーションを停止してから再度起動した場合は、メニューバーで再度［Preview (プレビュー)］、［Preview Running Application (実行中のアプリケーションのプレビュー)］または［Tools (ツール)］、［Preview (プレビュー)］、［Preview Running Application (実行中のアプリケーションのプレビュー)］を選択します。対応するアプリケーションプレビュータブが既に表示されている場合は、そのタブで［Refresh (最新の情報に更新)］ボタン (円状の矢印) を選択します。

サイトへの接続が安全ではないIDEため、 でウェブコンテンツをプレビューできない

問題： 環境でホスト AWS Cloud9 EC2されている WordPress サイトなどのウェブコンテンツにアクセスしようとすると、IDEプレビューウィンドウには表示されません。

考えられる原因： デフォルトでは、 AWS Cloud9 IDEのアプリケーションプレビュータブでアクセスするすべてのウェブページがHTTPSプロトコルを自動的に使用します。ページに安全でないhttpプロトコルURIが含まれている場合、自動的に に置き換えられますhttps。また、手動で https を http に戻す変更を行っても、安全でないコンテンツにアクセスすることはできません。

推奨される解決策： でプレビューしようとしているウェブサイトから安全でないHTTPスクリプトやコンテンツを削除しますIDE。の実装に関するガイダンスについては、ウェブサーバーまたはコンテンツ管理システムの指示に従ってくださいHTTPS。

ファイルをプレビューすると 499 エラーが返される

問題： 属性を含む<script>要素を含むファイルをプレビューするために を使用し AWS Cloud9 IDE、 src 属性を typeに設定しようとするとmodule、499 エラーが発生し、スクリプトは想定どおりに実行されません。

原因： の AWS Cloud9 IDEファイルプレビューフェッチリクエストでは、認証のためにウェブブラウザから Cookie を送信する必要があります。デフォルトでは、ウェブブラウザは、通常のスクリプトリクエストに対して Cookie を送信します。crossorigin 属性を追加しない限り、モジュールスクリプトリクエストに対しては Cookie を送信しません。

解決策: crossorigin 属性を <script> 要素に追加します。例えば、<script type="module" src="index.js" crossorigin></script> と指定します。次に、変更したファイルを保存し、もう一度プレビューを試みます。

パフォーマンス

次のセクションでは、パフォーマンスに関連する問題のトラブルシューティングについて概説します。

AWS Cloud9 IDE かなりの時間凍結する

問題： 起動時、および更新を実行すると、 AWS Cloud9 IDEターミナルはかなりの時間フリーズし、使用できなくなります。

原因: ご使用の環境に大量のファイルがあり、 AWS Cloud9のファイル監視モジュールによって再帰的に監視されている可能性があります。

推奨される解決策: ファイル監視の深さを減らし (最小値は 1)、大きいフォルダや、ソースコードに関係のないフォルダ (ビルド出力/アーティファクト、サードパーティパッケージ) を、無視するパターンに追加することを検討できます。これを行うには、[設定] > [ユーザー設定] > [ファイル監視] に移動します。これにより Toolkit が正しく動作 CodeLenses AWS しないことに注意してください。

別の解決策としては、検索するファイルの最大数を減らして、ソースコードに関係のない大きなファイルやフォルダを無視することを検討します。これを行うには、[設定] > [プロジェクト設定] > [フォルダを指定して検索] に移動します。これにより、無視したフォルダはファイル検索に表示されなくなることに注意してください。

コンソールの警告:「最小限のコード補完エンジンに切り替えます...」

問題： AWS Cloud9 コンソールで作業する場合 ( を開くIDE場合や IDEのウェブページを更新する場合など）、このメッセージが表示されます。「この環境では、1 つ以上のセッションまたはコラボレーターがアクティブです。メモリを節約するために最小限のコード補完エンジンに切り替えます。」」というメッセージが表示される。このメッセージと相関して、コード補完の動作が遅いか断続的になっている可能性がある。

原因： コード完了エンジンを実行すると、環境からメモリとCPUサイクルが取得されます。さらに、共同作業者および追加のセッションごとに個別のコード補完エンジンが必要です。特に などの小さなインスタンスサイズで、リソースの使用が多すぎないようにするには t2.nano また、t2.micro、最小コード完了エンジン AWS Cloud9 に切り替えます。

推奨される解決策： 頻繁に長時間コラボレーションする場合は、EC2環境を作成するときにより大きな Amazon EC2インスタンスを選択します。または、容量の大きいインスタンスにSSH環境を接続します。

注記

より大きな Amazon EC2インスタンスを選択すると AWS アカウント 、 に追加料金が発生する可能性があります。詳細については、「Amazon EC2料金」を参照してください。

IDE 警告：「この環境はメモリ不足」または「この環境はCPU負荷が高い」

問題： IDEの実行中に、「この環境のメモリ不足」または「この環境のCPU負荷が高い」というフレーズを含むメッセージが表示されます。

原因： には、遅延やハングなしで実行を継続するための十分なコンピューティングリソースがないIDE可能性があります。

推奨される解決策:

  • 実行中のプロセスを 1 つ以上停止し、使用可能なメモリを解放してください。これを行うには、環境IDEの のメニューバーで、ツール、プロセスリスト を選択します。停止するプロセスごとに、プロセスを選択して［Force Kill (強制終了)］を選択します。

  • 環境で swap ファイルを作成します。スワップファイルは、オペレーティングシステムが仮想メモリとして使用できる環境内のファイルです。

    環境で現在スワップメモリを使用しているかどうかを確認するには、環境のターミナルセッションで 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インスタンスを移動またはサイズを変更するには、「」を参照してくださいAmazon EBSボリュームからの AWS Cloud9 IDEの移動。他のインスタンスまたはサーバータイプについては、インスタンスまたはサーバーのドキュメントを参照してください。

でファイルをアップロードできません AWS Cloud9 IDE

問題： ユーザーは に大きなファイルをアップロードできません AWS Cloud9 IDE。アップロードは失敗しています。

原因： 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 メガバイト/秒に制限されます。

推奨される解決策： ファイルの転送速度を上げるには、 CLI AWS Cloud9 IDEの を使用して Amazon S3 にファイルをアップロードし、Amazon S3 を使用してそこからファイルをダウンロードします。

サイトへの接続が安全ではないIDEため、 でウェブコンテンツをプレビューできない

問題： 環境でホスト AWS Cloud9 EC2されている WordPress サイトなどのウェブコンテンツにアクセスしようとすると、IDEプレビューウィンドウには表示されません。

考えられる原因： デフォルトでは、 AWS Cloud9 IDEのアプリケーションプレビュータブでアクセスするすべてのウェブページがHTTPSプロトコルを自動的に使用します。ページに安全でないhttpプロトコルURIが含まれている場合、自動的に に置き換えられますhttps。また、手動で https を http に戻す変更を行っても、安全でないコンテンツにアクセスすることはできません。

推奨される解決策： でプレビューしようとしているウェブサイトから安全でないHTTPスクリプトやコンテンツを削除しますIDE。の実装に関するガイダンスについては、ウェブサーバーまたはコンテンツ管理システムの指示に従ってくださいHTTPS。

(先頭に戻ります)

サードパーティのアプリケーションとサービス

次のセクションでは、サードパーティのアプリケーションとサービスに関連する問題のトラブルシューティングについて概説します。

tmux セッションエラーのために AWS Cloud9 でターミナルウィンドウと対話できない

問題： で新しいターミナルウィンドウを起動しようとすると AWS Cloud9、予想されるコマンドラインインターフェイスは使用できません。コマンドプロンプトがないため、テキストを入力できません。tmux: need UTF-8 locale (LC_CTYPE) や invalid LC_ALL, LC_CTYPE or LANG などのエラーメッセージが返されます。

考えられる原因： 応答しないターミナルは、tmux エラーによって引き起こされる可能性があります。 は tmux ユーティリティ AWS Cloud9 を使用します。これにより、ページがリロードされたり、開発環境に再接続しても、ターミナルに表示される情報は保持されます。

tmux セッションでは、ターミナルウィンドウの表示内容はクライアントによって処理されます。クライアントは、複数のセッションを管理できるサーバーと通信します。サーバーとクライアントは、tmp フォルダにあるソケットを介して通信します。開発環境に tmp フォルダがないか、過度に制限的なアクセス許可が適用されている場合、tmux セッションは実行できません。この場合、 のターミナルウィンドウは応答しIDEなくなります。

推奨される解決策: tmux エラーによってターミナルウィンドウと対話できない場合は、別の方法を使用して適切な許可を持つ tmp フォルダを作成する必要があります。これにより、tmux セッションを実行できます。1 つの解決策は、.bash_profile または .bashrc ファイルの LC_CTYPE をエクスポートすることです。もう 1 つの推奨ソリューションは、 AWS Systems Manager を使用してホスト管理設定をセットアップすることです。これにより、Amazon EC2コンソールを介して関連するインスタンスにアクセスできます。

ホスト管理の設定

  1. まず、 AWS Cloud9 コンソールで、環境のインスタンスの名前を見つけます。これを行うには、[Your environments] (自分の環境) ページで該当するパネルを選択し、[View details] (詳細を表示) を選択します。[環境の詳細] ページで [インスタンスに移動] を選択します。Amazon EC2コンソールで、アクセスする必要があるインスタンスの名前を確認します。

  2. AWS Systems Manager コンソールに移動し、ナビゲーションペインでクイックセットアップ を選択します。

  3. [クイックセットアップ] ページで [作成] を選択します。

  4. [設定タイプ] では、[ホスト管理] に移動し、[登録] を選択します。

  5. [ホスト管理構成オプションのカスタマイズ] の [ターゲット]セクションで、[手動]を選択します。

  6. アクセスするEC2インスタンスを選択し、「 の作成」を選択します。

インスタンスに接続してコマンドを実行する

注記

次の手順は、新しいEC2コンソール用です。

  1. Amazon EC2コンソールのナビゲーションペインで、インスタンスを選択し、接続するインスタンスを選択します。

  2. [接続]を選択します。

    [Connect] (接続) がアクティブ化されていない場合は、最初にインスタンスを起動する必要があります。

  3. [Connect to your instance] (インスタンスへ接続) ペインの [Connection method] (接続方法) で、[Session Manager]、[Connect] (接続) の順に選択します。

  4. 表示されたターミナルセッションウィンドウで、次のコマンドを入力します。これらのコマンドは、tmux ソケットを使用するための適切なアクセス許可を持つ tmp フォルダを作成します。

    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++ プロジェクト

問題： で C++ プロジェクトをデバッグしようとすると、gdbデバッガーにエラーが報告されましたIDE。

考えられる原因： AWS Cloud9 環境が特定のEC2インスタンスタイプ (例: t3.smallまたは ) を使用しているとしますm5.large。その後、 を実行してデバッグしようとすると、デバッグエラーが発生する可能性があります。C++ IDEの組み込みランナーを使用してプロジェクトを実行します。このエラーは、環境にプリインストールされている のバージョン gdb (GNUプロジェクトデバッガー) が特定のプロセッサプラットフォームで機能しないために発生する可能性があります。次のエラーコードが表示される可能性があります。

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 バージョンに問題がある可能性があります。

推奨ソリューション: Node.js を AWS Cloud9にインストールする方法について、「ステップ 1: 必要なツールをインストールする」セクションを参照してください。