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

스택 문제 해결 AWS OpsWorks

이 섹션에는 일반적으로 발생하는 몇 가지 AWS OpsWorks Stacks 문제와 해결 방법이 수록되어 있습니다.

인스턴스를 관리할 수 없습니다

문제: 전에는 관리할 수 있었던 인스턴스를 더 이상 관리할 수 없습니다. 일부 경우, 로그에 다음과 비슷한 오류가 표시될 수 있습니다.

Aws::CharlieInstanceService::Errors::UnrecognizedClientException - The security token included in the request is invalid.

원인: 이 문제는 인스턴스가 의존하는 AWS OpsWorks 외부의 리소스가 편집 또는 삭제된 경우, 발생할 수 있습니다. 다음은 인스턴스와의 통신을 끊을 수 있는 리소스 변경의 예입니다.

해결 방법: 인스턴스가 의존하는 IAM 사용자나 역할을 삭제하지 마세요. 가능하다면 종속 인스턴스가 실행 중일 때만 볼륨 또는 스토리지 구성을 편집하세요. 인스턴스의 로드 밸런서 또는 EIP 멤버십을 관리하는 AWS OpsWorks 데 사용합니다. AWS OpsWorks 인스턴스를 등록할 때 사용자가 우연히 삭제될 경우 발생하는 등록된 인스턴스 관리 문제를 예방하려면, register 명령에 --use-instance-profile 파라미터를 추가하여 인스턴스의 내장 인스턴스 프로파일을 대신 사용합니다.

Chef 실행 후 인스턴스가 부팅되지 않습니다

문제: 사용자 지정 쿡북을 사용하도록 구성된 Chef 11.10 또는 이전의 스택에서 커뮤니티 쿡북을 사용한 Chef 실행 후 인스턴스가 부팅되지 않습니다. 로그 메시지에는 레시피가 컴파일에 실패했다거나("Recipe Compile Error") 종속성을 찾을 수 없어서 로드할 수 없다고 표시될 수 있습니다.

원인: 가장 가능성 높은 원인은 사용자 지정 또는 커뮤니티 쿡북이 스택이 사용하는 Chef 버전을 지원하지 않는 것입니다. apt 및 build-essential과 같은 일부 인기 있는 커뮤니티 쿡북은 Chef 11.10과의 알려진 호환성 문제가 있습니다.

솔루션: 사용자 지정 Chef 쿡북 사용 설정이 켜진 AWS OpsWorks 스택에서는 사용자 지정 또는 커뮤니티 쿡북이 스택에서 사용하는 Chef 버전을 항상 지원해야 합니다. 스택 설정에서 구성된 Chef 버전과 호환되는 버전으로 커뮤니티 쿡북을 고정시키십시오(즉, 쿡북 버전을 특정 버전으로 설정). 지원되는 커뮤니티 쿡북 버전을 찾으려면 컴파일에 실패하는 쿡북의 변경 로그를 보고 스택이 지원할 쿡북의 가장 최근 버전만을 사용합니다. 쿡북 버전을 고정하려면 사용자 지정 쿡북 리포지토리의 Berksfile에서 정확한 버전 번호를 지정하세요. 예를 들어 cookbook 'build-essential', '= 3.2.0'입니다.

계층의 인스턴스가 Elastic Load Balancing 상태 확인에 모두 실패

문제: Elastic Load Balancing 로드 밸런서를 앱 서버 계층에 연결하지만 모든 인스턴스가 상태 확인에 실패합니다.

원인: Elastic Load Balancing 로드 밸런서를 생성할 때 인스턴스 상태가 정상인지 확인하기 위해 로드 밸런서가 호출하는 ping 경로를 지정해야 합니다. 애플리케이션에 적합한 ping 경로를 지정해야 합니다. 기본값은 /index.html입니다. 애플리케이션에 index.html이 포함되지 않은 경우, 적절한 경로를 지정해야 상태 확인이 실패하지 않습니다. 예를 들어 Chef 11 Linux 스택 시작하기에서 사용되는 SimplePHPApp 애플리케이션은 index.html을 사용하지 않습니다. 이러한 서버에 적절한 ping 경로는 /입니다.

