인프라 드리프트란 무엇입니까?

저는 대부분의 경력을 애플리케이션/웹 개발자로 보냈기 때문에 주로 제가 좋아하는 일을 하기 위해 X와 Y를 연결했습니다! 그리고 DevOps를 통한 운영에 대한 노출은 애플리케이션 개발자의 렌즈를 통해 이루어졌습니다.

저는 최근에 SQL로 구동되는 오픈 소스 클라우드 자산 인벤토리인 CloudQuery에 가입했습니다. 이것이 의미하는 바는 이전보다 인프라에 대해 더 많이 배우고 있다는 것입니다. 이를 통해 Terraform을 통해 코드형 인프라와 인프라 드리프트의 개념에 대해 배우고 있습니다.

드리프트란?

간단히 말해 인프라 상태가 IaC(Infrastructure-as-Code)에서 설정한 상태와 다른 경우입니다. 예를 들어 기본 128MB의 메모리로 terraform을 통해 5개의 람다를 배포했지만 현재 그 중 3개가 256MB를 사용하고 있는 경우 상태에 드리프트가 있습니다.

드리프트의 원인은 무엇입니까?

내 독서를 통해 두 종류의 드리프트가 있을 수 있다고 믿게 되었습니다. 첫 번째는 IaC에서 관리하는 리소스이고 두 번째는 IaC에서 관리하지 않는 리소스입니다. 첫 번째는 모든 리소스가 Terraform 또는 CloudFormation과 같은 IaC에 의해 배포된 경우이고, 두 번째는 수동으로 또는 IaC를 사용하지 않는 다른 프로세스를 통해 리소스가 배포된 경우입니다. 드리프트를 일으키는 원인은 누군가 또는 개별 리소스를 수동으로 추가하거나 변경하는 두 경우 모두 동일합니다.

드리프트가 나쁜가요?

반드시 그런 것은 아니지만 프로덕션에서 일이 발생하므로 앱이 실행 중일 때 상황을 조정하고 유지해야 합니다. 때로는 감독이 필요한 보안 도구 등과 같이 IaC 외부의 리소스가 필요합니다.

그러나 표류했는지 어떻게 알 수 있습니까?

그리고 이것이 제가 오픈 소스 클라우드 자산 인벤토리 위에 구축된 이 토끼 구멍CloudQuery now has drift detection을 찾은 이유입니다. 다른 도구 또는 Terraform itself을 통해 드리프트를 감지할 수 있지만 이는 Terraform으로 관리되는 리소스에 대해서만 작동합니다. 그러나 CloudQuery를 사용하면 Terraform 상태의 드리프트뿐만 아니라 쉽게 식별할 수 있는 목록으로 관리되지 않는 Cloud 공급업체 계정 내의 리소스도 볼 수 있습니다.

드리프트를 어떻게 해결합니까?

cloudquery drift scan에 대한 documentation으로 이동하면 다음과 같은 예제 결과를 볼 수 있습니다.

=== DRIFT RESULTS  ===
5 Resources not managed by Terraform
aws:ec2.ebs_volumes:
- vol-id1
- vol-id2
aws:ec2.instances:
- i-id1
- i-id2
aws:ec2.security_groups:
- sg-id1
93 Resources managed by Terraform (equal IDs)
=== SUMMARY ===
Total number of resources: 98
- 5 not managed by Terraform
- 93 managed by Terraform (equal IDs)
- 94.89% covered by Terraform

Terraform에서 관리하지 않는 리소스와 Terraform 상태에서 이동한 리소스를 볼 수 있습니다. 이 시점에서 이제 Terraform에서 관리하지 않는 리소스를 결정하거나 Terraform 설명서의 Manage Resource Drift 가이드에 따라 관리를 시작하고 Terraform을 프로덕션에 일치시킬 수 있습니다. 그리고 약간의 추가 자동화를 통해 삶을 더 단순하게 만들기 위해 CloudQuery as part of your CI을 실행하여 배포 전후에 모든 것이 올바른 상태인지 확인할 수 있습니다.