문제 해결 AWS Cloud9 - AWS Cloud9
설치 관리자AWS Cloud9 환경Amazon EC2기타 서비스 AWS애플리케이션 미리 보기성능서드 파티 애플리케이션 및 서비스

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

문제 해결 AWS Cloud9

다음 정보를 사용하여 문제를 식별하고 해결하십시오 AWS Cloud9.

해당 문제가 나와 있지 않거나 추가 도움이 필요한 경우, AWS Cloud9 토론 포럼을 참조하세요. 이 포럼에 들어갈 때 로그인해야 할 수 있습니다. 또한 직접 당사에 문의할 수도 있습니다.

설치 관리자

다음 섹션에서는 AWS Cloud9 설치 프로그램과 관련된 문제 해결 문제를 간략하게 설명합니다.

AWS Cloud9 설치 프로그램이 중단되거나 실패합니다.

문제: AWS Cloud9 설치 프로그램을 다운로드하여 실행하면 오류가 하나 이상 발생하고 설치 스크립트가 표시되지 않습니다. Done

원인: AWS Cloud9 설치 프로그램에서 복구할 수 없는 오류가 하나 이상 발생하여 오류가 발생했습니다.

해결 방법: AWS Cloud9 설치 프로그램 문제 해결 섹션에서 자세한 정보를 확인합니다. 제공된 일반적인 문제, 가능한 원인 및 권장 해결 방법을 참조하세요.

AWS Cloud9 “패키지 Cloud9 IDE 1"이 표시된 후 설치 프로그램이 종료되지 않음

문제: AWS Cloud9 SSH 개발 환경 생성 프로세스의 일부로 기존 Amazon EC2 인스턴스 또는 자체 서버에 설치되었습니다. AWS Cloud9 설치 관리자 대화 상자에 "Package Cloud9 IDE 1" 메시지가 표시된 경우에는 설치가 중지됩니다. 취소를 선택하면 "Installation Failed(설치 실패)" 메시지가 표시됩니다. 이 오류는 고객의 SSH 호스트에 AWS Cloud9 패키지를 설치할 수 없을 때 발생합니다.

원인: SSH 호스트에는 Node.js가 설치되어 있어야 합니다. 호스트 운영 체제에서 지원하는 최신 Node.js 버전을 설치하는 것이 좋습니다. Node.js호스트에 지원되지 AWS Cloud9 않는 버전이 있는 경우 설치 오류가 발생할 수 있습니다.

권장 해결 방법: SSH 호스트에서 AWS Cloud9 지원하는 Node.js 버전을 설치하십시오.

종속성을 설치하지 못함

문제: 종속 항목을 다운로드하려면 인터넷 액세스가 AWS Cloud9 필요합니다.

가능한 원인:

  • 프록시를 사용하여 인터넷에 액세스하는 AWS Cloud9 환경에서 사용하는 경우 종속성을 설치하려면 프록시 세부 정보가 AWS Cloud9 필요합니다. 에 프록시 세부 정보를 제공하지 않은 AWS Cloud9경우 이 오류가 나타납니다.

  • 이 문제의 또 다른 원인은 환경에서 아웃바운드 트래픽을 허용하지 않는 경우일 수 있습니다.

권장 솔루션:

  • 프록시 세부 정보를 AWS Cloud9제공하려면 환경 ~/.bashrc 파일에 다음 코드를 추가하십시오.

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

    예를 들어 HTTP 프록시 URL이 https://172.31.26.80:3128이고 HTTP 프록시 URL이 https://172.31.26.80:3129인 경우 ~/.bashrc 파일에 다음 줄을 추가하고 NODE_EXTRA_CA_CERTS를 PEM 형식의 인증 기관 파일 경로로 설정합니다. 이 변수에 대한 자세한 내용은 https://nodejs.org/api/cli.html#node_extra_ca_certsfile 섹션을 참조하세요.

    export http_proxy=http://172.31.26.80:3128
export https_proxy=https://172.31.26.80:3129
export NODE_EXTRA_CA_CERTS=[path_to_pem_certificate]

  • 무수신 Amazon EC2 인스턴스를 사용하는 경우 Amazon S3용 Amazon VPC 엔드포인트가 구성되어 있는지 확인해야 합니다. 자세한 내용은 종속 구성 요소를 다운로드하도록 Amazon S3의 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 인스턴스를 생성할 수 없습니다.(We are unable to create EC2 instances ...)’

문제: 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 계정

이 명령을 실행한 후 환경을 다시 생성해 보세요.

페더레이션 ID로 환경을 만들 수 없음

문제: AWS 페더레이션 ID를 사용하여 AWS Cloud9 개발 환경을 만들려고 하면 액세스 오류 메시지가 표시되고 환경이 생성되지 않습니다.

원인:: 서비스 AWS Cloud9 연결 역할을 사용합니다. 서비스 연결 역할은 iam:CreateServiceLinkedRole 호출을 사용하여 계정에서 환경이 처음 생성될 때 생성됩니다. 그러나 페더레이션 사용자는 IAM API를 호출할 수 없습니다. 자세한 내용은 AWS Security Token Service API GetFederationToken참조를 참조하십시오.

해결 방법: AWS 계정 관리자에게 IAM 콘솔에서 AWS Cloud9 또는 () 와 함께 이 명령을 실행하여 서비스 연결 역할을 생성하도록 AWS Command Line Interface 요청하십시오.AWS CLI

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

또는 -shell을 사용하여 다음 명령을 실행하십시오. AWS

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

자세한 내용은 IAM 사용 설명서의 서비스 연결 역할 사용을 참조하세요.

콘솔 오류: ‘사용자가 리소스에 대한 작업을 수행하도록 승인되지 않음(User is not authorized to perform action on resource)’

