출처: https://www.redhat.com/en/blog/ansible-vs.-terraform-demystified
Ansible과 Terraform은 경쟁적인 토론에서 자주 비교되는 매우 강력하면서도 독특한 오픈소스 IT 도구입니다. 두 도구를 비교하는 글을 자주 보지만, 대부분의 경우 이러한 비교는 순전히 “사양서”를 기반으로 이루어집니다. 이러한 유형의 비교는 흥미롭지만, 제품을 대규모로 사용하는 방식이나 이진 “전부 아니면 전무” 방식으로 비교하는 것이 현실적인지는 고려하지 않습니다. Red Hat은 20년 이상 기업을 지원해 왔으며 대부분의 IT 관리자가 이 두 도구를 프로덕션 환경에서 어떻게 사용하는지 잘 알고 있습니다. 두 도구 모두 일반적으로 대부분의 작업을 수행 할 수 있지만 , 둘 중 하나를 선택해야 하는 것이 아니라 각 도구의 가장 큰 장점을 활용하는 경우가 많습니다.
스포일러: 두 도구는 함께 사용하면 더욱 효과적이며, 조화롭게 작동하여 개발자와 운영팀에게 더 나은 경험을 제공할 수 있습니다.
Ansible과 Terraform은 모두 방대한 사용자 기반을 가진 오픈소스 도구로, 고전적인 “hammer” 접근 방식 때문에 종종 열광적인 추종자를 형성합니다. 즉, 제가 사용하는 도구가 망치뿐이라면 모든 문제가 못처럼 되기 시작합니다. 결국 더 효과적인 다른 도구를 시도하기보다는 제가 아는 유일한 방법으로 새로운 문제를 해결하려고 하게 됩니다. 하나의 도구와 그 접근 방식, 철학만 이해하는 것은 결코 좋은 생각이 아닙니다. 다양한 도구와 플랫폼이 존재하는 이유와 성공적인 조직이 두 가지를 모두 사용하는 이유를 이해하도록 마음을 열어야 합니다. 이 블로그에서는 Ansible과 Terraform, 오픈소스 프로젝트 및 그 하위 엔터프라이즈 제품의 차이점과 유사점을 살펴보겠습니다. 제품과 프로젝트는 끊임없이 변화하고 발전하고 있으므로 이 블로그는 날짜와 관련성을 확인하기 위한 것임을 유념해 주십시오.
Terraform
Terraform은 HashiCorp가 후원하는 오픈 소스 프로젝트입니다. Terraform은 HashiCorp가 제품화한 여러 오픈 소스 프로젝트 중 하나이며, Vagrant, Packer, Consul, Vault 등이 있습니다. HashiCorp는 특히 프로젝트와 제품이 간단하고, 모듈화되어 있으며, 구성 가능해야 한다는 Tao of HashiCorp 라는 디자인 철학을 가지고 있습니다 . 각 프로젝트와 제품 쌍은 명확하게 정의된 범위를 가지며, 대규모 워크플로우의 경우 여러 프로젝트와 제품을 결합할 수 있습니다. HashiCorp는 Terraform을 다음과 같은 목적으로 정의합니다.
Terraform은 HashiCorp에서 제공하는 코드형 인프라(IaC)입니다. 안전하고 반복 가능한 방식으로 인프라를 구축, 변경 및 관리할 수 있는 도구입니다. 운영자와 인프라 팀은 Terraform을 사용하여 HashiCorp Configuration Language(HCL)라는 구성 언어로 환경을 관리하고, 사람이 읽을 수 있는 자동화된 배포를 구현할 수 있습니다.
Terraform은 주로 명령줄 기반이지만, 여러 인기 퍼블릭 클라우드와 긴밀하게 통합되어 있습니다. Terraform은 고정된 클라우드 인프라를 프로비저닝하고 나중에 해체하는 데 매우 유용합니다. HashiCorp은 고객에게 Terraform의 두 가지 제품화 방법을 제공합니다. Terraform Enterprise를 통해 맞춤형 배포를 직접 관리하거나, 자체 관리형 서비스인 Terraform Cloud를 사용할 수 있습니다. HashiCorp의 비즈니스 티어는 드리프트 감지, SSO 감사 로그, 셀프 호스팅 에이전트 및 맞춤형 동시성 기능을 제공합니다.
Ansible
Ansible은 IT 자동화 도구입니다. 시스템을 구성하고, 소프트웨어를 배포하고, 지속적인 배포나 무중단 롤링 업데이트와 같은 고급 IT 작업을 조율할 수 있습니다. 대부분의 사람들은 Ansible 플레이북을 실행하기 위한 명령줄 도구인 커뮤니티 Ansible에 익숙합니다. Terraform과 마찬가지로 Ansible은 단순성과 사용 편의성에 중점을 둡니다. Ansible은 Ansible 플레이북에 YAML 구문을 사용합니다 . YAML을 사용하는 이유는 XML이나 JSON과 같은 다른 일반적인 데이터 형식보다 사용자가 읽고 쓰기가 더 쉽기 때문입니다.
Red Hat Ansible Automation Platform은 고객에게 제공되는 제품입니다. Ansible을 기반으로 다양한 엔터프라이즈 기능을 제공하며, 12개 이상의 상위 프로젝트를 하나의 통합되고 간소화된 제품으로 결합했습니다. 각 제품 구성 요소는 HashiCorp의 설계 철학과 유사하게 명확하게 정의된 범위를 가진 특정 용도를 가지고 있습니다. 예를 들어, 자동화 컨트롤러는 상위 프로젝트인 AWX를 기반으로 하는 Ansible Automation용 웹 UI 및 API입니다. 이 구성 요소는 자동화 관리를 위해 플랫폼에 번들로 제공됩니다. Ansible Automation Platform은 온프레미스에서 실행 가능하며, 사용자 단위가 아닌 노드 단위로 요금이 부과됩니다. 또는 Microsoft Azure에서 제공되는 관리형 서비스를 사용할 수도 있습니다 .
요약하자면, Ansible과 Terraform 모두 오픈 소스 명령줄 전용 버전을 제공합니다. 두 제품 모두 웹 UI나 SSO와 같은 엔터프라이즈 기능을 갖춘 제품을 제공합니다. 커뮤니티 버전의 주요 차이점은 Ansible은 다목적 자동화 도구인 반면 Terraform은 코드 기반 인프라 도구라는 점입니다. 이러한 혼란은 Ansible과 Terraform 모두 서로를 호출하는 플러그인을 제공하기 때문에 발생합니다. 예를 들어, 많은 Ansible 전문가들은 Ansible 플레이북을 사용하여 AWS 리소스를 프로비저닝하기 때문에 다른 사람들이 완전히 다른 도구를 사용하는 이유를 이해하지 못할 수 있습니다. 마찬가지로 Terraform 전문가들은 아주 사소한 구성 변경에도 전체 인스턴스를 생성하고 삭제할 수 있습니다(다음 섹션의 불변성 참조).
불변성 인프라: 킬러 앱?
Terraform은 인프라에 대해 불변적 접근 방식을 취합니다. 불변적 인프라에 익숙하지 않은 경우, 이는 시간이 지나도 변경되지 않거나 변경할 수 없는 인스턴스로 정의됩니다. 크게 단순화하기 위해 IT 운영자는 최종 상태 클라우드 풋프린트를 원하는 구조화된 데이터로 표현하는 선언적 파일(Terraform HCL 파일)을 생성하고 Terraform을 사용하여 이를 배포할 수 있습니다. 이 접근 방식의 장점 중 하나는 최종 상태에 도달하는 방법을 이해할 필요 없이 반복적으로 배포할 수 있는 단일 진실 소스(해당 HCL 파일)를 생성한다는 것입니다. 이 접근 방식은 빠르게 시작하는 개인에게는 간단하고 우아할 수 있지만 인프라 규모에 따라 복잡하고 관리하기 어려워 질 수 있습니다 . 불변적 접근 방식의 또 다른 장점은 클라우드 리소스를 해체(디프로비저닝)하는 것이 매우 쉽다는 것입니다. 이를 통해 개발자는 리소스를 신속하게 시작하고 테스트한 다음 해체할 수 있습니다.
Ansible은 설계상 자동화에 명령형 접근 방식을 사용합니다. 각 리소스를 반복하는 작업 목록만 있으면 됩니다. 이 VPC, 이 서브넷, 그리고 이 VM을 프로비저닝하도록 설정하면 됩니다. 이 접근 방식의 장점은 이해하기 매우 쉽고, 숨겨진 마법 같은 요소가 없어 문제 해결이 쉽다는 것입니다. 단점은 일반적으로 올바른 순서를 알지 못한 상태에서 분해 및 프로비저닝 해제를 수행하는 것이 더 번거롭다는 것입니다. 인스턴스를 삭제한 다음 보안 그룹을 삭제하는 등의 작업을 반복해야 합니다. 그러나 Ansible은 AWS CloudFormation(AWS를 위한 또 다른 불변적이고 선언적인 접근 방식)과 Terraform을 모두 호출할 수 있도록 지원합니다. 실제로 Ansible Automation Platform은 모든 주요 퍼블릭 클라우드에서 이 기능을 제공하며, 사용자가 원하는 프로비저닝 및 프로비저닝 해제 방식을 사용하도록 권장합니다. 이는 Terraform과 Ansible이 함께 사용될 때 얼마나 더 나은지 보여주는 좋은 예입니다.
중요: Ansible은 보편적으로 변경 불가능한 것은 아니지만, 개별 작업을 구현하는 방법에 따라 일부 Ansible 작업은 변경 불가능할 수 있습니다.
예를 들어, CloudFormation Template을 사용하여 Linux 가상 머신을 퍼블릭 클라우드에 프로비저닝하는 Ansible 플레이북을 만든 다음, dnf Ansible 모듈을 통해 애플리케이션을 설치할 수 있습니다 . 이 활동은 Ansible에서 완전히 변경할 수 없습니다. 대부분의 Ansible 모듈은 멱등성을 가지도록 설계되어 필요할 때만 변경합니다. Ansible은 매우 유연하며, 플레이북이 실행될 때마다 변경되는 멱등성이 없는 셸 명령을 쉽게 자동화할 수 있습니다. 이는 Ansible이 개별적인 코드 기반 인프라 도구가 아닌 다목적 자동화 도구로서 얼마나 뛰어난지 보여줍니다.
사용 사례 비교
Terraform에 대한 모든 글을 읽어보면 퍼블릭 클라우드에 초점을 맞춘다는 것을 알 수 있습니다. 불변 인프라가 효과적으로 작동하는 분야는 바로 이 분야이며, Terraform은 AWS, Azure, Docker, GCP, OCI를 위한 클라우드 리소스 및 애플리케이션 프로비저닝에 탁월합니다. 하지만 IT 운영에는 자동화된 인프라 프로비저닝 외에도 다양한 기능이 있으며, 바로 이러한 이유로 Ansible이 매우 인기가 높습니다. 이는 Terraform을 폄하하는 것이 아니라, 코드형 인프라를 구현하기 위해 특정 목적과 철학을 가진 특수 도구입니다. 하지만 이러한 코드형 인프라는 인프라를 어떻게 정의하느냐에 따라 완전히 달라집니다. 중요한 Cisco IOS 네트워크 스위치가 인프라가 아닌가요? IT 인프라는 네트워크 엔지니어, 클라우드 운영 엔지니어, 시스템 관리자 등 IT 관리자마다 다른 의미를 가질 수 있습니다. 또는 다른 직책이나 역할을 맡고 있는지도 중요합니다.
Ansible은 일반적으로 기존 사일로로 인해 도메인으로 구분되는 다양한 사용 사례에 대한 자동화에 중점을 둡니다.
- 인프라 자동화 – Linux 및 Microsoft Windows 자동화는 물론 NetApp, PureStorage, HPE와 같은 스토리지 공급업체의 자동화도 포함됩니다.
- 네트워크 자동화 – Arista, Cisco, F5, Juniper 등 인기 있는 공급업체의 물리적 스위치, 라우터, 로드 밸런서, SDN 컨트롤러가 포함됩니다.
- 보안 자동화 – IBM, Checkpoint와 같은 공급업체의 SIEM, IDPS 및 방화벽과 ServiceNow와 같은 ITSM 도구를 통합합니다.
- 엣지 및 하이브리드 클라우드의 영향.
이벤트 기반 IT 전략으로 전환
Terraform과 달리 Ansible은 전체 IT 워크플로에 더 집중합니다. 예를 들어 다음 워크플로를 살펴보겠습니다.
- AWS에 웹 애플리케이션을 배포합니다.
- 웹 애플리케이션 정보로 ServiceNow ITSM을 업데이트하세요.
- 웹 애플리케이션이 올바른 포트에서 응답하는지 매시간 확인하는 일정을 실행하거나 이벤트 스트림을 사용하여 포트와 애플리케이션을 모니터링하여 추가 자동화를 수행합니다.
- 웹 애플리케이션이 응답하지 않고 수정을 위해 자동화를 시도하는 경우 ServiceNow 티켓을 업데이트/생성합니다.
위의 예에서 웹 애플리케이션을 퍼블릭 클라우드에 프로비저닝하는 것만으로는 충분하지 않습니다. 이 자동화 워크플로에는 다른 단계들이 필요합니다. 자동화를 고객의 ITSM 도구와 동기화하고, 웹 애플리케이션이 제대로 작동하는지 확인하기 위해 이벤트 기반 검사를 포함해야 합니다(이를 지속적인 IT 규정 준수라고 합니다). 상태 저장 자동화는 작업자가 자동화에서 대역 외 변경 작업을 수행하는 동안에도 서비스가 계속 실행되도록 보장할 수 있습니다.
더 나은 방법: Ansible Orchestrating Terraform
Terraform은 코드형 인프라(IaC)를 위한 탁월한 클라우드 프로비저닝 및 디프로비저닝 도구입니다. Ansible은 다목적 크로스 도메인 자동화 솔루션입니다. 두 솔루션 모두 훌륭한 오픈소스 커뮤니티와 잘 지원되는 다운스트림 유료 제품을 보유하고 있습니다. 커뮤니티, 고객, 그리고 자체 IT 워크플로를 통해 이러한 도구와 솔루션을 결합하여 더욱 놀라운 IT 워크플로를 구축할 수 있다는 것을 확인할 수 있었습니다. 이미 Terraform을 사용하고 있다면 Ansible을 사용하여 HCL 템플릿을 더욱 전체적인 자동화 워크플로로 래핑할 수 있습니다. Ansible은 자동화를 더욱 확장하여 구성 관리 및 애플리케이션 배포와 같은 작업을 Terraform IaC 배포에 추가할 수 있도록 지원합니다.
사람들은 Ansible을 어떻게 사용하고 있나요?
많은 IT 관리자가 Day 2 운영과 같은 다른 클라우드 운영 사례보다는 특정 “클라우드 배포 및 폐기” 사용 사례를 참조하는 것을 확인했습니다. 아이디어를 얻기 위해, 클라우드 리소스 프로비저닝 및 프로비저닝 해제 외에도 Ansible 클라우드 자동화 사용 사례를 몇 가지 살펴보겠습니다.
- 인프라 가시성 – Ansible을 사용하여 퍼블릭 클라우드에서 정보를 검색하여 클라우드 사용량을 파악하는 것입니다. 이는 여러 IT 관리자가 서로 다른 대역 외 리소스를 구성하는 브라운필드 환경에 매우 유용합니다. 강제적인 IT 프로세스가 없는 경우, 읽기 전용이며 프로덕션 환경 변경이 필요하지 않으므로 시작하기에 좋은 사용 사례입니다.
- 규정 준수 – 클라우드 인프라뿐만 아니라 클라우드 자체도 코드로 처리해야 합니다. 예를 들어, IAM 정책을 시행하고 퍼블릭 클라우드 전반에 걸쳐 공통된 환경을 제공할 수 있습니다. 또 다른 예로, 요금 청구 및 감사를 위해 인스턴스 전반에 태그 정책을 적용하고, 규정을 위반하는 인스턴스를 종료하는 것이 있습니다. Ansible의 장점은 변경 가능 및 변경 불가능 인프라 모두에서 이러한 정책을 운영하고 적용할 수 있다는 것입니다.
- 비즈니스 연속성 – Ansible은 운영 중단 없이 운영할 수 있도록 지원합니다. 클라우드 외부로 리소스를 이동 및 복사하고, 백업 정책을 생성 및 관리하며, 중단 및 장애 관리를 위한 자동화를 구축하세요.
- 클라우드 운영 – Ansible은 2일차 업무를 자동화할 수 있습니다. 여기에는 애플리케이션 배포 및 CI/CD 파이프라인, 수명 주기 관리 및 시행, OS 패치 적용 및 유지 관리가 포함됩니다.
- 클라우드 마이그레이션 – Ansible은 워크로드를 필요한 곳으로 이동하는 데 도움을 줄 수 있습니다. 예를 들어, 온프레미스 인프라에 자동화를 도입하면 운영자가 퍼블릭 클라우드를 도입하는 데 도움이 될 수 있습니다. 온박스 구성이 아닌 자동화를 통해 데이터 소스의 신뢰성을 확보하는 것이 클라우드 마이그레이션의 첫 단계입니다. Ansible 자동화는 클라우드 네이티브로의 마이그레이션 과정에서 발생하는 마찰을 줄여 개발자가 레거시 인프라에서 마이그레이션할 수 있도록 지원합니다. Ansible 자동화를 사용하면 IT 부서가 레거시 및 클라우드 네이티브 환경에서 자동화 아키텍처를 통합하는 데 도움을 줄 수 있습니다.
- 인프라 최적화 – 클라우드 도입은 IT 운영자의 시간과 비용 절감에 도움이 되지만, 초기에는 비용을 예측하고 청구 요건이 어떻게 변하는지 파악하기 어렵습니다. 자동화 전략을 구축하면 사용하지 않는 리소스를 비활성화하고, 클라우드 리소스의 규모를 적정 수준으로 조정하고, 인프라 가시성과 같은 사용 사례와 결합하여 비용을 효율적으로 관리할 수 있습니다. 이를 통해 사용되지 않는 리소스를 쉽게 복구하고 예상치 못한 비용이 발생하지 않도록 할 수 있습니다.
- 인프라 오케스트레이션 – 이전에도 언급했지만, 퍼블릭 클라우드에 없는 모든 것을 어떻게 통합할 수 있을까요? 오케스트레이션은 단순히 사일로를 허물고 클라우드 외부의 인프라와 통합하는 방법입니다. 이를 통해 IT 운영자는 기술 사일로에 구애받지 않고 비즈니스 성과를 조율하고 모든 인프라에 일관된 규정 준수를 적용할 수 있습니다.
- 자동화된 문제 해결 – IT 팀이 자동화에 대한 확신을 갖게 되면 이벤트 기반 아키텍처로 전환할 수 있습니다. 이를 통해 IT 팀은 인시던트에 더 빠르게 대응하고, 평균 해결 시간을 단축하며, 조직의 ITSM 솔루션과 통합할 수 있습니다.
사람들은 성공하고 있는가?
간단히 답하자면? 네! Ansible을 사용하여 Terraform을 자동화하는 것도 가능합니다! 하지만 전체적인 자동화는 클라우드에서 한 가지 일을 잘하는 것 이상입니다. Ansible은 물리적, 가상 및 클라우드 리소스를 자동화하고 조정할 수 있습니다. 네트워크 장치, Windows 서버, 스토리지, 그리고 물론 Linux의 프로비저닝, 구성 관리, 그리고 2일차 운영 관리까지 자동화할 수 있습니다. 하지만 어떤 솔루션을 사용하든, 기술적인 관점에서 진정한 문제는 “무엇” 또는 “어떻게” 문제를 해결하는지가 아니라, 전체 IT 조직으로 확장하고 성장하는 과정에서 기술 영역 전반에 걸쳐 표준화를 이루는 것입니다.
클라우드에서 Ansible Automation Platform을 활용한 가장 인상적이고 최근의 성공 사례 중 하나는 Asian Development Bank의 사례 연구입니다. 이 사례 연구는 아시아개발 은행이 인프라를 현대화하는 동시에 인력을 현대화하여 혁신적인 프로젝트와 새로운 서비스 제공과 같은 더 중요한 업무에 집중할 수 있는 시간을 확보한 방법을 자세히 설명합니다. 0일차에는 Terraform을, 1일차와 2일차에는 Ansible Automation Platform을 표준화했습니다. 임베디드 영상 에서 그들의 사례를 확인해 보세요 !
마지막 생각
Ansible과 Terraform 사이의 혼란은 부정확하거나 오래된 소스 자료, 또는 두 기술 모두 사용해 본 경험 부족으로 인해 한동안 존재해 왔습니다. 이 블로그 게시물은 (다소 편향적일 수 있지만) Ansible과 Terraform 사이의 더 깊은 연관성에 대한 논의를 시작하는 데 도움이 될 것입니다. 모든 상황, 사용 사례, 그리고 솔루션을 구현하는 사람은 다를 수 있지만, 이러한 요소들 때문에 Ansible이 자동화를 위한 최고의 솔루션이라고 생각합니다.
