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

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

トラブルシューティング 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 インストーラ］ダイアログボックスに「Package Cloud9 IDE 1」というメッセージが表示されて、インストールが停止します。［キャンセル］を選択すると、「インストールに失敗しました」というメッセージが表示されます。このエラーは、お客様の SSH ホストに AWS Cloud9 パッケージをインストールできない場合に発生します。

原因: SSH ホストでは、Node.js がインストールされている必要があります。ホストのオペレーティングシステムでサポートされている最新の Node.js バージョンをインストールすることをお勧めします。がサポート AWS Cloud9 していないバージョンの がホストNode.jsにある場合、インストールエラーが発生する可能性があります。

推奨される解決策： が AWS Cloud9 サポートする Node.js のバージョンを SSH ホストにインストールします。

依存関係をインストールできませんでした

問題： 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]

  • no-ingress Amazon EC2 インスタンスを使用している場合は、Amazon S3 の Amazon VPC エンドポイントが設定されていることを確認する必要があります。詳細については、「Amazon S3 のダウンロード依存関係に対応する Amazon VPC エンドポイントの設定」を参照してください。

SSH 環境エラー: 「pty.js をインストールするには Python バージョン 3 が必要です」

問題： AWS Cloud9 SSH 開発環境を開くと、 AWS Cloud9 IDE のターミナルに「pty.js のインストールには Python バージョン 3 が必要です」で始まるメッセージが表示されます。

原因: 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 API を呼び出すことができません。詳細については、AWS Security Token Service 「 API リファレンスGetFederationToken」の「」を参照してください。

解決策： IAM コンソールで AWS Cloud9 、または AWS Command Line Interface () でこのコマンドを実行して、 のサービスにリンクされたロールを作成するように AWS アカウント 管理者に依頼します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 ユーザーガイドの「サービスにリンクされたロールの使用」を参照してください。https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html

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

問題： 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 コンソールにサインインしている IAM ユーザーに、環境を開くために必要な AWS アクセス許可があることを確認します。その後、もう一度環境を開いてみてください。詳細については、以下を参照するか、 AWS アカウント 管理者にお問い合わせください。

    サインインした IAM ユーザーが引き続き環境を開くことができない場合は、サインアウトしてから、アカウントの AWS アカウント ルートユーザーまたは管理者ユーザーとしてサインインし直してみてください。その後、もう一度環境を開いてみてください。この方法で環境を開くことができない場合は、IAM ユーザーのアクセス許可に問題がある可能性が最も大です。

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

  • 環境が SSH 環境の場合は、それに関連付けられているクラウドコンピューティングインスタンスまたは独自のサーバーが正しく設定され、 がアクセス AWS Cloud9 できることを確認してください。その後、もう一度環境を開いてみてください。詳細については、「SSH 環境ホスト要件」を参照してください。

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 つの環境が削除されないというメッセージが表示されます。

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

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

  1. https://console.aws.amazon.com/cloudformation で AWS 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 テンプレートで定義されたアプリケーションの AWS SAM CLI コマンドを実行すると、エラーが発生します。

考えられる原因： AWS Toolkit を使用してサーバーレスアプリケーションをローカルで実行およびデバッグすると、 はDockerイメージ AWS SAM を使用します。これらのイメージは、デプロイを計画している 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 イメージを構築できるように、環境内のディスク領域を解放します。IDE の端末で次のコマンドを実行して、未使用の Docker イメージを削除します。

docker image prune -a

ディスク容量の制限により SAM CLI コマンドで問題が繰り返して発生する場合は、開発環境に切り替えて別のインスタンスタイプを使用します。

(先頭に戻ります)

古いバージョンの Microsoft Edge ブラウザを使用して IDE をロードすることはできません

問題： Microsoft Edgeウェブブラウザを使用して AWS Cloud9 IDE をロードしようとすると、HTTP403: FORBIDDENエラーが返されます。

考えられる原因： AWS Cloud9 IDE は、特定の古いバージョンの をサポートしていませんMicrosoft Edge。

推奨される解決策: ブラウザを更新するには、Microsoft Edge ツールバーの省略記号 (...) ボタンをクリックします。メニューで、[Settings] (設定) を選択して [About Microsoft Edge] ( について) を選択します。アップデートが必要な場合は、自動的にダウンロードされ、インストールされます。

(先頭に戻ります)

AWS Cloud9 IDE ファイルエクスプローラーで /home/ec2-user/environment/home/ec2-user/environment というサブフォルダー構造を作成できません。

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

考えられる原因： 現在、 AWS Cloud9 IDE のファイルシステムを使用して、同じ名前のフォルダ内にサブフォルダ構造 /home/ec2-user/environment を作成することはできません。 AWS Cloud9 IDE File Explorer からこのディレクトリ内のファイルにはアクセスできませんが、コマンドラインを使用してアクセスできます。この問題の影響を受けるのは /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 内にサブフォルダ構造 /projects/projects を作成することはできません CodeCatalyst。

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