문제: AWS Cloud9 콘솔을 사용하여 AWS Cloud9 개발 환경을 만들거나 관리하려고 하면 “사용자가 arn:aws:iam::123456789012:user/MyUser cloud9:action arn:aws:cloud9:us-east-2:123456789012:environment:12a34567b8cd9012345ef67abcd890e1 리소스에 대한 작업을 수행할 권한이 없습니다”와 비슷한 문구가 포함된 오류가 표시됩니다. 여기서 다음과 같습니다.

  • arn:aws:iam::123456789012:user/MyUser는 요청 사용자의 Amazon 리소스 이름(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 환경을 열 수 없음: “이 환경은 현재 공동 작업자가 액세스할 수 없습니다. Please wait until the removal of managed temporary credentials is complete, or contact the owner of this environment'(현재 공동 작업자가 이 환경에 액세스할 수 없습니다. 관리형 임시 보안 인증 정보 제거가 완료될 때까지 기다리거나 이 환경의 소유자에게 문의하세요.)

문제: 환경 소유자가 아닌 사람이 새 공동 작업자를 환경에 추가하면 AWS 관리되는 임시 자격 증명이 비활성화됩니다. 보안 인증 정보는 ~/.aws/credentials 파일을 삭제하면 사용 중지됩니다. ~/.aws/credentials파일이 삭제되는 동안에는 새 공동 작업자가 환경에 액세스할 수 없습니다. AWS Cloud9

원인: AWS 관리형 임시 보안 인증 정보를 삭제하는 동안 환경에 액세스하지 못하도록 하는 것은 보안을 위한 조치입니다. 이를 통해 환경 소유자는 신뢰할 수 있는 공동 작업자만 관리형 보안 인증 정보에 액세스하도록 할 수 있습니다. 공동 작업자 목록이 유효하다고 생각되면 환경 소유자는 관리형 자격 증명을 다시 사용하도록 설정하여 공유할 수 있습니다. 자세한 정보는 AWS 관리형 임시 자격 증명에 대한 액세스 제어을 참조하세요.

권장 해결 방법: ~/.aws/credentials 파일이 완전히 삭제될 때까지 기다린 후 AWS Cloud9 환경을 다시 열어보세요. 자격 증명 만료의 최대 대기 시간은 15분입니다. 또는 환경 소유자에게 관리형 임시 자격 증명을 다시 사용하도록 설정하거나 사용 중지하도록 요청합니다. 자격 증명을 다시 사용하도록 설정하거나 사용 중지하고 나면 공동 작업자가 즉시 환경에 액세스할 수 있습니다. 환경 소유자는 관리형 보안 인증 정보의 상태를 ENABLED 또는 DISABLED로 전환하여 자격 증명이 중간 상태로 남아 있지 않도록 합니다. 중간 통계 때문에 공동 작업자가 환경에 액세스하지 못할 수 있습니다.

참고

환경 소유자와 공동 작업자가 동일한 AWS 계정에 속하는 경우, 공동 작업자는 콘솔의 Your environments(환경) 페이지에서 환경의 카드를 검토하여 환경 소유자를 식별하고 연락할 수 있습니다. 환경 소유자는 [환경 세부 정보(Environment details)] 페이지에도 나열되어 있습니다.

환경 삭제 오류: ‘하나 이상의 환경을 삭제하지 못함(One or more environments failed to delete)’

문제: AWS Cloud9 콘솔에서 하나 이상의 환경을 삭제하려고 하면 “하나 이상의 환경을 삭제하지 못했습니다.”라는 메시지가 표시되고 환경 중 하나 이상이 삭제되지 않습니다.

가능한 원인: 하나 이상의 환경을 삭제하는 중에 문제가 AWS CloudFormation 있을 수 있습니다. AWS Cloud9 환경을 만들고 삭제하는 AWS CloudFormation 데 사용됩니다.

권장 해결 방법: 삭제되지 않은 환경을 각각 삭제하는 AWS CloudFormation 데 사용해 보십시오.

  1. https://console.aws.amazon.com/cloudformation 에서 AWS CloudFormation 콘솔을 엽니다.

  2. AWS 탐색 표시줄에서 해당 AWS 리전 환경을 선택합니다.

  3. 스택 목록에서 스택 이름에 삭제되지 않은 환경 이름이 포함되고 상태가 DELETE_FAILED인 항목을 선택합니다. AWS CloudFormation 예를 들어, 환경 이름이 인 경우 my-demo-environment aws-cloud9-라는 이름으로 시작하는 스택을 선택하십시오. my-demo-environment (환경 이름 자체가 아니라 환경 이름 옆에 있는 상자 또는 옵션을 선택합니다.)

  4. 작업, 스택 삭제을 선택합니다.

  5. 메시지가 나타나면 예, 삭제를 선택합니다.

스택 삭제 프로세스는 몇 분 정도 걸릴 수 있습니다.

목록에서 스택이 사라지면 이제 환경이 삭제됩니다.

몇 분 후 스택에 DELETE_FAILED 상태가 표시되면 해당 환경이 아직 삭제되지 않은 것입니다. 실패한 스택의 각 리소스를 수동으로 삭제해 볼 수 있습니다.

참고

장애가 발생한 스택의 리소스를 수동으로 삭제해도 스택 자체가 제거되지는 않습니다. AWS 계정

이러한 리소스를 수동으로 삭제하려면 다음과 같이 합니다. AWS CloudFormation 콘솔에서 장애가 발생한 스택을 선택한 다음 리소스 섹션을 선택합니다. 이 목록에 있는 각 리소스의 AWS 콘솔로 이동한 다음 해당 콘솔을 사용하여 리소스를 삭제하십시오.

IDE 환경의 타임아웃 시간 변경 AWS Cloud9

문제: 사용자가 Amazon EC2 환경의 제한 시간을 업데이트하려고 합니다.

원인: 기본 제한 시간은 30분입니다. 일부 사용자에게는 이 시간이 너무 짧을 수 있습니다.

권장 솔루션

  1. 구성하려는 환경을 엽니다.

  2. AWS Cloud9 IDE의 메뉴 모음에서 AWS Cloud9 기본 설정을 선택합니다.

  3. 기본 설정 창에서 Amazon EC2 인스턴스 섹션으로 스크롤합니다.

  4. 사용 가능한 목록에서 제한 시간 값을 선택하고 업데이트합니다.

AWS Cloud9 환경에 디스크 공간이 충분하지 않아 AWS 툴킷에서 SAM 응용 프로그램을 로컬로 실행하는 중 오류가 발생했습니다.

문제: AWS 툴킷을 사용하여 SAM 템플릿으로 정의된 애플리케이션에 대해 AWS SAM CLI 명령을 실행할 때 오류가 발생합니다.

가능한 원인: 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 이미지를 빌드할 수 있도록 환경에서 디스크 공간을 확보합니다. IDE 터미널에서 다음 명령을 실행하여 사용하지 않는 Docker 이미지를 제거합니다.

docker image prune -a

디스크 공간의 제약으로 인해 SAM CLI 명령에 반복적으로 문제가 발생하는 경우 다른 인스턴스 유형을 사용하는 개발 환경으로 전환해 보세요.

(맨 위로 이동)

이전 버전의 Microsoft Edge 브라우저를 사용하여 IDE를 로드할 수 없음

문제: 웹 HTTP403: FORBIDDEN 브라우저를 사용하여 AWS Cloud9 IDE를 로드하려고 하면 오류가 반환됩니다. Microsoft Edge

가능한 원인: AWS Cloud9 IDE가 일부 이전 버전을 지원하지 않습니다Microsoft Edge.

권장 솔루션: 브라우저를 업데이트하려면 Microsoft Edge 도구 모음에서 줄임표(...) 버튼을 선택합니다. 메뉴에서 Settings(설정)를 선택한 다음 About Microsoft Edge(Microsoft Edge 정보)를 선택합니다. 업데이트가 필요한 경우 자동으로 다운로드되어 설치됩니다.

(맨 위로 이동)

AWS Cloud9 IDE 파일 탐색기에서 하위 폴더 구조인 /home/ec2-user/environment/home/ec2-user/environment를 만들 수 없습니다.

문제: AWS Cloud9 IDE 파일 탐색기에서 하위 폴더 구조 /home/ec2-user/environment/home/ec2-user/environment 를 만들 때 이 디렉토리를 열 수 없다는 오류 메시지가 나타납니다.

가능한 원인: 현재 IDE의 파일 시스템을 사용하여 같은 이름의 폴더 내에 하위 폴더 구조 /home/ec2-user/environment 를 만들 수 없습니다. AWS Cloud9 AWS Cloud9 IDE 파일 탐색기에서는 이 디렉터리 내의 파일에 액세스할 수 없지만 명령줄을 사용하여 액세스할 수 있습니다. 이 문제는 파일 경로 /home/ec2-user/environment/home/ec2-user/environment에만 영향을 미치며 /test/home/ec2-user/environment 및 /home/ec2-user/environment/test와 같은 파일 경로가 적합합니다. 이는 알려진 문제이며 AWS Cloud9 IDE 파일 탐색기에만 영향을 미칩니다.

권장 해결 방법: 다른 파일 이름 및 구조를 사용하세요.

(맨 위로 이동)

IDE의 파일 탐색기에서 하위 폴더 구조 /projects/projects를 만들 수 없습니다. AWS Cloud9 CodeCatalyst

문제: AWS Cloud9 IDE 파일 탐색기에서 하위 폴더 구조 /projects/projects를 만들 때 이 디렉토리를 열 수 없다는 오류 메시지가 나타납니다. CodeCatalyst

가능한 원인: 현재 IDE의 파일 탐색기를 사용하여 같은 이름의 폴더 내에 하위 폴더 구조 /projects를 만들 수 없습니다. AWS Cloud9 CodeCatalyst AWS Cloud9 IDE 파일 탐색기에서는 이 디렉터리 내의 파일에 액세스할 수 없지만 명령줄을 사용하여 액세스할 수 있습니다. 이 문제는 /projects/projects 파일 경로에만 영향을 미치며, /test/projects와 /projects/test/projects 같은 파일 경로가 적합합니다. 이는 알려진 문제이며 해당 AWS Cloud9 IDE 파일 탐색기에만 영향을 줍니다 CodeCatalyst.

권장 해결 방법: 다른 파일 이름 및 구조를 사용하세요.

(맨 위로 이동)

tmux 세션 오류 때문에 AWS Cloud9 에서 터미널 창과 상호 작용할 수 없습니다.

문제: 에서 AWS Cloud9새 터미널 창을 시작하려고 하면 예상한 명령줄 인터페이스를 사용할 수 없습니다. 명령 프롬프트가 없으며 텍스트를 입력할 수 없습니다. tmux: need UTF-8 locale (LC_CTYPE) 및 invalid LC_ALL, LC_CTYPE or LANG 같은 오류 메시지가 반환됩니다.

가능한 원인: tmux 오류로 인해 터미널이 응답하지 않을 수 있습니다. AWS Cloud9 tmux 유틸리티를 사용합니다. 이렇게 하면 페이지가 다시 로드되거나 개발 환경에 다시 연결할 때도 터미널에 표시되는 정보를 유지합니다.

tmux 세션에서 터미널 창에 표시되는 항목은 클라이언트에 의해 처리됩니다. 클라이언트는 여러 세션을 관리할 수 있는 서버와 통신합니다. 서버와 클라이언트는 tmp 폴더에 있는 소켓을 통해 통신합니다. 만약 tmp 폴더가 개발 환경에서 누락되었거나 지나치게 제한적인 권한이 적용되면 tmux 세션을 실행할 수 없습니다. 이 경우 IDE의 터미널 창이 응답하지 않습니다.

권장 해결 방법: tmux 오류로 인해 터미널 창과 상호 작용할 수 없는 경우 올바른 권한이 있는 tmp 폴더를 생성하는 다른 방법을 사용해야 합니다. 그렇게 하면 tmux 세션을 실행할 수 있습니다. 한 가지 해결책은 LC_CTYPE을 .bash_profile 또는 .bashrc 파일에 내보내는 것입니다. 또 다른 권장 해결 방법은 호스트 관리 AWS Systems Manager 구성을 설정하는 데 사용하는 것입니다. 이렇게 하면 Amazon EC2 콘솔을 통해 관련 인스턴스에 액세스할 수 있습니다.

호스트 관리 설정

  1. 먼저 AWS Cloud9 콘솔에서 환경 인스턴스의 이름을 찾으십시오. Your environments(환경) 페이지에서 관련 패널을 선택하고 View details(세부 정보 보기)를 선택하면 됩니다. 환경 세부 정보 페이지에서 인스턴스로 이동(Go to Instance)을 선택합니다. Amazon EC2 콘솔에서 액세스해야 하는 인스턴스의 이름을 확인합니다.

  2. 이제 AWS Systems Manager 콘솔로 이동하여 탐색 창에서 Quick Setup을 선택합니다.

  3. 빠른 설정 페이지에서 생성(Create)을 선택합니다.

  4. 구성 유형(Configuration types)에서 호스트 관리(Host Management)로 이동하고 생성(Create)을 선택합니다.

  5. 호스트 관리 구성 옵션 사용자 지정(Customize Host Management configuration options)의 대상(Targets) 섹션에서 수동(Manual)을 선택합니다.

  6. 액세스하려는 EC2 인스턴스를 선택한 다음 생성(Create)을 선택합니다.

인스턴스에 연결 및 명령 실행

참고

다음 단계는 새로운 EC2 콘솔용입니다.

  1. Amazon EC2 콘솔의 탐색 창에서 인스턴스(Instances)를 선택한 다음 연결하려는 인스턴스를 선택합니다.

  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 또는 PuTTY 등과 같은 SSH 원격 액세스 유틸리티를 사용하여 인스턴스에 연결할 수도 있습니다. 이렇게 하려면 로컬 컴퓨터에서 ssh-keygen 또는 PuTTYgen 등과 같은 SSH 키 페어 생성 유틸리티를 사용합니다. 인스턴스에 연결된 환경의 AWS Cloud9 IDE를 사용하여 생성된 공개 키를 인스턴스에 저장합니다. 그런 다음 생성한 프라이빗 키와 함께 SSH 원격 액세스 유틸리티를 사용하여 인스턴스에 액세스합니다. 자세한 내용은 해당 유틸리티 설명서를 참조하세요.

AWS CLI 또는 AWS-shell 오류: EC2 환경에서 “요청에 포함된 보안 토큰이 유효하지 않습니다.”

문제: EC2 환경용 AWS Cloud9 IDE에서 AWS Command Line Interface (AWS CLI) 또는 AWS-shell을 사용하여 명령을 실행하려고 하면 “요청에 포함된 보안 토큰이 유효하지 않습니다.” 라는 오류 메시지가 표시됩니다.

원인: AWS 관리형 임시 자격 증명을 사용하도록 설정하고 다음 중 하나가 발생할 경우에 보안 토큰이 잘못될 수 있습니다.

  • AWS 관리형 임시 자격 증명으로 허용되지 않는 명령을 실행하려고 했습니다. 허용되는 명령 목록은 단원을 참조하세요AWS 관리형 임시 자격 증명이 지원하는 작업

  • AWS 관리형 임시 자격 증명은 15분 후에 자동으로 만료됩니다.

  • 환경 소유자가 아닌 다른 사람이 새 구성원을 추가했기 때문에 공유 환경의 AWS 관리형 임시 자격 증명이 비활성화되었습니다.

권장 솔루션:

  • AWS 관리형 임시 자격 증명에서 허용하는 명령만 실행하십시오. AWS 관리형 임시 자격 증명으로 허용되지 않는 명령을 실행해야 하는 경우 영구 자격 증명 세트를 사용하여 환경에서 AWS CLI 또는 AWS-shell을 구성하십시오. 이렇게 하면 이러한 제한이 해소됩니다. 지침은 영구 액세스 자격 증명을 생성하여 환경에 저장을 참조하세요.

  • 비활성화되거나 만료된 자격 증명의 경우 환경 소유자가 환경을 열어 해당 환경의 임시 자격 증명을 새로 고칠 AWS Cloud9 수 있도록 해야 합니다. 자세한 정보는 AWS 관리형 임시 자격 증명에 대한 액세스 제어을 참조하세요.

Docker에서 VPC의 IP 주소를 사용하므로 EC2 환경에 연결할 수 없음

문제: EC2 환경의 경우, IPv4 Classless Inter-Domain Routing(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 인스턴스에 연결할 수 없습니다.

권장 해결 방법: 동일한 IPv4 CIDR 주소 블록을 사용하는 Amazon VPC와 Docker로 인한 IP 주소 충돌을 해결하려면 EC2 환경을 지원하는 인스턴스에 대해 새 VPC를 구성합니다. 이 새 VPC의 CIDR 블록을 172.17.0.0/16과 다른 블록으로 구성합니다. (기존 VPC 또는 서브넷의 IP 주소 범위는 변경할 수 없습니다.)

구성 정보는 Amazon VPC 사용 설명서에서 VPC 및 서브넷 크기 조정을 참조하세요.

AWS Cloud9 IDE 파일 탐색기에서 하위 폴더 구조인 /home/ec2-user/environment/home/ec2-user/environment를 만들 수 없습니다.

문제: AWS Cloud9 IDE 파일 탐색기에서 하위 폴더 구조 /home/ec2-user/environment/home/ec2-user/environment를 생성할 때 이 디렉토리를 열 수 없다는 오류 메시지가 나타납니다.

가능한 원인: 현재 IDE의 파일 시스템을 사용하여 같은 이름의 폴더 내에 하위 폴더 구조 /home/ec2-user/environment 를 만들 수 없습니다. AWS Cloud9 AWS Cloud9 IDE 파일 탐색기에서는 이 디렉터리 내의 파일에 액세스할 수 없지만 명령줄을 사용하여 액세스할 수 있습니다. 이 문제는 파일 경로 /home/ec2-user/environment/home/ec2-user/environment에만 영향을 미치며 /test/home/ec2-user/environment 및 /home/ec2-user/environment/test와 같은 파일 경로가 적합합니다. 이는 알려진 문제이며 AWS Cloud9 IDE 파일 탐색기에만 영향을 미칩니다.

권장 해결 방법: 다른 파일 이름 및 구조를 사용하세요.

AWS License Manager 라이선스 구성이 Amazon EC2 인스턴스와 연결된 경우 AWS Cloud9 콘솔에서 시작할 수 없음

문제: 콘솔에서 AWS Cloud9 EC2 환경을 시작하려고 하면 오류 메시지가 unable to access your environment 반환됩니다.

가능한 원인: 전체 소프트웨어 공급업체 라이선스의 관리를 AWS License Manager 간소화합니다. AWS 클라우드 License Manager를 설정할 때 기업 계약 조건을 기반으로 하는 라이선스 규칙 집합인 라이선스 구성을 생성합니다. 이러한 라이선스 구성은 Amazon 머신 이미지 (AMI) 또는 같은 메커니즘에 연결할 수 AWS CloudFormation있습니다. 이러한 메커니즘 중 하나를 사용하여 EC2 인스턴스를 시작할 수 있습니다.

AWSCloud9ServiceRolePolicyfor AWSServiceRoleForAWSCloud 9 서비스 연결 역할 (SLR) 의 이전 버전에는 현재 리소스 조건이 포함되어 있지 않습니다. license-configuration 이로 인해 인스턴스를 시작하고 중지할 수 AWS Cloud9 없습니다. 따라서 Amazon EC2 인스턴스에 대한 AWS Cloud9 액세스가 거부되고 오류가 반환됩니다.

권장 해결 방법: 기존 AWS Cloud9 환경에 액세스하여 License Manager를 사용할 수 없는 경우, 이전 AWSCloud9ServiceRolePolicy서비스 연결 역할을 인스턴스에 적용할 때 EC2 작업을 명시적으로 허용하는 SLR 버전으로 교체하십시오. license-configuration 이전 역할을 삭제하여 간단히 바꿀 수 있습니다. 그러면 업데이트된 역할이 자동으로 생성됩니다.

EC2 환경에서 일부 명령 또는 스크립트를 실행할 수 없음

문제: AWS Cloud9 EC2 개발 환경을 연 후에는 일부 유형의 패키지를 yum 설치하거나 또는 apt 같은 명령을 실행할 수 없으며 일반적으로 다른 Linux 운영 체제에서 작동하는 명령이 포함된 스크립트를 실행할 수 없습니다.

원인: EC2 환경에 AWS Cloud9 사용하는 Amazon EC2 인스턴스는 아마존 리눅스 (레드햇 엔터프라이즈 리눅스 (RHEL) 기반) 또는 우분투 서버를 기반으로 합니다.

솔루션: 패키지를 설치 또는 관리하거나 EC2 환경에 대한 IDE에서 명령 또는 스크립트를 실행하는 경우 해당 환경의 인스턴스에 따라 RHEL(Amazon Linux의 경우) 또는 Ubuntu Server와 호환되는지 확인하세요.

를 사용하여 EC2 환경을 생성할 때 “계정에 인스턴스 AWSCloud9SSMInstanceProfile 프로필이 없습니다”라는 오류 메시지가 보고됩니다. AWS CloudFormation

문제: AWS::Cloud9::Environment EC2 AWS CloudFormation 리소스를 사용하여 EC2 환경을 생성할 때 사용자에게 인스턴스 프로필이 계정에 존재하지 AWSCloud9SSMInstanceProfile 않는다는 오류 메시지가 표시됩니다.

원인: 수신하지 않는 EC2 환경을 생성할 때 서비스 역할 AWSCloud9SSMAccessRole과 인스턴스 프로파일 AWSCloud9SSMInstanceProfile을 생성해야 합니다. 이러한 IAM 리소스를 통해 Systems Manager는 개발 환경을 백업하는 EC2 인스턴스를 관리할 수 있습니다.

콘솔을 사용하여 수신하지 않는 환경을 만드는 경우 AWSCloud9SSMAccessRole 및 AWSCloud9SSMInstanceProfile이 자동으로 생성됩니다. 하지만 AWS CloudFormation 또는 AWS CLI 를 사용하여 처음으로 무수신 환경을 만들 때는 이러한 IAM 리소스를 수동으로 생성해야 합니다.

권장 솔루션: AWS CloudFormation 템플릿 편집 및 IAM 권한 업데이트에 대한 자세한 내용은 을 참조하십시오. AWS CloudFormation을 사용하여 수신하지 않는 EC2 환경 생성

AWS CloudFormation을 사용하여 EC2 환경을 만들 때 ‘리소스에서 perform: ssm:StartSession에 대한 권한 없음’이라는 오류 메시지가 표시됨

문제: AWS::Cloud9::Environment EC2 AWS CloudFormation 리소스를 사용하여 EC2 환경을 만들 때 사용자는 “리소스에서 작업을 수행할 권한이 없음”이라는 알림을 AccessDeniedException 받고 알림을 받습니다. ssm:StartSession

원인: Systems Manager가 수신하지 않는 인스턴스에 사용하는 EC2 환경에 대한 구성의 일부로서 필요한 StartSession API를 호출할 권한이 사용자에게 없습니다.

권장 솔루션: AWS CloudFormation 템플릿 편집 및 IAM 권한 업데이트에 대한 자세한 내용은 을 참조하십시오. AWS CloudFormation을 사용하여 수신하지 않는 EC2 환경 생성

AWS CLI를 사용하여 EC2 환경을 생성할 때 "리소스에 iam:GetInstanceProfile: 인스턴스 프로파일 AWSCloud9SSMInstanceProfile를 수행할" 권한이 없음을 보고하는 오류 메시지

문제: 를 사용하여 EC2 환경을 만들 때 사용자는 해당 환경이 “리소스: 인스턴스 GetInstanceProfile 프로필에서 iam을 수행할 수 있는” 권한이 없다는 알림을 받고 알림을 받습니다. AWS CLIAccessDeniedException AWS Cloud9 AWSCloud9SSMInstanceProfile

원인: AWS Cloud9 무수신 인스턴스에 대해 Systems Manager를 사용하는 EC2 환경 구성의 일부로 필요한 StartSession API를 호출할 권한이 없습니다.

권장 솔루션: 환경에 필요한 AWSCloud9SSMAccessRole 서비스 역할을 추가하는 방법에 대한 자세한 내용은 AWSCloud9SSMInstanceProfile 을 참조하십시오. AWS Cloud9 AWS CLI를 사용하여 Systems Manager의 인스턴스 프로파일 관리

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 서비스 연결 역할에 대한 EBS 볼륨에 대한 액세스 권한이 AWS Cloud9 필요합니다. AWS KMS keys 액세스가 제공되지 않으면 AWS Cloud9 IDE가 시작되지 않을 수 있으며 문제를 디버깅하기 어려울 수 있습니다.

권장 솔루션: 액세스를 제공하려면 Amazon EBS 볼륨에서 사용하는 고객 관리 키에 AWS Cloud9AWSServiceRoleForAWSCloud9, 의 서비스 연결 역할을 추가하십시오.

이 작업에 대한 자세한 내용은 AWS 규범적 지침 패턴의 AWS Cloud9 기본 암호화가 적용된 Amazon EBS 볼륨을 사용하는 Amazon EBS 볼륨 생성을 참조하십시오.

EC2-Classic 계정에 대한 VPC 오류: "Unable to access your environment(사용자 환경에 액세스할 수 없음)"

문제: EC2-Classic이 Amazon EC2의 원래 릴리스에 도입되었습니다. 2013년 12월 4일 이전에 설정된 AWS 계정 것을 사용하는 경우, AWS Cloud9 EC2 개발 환경을 생성할 때 Amazon VPC와 서브넷을 구성하지 않으면 이 오류가 발생할 수 있습니다.

기본 VPC 설정을 수락하면 EC2-Classic 네트워크에서 Amazon EC2 인스턴스가 시작됩니다. 인스턴스는 기본 VPC의 서브넷에서 시작되지 않습니다. 환경 생성이 실패하면 다음과 같은 메시지가 표시됩니다.

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 데 사용합니다.

  1. AWS CloudFormation 콘솔을 엽니다. 자세한 내용은 AWS CloudFormation 콘솔에 로그인을 참조하세요.

  2. AWS CloudFormation 콘솔에서 스택을 선택합니다.

  3. Stacks(스택) 페이지에서 생성하지 못한 개발 환경의 이름을 선택합니다.

  4. Stack details(스택 세부 정보) 페이지에서 Events(이벤트) 탭을 선택하고 다음 항목을 확인합니다.

    Status: CREATE_FAILED

    상태 이유: AssociatePublicIpAddress 매개변수는 VPC 시작 시에만 지원됩니다. [...]

원인: AWS Cloud9 개발 환경은 특정 VPC 요구 사항을 충족하는 Amazon VPC와 연결되어야 합니다. EC2-Classic이 활성화된 계정의 경우, EC2 환경 생성 시 기본 네트워크 설정을 수락하면 VPC에서 필수 EC2 인스턴스가 시작되지 않습니다. 대신, EC2-Classic 네트워크에서 인스턴스가 시작됩니다.

권장 솔루션: EC2-Classic 계정의 경우, EC2 환경 생성 시 VPC 및 서브넷을 선택해야 합니다. Configure settings(설정 구성) 페이지의 Network settings (advanced)(네트워크 설정(고급)) 섹션에서 EC2 인스턴스를 시작할 수 있는 VPC 및 서브넷을 선택합니다.

기타 서비스 AWS

다음 섹션에서는 기타 AWS 서비스와 관련된 문제 해결 문제를 간략하게 설명합니다.

IDE의 파일 탐색기 내에서 하위 폴더 구조 /projects/projects를 만들 수 없습니다. AWS Cloud9 CodeCatalyst

문제: AWS Cloud9 IDE 파일 탐색기에서 하위 폴더 구조 /projects/projects를 만들 때 이 디렉토리를 열 수 없다는 오류 메시지가 나타납니다. CodeCatalyst

가능한 원인: 현재 IDE의 파일 탐색기를 사용하여 같은 이름의 폴더 내에 하위 폴더 구조 /projects를 만들 수 없습니다. AWS Cloud9 CodeCatalyst AWS Cloud9 IDE 파일 탐색기에서는 이 디렉터리 내의 파일에 액세스할 수 없지만 명령줄을 사용하여 액세스할 수 있습니다. 이 문제는 /projects/projects 파일 경로에만 영향을 미치며, /test/projects와 /projects/test/projects 같은 파일 경로가 적합합니다. 이는 알려진 문제이며 해당 AWS Cloud9 IDE 파일 탐색기에만 영향을 줍니다 CodeCatalyst.

권장 해결 방법: 다른 파일 이름 및 구조를 사용하세요.

IDE 외부에서 실행 중인 애플리케이션을 표시할 수 없음

문제: IDE 외부에서 웹 브라우저 탭에서 실행 중인 애플리케이션을 보려고 하면 웹 브라우저 탭에 오류가 표시되거나 탭이 비어 있습니다.

가능한 원인:

  • IDE에서 애플리케이션이 실행되고 있지 않습니다.

  • 애플리케이션이 IP 127.0.0.1 또는 localhost를 사용해 실행 중입니다.

  • 애플리케이션이 AWS Cloud9 EC2 개발 환경에서 실행 중입니다. 해당하는 Amazon EC2 인스턴스와 연결된 하나 이상의 보안 그룹이 애플리케이션에 필요한 프로토콜, 포트 또는 IP 주소를 통한 인바운드 트래픽을 허용하지 않습니다.

  • 애플리케이션이 AWS 클라우드 컴퓨팅 인스턴스 (예: Amazon EC2 인스턴스) 를 위한 AWS Cloud9 SSH 개발 환경에서 실행되고 있습니다. 또한 해당 인스턴스와 연결된 Virtual Private Cloud(VPC)의 서브넷에 대한 네트워크 ACL이 애플리케이션에 필요한 프로토콜 포트 또는 IP 주소를 통한 인바운드 트래픽을 허용하지 않습니다.

  • URL이 올바르지 않습니다.

  • 인스턴스의 퍼블릭 IP 주소 대신 애플리케이션 미리 보기 탭의 URL이 요청됩니다.

  • 127.0.0.1 또는 localhost IP가 포함된 주소로 이동하려고 했습니다. 이러한 IP는 환경의 리소스가 아니라 로컬 컴퓨터의 리소스에 액세스하려고 합니다.

  • 인스턴스의 퍼블릭 IP 주소가 변경되었습니다.

  • 웹 요청이 애플리케이션에 필요한 프로토콜, 포트 또는 IP 주소를 통한 트래픽을 차단하는 가상 프라이빗 네트워크(VPN)에서 시작되었습니다.

  • 애플리케이션이 SSH 환경에서 실행 중입니다. 하지만 서버 또는 연결된 네트워크가 애플리케이션에 필요한 프로토콜, 포트 또는 IP 주소를 통한 트래픽을 허용하지 않습니다.

권장 솔루션:

  • 애플리케이션이 IDE에서 실행 중인지 확인하세요.

  • 애플리케이션이 IP 127.0.0.1 또는 localhost를 사용해 실행 중이지 않은지 확인하세요. 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 주소가 변경되지 않도록 하려면 탄력적 IP 주소를 할당한 후 해당 주소를 실행 중인 인스턴스에 할당합니다. 자세한 내용은 인터넷을 통해 실행 중인 애플리케이션 공유에서 4단계: 실행 중인 애플리케이션 URL 공유 섹션을 참조하세요.

  • 웹 요청이 VPN에서 시작된 경우 VPN이 애플리케이션에 필요한 프로토콜, 포트 또는 IP 주소를 통한 트래픽을 허용하는지 확인하십시오. VPN을 변경할 수 없는 경우 네트워크 관리자에게 문의하세요. 또는 가능한 경우 다른 네트워크에서 웹 요청을 수행하세요.

  • 애플리케이션이 자체 서버의 SSH 환경에서 실행 중인 경우 서버 및 연결된 네트워크가 애플리케이션에 필요한 프로토콜, 포트 및 IP 주소를 통한 트래픽을 허용하는지 확인하세요. 서버 또는 연결된 네트워크를 변경할 수 없는 경우 서버 또는 네트워크 관리자에게 문의하세요.

  • URL 앞에서 curl 명령을 실행하여 환경의 터미널에서 애플리케이션을 실행해 보세요. 이 명령어에 오류 메시지가 표시되는 경우 관련 없는 다른 문제가 있을 수 있습니다. AWS Cloud9

AWS 툴킷 실행 중 오류: “환경에 inode가 부족합니다. 'fs.inotify.max_user_watchs' 제한을 늘리십시오.”

문제: AWS 툴킷에서 사용하는 파일 감시 유틸리티가 감시할 수 있는 파일의 현재 한도 또는 할당량에 근접하고 있습니다.

원인: AWS 툴킷은 파일 및 디렉토리의 변경 사항을 모니터링하는 파일 감시 유틸리티를 사용합니다. 유틸리티가 감시할 수 있는 파일 수의 현재 할당량에 가까울 때 경고 메시지가 나타납니다.

권장 솔루션: 파일 감시자가 처리할 수 있는 최대 파일 수를 늘리려면 다음을 수행합니다.

  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 함수의 로컬 버전을 실행하려고 하면 대화 상자가 표시됩니다. 대화 상자에 SAM Local을 설치하는 데 문제가 있다고 표시됩니다. AWS Cloud9 AWS Cloud9 IDE에서 로컬 버전의 AWS Lambda 함수를 실행하려면 SAM Local이 필요합니다. SAM Local이 설치될 때까지 IDE에서 Lambda 함수의 로컬 버전을 실행할 수 없습니다.

원인: 환경의 예상 경로에서 SAM Local을 찾을 AWS Cloud9 수 없습니다~/.c9/bin/sam. 이는 SAM Local이 아직 설치되지 않았거나, 설치된 경우에는 AWS Cloud9 에서 설치 위치를 찾을 수 없기 때문입니다.

권장 해결 방법: SAM Local 설치가 완료될 때까지 AWS Cloud9 기다리거나 직접 설치할 수 있습니다.

SAM Local 설치 시도가 어떻게 AWS Cloud9 진행되는지 보려면 메뉴 표시줄에서 [창], [설치 프로그램] 을 선택하십시오.

SAM Local을 직접 설치하려면 AWS Serverless Application Model 개발자 안내서의 Linux에 AWS SAM CLI 설치에 나와 있는 지침을 따르십시오.

AWS Control Tower 다음을 사용하여 AWS Cloud9 Amazon EC2 환경을 생성하려고 할 때 오류가 발생했습니다. “오류가 발생하여 환경 생성에 실패했습니다. [: :GuardControlTower: :Hook].”

문제: 사전 예방적 제어 AWS Cloud9 AWS Control Tower CT.EC2.PR.8에 호환성 문제가 있습니다. 이 컨트롤이 활성화되면 AWS Cloud9에서 EC2 환경을 만들 수 없습니다.

원인: 매개 변수가 AWS Control Tower 템플릿에 있을 것으로 예상하고 있습니다. AssociatePublicIpAddress AWS CloudFormation 지금은 이 파라미터를 추가할 수 없습니다.

권장 해결 방법: 콘솔에서 컨트롤 CT.EC2.PR.8을 비활성화하고 에서 환경을 다시 생성하십시오 AWS Control Tower . AWS Cloud9

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 서비스 연결 역할에 대한 EBS 볼륨에 대한 액세스 권한이 AWS Cloud9 필요합니다. AWS KMS keys 액세스가 제공되지 않으면 AWS Cloud9 IDE가 시작되지 않을 수 있으며 문제를 디버깅하기 어려울 수 있습니다.

권장 솔루션: 액세스를 제공하려면 Amazon EBS 볼륨에서 사용하는 고객 관리 키에 AWS Cloud9AWSServiceRoleForAWSCloud9, 의 서비스 연결 역할을 추가하십시오.

이 작업에 대한 자세한 내용은 AWS 규범적 지침 패턴의 AWS Cloud9 기본 암호화가 적용된 Amazon EBS 볼륨을 사용하는 Amazon EBS 볼륨 생성을 참조하십시오.

(맨 위로 이동)

AWS License Manager 라이선스 구성이 Amazon EC2 인스턴스와 연결된 경우 AWS Cloud9 콘솔에서 시작할 수 없음

문제: 콘솔에서 AWS Cloud9 EC2 환경을 시작하려고 하면 오류 메시지가 unable to access your environment 반환됩니다.

가능한 원인: 전체 소프트웨어 공급업체 라이선스의 관리를 AWS License Manager 간소화합니다. AWS 클라우드 License Manager를 설정할 때 기업 계약 조건을 기반으로 하는 라이선스 규칙 집합인 라이선스 구성을 생성합니다. 이러한 라이선스 구성은 Amazon 머신 이미지 (AMI) 또는 같은 메커니즘에 연결할 수 AWS CloudFormation있습니다. 이러한 메커니즘 중 하나를 사용하여 EC2 인스턴스를 시작할 수 있습니다.

AWSCloud9ServiceRolePolicyfor AWSServiceRoleForAWSCloud 9 서비스 연결 역할 (SLR) 의 이전 버전에는 현재 리소스 조건이 포함되어 있지 않습니다. license-configuration 이로 인해 인스턴스를 시작하고 중지할 수 AWS Cloud9 없습니다. 따라서 Amazon EC2 인스턴스에 대한 AWS Cloud9 액세스가 거부되고 오류가 반환됩니다.

권장 해결 방법: 기존 AWS Cloud9 환경에 액세스하여 License Manager를 사용할 수 없는 경우, 이전 AWSCloud9ServiceRolePolicy서비스 연결 역할을 인스턴스에 적용할 때 EC2 작업을 명시적으로 허용하는 SLR 버전으로 교체하십시오. license-configuration 이전 역할을 삭제하여 간단히 바꿀 수 있습니다. 그러면 업데이트된 역할이 자동으로 생성됩니다.

(맨 위로 이동)

애플리케이션 미리 보기

다음 섹션에서는 애플리케이션 미리 보기와 관련된 문제 해결 문제를 간략하게 설명합니다.

환경을 다시 로드한 후 애플리케이션 미리 보기를 새로 고쳐야 함

문제: 애플리케이션 미리 보기 탭을 표시하는 환경을 다시 로드한 후 해당 탭에 애플리케이션 미리 보기가 표시되지 않습니다.

원인: 때때로 사용자가 무한 루프를 실행할 수 있는 코드를 작성합니다. 또는 코드에 너무 많은 메모리를 사용해서 애플리케이션 미리보기가 실행 중일 때 AWS Cloud9 IDE가 일시 중지되거나 중지될 수 있습니다. 이 문제가 발생하지 않도록 하려면 환경을 다시 로드할 때마다 응용 프로그램 미리 보기 탭을 다시 로드하지 AWS Cloud9 않습니다.

솔루션: 애플리케이션 미리 보기 탭을 표시하는 환경을 다시 로드한 후 애플리케이션 미리 보기를 표시하려면 탭에서 [페이지를 로드하려면 클릭(Click to load the page)] 버튼을 선택합니다.

애플리케이션 미리 보기 또는 파일 미리 보기 알림: ‘서드 파티 쿠키가 사용 중지됨(Third-party cookies disabled)’

문제: 응용 프로그램 또는 파일을 미리 보려고 하면 알림에 다음과 같은 메시지가 표시됩니다. “브라우저에 타사 쿠키가 비활성화되어 있으므로 미리 보기 기능이 비활성화됩니다.”

원인: IDE를 여는 데 타사 쿠키가 필요하지 않습니다. AWS Cloud9 그러나 애플리케이션 미리 보기 또는 파일 미리 보기 기능을 사용하려면 서드 파티 쿠키를 활성화해야 합니다.

해결 방법: 웹 브라우저에서 타사 쿠키를 활성화하고, IDE를 다시 로드한 다음, 미리 보기를 다시 열어 보십시오.

웹 브라우저에서 이러한 세분성을 허용하는 경우 AWS Cloud9에 대해서만 서드 파티 쿠키를 활성화할 수 있습니다. 이렇게 하려면 AWS Cloud9을 사용하려는 지원 AWS 리전 에 따라 다음 도메인을 지정합니다.

AWS 리전 도메인

미국 동부(버지니아 북부)

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

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

미국 동부(오하이오)

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

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

미국 서부(캘리포니아 북부)

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

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

미국 서부(오레곤)

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

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

아프리카(케이프타운)

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

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

아시아 태평양(홍콩)

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

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

아시아 태평양(뭄바이)

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

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

아시아 태평양(오사카)

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

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

아시아 태평양(서울)

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

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

아시아 태평양(싱가포르)

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

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

아시아 태평양(시드니)

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

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

아시아 태평양(도쿄)

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

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

캐나다(중부)

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

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

유럽(프랑크푸르트)

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

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

유럽(아일랜드)

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

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

유럽(런던)

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

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

유럽(밀라노)

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

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

유럽(파리)

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

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

유럽(스톡홀름)

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

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

중동(바레인)

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

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

남아메리카(상파울루)

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

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

애플리케이션 미리 보기 탭에 오류가 표시되거나 이 탭이 비어 있음

문제: IDE의 메뉴 모음에서 [미리 보기, 실행 중인 애플리케이션 미리 보기(Preview, 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에 대한 인바운드 트래픽을 차단합니다.

  • 127.0.0.1, localhost 또는 0.0.0.0 IP가 포함된 주소로 이동하려고 했습니다. 기본적으로 AWS Cloud9 IDE는 로컬 컴퓨터로 이동하려고 시도합니다. 환경에 연결된 인스턴스나 자체 서버로 이동하려고 시도하지 않습니다.

권장 솔루션:

  • 애플리케이션이 IDE에서 실행 중인지 확인하세요.

  • 애플리케이션이 HTTP를 사용하여 실행 중인지 확인하십시오. Node.js 및 Python으로 작성된 예제는 단원을 참조하세요애플리케이션 실행

  • 애플리케이션이 하나의 포트만 통해 실행 중인지 확인하십시오. 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에서 웹 콘텐츠를 미리 볼 수 없음

문제: AWS Cloud9 EC2 환경에서 호스팅되는 WordPress 사이트와 같은 웹 콘텐츠에 액세스하려고 하면 IDE 미리 보기 창에 해당 콘텐츠가 표시되지 않습니다.

가능한 원인: 기본적으로 AWS Cloud9 IDE의 애플리케이션 미리 보기 탭에서 액세스하는 모든 웹 페이지는 자동으로 HTTPS 프로토콜을 사용합니다. 페이지의 URI에 안전하지 않은 http 프로토콜이 있으면 자동으로 https로 대체됩니다. 그리고 수동으로 https를 다시 http로 변경하더라도 안전하지 않은 콘텐츠에 액세스할 수 없습니다.

권장 솔루션: IDE에서 미리 보려는 웹 사이트에서 안전하지 않은 HTTP 스크립트 또는 콘텐츠를 제거합니다. 웹 서버 또는 콘텐츠 관리 시스템에 대한 지침에서 HTTPS 구현에 대한 지침을 따릅니다.

파일을 미리 보려고 하는데 499 오류가 반환됨

문제: 특성이 포함되고 src 속성이 로 설정된 <script> 요소가 포함된 파일을 AWS Cloud9 IDE를 사용하여 미리 보려고 하면 499 오류가 발생하고 스크립트가 예상대로 실행되지 않습니다. type module

원인: AWS Cloud9 IDE의 파일 미리 보기 가져오기 요청은 인증을 위해 웹 브라우저에서 쿠키를 보내야 합니다. 기본적으로 웹 브라우저는 일반 스크립트 요청에 대해 쿠키를 전송하지만 crossorigin 속성을 추가하지 않는 한 모듈 스크립트 요청에 대해서는 쿠키를 전송하지 않습니다.

솔루션: <script> 요소에 crossorigin 속성을 추가하십시오. 예를 들어 <script type="module" src="index.js" crossorigin></script>입니다. 그런 다음 변경된 파일을 저장하고 미리 보기를 다시 시도해 보세요.

성능

다음 섹션에서는 성능과 관련된 문제 해결을 간략하게 설명합니다.

AWS Cloud9 IDE가 상당한 시간 동안 멈췄습니다.

문제: 시작 중 및 새로 고침을 수행할 때 AWS Cloud9 IDE 터미널이 상당한 시간 동안 정지되어 사용할 수 없게 됩니다.

원인: AWS Cloud9의 파일 감시 모듈에서 반복적으로 감시하는 많은 양의 파일이 사용자 환경에 있을 수 있습니다.

권장 솔루션: 파일 감시 깊이(최소값은 1)를 줄이고 소스 코드와 관련되지 않은 큰 폴더 또는 폴더(빌드 출력/아티팩트, 서드 파티 패키지)를 무시된 패턴에 추가하는 것을 고려할 수 있습니다. 이렇게 하려면 기본 설정 > 사용자 설정 > 파일 감시로 이동합니다. 이로 인해 CodeLenses In AWS Toolkit이 제대로 작동하지 않을 수 있다는 점에 유의하십시오.

또 다른 가능한 해결 방법은 검색할 최대 파일 수를 줄여 소스 코드와 관련이 없는 대용량 파일 및 폴더를 무시하는 것입니다. 이렇게 하려면 기본 설정 > 프로젝트 설정 > 파일에서 찾기로 이동합니다. 이렇게 하면 무시된 폴더가 파일 검색에 표시되지 않으니 주의하세요.

콘솔 경고: ‘최소 코드 완성 엔진으로 전환하는 중...(Switching to the minimal code completion engine...)’

문제: AWS Cloud9 콘솔에서 작업할 때 (예: IDE를 열거나 IDE의 웹 페이지를 새로 고칠 때) 다음 메시지가 표시됩니다. “하나 이상의 세션 또는 공동 작업자가 이 환경에서 활동 중입니다. 메모리를 절약하기 위해 최소 코드 완성 엔진으로 전환하는 중입니다.”라는 메시지가 표시됩니다. 이 메시지와 관련하여, 코드 완성 동작이 느려지거나 간헐적일 수 있습니다.

원인: 코드 완성 엔진을 실행하느라 환경의 메모리 및 CPU 주기가 소모됩니다. 또한 협력자와 추가 세션마다 별도의 코드 완성 엔진이 필요합니다. 특히 t2.nano 및 같은 작은 인스턴스 크기에서 리소스를 너무 많이 사용하지 않으려면 최소 코드 t2.micro 완성 엔진으로 AWS Cloud9 전환하십시오.

권장 해결 방법: 장기간에 걸쳐 자주 협업을 하는 경우 EC2 환경을 만들 때 더 큰 Amazon EC2 인스턴스를 선택하거나 용량이 더 큰 인스턴스에 SSH 환경을 연결합니다.

참고

더 큰 Amazon EC2 인스턴스를 선택하면 추가 요금이 발생할 AWS 계정 수 있습니다. 자세한 내용은 Amazon EC2 요금을 참조하세요.

IDE 경고: ‘이 환경의 메모리가 부족함(This environment is running low on memory)’ 또는 ‘이 환경의 CPU 부하 상태가 높음(This environment has high CPU load)’

문제: IDE가 실행 중인데 ‘이 환경의 메모리가 부족함(this environment is running low on memory)’ 또는 ‘이 환경의 CPU 부하 상태가 높음(this environment has high CPU load)’이라는 문구가 포함된 메시지가 표시됩니다.

원인: IDE에 지연 또는 중단 없이 계속해서 실행하는 데 사용할 수 있는 충분한 컴퓨터 리소스가 없을 수 있습니다.

권장 솔루션:

  • 실행 중인 프로세스를 하나 이상 중지해 사용 가능한 메모리를 확보하십시오. 이렇게 하려면 환경용 IDE의 메뉴 모음에서 [도구, 프로세스 목록(Tools, Process List)]을 선택합니다. 중지하려는 각 프로세스에 대해 프로세스를 선택한 다음 Force Kill(강제 종료)을 선택합니다.

  • 환경에서 스왑 파일을 생성합니다. 스왑 파일은 운영 체제가 가상 메모리로 사용할 수 있는 환경의 파일입니다.

    환경에서 현재 스왑 메모리를 사용하고 있는지 확인하려면 환경의 터미널 세션에서 top 명령을 실행합니다. 스왑 메모리를 사용 중인 경우 출력에 0이 아닌 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이라는 512MB 파일을 생성합니다.

    2. 소유자만 읽기-쓰기가 가능하도록 swapfile 파일에 대한 액세스 권한을 변경합니다.

    3. swapfile 파일을 스왑 파일로 설정합니다.

    4. /etc/fstab file에 정보를 씁니다. 그러면 시스템을 재부팅할 때마다 이 스왑 파일을 사용할 수 있습니다.

    위의 명령을 실행한 후 이 스왑 파일을 즉시 사용하도록 설정하려면 다음 명령을 실행합니다.

    sudo swapon /var/swapfile

  • 추가 컴퓨팅 리소스를 사용하여 인스턴스 또는 서버로 환경을 이동하거나 크기를 조정합니다. Amazon EC2 인스턴스를 이동하거나 크기를 조정하려면 환경 이동 및 Amazon EBS 볼륨 크기 조정 또는 암호화 섹션을 참조하세요. 다른 인스턴스 또는 서버 유형의 경우 인스턴스 또는 서버의 설명서를 참조하세요.

IDE에서 파일을 업로드할 수 없습니다. AWS Cloud9

문제: 사용자가 AWS Cloud9 IDE에서 대용량 파일을 업로드할 수 없습니다. 이러한 업로드는 실패합니다.

원인: AWS Cloud9 IDE로의 업로드 속도를 AWS Cloud9 제한하여 파일 업로드 요청 시간이 초과됩니다.

권장 해결 방법: Amazon S3에 파일을 업로드한 다음 Amazon S3를 사용하여 IDE의 CLI가 있는 환경에 파일을 다운로드하는 것이 좋습니다. AWS Cloud9 Amazon S3에 객체를 업로드하는 방법에 대한 자세한 내용은 Amazon S3 사용 설명서의 객체 업로드를 참조하세요.

IDE의 다운로드 속도가 느립니다. AWS Cloud9

문제: 사용자가 AWS Cloud9 IDE에서 파일을 다운로드하려고 할 때 다운로드 속도가 느려지는 문제를 겪고 있습니다.

원인: IDE에서 로컬 파일 시스템으로 파일을 다운로드할 때 전송 속도는 0.1MB/초의 속도로 제한됩니다.

권장 솔루션: 파일 전송 속도를 높이려면 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 오류로 인해 터미널이 응답하지 않을 수 있습니다. AWS Cloud9 tmux 유틸리티를 사용합니다. 이렇게 하면 페이지가 다시 로드되거나 개발 환경에 다시 연결할 때도 터미널에 표시되는 정보를 유지합니다.

tmux 세션에서 터미널 창에 표시되는 항목은 클라이언트에 의해 처리됩니다. 클라이언트는 여러 세션을 관리할 수 있는 서버와 통신합니다. 서버와 클라이언트는 tmp 폴더에 있는 소켓을 통해 통신합니다. 만약 tmp 폴더가 개발 환경에서 누락되었거나 지나치게 제한적인 권한이 적용되면 tmux 세션을 실행할 수 없습니다. 이 경우 IDE의 터미널 창이 응답하지 않습니다.

권장 해결 방법: tmux 오류로 인해 터미널 창과 상호 작용할 수 없는 경우 올바른 권한이 있는 tmp 폴더를 생성하는 다른 방법을 사용해야 합니다. 그렇게 하면 tmux 세션을 실행할 수 있습니다. 한 가지 해결책은 LC_CTYPE을 .bash_profile 또는 .bashrc 파일에 내보내는 것입니다. 또 다른 권장 해결 방법은 호스트 관리 AWS Systems Manager 구성을 설정하는 데 사용하는 것입니다. 이렇게 하면 Amazon EC2 콘솔을 통해 관련 인스턴스에 액세스할 수 있습니다.

호스트 관리 설정

  1. 먼저 AWS Cloud9 콘솔에서 환경 인스턴스의 이름을 찾으십시오. Your environments(환경) 페이지에서 관련 패널을 선택하고 View details(세부 정보 보기)를 선택하면 됩니다. 환경 세부 정보 페이지에서 인스턴스로 이동(Go to Instance)을 선택합니다. Amazon EC2 콘솔에서 액세스해야 하는 인스턴스의 이름을 확인합니다.

  2. 이제 AWS Systems Manager 콘솔로 이동하여 탐색 창에서 Quick Setup을 선택합니다.

  3. 빠른 설정 페이지에서 생성(Create)을 선택합니다.

  4. 구성 유형(Configuration types)에서 호스트 관리(Host Management)로 이동하고 생성(Create)을 선택합니다.

  5. 호스트 관리 구성 옵션 사용자 지정(Customize Host Management configuration options)의 대상(Targets) 섹션에서 수동(Manual)을 선택합니다.

  6. 액세스하려는 EC2 인스턴스를 선택한 다음 생성(Create)을 선택합니다.

인스턴스에 연결 및 명령 실행

참고

다음 단계는 새로운 EC2 콘솔용입니다.

  1. Amazon EC2 콘솔의 탐색 창에서 인스턴스(Instances)를 선택한 다음 연결하려는 인스턴스를 선택합니다.

  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(Microsoft Edge 정보)를 선택합니다. 업데이트가 필요한 경우 자동으로 다운로드되어 설치됩니다.

C++ 프로젝트를 디버깅할 때 gdb에서 오류 발생

문제: gdb IDE에서 C++ 프로젝트를 디버그하려고 하면 디버거에서 오류가 발생합니다.

가능한 원인: 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 버전 문제일 수 있습니다.

권장 솔루션: AWS Cloud9용 Node.js 설치 방법에 대한 자세한 내용은 1단계: 필수 도구 설치 섹션을 참조하세요.