CloudFormation은 같은 같은 AWS 리소스 스택의 프로그램 만들 수있는 강력한 AWS를 제공하고 애플리케이션의 웹 티어, 고성능 컴퓨팅 클러스터, 또는 , 전체 애플리케이션 스택을 하나의 API 호출로. 엄청나게 강력합니다. 특히 Chef, Puppet 또는 cloud-init 와 함께 사용할 때이를 사용하는 것은 좋은 AWS 관행으로 간주됩니다 . 그것을 디버깅하면 저를 악으로 만듭니다.
프로덕션 예를 들어 보겠습니다. 재고 mongodb 클러스터 템플릿 이 저에게 적합하지 않습니다. 나는 특별히 이유를 모릅니다. 거의 항상 그렇듯이 간단한 일이라고 확신합니다. 내 문제는 무엇이 잘못되었는지 알아낼 수 없다는 것이 아닙니다. 스택이 실패하는 데는 20 분에서 30 분 사이가 걸리고, 리소스를 전혀 삭제한다고 가정하면 삭제하는 데 3-4 분이 더 걸립니다.
내가 무엇을 놓치고 있습니까? 나는 --disable-rollback깃발 에 대해 알고 그것을 산소처럼 사용합니다. 나는 오래 전에 출구 메시지를 감싸고 cfn-signal가라 앉는 배에서 밸러스트처럼 던지는 법을 배웠습니다 . 템플릿 디버깅 프로세스를 더 빠르게 만들 수있는 방법은 무엇입니까? 아니면 실수를 저지른 지 30 분 후에 영원히 눈치 채지 못합니까?
답변
aws cloudformation validate-templateAWS CLI 도구에서 명령을 사용합니다 . 템플릿이 유효한 JSON인지 YAML인지 여부 만 확인하고 키와 값이 올바른지 여부 만 확인합니다 (예 : 키의 오타를 확인하지 않음).
답변
1 년 후 또 다른 옵션은 이러한 템플릿을 대류권 과 같은 타사 라이브러리로 추상화하는 것 입니다. 이 라이브러리는 JSON 페이로드를 생성하고 그 과정에서 많은 유효성 검사를 수행합니다. 이것은 또한 “천행 JSON 파일을 관리하는 것은 정말 슬픈 일입니다” 문제도 해결합니다.
답변
템플릿 디버깅 프로세스를 더 빠르게 만들 수있는 방법은 무엇입니까? 아니면 실수를 저지른 지 30 분 후에 영원히 눈치 채지 못합니까?
다음은 복잡한 CloudFormation 템플릿 개발의 반복 속도 향상에 특히 초점을 맞춘 몇 가지 모범 사례 제안입니다.
CloudFormation 도구를 사용하여 템플릿 및 스택 업데이트 유효성 검사
AWS는 이미 자체 모범 사례 문서 에 이러한 내용을 설명 했으므로 반복하지 않겠습니다.
이 단계의 요점은 실제로 스택 생성 / 업데이트를 수행하기 전에 명백한 구문 또는 논리적 오류를 포착하는 것입니다.
격리 된 테스트 리소스
복잡한 스택에서 개별 CloudFormation 리소스를 사용하기 전에 더 작은 독립 실행 형 스택에서 동작을 테스트하여 사용 제한 및 일반적인 시작 / 해체 시간을 포함하여 해당 리소스의 생성 / 업데이트 / 삭제 동작의 전체 범위를 철저히 이해해야합니다. 먼저.
- 타사 사용자 지정 리소스를 개발하거나 사용하는 경우 언어 플랫폼에 적합한 라이브러리를 사용하여 단위 테스트를 작성하여 응용 프로그램 논리가 모든 사용 사례에서 예상대로 작동하는지 확인합니다.
- 개별 리소스가 생성 / 업데이트 / 삭제하는 데 걸리는 시간은 기본 API 호출의 동작에 따라 리소스 유형마다 크게 다를 수 있습니다. 예를 들어 복잡한
AWS::CloudFront::Distribution리소스는 생성 / 업데이트 / 삭제하는 데 30 ~ 60 분이 걸리는 반면AWS::EC2::SecurityGroup업데이트는 몇 초 만에 완료 될 수 있습니다. - 개별 리소스는 구현에 버그 / 문제 / 제한 사항이있을 수 있으며, 이는 훨씬 더 큰 스택 내에서가 아니라 격리 테스트 할 때 해결 방법을 디버깅하고 개발하기가 훨씬 쉽습니다. 개별 AWS 계정 설정에 따른 AWS 서비스 제한 또는 스택을 생성하는 리전에 따른 서비스의 리전 가용성 과 같은 제한을 염두에 두십시오 .
작은 단위로 복잡한 스택 구축
스택 생성 / 업데이트를 수행 할 때 단일 리소스에서 오류가 발생하면 스택이 전체 리소스 변경 세트를 롤백하게되며, 이로 인해 성공적으로 생성 된 다른 리소스가 불필요하게 파괴 될 수 있으며, 관련 리소스의 종속성 그래프.
이에 대한 해결책은 한 번에 하나 (또는 몇 개)의 리소스를 추가하여 더 작은 업데이트 배치로 스택을 점진적으로 빌드하는 것입니다. 이렇게하면 리소스 생성 / 업데이트에서 오류가 발생하는 경우 롤백으로 인해 전체 스택의 리소스가 파괴되지 않고 최신 업데이트에서 변경된 리소스 집합 만 발생합니다.
스택 업데이트 진행 상황 모니터링
생성 / 업데이트가 수행되는 동안 스택의 이벤트를 확인 하여 스택 업데이트의 진행 상황 을 모니터링 해야합니다 . 이것은 개별 리소스와 관련된 추가 문제를 디버깅하기위한 시작점이 될 것입니다.
답변
AWS Toolkit for Eclipse에 포함 된 AWS CloudFormation 템플릿 편집기를 보셨습니까 ? 구문 강조, 문 완성 및 AWS CloudFormation에 대한 배포가 있습니다.
답변
파티에 늦었지만 편집자를 구성하고 배우는 데 약간의 시간을 할애하는 것이 가치가 있다고 덧붙일 수도 있습니다. 대답으로 웃기게 기본적으로 들리지만 시도해보십시오.
제 경우에는 vim을 사용하여 json 구문 플러그인을 설치하고 큰 CF 파일을 쉽게 탐색 할 수있는 폴딩 기술을 (마지막으로) 이해 한 후 훨씬 더 잘 수행했습니다. Mine은 이제 오타를 제안하고 (사용해서는 안되는 쉼표 등) 색상 강조 표시를 통해 명확한 시각적 단서를 제공하는 데 많은 시간을 절약 할 수 있습니다.
이렇게하면 구문 오류를 완화하는 데 도움이 될 수 있지만 템플릿 내 논리 오류는 다른 도구로 더 잘 수정됩니다. 언젠가 CF에 “미리보기”모드가 있기를 바랍니다.
답변
JetBrains IDE (IntelliJ IDEA PhpStorm WebStorm PyCharm RubyMine AppCode CLion Gogland DataGrip Rider Android Studio) 의 경우 JSON 및 YAML CFN 템플릿의 심층 검사를 지원하는 AWS CloudFormation 플러그인이 있습니다.
답변
AWS CloudFormation의 린터가 추가 정적 분석 이상을 제공합니다aws cloudformation validate-template
특정 리전에서 사용할 수없는 리소스 유형 및 인스턴스 유형을 알려주고, 허용 된 값에 대한 속성 값의 유효성을 검사하고, 순환 리소스 종속성, 구문 오류, 템플릿 제한 등을 포착합니다.
CLI 외에도 linter를 실행하는 데 가장 많이 사용되는 메커니즘 중 하나는 모든 파일 저장에서 실행되는 Visual Studio Code 확장 과 같은 편집기 플러그인을 설치하는 것입니다.
사전 커밋 Git 후크 와 같은 다른 메커니즘 이 여기에 설명되어 있습니다.