考えられる原因： 現在、 の AWS Cloud9 IDE の File Explorer を使用して、同じ名前のフォルダ内にサブフォルダ構造 /プロジェクトを作成することはできません CodeCatalyst。 AWS Cloud9 IDE File Explorer からこのディレクトリ内のファイルにアクセスすることはできませんが、コマンドラインを使用してアクセスすることはできます。この問題は /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ソフトウェアの更新」の手順に従って、Amazon EC2 インスタンスにシステム更新を定期的に適用します。

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

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

AWS CLI または AWS-shell エラー: 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 アドレスを Docker が使用しているため、EC2 環境に接続できません

問題: EC2 環境で、IPv4 クラスレスドメイン間ルーティング (CIDR) ブロック 172.17.0.0/16 を使用する Amazon VPC で EC2 インスタンスを起動した場合、その環境を開こうとすると、接続が停止することがあります。

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

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

推奨される解決策: Amazon VPC と Docker が同じ IPv4 CIDR アドレスブロックを使用することで発生する IP アドレスの競合を解決するには、EC2 環境をバッキングするインスタンス用に新しい VPC を設定します。この新しいVPC では、172.17.0.0/16 とは異なる CIDR ブロックを設定します (既存の VPC またはサブネットの IP アドレスの範囲を変更することはできません)。

設定情報については、「Amazon VPC ユーザーガイド」の「VPC とサブネットサイジング」を参照してください。

AWS Cloud9 IDE ファイルエクスプローラーで /home/ec2-user/environment/home/ec2-user/environment というサブフォルダー構造を作成できません。

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

考えられる原因： 現在、 AWS Cloud9 IDE のファイルシステムを使用して、同じ名前のフォルダ内にサブフォルダ構造 /home/ec2-user/environment を作成することはできません。 AWS Cloud9 IDE File Explorer からこのディレクトリ内のファイルにはアクセスできませんが、コマンドラインを使用してアクセスできます。この問題の影響を受けるのは /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 マシンイメージ (AMI) や などのメカニズムにアタッチできます AWS CloudFormation。これらのメカニズムのいずれかを使用して、EC2 インスタンスを起動できます。

AWSServiceRoleForAWSCloud9 つのサービスにリンクされたロール (SLR) AWSCloud9ServiceRolePolicyの古いバージョンの には、現在 license-configurationリソース条件が含まれていません。このため、 AWS Cloud9 はインスタンスを起動および停止することはできません。そのため、 AWS Cloud9 は Amazon EC2 インスタンスへのアクセスを拒否され、エラーが返されます。

推奨される解決策: 既存の AWS Cloud9 環境にアクセスして License Manager を使用できない場合は、古いAWSCloud9ServiceRolePolicyサービスにリンクされたロールを、 がインスタンスlicense-configurationに適用されたときに EC2 アクションを明示的に許可する SLR のバージョンに置き換えます。古いロールを削除するだけで置き換えることができます。その後、更新されたロールが自動的に作成されます。

EC2 環境で一部のコマンドやスクリプトを実行できない

問題： AWS Cloud9 EC2 開発環境を開いた後、一部のタイプのパッケージをインストールしたり、 yum や などのコマンドを実行したりapt、他の Linux オペレーティングシステムで通常機能するコマンドを含むスクリプトを実行したりすることはできません。

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

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

を使用して EC2 環境を作成するときに「インスタンスプロファイル AWSCloud9SSMInstanceProfile がアカウントに存在しません」と報告するエラーメッセージ 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 または を使用して最初の no-ingress 環境を作成する場合は、これらの IAM リソースを手動で作成する必要があります。

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

AWS CloudFormationを使用してEC2環境を作成するときに「リソースで perform: ssm:StartSession を実行する権限がないこと」を報告するエラーメッセージ

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

原因: ユーザーには no-ingress インスタンス用Systems Manager を活用する EC2 環境の設定パートとして必要なStartSession API を呼び出す許可がおりていません。

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

AWS CLIを使用して EC2 環境を作成するときに、「実行する権限がありません: iam:GetInstanceProfile on resource: instance profile AWSCloud9SSMInstanceProfile」を報告するエラーメッセージ

問題： を使用して EC2 環境AWS CLIを作成するAccessDeniedExceptionと、ユーザーは を受け取り、環境 AWS Cloud9 が「iam:GetInstanceProfile on resource: instance profile を実行する権限がない」ことが通知されますAWSCloud9SSMInstanceProfile。