해결책: 로드 밸런서의 ping 경로를 편집합니다. 자세한 내용은 Elastic Load Balancing을 참조하세요.

Elastic Load Balancing 로드 밸런서와 통신할 수 없음

문제: Elastic Load Balancing 로드 밸런서를 생성해 앱 서버 계층에 연결했지만 애플리케이션을 실행하기 위해 로드 밸런서의 DNS 이름이나 IP 주소를 클릭하면 "원격 서버가 응답하지 않습니다"라는 오류가 표시됩니다.

원인: 스택이 기본 VPC에서 실행되는 경우, 리전에서 Elastic Load Balancing 로드 밸런서를 생성할 때 보안 그룹을 지정해야 합니다. 보안 그룹에는 IP 주소로부터의 인바운드 트래픽을 허용하는 수신 규칙이 있어야 합니다. [기본 VPC 보안 그룹]을 지정한 경우, 기본 수신 규칙은 인바운드 트래픽을 전혀 허용하지 않습니다.

해결책: 적절한 IP 주소로부터의 인바운드 트래픽을 허용하도록 보안 그룹 수신 규칙을 편집합니다.

가져온 온프레미스 인스턴스가 재시작 후 볼륨 설정을 완료하는 데 실패합니다

문제: AWS OpsWorks Stacks로 가져온 EC2 인스턴스를 다시 시작하면 AWS OpsWorks Stacks 콘솔에 인스턴스 상태가 실패로 표시됩니다. 이 문제는 Chef 11 또는 Chef 12 인스턴스에서 발생할 수 있습니다.

원인: AWS OpsWorks Stacks가 설정 프로세스 도중 인스턴스에 볼륨을 연결하지 못할 수 있습니다. 가능한 한 가지 원인은 setup 명령을 실행할 때 AWS OpsWorks Stacks가 인스턴스에서 볼륨 구성을 덮어쓰는 것입니다.

해결책: 인스턴스의 [세부 정보] 페이지를 열고 [볼륨] 영역에서 볼륨 구성을 검사합니다. 볼륨 구성은 인스턴스가 [중지됨] 상태일 때만 변경할 수 있습니다. 모든 볼륨의 탑재 지점과 이름이 지정되어 있어야 합니다. 인스턴스를 재시작하기 전에 AWS OpsWorks Stacks의 구성에 올바른 마운트 지점을 제공했는지 확인하십시오.

재부팅 후 EBS 볼륨이 다시 연결되지 않습니다

문제: 콘솔을 사용하여 Amazon EBS 볼륨을 인스턴스에 연결했지만 인스턴스를 재부팅할 때 볼륨이 더 이상 연결되지 않습니다.

원인: AWS OpsWorks 스택은 인식되는 Amazon EBS 볼륨만 다시 연결할 수 있으며, 이러한 볼륨은 다음으로 제한됩니다.

해결 방법: Amazon EBS 볼륨은 AWS OpsWorks 스택 콘솔, API 또는 CLI를 사용해서만 관리하십시오. 스택에 계정의 Amazon EBS 볼륨 중 하나를 사용하려면 스택의 리소스 페이지를 사용하여 볼륨을 등록하고 인스턴스에 연결하세요. 자세한 정보는 리소스 관리을 참조하세요.

AWS OpsWorks Stacks 보안 그룹을 삭제할 수 없습니다

문제: 스택을 삭제하고 나면 삭제할 수 없는 AWS OpsWorks Stacks 보안 그룹이 많이 남아 있습니다.

원인: 보안 그룹은 특정 순서로 삭제해야 합니다.

해결책: 먼저 보안 그룹을 사용 중인 인스턴스가 없어야 합니다. 그 후 다음의 보안 그룹(존재하는 경우)을 다음 순서로 삭제하세요.

스택 보안 그룹을 실수로 삭제했습니다. AWS OpsWorks

문제: AWS OpsWorks Stacks 보안 그룹 중 하나를 삭제했는데 다시 생성해야 합니다.

원인: 이러한 보안 그룹은 보통 우연히 삭제됩니다.

