IaC 도구 이해: Cloudformation 대 ​​Terraform

AWS CloudFormation 및 Terraform – 무엇을 선택해야 할지 모르십니까? 이 기사는 현명한 결정을 내리는 데 도움이 될 것입니다.

클라우드 컴퓨팅은 DevOps의 세계를 혁신했습니다. 더 이상 단순한 유행어가 아닙니다. 우리가 애플리케이션을 개발하고 유지 관리하는 방식을 변경하기 위해 여기에 있습니다. 모든 규모의 비즈니스에 클라우드 컴퓨팅을 사용해야 하는 수많은 이유가 있지만 약간의 제한이 있지만 인프라를 수동으로 프로비저닝해야 합니다.

클라우드 공급자의 콘솔로 이동하여 원하는 것을 정확히 말해야 합니다. 이것은 소규모 사용 사례에서 잘 작동하지만 콘솔에서 구성을 변경하는 다른 사람들이 있는 경우에는 어떻게 될까요? 유지 관리가 점점 더 어려워지는 매우 복잡한 인프라로 끝날 수 있습니다. 클라우드 인프라에 대한 변경 사항을 추적하거나 협업할 효율적인 방법이 없습니다. 음, 실제로 있습니다. 코드로서의 인프라.

코드로서의 인프라는 클라우드 컴퓨팅에서 매우 인기 있는 용어입니다. 코드를 사용하여 IT 인프라를 관리하는 프로세스입니다. 그래 맞아. 콘솔로 가서 모든 것을 수동으로 하는 대신; 코드로서의 인프라(IAAC 또는 IAC라고도 함)를 사용하면 구성 파일을 작성한 다음 클라우드 인프라를 프로비저닝할 수 있습니다. IAC는 일관성, 쉽고 빠른 유지 관리, 인적 오류의 여지가 없는 등의 이점을 제공합니다.

Amazon Web Services와 함께 IAC 사용

AWS는 세계 최고의 클라우드 컴퓨팅 서비스로, 다음 클라우드 제공업체보다 두 배의 시장 점유율을 차지하고 있습니다. AWS에는 수백 수천 개의 사용 사례를 수용할 수 있는 200개 이상의 서비스가 있습니다.

AWS에서 IAC를 사용하기 시작하면 AWS CloudFormation과 오픈 소스 도구인 Terraform으로 선택 범위를 좁힐 수 있습니다. 둘 중 하나를 선택하려고 할 때 두 도구가 제공하는 다양한 기능을 이해하는 것이 상당히 어려울 수 있습니다. 이 기사에서는 AWS CloudFormation과 Terraform의 차이점을 살펴보고 귀하의 요구 사항에 더 적합한 도구를 결정하는 데 도움이 될 것입니다.

Terraform 대 AWS CloudFormation: 차이점

모듈화

대규모 조직에서 IAC를 사용할 때 모듈성은 올바른 도구를 선택하는 데 중요한 요소가 될 수 있습니다.

클라우드포메이션

CloudFormation에는 모듈에 대한 기본 지원이 없습니다. 중첩 스택 이라는 것을 모듈로 사용할 수 있습니다.

예를 들어 조직에서 S3 버킷을 프로비저닝하려는 방법에 대한 표준 구성을 가질 수 있습니다. 따라서 S3 버킷을 생성하는 표준 CloudFormation 템플릿을 생성합니다. 이제 최종 사용자가 S3 버킷을 생성하고자 할 때 이 CloudFormation 템플릿을 중첩 스택으로 사용하고 표준 S3 버킷을 생성할 수 있습니다.

AWS CloudFormation의 모듈화에 도움을 줄 수 있는 AWS 서비스 카탈로그인 덜 알려진 AWS 서비스도 있습니다. 서비스 카탈로그는 규정 준수, 보안, 비용 또는 성능 요구 사항을 충족하기 위해 AWS 서비스의 범위를 제한하려는 조직을 위해 특별히 설계된 AWS 서비스입니다. 그리고 무엇을 추측? AWS Service Catalog는 백엔드에서 CloudFormation 템플릿을 사용합니다.