原因： AWS Cloud9 no-ingress インスタンスに Systems Manager を使用する EC2 環境の設定の一部として必要な StartSession API を呼び出すアクセス許可を に付与します。

推奨される解決策: 必要なAWSCloud9SSMAccessRoleサービスロールと を AWS Cloud9 環境に追加する方法については、AWSCloud9SSMInstanceProfile「」を参照してくださいAWS CLI を使ったSystems Manager のインスタンスプロファイルの管理。

デフォルトの暗号化が Amazon EBS ボリュームに適用されている場合に、環境の作成障害がでる

問題: Failed to create environments. The development environment '[environment-ID]' failed to create Amazon EC2 環境を作成しようとすると、エラーが返されます。

考えられる原因： 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

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

問題: 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 要件を満たす Amazon VPC に関連付ける必要があります。EC2-Classic が有効なアカウントの場合、EC2 環境の作成 時にデフォルトのネットワーク設定を受け入れると、必要な EC2 インスタンスが VPC 内で起動されません。代わりに、インスタンスは EC2-Classic ネットワーク内で起動されます。

推奨される解決策: EC2-Classic アカウントでは、EC2 環境の作成時に VPC とサブネットを選択する必要があります。［設定の構成］ページの［ネットワーク設定 (アドバンスト)］セクションで、EC2 インスタンスを起動できる VPC とサブネットを選択します。

その他の AWS サービス

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

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

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

考えられる原因： 現在、 の AWS Cloud9 IDE の File Explorer を使用して、同じ名前のフォルダ内にサブフォルダ構造 /projects を作成することはできません CodeCatalyst。 AWS Cloud9 IDE File Explorer からこのディレクトリ内のファイルにアクセスすることはできませんが、コマンドラインを使用してアクセスすることはできます。この問題は /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 クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) の AWS Cloud9 SSH 開発環境で実行されています。さらに、対応するインスタンスに関連付けられている仮想プライベートクラウド (VPC) のサブネットのネットワーク ACL が、アプリケーションで必要とするプロトコル、ポート、または IP アドレスを介したインバウンドトラフィックを許可していません。

  • URL に誤りがある。

  • インスタンスのパブリック IP アドレスではなく、アプリケーションプレビュータブの URL がリクエストされている。

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

  • インスタンスのパブリック 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 が存在するとします。この場合、ネットワーク ACL が、アプリケーションで必要とするプロトコル、ポート、および IP アドレスを介したインバウンドトラフィックを許可していることを確認します。指示については、実行中のアプリケーションをインターネット上で共有するの ステップ 3: インスタンスのサブネットをセットアップする を参照してください。また、「Amazon VPC ユーザーガイド」の「ネットワーク ACL」を参照してください。

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

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

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

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

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

  • アプリケーションが独自のサーバーの SSH 環境で実行しているとします。サーバーおよび関連付けられているネットワークが、アプリケーションで必要とするプロトコル、ポート、または IP アドレスを介したインバウンドトラフィックを許可していることを確認します。サーバーまたは関連付けられているネットワークを変更できない場合は、サーバーまたはネットワークの管理者にお問い合わせください。

  • curl コマンドに URL を続けて実行し、環境のターミナルからアプリケーションの実行を試みます。このコマンドでエラーメッセージが表示される場合は、 に関連しない他の問題がある可能性があります AWS Cloud9。

Toolkit の実行中にエラーが発生しました AWS ：「環境が inodes を使い果たしています。「fs.inotify.max_user_watches」の制限を増やしてください。」

問題： AWS Toolkit が使用するファイル監視ユーティリティが、監視できるファイルの現在の制限またはクォータに近づいています。

原因： 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 Cloud9 IDE で AWS Lambda 関数のローカルバージョンを実行しようとすると、ダイアログボックスが表示されます。ダイアログボックスには、 AWS Cloud9 が IDE でローカルバージョンの AWS Lambda 関数を実行するために SAM Local. AWS Cloud9 needs SAM Local のインストールで問題が発生していると表示されます。SAM Local をインストールするまで、IDE でローカルバージョンの Lambda 関数を実行することはできません。

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

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

AWS Cloud9 が SAM Local をインストールしようとしてどのように動作しているかを確認するには、メニューバーでウィンドウ、インストーラを選択します。

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

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

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

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

推奨される解決策: AWS Control Tower コンソールから controlCT.EC2.PR.8 を無効にし、 で環境を再作成します AWS Cloud9。

デフォルトの暗号化が Amazon EBS ボリュームに適用されている場合に、環境の作成障害がでる

問題: Failed to create environments. The development environment '[environment-ID]' failed to create Amazon EC2 環境を作成しようとすると、エラーが返されます。

考えられる原因： 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

(先頭に戻ります)

