Terraform & Ansible 관계

안녕하세요!
하씨가문의 영광입니다!
이전 세션까지 Terraform과 Ansible에 대해 알아봤어요!
이번 세션에서는 Terraform과 Ansible의 차이점에 대해 알아보고자 해요!

---

들어가기전에..
앞서 다뤄봤듯이 Terraform과 Ansible 모두 DevOps 도구이지만
Terraform은 오픈소스로, Infrastructure as Code 플랫폼인
반면, Ansible은 해당 인프라 구성에 중점을 둔 오픈 소스 구성 관리 도구입니다.

1. 유사점

• Terraform과 Ansible은 유사한 도구입니다.
• 둘 다 새로운 클라우드 인프라를 프로비저닝하고 필요한 애플리케이션 구성 요소를 동일하게 구성할 수 있습니다.
• 또한, 새로 생성된 가상 머신에서 원격 명령을 실행할 수 있습니다.
  • 즉, 두 도구 모두 에이전트가 없습니다.
  • 운영 목적으로 머신에 에이전트를 배포할 필요가 없다는 것 입니다.

Terraform	Ansible
클라우드 클라우드 공급자 API를 사용하여 인프라를 만들고 기본 구성 작업은 SSH를 사용하여 수행합니다.	Ansible도 마찬가지로 SSH를 사용하여 필요한 모든 구성 작업을 수행합니다.
두 가지 모두 "상태" 정보를 관리하기 위해 별도의 인프라 세트가 필요하지 않으므로 두 도구 모두 Masterless(주인을 두지 않는) 입니다.

---

2. 차이점

이전 섹션에서는 두 도구에 대한 유사점을 살펴봤다면, 지금부터는 차이점에 대해 알아보도록 하겠습니다.

• Terrform과 Ansible은 장점과 단점을 모두 관리하는 방법을 지니고 있습니다.
• 따라서 완벽하고 섬세하게 조합하기 위해서 두 도구의 세부 사항을 먼저 조사하는 것이 중요합니다.

1) 오케스트레이션 vs 구성 관리

• 오케스트레이션/프로비저닝은 가상 머신, 네트워크 구성 요소, 데이터베이스 등의 인프라를 만드는 프로세스입니다.
• 반면에 구성 관리는 버전이 지정된 소프트웨어 구성 요소 설치, OS 구성 작업, 네트워크 및 방화벽 구성을 자동화하는 프로세스입니다.
• Terraform을 사용하여 구성 관리를 구현하고 Ansible를 사용하여 인프라 자동화를 구현하는 경우에는 한계가 있습니다. 복잡한 인프라 관리와 관련하여 유연성이 충분하지 않는 문제가 있습니다.

Terraform	Ansible
인프라 관리를 위한 포괄적인 솔루션을 제공합니다.	클라우드 인프라를 프로비저닝할 수도 있지만 충분히 포괄적이지 않습니다.
클라우드 제공자 API를 사용하여 선언된 리소스를 기반으로 인프라를 프로비저닝 및 디프로비저닝합니다.	주로 구성 관리에 맞춰져 있으며, 애플리케이션과 종속성을 최신 상태로 유지하는 프로세스입니다.

2) 선언적 vs 절차적

Terraform	Ansible
Iac(Infrastructure as Code)를 작성하는데 사용됩니다.	Ansible은 YAML 구문을 사용하여 대상 인프라에서 수행할 절차를 정의합니다.
선언적 형식인 HCL를 사용하고 코드가 작성된 순서는 중요하지 않습니다.	Ansible YAML 스크립트는 절차적 언어로 스크립트를 작성할 때 아래로 실행됩니다.
코드는 여러 파일에 분산될 수도 있습니다.	Ansible 스크립트를 "Ansible Playbook"이라고 합니다.
코드를 어떻게 작성하든 Terraform은 종속성을 식별하고 인프라를 프로비저닝합니다.	특정 일련의 작업을 수행해야 하는 경우 플레이북에서 동일한 작업을 정의하고, 작업은 작성된 순서대로 수행됩니다.
Terraform에서는 기존 인프라를 작성하거나 코드로 쉽게 변환할 수 있습니다.	예를 들어, 루트 사용자로 지정된 가상 머신에 Apache 서버를 설치하려면 설치 작업을 정의하기 전에 사용자 생성 단계를 작성해야 합니다.

3) 변경 가능 vs 불변

• 인프라를 재부팅하거나 교체하지 않고 구성을 변경할 수 있는 경우, 구성 변경이 가능합니다.
• 하지만 그렇지 않은 경우, 구성을 변경할 수 없습니다.

Terraform	Ansible
원하는 인프라 상태를 입력으로 가져와 프로비저닝합니다.	기본적으로 변경할 수 없습니다.
변경 사항이 도입되면 Terraform은 변경 사항 자체의 특성에 따라 실행됩니다.	최신 버전의 플레이북에 따라 구성 변경 사항을 일관되게 유지하려고 관리합니다.
클라우드 공급자가 인프라를 재부팅하거나 교체하지 않고 변경 사항을 구현할 수 없는 경우 Terraform은 인프라를 변경합니다.	변경 사항은 기본 인프라의 "교체"에 영향을 주지않으며 지정된 구성 요소의 구성만 복구하거나 수정할 수 있습니다.
이전 인프라 구성요소를 제거하고 최신 구성 설정이 있는 새 구성 요소로 교체합니다. 예를 들어, AWS EC2 인스턴스에서 인스턴스 유형을 변경해도 리소스가 교체되지는 않지만 AMI(이미지)를 변경하면 리소스가 교체됩니다.	시간이 지날수록 Ansible에서 관리하는 서버는 수행한 구성의 변경 사항을 기록합니다. 이로 인해 제대로 관리되지 않으면 다른 서버가 다른 구성을 가질 수 있습니다.(드리프트)

4) 상태 관리

Terraform	Ansible
관리 중인 리소스의 전체 수명 주기를 관리합니다.	수명 주기 관리를 지원하지 않습니다.
상태 파일의 현재 구성과 인프라 리소스의 매핑을 유지 관리합니다.
상태 관리는 Terraform에서 매우 중요한 역할을 합니다.	주로 구성 관리를 다루며 기본적으로 변경할 수 없는 인프라를 고려하기 때문에 구성에 도입된 모든 변경 사항은 대상 리소스에서 자동으로 실행됩니다.
상태는 구성 변경 사항을 추적하고 동일하게 프로비저닝하는 데 사용되고 상태 파일의 실제 인프라를 가져와 Terraform 관리 하에 있는 기존 리소스를 가져올 수도 있습니다.

---

3. Terraform과 Ansible 중 어느 것을 선택해야 할까?

Terraform	Ansible
우수한 스케줄링 기능과 함께 제공되며 매우 사용자에게 쾌적한 환경을 제공합니다.	보다 안전한 보안과 ACL 기능과 함께 제공됩니다.
Docker가 Terraform 보다 구성 관리를 더 잘 처리하므로 Docker와 잘 통합됩니다.	전통적인 자동화 프레임워크와 함께 편안하게 조정되기 때문에 성숙한 도구입니다.
그러나 대상 장치가 어떻게 최종 상태가 되었는 지에 대한 명확한 증거가 없습니다.	반면에 논리적 종속성, 오케스트레이션 서비스 및 상호 연결된 응용 프로그램과 같은 서비스에는 좋지 않습니다.

---

이상으로 Terraform과 Ansible에 대해 알아보았습니다!

읽어주셔서 감사합니다:)