「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」
AWS Cloud9 のトラブルシューティング
以下の情報を使用して、AWS Cloud9 の問題を特定および対処します。
該当する問題が以下に示されていない場合や、追加のヘルプが必要な場合は、AWS Cloud9 ディスカッションフォーラム
トピック
- 環境 の作成エラー: 「EC2 インスタンスを作成できません...」
- 環境 の作成エラー: 「sts:AssumeRole を実行する権限がありません」
- コンソールエラー: 「ユーザーにリソースでアクションを実行する権限がありません」
- フェデレーテッド ID で 環境 を作成できない
- を開くことができない環境
- インストーラがハングまたは失敗するAWS Cloud9
- SSH 環境 エラー: 「pty.js をインストールするには Python バージョン 2.7 が必要です」
- アプリケーションプレビューまたはファイルプレビュー通知: 「サードパーティーの Cookie 無効」
- アプリケーションプレビュータブにエラーが表示される、または空白になる
- 実行中のアプリケーションを IDE の外部で表示できない
- を再ロードしたら、アプリケーションプレビューを更新する必要があります環境
- HTTP を使用する AWS Cloud9 IDE でアプリケーションをプレビューできない
- EC2 環境 で一部のコマンドまたはスクリプトを実行できない
- AWS CLI / aws-shell エラー: の「リクエストに含まれているセキュリティトークンが無効です」EC2 環境
- Amazon EC2 インスタンスは自動的に更新されません
- Lambda ローカル関数の実行エラー: SAM Local をインストールできない
- IDE 警告: 「この 環境 のメモリが不足しています」または「この 環境 の CPU 負荷が高くなっています」
- ファイルをプレビューすると 499 エラーが返される
- 環境 削除エラー: 「1 つ以上の 環境 を削除できませんでした」
- コンソールの警告: 「最小限のコード補完エンジンに切り替えます...」
- 以下を表示した後に AWS Cloud9 インストーラが終了しない: 「Cloud9 IDE 1 のパッケージ」
- EC2-Classic アカウントの VPC エラー: 「環境にアクセスできません」
- 環境を開くことができません:AWS Cloud9 "この環境には、共同作業者が現在アクセスすることはできません。管理された一時的な認証情報の削除が完了するまで待つか、この環境の所有者に連絡してください。"
- を使用して AWSCloud9SSMInstanceProfile を作成したときのエラーメッセージレポート「インスタンスプロファイル EC2 環境 がアカウントに存在しません」AWS CloudFormation
- を使用して EC2 環境 を作成するときに「リソースで ssm:StartSession を実行する権限がありません」と報告するエラーメッセージAWS CloudFormation
- VPC の IP アドレスが Docker で使用されているため、EC2 環境 に接続できない
- 実行時のエラー:AWS Toolkit 「環境が inode を使い果たしています。'fs.inotify.max_user_watches' の制限を増やしてください。」
- 注意: コラボレーションサポートの依存関係をインストールできませんでした
環境 の作成エラー: 「EC2 インスタンスを作成できません...」
問題: を作成しようとすると、「アカウントの検証とアクティベーション中に、アカウントで EC2 インスタンスを作成できません」という内容のメッセージが表示されます。AWS Cloud9 開発環境
原因: 現在、AWS はお客様の AWS アカウントを検証およびアクティブ化中です。アクティベーションが完了するまで (最大 24 時間かかる場合があります)、この環境やその他の環境を作成することはできません。
解決策: 後で 環境 をもう一度作成してみてください。24 時間以上経過してもこのメッセージがまだ表示される場合は、aws-verification@amazon.com
(先頭に戻る)
環境 の作成エラー: 「sts:AssumeRole を実行する権限がありません」
問題: 新しい 環境 を作成しようとすると、このエラーが表示されます。「sts:AssumeRole を実行する権限はありません。」と 環境 が作成されません。
考えられる原因: サービスにリンクされたロールが AWS Cloud9 アカウントに存在しません。AWS
推奨される解決策: (AWS Cloud9) または aws-shell を使用して次のコマンドを実行して、AWS アカウント内に AWS Command Line Interface サービスにリンクされたロールを作成します。AWS CLI
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 Cloud9 を作成または管理しようとすると、「User arn:aws:iam::123456789012:user/MyUser には cloud9:action on resource arn:aws:cloud9:us-east-2:123456789012:environment:12a34567b8cd67cd890e」 のようなフレーズを含むエラーが表示されます。AWS Cloud9 開発環境
-
arn:aws:iam::123456789012:user/MyUser
は、リクエストするユーザーの Amazon リソースネーム (ARN) です。 -
action
は、ユーザーがリクエストしたオペレーションの名前です。 -
arn:aws:cloud9:us-east-2:123456789012:environment:12a34567b8cd9012345ef67abcd890e1
は、ユーザーがオペレーションを実行するためにリクエストした 環境 の ARN です。
原因: コンソールにサインインするときに使用したユーザーに、このアクションを実行するための正しい AWS Cloud9 アクセス権限がありません。AWS
解決策: ユーザーに正しい AWS アクセス許可があることを確認して、再度アクションの実行を試みます。詳細については、次のトピックの 1 つ以上を参照してください。
-
ステップ 3. 追加 AWS Cloud9 グループへのアクセス許可チームセットアップ
-
ステップ 6. 組織内のグループとユーザーが使用できるようにする AWS Cloud9エンタープライズセットアップ
-
環境メンバー のアクセスロールについて共有環境を使用する
(先頭に戻る)
フェデレーテッド ID で 環境 を作成できない
問題: フェデレーテッドアイデンティティを使用して AWS を作成しようとすると、アクセスエラーメッセージが表示され、環境は作成されません。AWS Cloud9 開発環境
原因: AWS Cloud9 はサービスにリンクされたロールを使用します。サービスにリンクされたロールは、iam:CreateServiceLinkedRole
コールを使用してアカウントに初めて 環境 が作成されたときに作成されます。ただし、フェデレーティッドユーザーは IAM APIs を呼び出すことができません。 詳細については、GetFederationToken の「」を参照してください。AWS Security Token Service API リファレンス
解決策: アカウント管理者に、AWS のサービスにリンクされたロールを作成するように依頼してください。AWS Cloud9 コンソールを使用するか、IAM (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
詳細については、https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.htmlの「IAM ユーザーガイドサービスにリンクされたロールの使用」を参照してください。
(先頭に戻る)
を開くことができない環境
問題: を開こうとすると、環境 が長時間 (5 分以上) 表示されません。IDE
考えられる原因:
-
AWS Cloud9 コンソールにサインインした IAM ユーザーに 環境 を開くために必要な AWS アクセス権限がない。
-
環境 が AWS クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) に関連付けられている場合:
-
インスタンスに関連付けられた VPC が、AWS Cloud9 用に正しく設定されていません。
-
AWS Cloud9 がインスタンスに接続しようとしたときにインスタンスが状態から状態への遷移中、または自動化されたステータスチェックに失敗した。
-
-
環境 が SSH 環境 の場合、関連付けられているクラウドコンピューティングインスタンスまたは独自のサーバーが AWS Cloud9 によるアクセスを許可するように正しくセットアップされていない。
推奨される解決策:
-
AWS Cloud9 コンソールにサインインしている IAM ユーザーに、環境 を開くために必要な AWS アクセス権限があることを確認して、再度 環境 を開きます。詳細については以下を参照するか、AWS アカウントの管理者に確認してください。
-
ステップ 3. 追加 AWS Cloud9 グループへのアクセス許可チームセットアップ
-
AWS Cloud9 用の AWS 管理 (事前定義) ポリシー認証とアクセスコントロール
-
AWS Cloud9 を使用したチームのカスタマー管理ポリシーの例高度なチームセットアップ
-
カスタマー管理ポリシーの例認証とアクセスコントロール
-
の「IAM ユーザーのアクセス許可の変更」IAM ユーザーガイド
-
の「IAM ポリシーのトラブルシューティング」IAM ユーザーガイド
サインインしている IAM ユーザーがまだ 環境 を開くことができない場合は、いったんサインアウトしてから、アカウントの AWS アカウントルートユーザーまたは IAM 管理者ユーザーとしてサインインし直してみます。その後、もう一度 環境 を開いてみてください。この方法で 環境 を開くことができる場合、IAM ユーザーのアクセス権限に問題がある可能性が最も高いと言えます。
-
-
環境 が AWS クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) に関連付けられている場合:
-
インスタンスに関連付けられている VPC が AWS Cloud9 用に正しく設定されていることを確認してから、もう一度 環境 を開いてください。詳細については、「Amazon VPC 要件 AWS Cloud9」を参照してください。
AWS クラウドコンピューティングインスタンスに関連付けられている VPC が AWS Cloud9 用に正しく設定されているが、それでも 環境 を開くことができない場合は、インスタンスのセキュリティグループによって AWS Cloud9 へのアクセスが妨げられている可能性があります。トラブルシューティングの手法としてのみ、セキュリティグループをチェックして、少なくともポート 22 経由のインバウンド SSH トラフィックがすべての IP アドレス (
Anywhere
または0.0.0.0/0
) について許可されていることを確認してください。手順については、の「セキュリティグループについて説明する」および「セキュリティグループルールを更新するLinux インスタンス用 Amazon EC2 ユーザーガイド」を参照してください。追加の VPC トラブルシューティングの手順については、関連する 5 分間のビデオ「AWS ナレッジセンターのビデオ:」をご覧ください。 ウェブサイトの
VPC のインスタンスに接続できない場合、どうすればよいですか?YouTube 警告 トラブルシューティングが完了したら、「AWS Cloud9 のインバウンド SSH IP アドレスの範囲」の説明に従って、インバウンドルールを適切なアドレス範囲に設定してください。
-
インスタンスを再起動して、インスタンスが実行されており、すべてのシステムチェックをパスしていることを確認してから、もう一度 環境 を開いてください。詳細については、の「インスタンスの再起動」および「ステータスチェックの表示Linux インスタンス用 Amazon EC2 ユーザーガイド」を参照してください。
-
-
環境 が SSH 環境 の場合、関連付けられているクラウドコンピューティングインスタンスまたは独自のサーバーが AWS Cloud9 によるアクセスを許可するように正しくセットアップされていることを確認してから、もう一度 環境 を開いてください。詳細については、「AWS Cloud9 SSH 開発環境 ホストの要件」を参照してください。
(先頭に戻る)
インストーラがハングまたは失敗するAWS Cloud9
問題: インストーラをダウンロードして実行すると、1 つ以上のエラーメッセージが表示され、インストーラのスクリプトに AWS Cloud9 は表示されません。Done
原因: インストーラで 1 つ以上のエラーが発生し、このエラーから復旧できないために失敗しています。AWS Cloud9
解決策: で、一般的な問題、考えられる原因、および推奨される解決策を参照してください。AWS Cloud9 インストーラのトラブルシューティング
(先頭に戻る)
SSH 環境 エラー: 「pty.js をインストールするには Python バージョン 2.7 が必要です」
問題: を開くと、AWS Cloud9 SSH 開発環境 のターミナルに「pty.js をインストールするには Python バージョン 2.7 が必要です」で始まるメッセージが表示されます。AWS Cloud9 IDE
原因: が想定どおりに動作するには、Python バージョン 2.7 がインストールされている必要があります。SSH 環境
解決策: に Python バージョン 2.7 をインストールします。環境バージョンを確認するには、サーバーのターミナルからコマンド python --version
を実行します。サーバーに Python 2.7 をインストールするには、次のいずれかを参照してください。
-
ステップ 1. Python をインストールします。Python サンプルの 。
-
Python ウェブサイトの Download Python
および Python Packaging User Guide の「Installing Packages」。
(先頭に戻る)
アプリケーションプレビューまたはファイルプレビュー通知: 「サードパーティーの Cookie 無効」
問題: アプリケーションまたはファイルをプレビューしようとすると、次のメッセージが表示されて通知が表示されます。「ブラウザでサードパーティーの Cookie が無効になっているため、プレビュー機能は無効になっています。」
原因: AWS Cloud9 を開くためにサードパーティーの Cookie は必要ありませんが、アプリケーションプレビュー機能またはファイルプレビュー機能を使用するには、サードパーティーの Cookie を有効にする必要があります。IDE
解決策: ウェブブラウザでサードパーティーの Cookie を有効にし、IDE を再ロードして、もう一度プレビューを開いてみてください。
-
Apple Safari: Apple サポートウェブサイトの Safari
で Cookie と Web サイトのデータを管理します。 -
Google Chrome: Google Chrome ヘルプウェブサイトの Chrome で Cookie の削除、有効化、管理を行うの「
Cookie の設定を変更する」。 -
Internet Explorer: Microsoft サポートウェブサイトの Cookie の削除と管理を行うの「
Cookie のブロックと管理」を参照してください。 -
Microsoft Edge: サードパーティー Cookie のブロック
」を参照してください。 -
Mozilla Firefox: サードパーティーの Cookie を受け入れられる設定 (Mozilla サポートウェブサイトの「Cookie を有効または無効にする
」)。 -
他のウェブブラウザの場合は、そのウェブブラウザのドキュメントを参照してください。
AWS Cloud9 にのみサードパーティーの Cookie を有効化するには(ウェブブラウザでこの詳細度が可能な場合)、AWS を使用する先のサポートされている AWS Cloud9 リージョンに応じて、以下のドメインを指定します。
AWS リージョン | ドメイン |
---|---|
米国東部(バージニア北部) |
|
米国東部 (オハイオ) |
|
米国西部 (北カリフォルニア) |
|
米国西部 (オレゴン) |
|
アジアパシフィック (香港) |
|
アジアパシフィック (ムンバイ) |
|
アジアパシフィック (ソウル) |
|
アジアパシフィック (シンガポール) |
|
アジアパシフィック (シドニー) |
|
アジアパシフィック (東京) |
|
カナダ (中部) |
|
欧州 (フランクフルト) |
|
欧州 (アイルランド) |
|
欧州 (ロンドン) |
|
ヨーロッパ (ミラノ) |
|
欧州 (パリ) |
|
欧州 (ストックホルム) |
|
中東 (バーレーン) |
|
南米 (サンパウロ) |
|
(先頭に戻る)
アプリケーションプレビュータブにエラーが表示される、または空白になる
問題: のメニューバーで、[IDEPreview (プレビュー)]、[Preview Running Application (実行中のアプリケーションのプレビュー)] または [Tools (ツール)]、[Preview (プレビュー)]、[Preview Running Application (実行中のアプリケーションのプレビュー)] を選択して のプレビュータブでアプリケーションを表示しようとすると、タブにエラーが表示されるか、タブが空白になります。IDE
考えられる原因:
-
アプリケーションが IDE で実行されていない。
-
アプリケーションが HTTP を使用して実行されていない。
-
アプリケーションが複数のポート経由で実行されている。
-
アプリケーションが
8080
、8081
、または8082
以外のポート経由で実行されている。 -
アプリケーションが
127.0.0.1
、localhost
、または0.0.0.0
以外の IP で実行されている。 -
ポート (
8080
、8081
、または8082
) がプレビュータブの URL で指定されていない。 -
ネットワークがポート
8080
、8081
、または8082
へのインバウンドトラフィックをブロックしている。 -
IP
127.0.0.1
、localhost
、または0.0.0.0
を含むアドレスに移動しようとしている。 に組み込まれているデフォルトの動作では、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 に
:8080
、:8081
、または:8082
を追加します。 -
ネットワークがポート
8080
、8081
、または8082
経由のインバウンドトラフィックを許可していることを確認します。 ネットワークを変更できない場合は、ネットワーク管理者にお問い合わせください。 -
IP
127.0.0.1
、localhost
、または0.0.0.0
を含むアドレスに移動しようとしている場合、代わりに次のアドレスに移動してみます。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 の外部で表示できない
問題: 外部のウェブブラウザタブで実行中のアプリケーションを表示しようとすると、そのウェブブラウザタブにエラーが表示されるか、タブが空白になります。IDE
考えられる原因:
-
アプリケーションが IDE で実行されていない。
-
アプリケーションが
127.0.0.1
またはlocalhost
の IP で実行されている。 -
アプリケーションが AWS Cloud9 EC2 開発環境 で実行されており、対応する Amazon EC2 インスタンスに関連付けられている 1 つ以上のセキュリティグループが、アプリケーションで必要とするプロトコル、ポート、または IP アドレス経由のインバウンドトラフィックを許可していない。
-
アプリケーションが AWS クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) 用の AWS Cloud9 SSH 開発環境 で実行されており、対応するインスタンスに関連付けられている Virtual Private Cloud (VPC) のサブネットのネットワーク ACL が、アプリケーションで必要とするプロトコル、ポート、または IP アドレス経由のインバウンドトラフィックを許可していない。
-
URL に誤りがある。
-
インスタンスのパブリック IP アドレスではなく、アプリケーションプレビュータブの URL がリクエストされている。
-
IP
127.0.0.1
またはlocalhost
を含むアドレスに移動しようとしている。 これらの IPs は、環境 のリソースではなくローカルコンピュータ上のリソースにアクセスしようとします。 -
インスタンスのパブリック IP アドレスが変更された。
-
ウェブリクエストが、アプリケーションで必要とするプロトコル、ポート、または IP アドレス経由のトラフィックをブロックしている仮想プライベートネットワーク (VPN) から送信されている。
-
アプリケーションが SSH 環境 で実行されており、サーバーまたは関連付けられたネットワークが、アプリケーションで必要とするプロトコル、ポート、または IP アドレス経由のインバウンドトラフィックを許可していない。
推奨される解決策:
-
IDE でアプリケーションが実行されていることを確認します。
-
アプリケーションが IP
127.0.0.1
またはlocalhost
を使用して実行されていないことを確認します。 Node.js および Python の例については、「アプリケーションの実行」を参照してください。 -
アプリケーションが AWS クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) で実行されている場合は、対応するインスタンスに関連付けられているすべてのセキュリティグループが、アプリケーションで必要とするプロトコル、ポート、および IP アドレス経由のインバウンドトラフィックを許可していることを確認します。手順については、「ステップ 2. インスタンスのセキュリティ グループを設定する実行中のアプリケーションをインターネット経由で共有する」の「」を参照してください。また、の「VPC のセキュリティグループAmazon VPC ユーザーガイド」も参照してください。
-
アプリケーションが AWS クラウドコンピューティングインスタンスで実行されており、対応するインスタンスに関連付けられている VPC のサブネットにネットワーク ACL が存在する場合、そのネットワーク ACL でアプリケーションで必要とするプロトコル、ポート、および IP アドレス経由のインバウンドトラフィックを許可されていることを確認します。手順については、「ステップ 3. インスタンスのサブネットを設定する実行中のアプリケーションをインターネット経由で共有する」の「」を参照してください。『』の「ACLsネットワーク 」も参照してください。Amazon VPC ユーザーガイド
-
プロトコル (およびポートを指定する必要がある場合はポート) を含むリクエストしている URL が正しいことを確認します。詳細については、「ステップ 5. 実行中のアプリケーションURLを共有する実行中のアプリケーションをインターネット経由で共有する」の「」を参照してください。
-
https://12a34567b8cd9012345ef67abcd890e1.vfs.cloud9.us-east-2.amazonaws.com/
形式の URL (12a34567b8cd9012345ef67abcd890e1
は AWS Cloud9 が 環境 に割り当てる ID、us-east-2
は環境 の AWS リージョンの ID) のリクエストは推奨されません。この URL を使用するには、環境 の IDE が開いており、アプリケーションが同じウェブブラウザで実行されている必要があります。 -
IP
127.0.0.1
またはlocalhost
を含むアドレスに移動しようとしている場合、代わりに実行中のアプリケーションのローカルではない正しいアドレスに移動してみます。詳細については、「インターネット上で実行中のアプリケーションを共有」を参照してください。 -
アプリケーションが AWS クラウドコンピューティングインスタンスで実行されている場合、インスタンスのパブリック IP アドレスが変更されたかどうかを判断します。インスタンスのパブリック IP アドレスは、インスタンスが再起動されると変更される可能性があります。この IP アドレスの変更を防ぐには、Elastic IP アドレスを割り当てて、それを実行中のインスタンスに割り当てます。詳細については、「ステップ 5. 実行中のアプリケーションURLを共有する実行中のアプリケーションをインターネット経由で共有する」の「」を参照してください。
-
ウェブリクエストが VPN から送信されている場合は、その VPN でアプリケーションで必要とするプロトコル、ポート、および IP アドレス経由のトラフィックが許可されていることを確認します。VPN を変更できない場合は、ネットワーク管理者にお問い合わせください。または、可能であれば別のネットワークからウェブリクエストを行います。
-
アプリケーションが独自のサーバーの SSH 環境 で実行されている場合は、サーバーおよび関連付けられたネットワークで、アプリケーションで必要とするプロトコル、ポート、または IP アドレス経由のインバウンドトラフィックが許可されていることを確認します。サーバーまたは関連付けられているネットワークに変更を加えることができない場合は、サーバーまたはネットワークの管理者にお問い合わせください。
-
curl
コマンドに URL を続けて実行し、環境 のターミナルからアプリケーションの実行を試みます。このコマンドでエラーメッセージが表示される場合、AWS Cloud9 に関連しない他の問題がある可能性があります。
(先頭に戻る)
を再ロードしたら、アプリケーションプレビューを更新する必要があります環境
問題: アプリケーションプレビュータブを表示する 環境 を再ロードした後、タブにアプリケーションプレビューは表示されません。
原因: ユーザーは、無限ループを実行したり、非常に多くのメモリを使用するコードを記述して、アプリケーションプレビューの実行時に AWS Cloud9 IDE が一時停止または停止する場合があります。これを防止するには、環境 が再ロードされても、AWS Cloud9 ではアプリケーションプレビュータブを再ロードしません。
解決策: アプリケーションプレビュータブを表示する 環境 を再ロードした後で、アプリケーションプレビューを表示するには、タブの [Click to load the page (クリックしてページをロード)] ボタンを選択します。
(先頭に戻る)
HTTP を使用する AWS Cloud9 IDE でアプリケーションをプレビューできない
問題: のアプリケーションプレビュータブのアドレスボックスの URL は、常に AWS Cloud9 IDE で始まります。https
ボックスの https
を http
に変更して Enter
を押すと、タブにアプリケーションプレビューが表示されません。
原因: コードの安全性を向上させるため、IDE のアプリケーションプレビュータブのアドレスボックスで、AWS Cloud9 は常に https
を使用します。 この動作は変更できません。
解決策: ではなく http
で始まるアドレスを持つアプリケーションプレビューを表示するには、タブのアドレスボックスの https
を https
に変更して http
を押します。Enter
次に、[Open your page in a new tab
] ボタンを選択します。こうすることで、アプリケーションプレビューが HTTP を使用して別のウェブブラウザタブに表示されます。
(先頭に戻る)
EC2 環境 で一部のコマンドまたはスクリプトを実行できない
問題: を開いたら、一部のタイプのパッケージのインストール、AWS Cloud9 EC2 開発環境 や yum
などのコマンドの実行、通常他の Linux オペレーティングシステムで使用されるコマンドを含むスクリプトの実行はできません。apt
原因: が Amazon EC2 で使用する AWS Cloud9 インスタンスは、EC2 環境 (Red Hat Enterprise Linux (RHEL) に基づく) または Ubuntu Server に依存します。Amazon Linux
解決策: の IDE でパッケージをインストールまたは管理するか、コマンドまたはスクリプトを実行する場合は、その EC2 環境 のインスタンスに応じて、RHEL (Amazon Linux 用) または Ubuntu Server と互換性があることを確認してください。環境
(先頭に戻る)
AWS CLI / aws-shell エラー: の「リクエストに含まれているセキュリティトークンが無効です」EC2 環境
問題: (AWS Command Line Interface) または aws-shell を使用して AWS CLI の AWS Cloud9 IDE でコマンドを実行しようとすると、次のエラーが表示されます。EC2 環境「リクエストに含まれているセキュリティトークンが無効です。」
考えられる原因:
-
AWS 管理の一時認証情報 を有効にしている場合、これらの AWS 管理の一時認証情報 では許可されていないコマンドを実行しようとしています。許可されたコマンドの一覧については、「AWS 管理の一時認証情報 によってサポートされるアクション」を参照してください。
-
AWS 管理の一時認証情報 を有効にしており、環境 が共有 環境 である場合、環境 の所有者が 12 時間以内に 環境 を開いていないため、AWS Cloud9 が 環境 の AWS 管理の一時認証情報 を更新できません (AWS Cloud9 は、この 12 時間の制限を AWS セキュリティのベストプラクティスとして設定します)。
推奨される解決策:
-
AWS 管理の一時認証情報 を有効にしている場合、許可されているコマンドのみを実行します。AWS 管理の一時認証情報 によって許可されていないコマンドを実行する必要がある場合は、1 つの方法として、永続的認証情報を持つ AWS CLI または aws-shell を 環境 に設定することで、この制限を取り除くことができます。手順については、「パーマネントアクセス資格情報を作成し、 環境」を参照してください。
-
AWS Cloud9 が 環境 で一時的認証情報を更新できるように、環境 の所有者が 環境 を開きます。
詳細については、「AWS 管理の一時認証情報」を参照してください。
(先頭に戻る)
Amazon EC2 インスタンスは自動的に更新されません
問題: 最新のシステム更新は、Amazon EC2 に接続する AWS Cloud9 開発環境 インスタンスに自動的に適用されません。
原因: 最新のシステム更新を自動的に適用すると、事前の情報や承認なくコードや Amazon EC2 インスタンスで予期しない動作が発生する可能性があります。
推奨される解決策:
Linux インスタンス用 Amazon EC2 ユーザーガイド の「インスタンスソフトウェアの更新」の手順に従って、定期的に Amazon EC2 インスタンスにシステム更新を適用します。
インスタンスでコマンドを実行するには、インスタンスに接続されている 環境 から AWS Cloud9 IDE でターミナルセッションを使用できます。
または、ssh や PuTTY などの SSH リモートアクセスユーティリティを使用して、インスタンスに接続することもできます。これを行うには、ローカルコンピュータから、ssh-keygen や PuTTYgen などの SSH キーペア作成ユーティリティを使用します。 インスタンスに接続されている AWS Cloud9 IDE から 環境 を使用して、生成したパブリックキーをインスタンスに保存します。次に、生成されたプライベートキーとともに SSH リモートアクセスユーティリティを使用して、インスタンスにアクセスします。詳細については、ユーティリティのドキュメントを参照してください。
(先頭に戻る)
Lambda ローカル関数の実行エラー: SAM Local をインストールできない
問題: でローカルバージョンの AWS Lambda 関数を実行すると、AWS Cloud9 IDE が SAM Local のインストールで問題が発生したというダイアログボックスが表示されます。AWS Cloud9 は、AWS Cloud9 でローカルバージョンの AWS Lambda 関数を実行するために SAM Local を必要とします。IDESAM Local がインストールされるまで、IDE でローカルバージョンの Lambda 関数を実行することはできません。
原因: AWS Cloud9 は 環境 の予定されたパス (~/.c9/bin/sam
) で SAM Local を見つけられません。 これは、SAM Local がまだインストールされていないか、インストールされている場合は AWS Cloud9
がその場所に見つけられないためです。
推奨される解決策: によって SAM Local のインストールが完了するまで待つか、自分でインストールします。AWS Cloud9
SAM Local をインストールするために AWS Cloud9 が行っている動作を確認するには、メニューバーで [Window (ウィンドウ)]、[Installer] を選択します。
自分で SAM Local をインストールするには、『』の「Linux に AWS SAM CLI をインストールする」の手順に従います。AWS サーバーレスアプリケーションモデル 開発者ガイド
IDE 警告: 「この 環境 のメモリが不足しています」または「この 環境 の CPU 負荷が高くなっています」
問題: の実行中、「この IDE のメモリが不足しています」または「この 環境 の CPU 負荷が高くなっています」という内容のメッセージが表示されます。環境
原因: には、遅延やハングアップせずに実行を続けるのに十分なコンピューティングリソースがない可能性があります。IDE
推奨される解決策:
-
実行中のプロセスを 1 つ以上停止し、使用可能なメモリを解放してください。これを行うには、メニューバーにある 環境 用 IDE で、[Tools (ツール)]、[Process List (プロセスリスト)] を選択します。停止するプロセスごとに、プロセスを選択して [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
前述のコマンドは以下の処理を実行します。
-
/var
ディレクトリにswapfile
という 512 MB のファイルを作成します。 -
swapfile
ファイルのアクセス権限を所有者のみの読み取り/書き込みに変更します。 -
swapfile
ファイルをスワップファイルとして設定します。 -
情報を
/etc/fstab file
に書き込みます。これにより、システムが再起動するたびにこのスワップファイルが使用可能になります。
前述のコマンドを実行したら、再起動しなくてもこのスワップファイルをすぐに使用可能にするため、次のコマンドを実行します。
sudo swapon /var/swapfile
-
-
環境 をコンピューティングリソースの多いインスタンスまたはサーバーに移動するか、サイズを変更します。Amazon EC2 インスタンスを移動またはサイズ変更するには、「環境の移動とサイズ変更または暗号化 Amazon EBS ボリューム」を参照してください。他のインスタンスまたはサーバータイプについては、インスタンスまたはサーバーのドキュメントを参照してください。
(先頭に戻る)
ファイルをプレビューすると 499 エラーが返される
問題: を使用して、AWS Cloud9 IDE 属性を含み、<script>
属性が src
に設定された type
要素を含むファイルをプレビューしようとすると、499 エラーが発生し、スクリプトは予期どおりに実行されません。module
原因: のファイルプレビューのフェッチリクエストでは、認証のためにウェブブラウザから Cookie を送信する必要があります。AWS Cloud9 IDEcrossorigin
属性を追加した場合を除き、デフォルトでは、ウェブブラウザは通常のスクリプトリクエストに対しては Cookie を送信しますが、モジュールスクリプトリクエストに対しては
Cookie を送信しません。
解決策: 属性を crossorigin
要素に追加します。<script>
たとえば、<script type="module" src="index.js" crossorigin></script>
と指定します。 次に変更したファイルを保存し、再度プレビューを試みます。
(先頭に戻る)
環境 削除エラー: 「1 つ以上の 環境 を削除できませんでした」
問題: コンソールで 1 つ以上の 環境 を削除しようとすると、「1 つ以上の AWS Cloud9 を削除できませんでした」というメッセージが表示されます。このとき、少なくとも 1 つの 環境 は削除されません。環境
考えられる原因: AWS CloudFormation で、1 つ以上の 環境 の削除に問題が発生しました (AWS Cloud9 が 環境 の作成または削除で AWS CloudFormation に依存しています)。
推奨される解決策: 次のように、AWS CloudFormation を使用して、削除されていない各環境を削除してみてください。
-
AWS CloudFormation コンソール (https://console.aws.amazon.com/cloudformation
) を開きます。 -
AWS ナビゲーションバーで、環境の AWS リージョンを選択します。
-
AWS CloudFormation スタックのリストで、[スタックの名前] に削除されなかった 環境 が示され、[ステータス] が [DELETE_FAILED] になっているエントリを選択します。たとえば、環境 名が
my-demo-environment
の場合は、aws-cloud9-my-demo-environment を含む名前で始まるスタックを選択します。(環境 名の横にあるボックスまたはオプションを選択してください。環境 名自体は選択しないでください)。 -
[アクション]、[スタックの削除] の順に選択します。
-
プロンプトが表示されたら、[はい、削除します] を選択します。
スタックの削除処理には数分かかる場合があります。
スタックがリストから消えた場合、環境 は削除されています。
スタックがまだ表示されており、数分たっても [DELETE_FAILED] と表示されている場合、環境 はまだ削除されていません。その場合は、障害が発生した各スタックのリソースを手動で削除してみてください。
障害が発生したスタックのリソースを手動で削除すると、スタック自体は AWS アカウントから削除されません。
これらのリソースを手動で削除するには、AWS CloudFormation コンソールで、障害が発生したスタックを選択してから [リソース] セクションを選択します。AWS で、このリストの各リソースのコンソールに移動し、それぞれのコンソールを使用して手動でリソースを削除します。
(先頭に戻る)
コンソールの警告: 「最小限のコード補完エンジンに切り替えます...」
問題: コンソールで作業している場合 (IDE を開いたり、IDE のウェブページを更新したりする場合など)、次のメッセージが表示されます。AWS Cloud9"この環境で 1 つ以上のセッションまたは共同作業者がアクティブです。メモリを節約するために最小限のコード補完エンジンに切り替えます。」」というメッセージが表示される。このメッセージと相関して、コード補完の動作が遅いか断続的になっている可能性がある。
原因: コード補完エンジンを実行すると、環境からメモリと CPU サイクルが消費されます。さらに、共同作業者および追加のセッションごとに個別のコード補完エンジンが必要です。特に t2.nano や t2.micro などの小さなインスタンスサイズで、リソースの使用量が多すぎないようにするため、AWS Cloud9 は最小限のコード補完エンジンに切り替えます。
推奨される解決策: 頻繁および長期間共同作業を行う場合は、Amazon EC2 を作成する際により大きい EC2 環境 インスタンスを選択します。または、SSH 環境 をより大きいキャパシティーのインスタンスに接続します。
より大きな Amazon EC2 インスタンスを選択すると、AWS アカウントに追加料金が発生する場合があります。詳細については、「Amazon EC2 料金表
(先頭に戻る)
以下を表示した後に AWS Cloud9 インストーラが終了しない: 「Cloud9 IDE 1 のパッケージ」
問題: AWS Cloud9 は、SSH 開発環境を作成するプロセスの一環として、既存の Amazon EC2 インスタンスまたは独自のサーバーにインストールされます。[AWS Cloud9 インストーラ] ダイアログボックスにこのメッセージが表示された後、インストールが停止します。「Cloud9 IDE 1 のパッケージ」。[キャンセル] を選択すると、次のメッセージが表示されます。「インストールに失敗しました」。このエラーは、お客様の SSH ホストに AWS Cloud9 パッケージをインストールできない場合に発生します。
原因: SSH ホストでは、Node.js がインストールされている必要があります。現在、Node.js 0.6.16 から Node.js 12.x までのバージョンがサポートされています。AWS Cloud9 でサポートされていないバージョンの Node.js がホストにある場合、インストールエラーが発生する可能性があります。
推奨される解決策: でサポートされている Node.js のバージョンを SSH ホストにインストールします。AWS Cloud9
(先頭に戻る)
EC2-Classic アカウントの VPC エラー: 「環境にアクセスできません」
問題: EC2-Classic は、Amazon EC2 のオリジナルリリースで導入されました。2013 年 12 月 4 日より前にセットアップされた AWS アカウントを使用している場合、 の作成時に仮想プライベートクラウドAmazon VPC (AWS Cloud9 EC2 開発環境) とサブネットを明示的に設定しないと、このエラーが発生することがあります。
デフォルトの VPC 設定を受け入れると、Amazon EC2 インスタンスはデフォルト VPC のサブネットではなく EC2-Classic ネットワーク内で起動されます。環境の作成に失敗すると、次のメッセージが表示されます。
Environment Error
Unable to access your environment
The environment creation failed with the error: The following resource(s) failed
to create: [Instance]. . Rollback requested by user..
EC2 インスタンスがデフォルト VPC に存在しないためにエラーが発生したことを確認できます。開発環境のスタックイベント履歴を表示する場合に AWS CloudFormation を使用します。
-
AWS CloudFormation コンソールを開きます。詳細については、「AWS CloudFormation コンソールへのログイン」を参照してください。
-
AWS CloudFormation コンソールで、[スタック] を選択します。
-
[スタック] ページで、作成に失敗した開発環境の名前を選択します。
-
[スタックの詳細] ページで、[イベント ] タブを選択し、次のエントリを確認します。
Status: CREATE_FAILED
Status reason: The AssociatePublicIpAddress parameter is only supported by VPC launches. [...]
原因: は、特定の VPC 要件を満たす AWS Cloud9 開発環境 に関連付ける必要があります。Amazon VPCEC2-Classic が有効なアカウントの場合、EC2 環境 の作成時にデフォルトのネットワーク設定を受け入れると、必要な EC2 インスタンスが VPC 内で起動されません。代わりに、インスタンスは EC2-Classic ネットワーク内で起動されます。
推奨される解決策: EC2-Classic アカウントでは、 の作成EC2 環境時に VPC とサブネットを選択する必要があります。[設定の構成] ページの [ネットワーク設定 (高度)] セクションで、EC2 インスタンスを起動できる VPC とサブネットを選択します。
(先頭に戻る)
環境を開くことができません:AWS Cloud9 "この環境には、共同作業者が現在アクセスすることはできません。管理された一時的な認証情報の削除が完了するまで待つか、この環境の所有者に連絡してください。"
問題: 所有者でないユーザーによって新しい共同作業者が 環境 に追加された場合、環境 は無効になります。AWS 管理の一時認証情報認証情報は、~/.aws/credentials
ファイルの削除によって無効になります。ファイルの削除が進行中、新しい共同作業者は ~/.aws/credentials
環境にアクセスできません。AWS Cloud9
原因: の削除中に 環境 へのアクセスを防ぐことは、セキュリティ対策です。AWS 管理の一時認証情報これにより、環境の所有者は、信頼されている共同作業者のみが管理された認証情報にアクセスできることを確認できます。協力者のリストが有効であることを確認した場合、環境の所有者は管理された認証情報を再び有効にして共有できるようにします。詳細については、「AWS 管理の一時認証情報 へのアクセスのコントロール」を参照してください。
推奨される解決策: ファイルの削除が完了するのを待ってから、~/.aws/credentials
環境を再度開くことができます。AWS Cloud9認証情報の有効期限の最大待機時間は 15 分です。または、環境の所有者に、管理された一時的な認証情報を再有効化または無効化するように依頼してください。認証情報が再び有効化または無効化されると、共同作業者はすぐに環境にアクセスできます。(管理された認証情報の状態を
ENABLED または DISABLED に切り替えることで、環境の所有者は、共同作業者が環境にアクセスできなくなる中間状態に認証情報が残りないようにします)。
環境所有者と環境共同作業者が同じ AWS アカウントに属している場合、共同作業者は、 コンソールの [Your environments] ページで環境のカードを確認することで、連絡する環境所有者を特定できます。環境の所有者は、[Environment details (環境の詳細)] ページにも表示されます。
(先頭に戻る)
を使用して AWSCloud9SSMInstanceProfile を作成したときのエラーメッセージレポート「インスタンスプロファイル EC2 環境 がアカウントに存在しません」AWS CloudFormation
問題: AWS::Cloud9::EnvironmentEC2 リソースを使用して AWS CloudFormation を作成すると、ユーザーはEC2 環境 Instance profile AWSCloud9SSMInstanceProfile does not
exist in account.
原因: 入力しない EC2 環境 を作成するときは、サービスロール AWSCloud9SSMAccessRole
とインスタンスプロファイル AWSCloud9SSMInstanceProfile
を作成する必要があります。 これらの IAM リソースによって、Systems Manager は開発環境をバックアップする EC2 インスタンスを管理できます。
コンソールを使用して入力なし 環境 を作成すると、AWSCloud9SSMAccessRole
と AWSCloud9SSMInstanceProfile
が自動的に作成されます。ただし、AWS CloudFormation または AWS CLI を使用して最初の進入なし 環境 を作成するときは、これらの IAM
リソースを手動で作成する必要があります。
推奨される解決策: テンプレートの編集と AWS CloudFormation アクセス許可の更新については、「IAM」を参照してください。を使用した入力なしの作成AWS CloudFormationEC2 環境
を使用して EC2 環境 を作成するときに「リソースで ssm:StartSession を実行する権限がありません」と報告するエラーメッセージAWS CloudFormation
問題: AWS::Cloud9::EnvironmentEC2 リソースを使用して AWS CloudFormation を作成すると、ユーザーは EC2 環境 を受け取り、「リソースで ssm:StartSession」を実行する権限がないことが通知されます。AccessDeniedException
原因: ユーザーには、StartSession
を使用する EC2 環境 の設定の一部として必要な Systems Manager API を呼び出すアクセス許可がありません。
推奨される解決策: テンプレートの編集と AWS CloudFormation アクセス許可の更新については、「IAM」を参照してください。を使用した入力なしの作成AWS CloudFormationEC2 環境
(先頭に戻る)
VPC の IP アドレスが Docker で使用されているため、EC2 環境 に接続できない
問題: の場合、EC2 環境 Classless Inter-Domain Routing (CIDR) ブロック Amazon VPC を使用する IPv4 (仮想プライベートクラウド)
で EC2 インスタンスを起動すると、その環境を開いたときに接続が停止することがあります。172.17.0.0/16
原因: Docker は、同じブリッジネットワークに接続されたコンテナが通信できるようにするブリッジネットワークと呼ばれるリンクレイヤーデバイスを使用します。AWS Cloud9
は、コンテナ通信用のデフォルトブリッジを使用するコンテナを作成します。通常、デフォルトのブリッジはコンテナネットワーキングに 172.17.0.0/16
サブネットを使用します。
環境のインスタンスの VPC サブネットが、Docker で既に使用されているのと同じアドレス範囲を使用している場合、IP アドレスの競合が発生する可能性があります。したがって、AWS Cloud9 がインスタンスに接続しようとすると、その接続はゲートウェイルートテーブルによって EC2 インスタンスではなく Docker ブリッジにルーティングされます。これにより、AWS Cloud9 は開発環境をバックアップする EC2 インスタンスに接続できなくなります。
推奨される解決策: 同じ Amazon VPC CIDR アドレスブロックを使用して IPv4 と Docker による IP アドレスの競合を解決するには、EC2 環境 をバックアップするインスタンス用に新しい
VPC を設定します。この新しい VPC については、172.17.0.0/16
とは異なる CIDR ブロックを設定します。 (既存の VPC またはサブネットの IP アドレス範囲を変更することはできません)。
設定の詳細については、 の「VPC とサブネットのサイズ設定Amazon VPC ユーザーガイド」を参照してください。
(先頭に戻る)
実行時のエラー:AWS Toolkit 「環境が inode を使い果たしています。'fs.inotify.max_user_watches' の制限を増やしてください。」
問題: で使用されるファイル監視ユーティリティは、現在監視可能なファイルの制限に近づいています。AWS Toolkit
原因: は、ファイルとディレクトリの変更をモニタリングするファイル監視ユーティリティを使用します。AWS Toolkitユーティリティが監視できるファイルの現在の制限にほぼ達すると、警告メッセージが表示されます。
推奨される解決策: ファイルウォッチャーで処理できるファイルの最大数を増やすには、次の操作を行います。
-
[] を選択してターミナルセッションを開始する Window, New Terminal メニューバーの 。
-
コマンドラインで以下のように入力します。
sudo bash -c 'echo "fs.inotify.max_user_watches=524288" >> /etc/sysctl.conf' && sudo sysctl -p
(先頭に戻る)
注意: コラボレーションサポートの依存関係をインストールできませんでした
の問題: 依存関係をダウンロードするには、 にインターネットへのアクセスが必要です。AWS Cloud9がこれらの依存関係をダウンロードできない場合、[AWS Cloud9] ダイアログボックスに次のエラーが表示されます。Notice
Failed to install dependencies for collaboration support Please try to resolve this problem and refresh the page to enable collaboration support. A common cause is a lack of available disk space. Error was: Error downloading from location <LINK> to <LOCATION> Problem was: Error: connect ETIMEDOUT <IPADDRESS>
考えられる原因: 環境でプロキシを使用してインターネットにアクセスする場合、依存関係をインストールするために AWS Cloud9 にプロキシの詳細が必要です。AWS Cloud9このエラーは、プロキシの詳細を AWS Cloud9 に指定していない場合に表示されます。
推奨される解決策: プロキシの詳細を AWS Cloud9 に提供するには、環境の ~/.bashrc
ファイルに以下を追加します。
export http_proxy=<proxy url for http> export https_proxy=<proxy url for https>
たとえば、http プロキシ URL が http://172.31.26.80:3128
で https プロキシ URL が https://172.31.26.80:3129
の場合、次の行を ~/.bashrc
ファイルに追加します。
export http_proxy=http://172.31.26.80:3128 export https_proxy=https://172.31.26.80:3129
これらの環境変数が /etc/profile
には存在するが ~/.bashrc
には存在しない場合、AWS Cloud9 はこれらをログインシェルにのみ使用するため、これを使用できません。/etc/profile
では /etc/profile
もロードされるため、~/.bashrc
に設定を指定すると、環境変数がログインシェルと ~/.bashrc
の両方で使用できるようになります。AWS Cloud9
(先頭に戻る)