해결책: 다시 생성되는 그룹은 그룹 이름의 동일한 대문자를 포함하여 원본의 정확한 복제본이어야 합니다. 수동으로 그룹을 다시 생성하는 것보다는 AWS OpsWorks Stacks가 대신 이 작업을 수행하도록 하는 것이 좋습니다. 동일한 AWS 지역 및 VPC AWS OpsWorks (있는 경우) 에 새 스택을 생성하기만 하면 Stacks는 삭제한 그룹을 포함하여 모든 빌트인 보안 그룹을 자동으로 다시 생성합니다. 그런 다음 더 이상 사용할 일이 없으면 스택을 삭제할 수 있습니다. 보안 그룹은 그대로 남습니다.

Chef 로그가 갑자기 종료됩니다

문제: Chef 로그가 갑자기 종료됩니다. 로그의 끝에 성공적 실행이 표시되지 않거나 예외 및 스택 추적이 표시되지 않습니다.

원인: 이 동작의 원인은 일반적으로 메모리 부족입니다.

해결책: 더 큰 인스턴스를 생성해 에이전트 CLI run_command 명령을 사용하여 레시피를 다시 실행합니다. 자세한 정보는 레시피 실행을 참조하세요.

쿡북이 업데이트되지 않습니다

문제: 쿡북을 업데이트했으나 스택의 인스턴스가 계속해서 이전 레시피를 실행 중입니다.

원인: AWS OpsWorks Stacks는 쿡북을 각 인스턴스에서 캐시하고 리포지토리가 아닌 캐시에서 레시피를 실행합니다. 새 인스턴스를 시작하면 AWS OpsWorks Stacks는 저장소에서 인스턴스의 캐시로 쿡북을 다운로드합니다. 하지만 이후에 사용자 지정 쿡북을 수정하면 AWS OpsWorks Stacks는 온라인 인스턴스의 캐시를 자동으로 업데이트하지 않습니다.

해결 방법: Update Cookbooks stack 명령을 실행하여 온라인 인스턴스의 쿡북 캐시를 업데이트하도록 AWS OpsWorks 스택에 명시적으로 지시하십시오.

인스턴스가 부팅 상태에 멈춰 있습니다

문제: 인스턴스를 다시 시작하거나 자동 복구가 인스턴스를 자동으로 다시 시작할 때 시작 작업이 booting 상태에 멈춰 있습니다.

원인: 이 문제의 가능한 원인 한 가지는 기본 VPC를 포함한 VPC 구성입니다. 인스턴스는 항상 AWS OpsWorks Stacks 서비스, Amazon S3, 패키지, 쿡북, 앱 리포지토리와 통신할 수 있어야 합니다. 예를 들어 기본 VPC에서 기본 게이트웨이를 제거하면 인스턴스와 AWS OpsWorks Stacks 서비스 연결이 끊깁니다. AWS OpsWorks Stacks는 더 이상 인스턴스 에이전트와 통신할 수 없으므로 인스턴스를 장애가 발생한 것으로 간주하고 자동으로 복구합니다. 하지만 연결이 없으면 AWS OpsWorks Stacks는 복구된 인스턴스에 인스턴스 에이전트를 설치할 수 없습니다. 에이전트가 없으면 AWS OpsWorks Stacks는 인스턴스에서 설치 레시피를 실행할 수 없으므로 시작 작업이 “부팅 중” 상태 이상으로 진행될 수 없습니다.

해결책: 인스턴스가 필요한 연결을 갖추도록 VPC 구성을 수정합니다.

인스턴스가 예기치 않게 다시 시작됩니다

문제: 정지한 인스턴스가 예기치 않게 다시 시작합니다.

원인 1: 인스턴스에 대해 자동 복구를 활성화한 경우, AWS OpsWorks Stacks는 연결된 Amazon EC2 인스턴스에서 주기적으로 상태 확인을 수행하고 비정상 상태인 인스턴스를 다시 시작합니다. Amazon EC2 콘솔, API 또는 CLI를 사용하여 AWS OpsWorks 스택 관리형 인스턴스를 중지하거나 종료하는 경우 스택에 알림이 전송되지 않습니다. AWS OpsWorks 그 대신 정지된 인스턴스를 비정상으로 인식하고 자동으로 해당 인스턴스를 다시 시작합니다.