예를 들어 이것을 빠르게 이해합시다. S3 버킷을 제대로 사용하지 않으면 곧 기밀 데이터에 치명적일 수 있습니다. 동일한 예를 들어보겠습니다. 조직에서 S3를 사용하려는 표준 방법을 원합니다. 첫 번째 옵션은 다른 CloudFormation 스택 내에서 사용할 수 있고 동등하게 좋은 중첩 스택 템플릿을 만드는 것입니다.

사용자가 이 표준 템플릿을 중첩 스택으로 사용하지 않도록 하려면 AWS Service Catalog를 사용할 수 있습니다. 서비스 카탈로그를 통해 사용자는 콘솔 UI에서 이 표준 템플릿을 사용하고 약간의 사용자 정의를 위해 일부 매개변수를 지정할 수 있습니다. 이를 통해 AWS 계정에서 인프라가 프로비저닝되는 방식을 제어하고 원치 않는 시나리오를 방지할 수 있습니다.

테라폼

Terraform은 모듈을 기본적으로 지원합니다. 이를 통해 AWS CloudFormation과 매우 유사한 표준 구성을 생성하고 다른 Terraform 구성에서 사용할 수 있습니다.

Terraform은 오픈 소스 도구이므로 Terraform 레지스트리에서 미리 만들어진 일부 오픈 소스 모듈을 찾아 사용할 수도 있습니다. 또한 고유한 구성으로 고유한 모듈을 만들고 개인 모듈 레지스트리에서 호스트할 수 있습니다.

개인적으로 모듈화가 큰 요구 사항이라면 CloudFormation보다 Terraform을 사용하는 것을 선호합니다.

CloudFormation에서 중첩 스택을 사용하는 것은 Terraform에서 모듈을 사용하는 것만큼 쉽지 않습니다. 주요 요인은 CFN 템플릿에서 중첩 스택으로 데이터를 전달하는 것이 상당히 복잡할 수 있다는 것입니다.

CloudFormation 템플릿을 공유할 수 있는 표준 장소는 없습니다. AWS 서비스 카탈로그가 있지만 이는 콘솔을 통해 인프라를 생성하기 위한 몇 가지 규칙을 시행하는 방법일 뿐입니다. 우리는 모두 코드에 관한 것입니다. 서비스 카탈로그를 사용할 때 일부 복잡한 작업은 CloudFormation 파일로 캡슐화되지만 여전히 콘솔로 이동하고 인프라를 만들기 위해 매개변수를 지정하는 수동 작업을 거쳐야 합니다.

반면 Terraform은 모듈을 생성, 유지, 공유하는 방법이 정해져 있습니다. Terraform Module Registry에서 모듈의 정확한 요구 사항을 확인하고 Terraform 파일에서 매우 쉽게 사용할 수 있습니다.

인프라에 대한 제어 및 거버넌스

사람들이 AWS 계정에서 생성할 수 있는 리소스를 제한하려는 경우: AWS CloudFormation과 Terraform 모두 그렇게 할 수 있는 수단을 제공합니다.

먼저 CloudFormation에 대해 이야기하겠습니다. CloudFormation 자체는 템플릿 사용 방식에 대한 제어를 제공하지 않지만 AWS IAM 정책을 사용하여 AWS 계정의 사용자가 리소스 생성을 위해 표준 CloudFormation 템플릿만 사용하도록 허용할 수 있습니다. S3 버킷 예제에서는 사용자에 대한 모든 "S3 생성" 권한을 제한하고 사용자가 AWS 서비스 카탈로그 또는 중첩 스택에서 S3 버킷을 생성하도록 허용할 수 있습니다.

Terraform을 사용하면 정책을 코드 도구 Sentinel로 사용하여 사용자가 생성할 수 있는 리소스를 제어할 수 있습니다. Sentinel을 사용하면 Terraform을 통해 사용자 작업을 허용하거나 거부하는 세분화된 논리 기반 정책을 시행할 수 있습니다. 예를 들어 S3 버킷을 생성하는 모든 리소스를 거부하고 사용자가 표준 모듈에서 S3 버킷을 생성하도록 허용할 수 있습니다.

상태 관리

AWS CloudFormation과 Terraform은 모두 유지 관리 중인 리소스를 추적해야 합니다.

