Pulumi를 사용하여 인프라를 코드로 테스트합니다. 2 부

안녕하세요 여러분. 오늘 우리는 기사의 마지막 부분을 여러분과 공유합니다. "Pulumi를 사용하여 코드형 인프라 테스트", 그 번역은 수강생을 위해 특별히 준비되었습니다. "DevOps 사례 및 도구".

배포 테스트

이러한 스타일의 테스트는 강력한 접근 방식이며 이를 통해 화이트박스 테스트를 수행하여 인프라 코드의 내부 작동을 테스트할 수 있습니다. 그러나 테스트할 수 있는 내용이 다소 제한됩니다. 테스트는 실제 배포 전 풀루미에서 수립한 인메모리 배포 계획을 기반으로 진행되므로 배포 자체를 테스트할 수는 없습니다. 이러한 경우를 위해 Pulumi에는 통합 테스트 프레임워크가 있습니다. 그리고 이 두 가지 접근 방식은 서로 잘 작동합니다!

Pulumi 통합 테스트 프레임워크는 Go로 작성되었으며, 이는 대부분의 내부 코드를 테스트하는 방법입니다. 이전에 논의된 단위 테스트 접근 방식은 화이트 박스 테스트에 가깝지만 통합 테스트는 블랙 박스입니다. (엄격한 내부 테스트를 위한 옵션도 있습니다.) 이 프레임워크는 완전한 Pulumi 프로그램을 가져와서 새 스택을 처음부터 배포하고 변형으로 업데이트하고 삭제하는 등 다양한 수명주기 작업을 수행하기 위해 만들어졌습니다. . 정기적으로(예: 밤에) 스트레스 테스트로 실행합니다.