ライセンス設定が 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サービスにリンクされたロールを、 がインスタンスlicense-configurationに適用されたときに EC2 アクションを明示的に許可する SLR のバージョンに置き換えます。古いロールを削除するだけで置き換えることができます。その後、更新されたロールが自動的に作成されます。

(先頭に戻ります)

アプリケーションプレビュー

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

環境を再ロードした後、アプリケーションプレビューを最新の情報に更新する必要がある

問題: アプリケーションプレビュータブを表示する環境を再ロードした後、タブにアプリケーションプレビューが表示されません。

原因: 無限ループを実行できるコードをユーザーが書くことがあります。または、コードで大量のメモリが使用されるため、アプリケーションのプレビューの実行時に AWS Cloud9 IDE が一時停止または停止する可能性があります。これを防ぐために、環境が再ロードされるたびにアプリケーションのプレビュータブを再ロード AWS Cloud9 しないでください。

解決策: アプリケーションプレビュータブを表示する環境を再ロードした後で、アプリケーションプレビューを表示するには、タブの ［Click to load the page (クリックしてページをロード)］ボタンを選択します。

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

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

原因： AWS Cloud9 IDE を開くためにサードパーティーの Cookie は必要ありません。ただし、アプリケーションプレビュー機能またはファイルプレビュー機能を使用するには、サードパーティーの 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 に :8080、:8081、または :8082 を追加します。

  • ネットワークがポート 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 プロトコルを自動的に使用します。ページの URI が安全でない http プロトコルを備えている場合、https に自動的に置き換えられます。また、手動で https を http に戻す変更を行っても、安全でないコンテンツにアクセスすることはできません。

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

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

問題： AWS Cloud9 IDE を使用して、 src 属性を含む <script>要素を含むファイルをプレビューし、 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)、大きいフォルダや、ソースコードに関係のないフォルダ (ビルド出力/アーティファクト、サードパーティパッケージ) を、無視するパターンに追加することを検討できます。これを行うには、[設定] > [ユーザー設定] > [ファイル監視] に移動します。これにより、 CodeLenses AWS Toolkit が正しく動作しなくなることに注意してください。

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

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

問題： 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 AWS Cloud9 IDE へのアップロード速度をスロットリングし、その結果、ファイルのアップロードリクエストがタイムアウトします。

推奨される解決策： ファイルを Amazon S3 にアップロードしてから、Amazon S3 を使用して AWS Cloud9 IDE の CLI を使用してファイルを環境にダウンロードすることをお勧めします。Amazon S3 にファイルをアップロードする方法の詳細については、「Amazon S3 ユーザーガイド」の「オブジェクトのアップロード」を参照してください。

AWS Cloud9 IDE のダウンロード速度が遅い

問題： ユーザーが AWS Cloud9 IDE からファイルをダウンロードしようとすると、ダウンロード速度が遅くなります。

原因: IDE からローカルファイルシステムにファイルをダウンロードする場合、転送速度は 0.1 メガバイト/秒に制限されます。

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

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

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

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

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

(先頭に戻ります)

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

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

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

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

考えられる原因： tmux error. AWS Cloud9 uses the tmux utility が原因でターミナルが応答しない可能性があります。これにより、ページがリロードされたり、開発環境に再接続しても、ターミナルに表示される情報は保持されます。

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-*

古いバージョンの Microsoft Edge ブラウザを使用して IDE をロードすることはできません

問題： Microsoft Edgeウェブブラウザを使用して AWS Cloud9 IDE をロードしようとすると、HTTP403: FORBIDDENエラーが返されます。

考えられる原因： AWS Cloud9 IDE は、特定の古いバージョンの をサポートしていませんMicrosoft Edge。

推奨される解決策: ブラウザを更新するには、Microsoft Edge ツールバーの省略記号 (...) ボタンをクリックします。メニューで、[Settings] (設定) を選択して [About Microsoft Edge] ( について) を選択します。アップデートが必要な場合は、自動的にダウンロードされ、インストールされます。

C++ プロジェクトのデバッグ時に、gdb を伴うエラー

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

考えられる原因： AWS Cloud9 環境が特定の EC2 インスタンスタイプ ( t3.smallや など) を使用しているとしますm5.large。この場合、IDE の組み込みランナーを使用して C++ プロジェクトを実行およびデバッグしようとすると、デバッグエラーが発生することがあります。このエラーは、環境にプリインストールされた 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

問題: ユーザーは PHP CLI ランナーターミナルで出力を表示できません。

原因: CLI ランナーを PHP に設定し、デバッガーモードを有効にする必要があります。

推奨される解決策: CLI ランナーを PHP に設定し、デバッガーモードが有効になっていることを確認します。

Node.js に関連する GLIBC エラー

問題: ユーザーが 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: 必要なツールをインストールする」セクションを参照してください。