Terraform 은 인프라 상태를 상태 파일에 저장합니다. 이 파일은 기본적으로 로컬에 저장되지만 S3와 같은 원격 백엔드에 저장하고 여러 사용자가 동일한 인프라 세트를 변경하도록 할 수 있습니다.

CloudFormation 은 적어도 우리가 볼 수 있는 상태 파일을 유지 관리하지 않습니다. CloudFormation은 관리형 서비스이므로 백그라운드에서 모든 상태 유지 관리 및 확인을 수행합니다.

AWS CloudFormation과 Terraform에는 인프라에 어떤 변경 사항이 적용되는지 확인할 수 있는 수단이 있습니다. Terraform에서 "terraform plan"이라는 명령과 Terraform이 구성 변경 사항을 적용할 계획을 실행할 수 있습니다. CloudFormation 사용자는 변경 세트를 통해 이 정보를 볼 수 있습니다.

언어

Terraform은 HashiCorp에서 만든 언어인 HashiCorp 구성 언어 HCL을 사용합니다. 추가 내장 기능이 있는 JSON과 매우 유사합니다.

CloudFormation 템플릿은 YAML 또는 JSON 형식으로 작성됩니다.

로깅 및 롤백

AWS CloudFormation과 Terraform은 모두 우수한 로깅 기능을 가지고 있습니다. 내 경험상 오류와 문제는 간단했습니다(대부분).

CloudFormation: 기본적으로 CloudFormation은 스택 변경이 실패한 경우 모든 변경 사항을 롤백합니다. 이것은 좋은 기능이며 디버깅 목적으로 비활성화할 수 있습니다.

Terraform: Terraform은 실패할 경우 변경 사항을 자동으로 롤백하지 않습니다. 언제든지 terraform destroy 명령을 실행하여 절반 프로비저닝된 구성을 삭제하고 Terraform 실행을 다시 시작할 수 있으므로 이것은 문제가 아닙니다.

범위

Terraform은 AWS 클라우드에 국한되지 않습니다. Terraform과 CloudFormation 중에서 선택할 때 가장 중요한 요소는 Terraform이 다른 클라우드 공급자 및 서비스를 지원한다는 것입니다.

따라서 여러 클라우드 플랫폼에 IAC를 사용할 계획이라면 Terraform이 최선의 선택입니다. CloudFormation은 강력한 도구이지만 AWS에만 국한됩니다. Terraform을 사용하면 인프라를 설정하고 여러 클라우드 플랫폼에 애플리케이션을 배포할 수 있으므로 애플리케이션의 가용성과 견고성을 높일 수 있습니다.

기능 지원

일반적으로 AWS가 새로운 서비스와 기능을 출시함에 따라 CloudFormation은 AWS 서비스이기 때문에 Terraform보다 먼저 업데이트됩니다. 현재 두 도구 모두 이러한 서비스의 대부분의 서비스와 기능을 다룹니다. 이것은 Terraform 사용의 약간의 단점이 될 수 있지만 솔루션이 있습니다.

Terraform 코드 내에서 CloudFormation 스택을 생성할 수도 있습니다. 따라서 Terraform을 사용하고 기능이 없는 경우 Terraform 코드 내에서 임시로 CloudFormation 스택을 설정할 수 있습니다.

기술적 지원

유료 AWS 기술 지원 플랜에는 CloudFormation 지원도 포함됩니다.

HashiCorp는 Terraform에 대한 기술 지원 계획도 지불했습니다.

결론

AWS CloudFormation과 Terraform은 모두 강력하고 완전히 개발된 도구입니다. 위의 차이점은 요구 사항에 따라 도구를 선택하기 위해 정보에 입각한 결정을 내리는 데 도움이 됩니다. 개인적인 제안으로 향후 여러 클라우드 플랫폼을 사용할 계획이거나 현재 여러 클라우드를 사용 중인 경우 Terraform을 모든 요구 사항에 대한 원스톱 상점으로 사용해야 합니다. AWS 전용 IAC 도구를 찾고 있다면 AWS CloudFormation과 Terraform 모두 공정한 게임입니다.

Terraform 학습에 관심이 있는 경우 이 온라인 과정을 확인하십시오.