(우리 우리는 그것을 위해 노력하고 있습니다, 유사한 통합 테스트 기능을 언어의 기본 SDK에서 사용할 수 있습니다. Pulumi 프로그램이 작성된 언어에 관계없이 Go 통합 테스트 프레임워크를 사용할 수 있습니다.

이 프레임워크를 사용하여 프로그램을 실행하면 다음을 확인할 수 있습니다.

• 프로젝트 코드가 구문적으로 정확하고 오류 없이 실행됩니다.
• 스택 및 비밀 구성 설정이 작동하고 올바르게 해석됩니다.
• 귀하의 프로젝트는 귀하가 선택한 클라우드 제공업체에 성공적으로 배포될 수 있습니다.
• 프로젝트를 초기 상태에서 다른 N개 상태로 성공적으로 업그레이드할 수 있습니다.
• 프로젝트가 성공적으로 폐기되고 클라우드 공급자에서 제거될 수 있습니다.

곧 살펴보겠지만 이 프레임워크를 사용하여 런타임 유효성 검사를 수행할 수도 있습니다.

간단한 통합 테스트

이것이 실제로 어떻게 작동하는지 확인하기 위해 저장소를 살펴보겠습니다. pulumi/examples, 우리 팀과 Pulumi 커뮤니티는 이를 사용하여 자체 풀 요청, 커밋 및 야간 빌드를 테스트합니다.

다음은 우리의 간단한 테스트입니다. S3 버킷 및 기타 객체를 제공하는 예:

example_test.go:

package test
 
import (
    "os"
    "path"
    "testing"
 
    "github.com/pulumi/pulumi/pkg/testing/integration"
)
 
func TestExamples(t *testing.T) {
    awsRegion := os.Getenv("AWS_REGION")
    if awsRegion == "" {
        awsRegion = "us-west-1"
    }
    cwd, _ := os.Getwd()
    integration.ProgramTest(t, &integration.ProgramTestOptions{
        Quick:       true,
        SkipRefresh: true,
        Dir:         path.Join(cwd, "..", "..", "aws-js-s3-folder"),
        Config: map[string]string{
            "aws:region": awsRegion,
        },
    })
}

이 테스트는 폴더의 스택을 생성, 수정, 삭제하는 기본 수명 주기를 거칩니다. aws-js-s3-folder. 테스트 통과를 보고하는 데 약 XNUMX분 정도 걸립니다.

$ go test .
PASS
ok      ... 43.993s

이러한 테스트의 동작을 사용자 정의할 수 있는 다양한 옵션이 있습니다. 전체 옵션 목록을 확인하세요. 구조에서 ProgramTestOptions. 예를 들어 Jaeger 엔드포인트를 구성하여 추적할 수 있습니다(Tracing), 테스트가 음성인 경우 테스트가 실패할 것으로 예상함을 나타냅니다(ExpectFailure), 순차적인 상태 전환을 위해 프로그램에 일련의 "편집"을 적용합니다(EditDirs) 그리고 훨씬 더. 이를 사용하여 애플리케이션 배포를 테스트하는 방법을 살펴보겠습니다.

리소스 속성 확인

위에서 논의한 통합은 우리 프로그램이 충돌하지 않고 "작동"하도록 보장합니다. 하지만 결과 스택의 속성을 확인하려면 어떻게 해야 할까요? 예를 들어 특정 유형의 리소스가 프로비저닝되었거나 프로비저닝되지 않았으며 특정 속성이 있습니다.

매개 변수 ExtraRuntimeValidation 에 ProgramTestOptions 이를 통해 Pulumi가 기록한 배포 후 상태를 확인하여 추가 확인을 할 수 있습니다. 여기에는 구성, 내보낸 출력 값, 모든 리소스와 해당 속성 값, 리소스 간의 모든 종속성을 포함하여 결과 스택 상태의 전체 스냅샷이 포함됩니다.

이에 대한 기본적인 예를 보려면 프로그램이 하나를 생성하는지 확인해 보겠습니다. S3 버킷:

  integration.ProgramTest(t, &integration.ProgramTestOptions{
        // as before...
        ExtraRuntimeValidation: func(t *testing.T, stack integration.RuntimeValidationStackInfo) {
            var foundBuckets int
            for _, res := range stack.Deployment.Resources {
                if res.Type == "aws:s3/bucket:Bucket" {
                    foundBuckets++
                }
            }
            assert.Equal(t, 1, foundBuckets, "Expected to find a single AWS S3 Bucket")
        },
    })

이제 go 테스트를 실행하면 일련의 수명 주기 테스트를 거칠 뿐만 아니라 스택을 성공적으로 배포한 후 결과 상태에 대한 추가 검사도 수행합니다.

런타임 테스트

지금까지 모든 테스트는 순전히 배포 동작과 Pulumi 리소스 모델에 관한 것이었습니다. 프로비저닝된 인프라가 실제로 작동하는지 확인하려면 어떻게 해야 합니까? 예를 들어, 가상 머신이 실행 중이고 S3 버킷에 우리가 기대하는 내용이 포함되어 있는 경우 등이 있습니다.

이 작업을 수행하는 방법을 이미 짐작했을 수도 있습니다. 옵션 ExtraRuntimeValidation 에 ProgramTestOptions - 이것은 좋은 기회입니다. 이 시점에서 프로그램 리소스의 전체 상태에 액세스하여 사용자 정의 Go 테스트를 실행합니다. 이 상태에는 가상 머신 IP 주소, URL, 그리고 결과 클라우드 애플리케이션 및 인프라와 실제로 상호 작용하는 데 필요한 모든 정보가 포함됩니다.

예를 들어 테스트 프로그램은 다음 속성을 내보냅니다. webEndpoint 버킷 호출됨 websiteUrl, 구성된 URL을 얻을 수 있는 전체 URL입니다. index document. 상태 파일을 자세히 조사하여 찾을 수는 있지만 bucket 해당 속성을 직접 읽지만 대부분의 경우 스택은 확인에 사용하기 편리한 다음과 같은 유용한 속성을 내보냅니다.

integration.ProgramTest(t, &integration.ProgramTestOptions{
            // as before ...
        ExtraRuntimeValidation: func(t *testing.T, stack integration.RuntimeValidationStackInfo) {
            url := "http://" + stack.Outputs["websiteUrl"].(string)
            resp, err := http.Get(url)
            if !assert.NoError(t, err) {
                return
            }
            if !assert.Equal(t, 200, resp.StatusCode) {
                return
            }
            defer resp.Body.Close()
            body, err := ioutil.ReadAll(resp.Body)
            if !assert.NoError(t, err) {
                return
            }
            assert.Contains(t, string(body), "Hello, Pulumi!")
        },
    })

이전 런타임 검사와 마찬가지로 이 검사는 스택을 올린 후 즉시 실행되며 모두 간단한 호출에 대한 응답입니다. go test. 이는 빙산의 일각에 불과합니다. 코드로 작성할 수 있는 모든 Go 테스트 기능을 사용할 수 있습니다.

지속적인 인프라 통합

많은 인프라 변경이 있을 때 코드 검토를 위해 제출하기 전에 랩탑에서 테스트를 실행할 수 있다는 점은 좋습니다. 그러나 우리와 많은 고객은 개발 수명 주기의 다양한 단계에서 인프라를 테스트합니다.

• 병합 전 테스트를 위한 모든 공개 풀 요청에서.
• 각 커밋에 대한 응답으로 병합이 올바르게 수행되었는지 다시 확인합니다.
• 추가 테스트를 위해 밤이나 매주 등 정기적으로 실시합니다.
• 일반적으로 장기간에 걸쳐 실행되고 테스트를 병렬로 실행하거나 동일한 프로그램을 여러 번 배포하는 성능 또는 스트레스 테스트의 일부입니다.

이들 각각에 대해 Pulumi는 귀하가 선호하는 지속적 통합 시스템과의 통합을 지원합니다. 지속적인 통합을 통해 인프라에 대해 애플리케이션 소프트웨어와 동일한 테스트 범위를 제공합니다.

Pulumi는 공통 CI 시스템을 지원합니다. 그 중 일부는 다음과 같습니다.

• AWS 코드 서비스
• 애저 데브옵스
• 서클CI
• GitHub 액션
• 깃랩 CI
• 구글 클라우드 빌드
• 트래비스

자세한 내용은 에 대한 설명서를 참조하세요. 연속 배달.

임시 환경

매우 강력한 기회는 승인 테스트 목적으로만 임시 환경을 배포할 수 있는 능력입니다. 개념 프로젝트 및 스택 Pulumi는 몇 가지 간단한 CLI 명령 또는 통합 테스트 프레임워크를 사용하여 완전히 격리되고 독립적인 환경을 쉽게 배포하고 해체하도록 설계되었습니다.

GitHub를 사용하는 경우 Pulumi는 다음을 제공합니다. GitHub 앱, CI 파이프라인 내에서 승인 테스트를 풀 요청에 연결하는 데 도움이 됩니다. GitHub 저장소에 애플리케이션을 설치하기만 하면 Pulumi가 인프라 미리보기, 업데이트 및 테스트 결과에 대한 정보를 CI 및 풀 요청에 추가합니다.

핵심 승인 테스트에 Pulumi를 사용하면 팀 생산성을 향상하고 변경 사항의 품질에 대한 확신을 주는 새로운 자동화 기능을 얻게 됩니다.

합계

이 기사에서 우리는 범용 프로그래밍 언어를 사용함으로써 애플리케이션 개발에 유용한 많은 소프트웨어 개발 기술을 사용할 수 있음을 확인했습니다. 여기에는 단위 테스트, 통합 테스트 및 광범위한 런타임 테스트를 수행하기 위해 함께 작동하는 방법이 포함됩니다. 테스트는 요청 시 또는 CI 시스템에서 쉽게 실행할 수 있습니다.

풀 루미 - 오픈 소스 소프트웨어, 무료로 사용 가능하며 선호하는 프로그래밍 언어 및 클라우드와 함께 작동 - 오늘 시도해 보세요!

→ 첫 번째 부분

출처 : habr.com