해결 방법: AWS OpsWorks Stacks 콘솔, API 또는 CLI만을 사용하여 인스턴스를 관리합니다. AWS OpsWorks 스택을 사용하여 인스턴스를 중지하거나 삭제하면 다시 시작되지 않습니다. 자세한 내용은 수동으로 24/7 인스턴스 시작, 중지 및 재부팅 및 AWS OpsWorks 스택 인스턴스 삭제 섹션을 참조하세요.

원인 2: 인스턴스는 다양한 이유로 실패할 수 있습니다. 자동 복구를 활성화한 경우 AWS OpsWorks Stacks는 장애가 발생한 인스턴스를 자동으로 다시 시작합니다.

해결 방법: 이는 정상적인 작동이므로 AWS OpsWorks Stacks에서 장애가 발생한 인스턴스를 다시 시작하지 않도록 하려면 아무 것도 할 필요가 없습니다. 이 경우, 자동 복구를 비활성화해야 합니다.

opsworks-agent 프로세스가 인스턴스에서 실행 중입니다

문제: 몇몇 opsworks-agent 프로세스가 인스턴스에서 실행 중입니다. 예:

aws 24543 0.0 1.3 172360 53332 ? S Feb24 0:29 opsworks-agent: master 24543
aws 24545 0.1 2.0 208932 79224 ? S Feb24 22:02 opsworks-agent: keep_alive of master 24543
aws 24557 0.0 2.0 209012 79412 ? S Feb24 8:04 opsworks-agent: statistics of master 24543
aws 24559 0.0 2.2 216604 86992 ? S Feb24 4:14 opsworks-agent: process_command of master 24

원인: 이들은 에이전트의 정상 작동에 필요한 올바른 프로세스입니다. 이들은 배포를 처리하고 서비스에 연결 유지 메시지를 다시 전송하는 등의 작업을 수행합니다.

해결책: 이것은 정상적 동작입니다. 이 프로세스들을 중지하지 마십시오. 중지할 경우, 에이전트 작동이 손상될 수 있습니다.

예기치 않은 execute_recipes 명령

문제: 인스턴스 세부 정보 페이지의 [로그] 섹션에 예기치 않은 execute_recipes 명령이 포함되어 있습니다. 예기치 않은 execute_recipes 명령은 [스택] 및 [배포] 페이지에도 표시될 수 있습니다.

원인: 이 문제는 흔히 권한 변경으로 인해 발생합니다. 사용자 또는 그룹의 SSH 또는 sudo 권한을 변경하면 스택이 execute_recipes 실행되어 스택의 인스턴스를 업데이트하고 Configure 이벤트도 트리거합니다. AWS OpsWorks execute_recipes 명령의 또 다른 출처는 인스턴스 에이전트를 업데이트하는 AWS OpsWorks Stacks입니다.

해결책: 이것은 정상 작동이며 아무 조치도 취할 필요가 없습니다.

execute_recipes 명령이 어떤 작업을 수행했는지 보려면 [배포] 페이지로 가서 명령의 타임스탬프를 클릭하세요. 그러면 실행된 주요 레시피가 나열된 명령의 세부 정보 페이지가 열립니다. 예를 들어 다음 세부 정보 페이지는 ssh_users를 실행하여 SSH 권한을 업데이트한 execute_recipes 명령의 세부 정보 페이지입니다.

모든 세부 정보를 보려면 명령의 로그 열에서 표시를 클릭하여 관련 Chef 로그를 표시하세요. 로그를 검색하십시오. Run List AWS OpsWorks 스택 유지 관리 레시피는 아래에서 OpsWorks Custom Run List 확인할 수 있습니다. 예를 들어 다음은 이전 스크린샷에 나온 execute_recipes 명령의 실행 목록으로서 명령에 연결된 모든 레시피를 보여 줍니다.

[2014-02-21T17:16:30+00:00] INFO: OpsWorks Custom Run List: ["opsworks_stack_state_sync",
  "ssh_users", "test_suite", "opsworks_cleanup"]