블로그

F5 애플리케이션 서비스를 위해 Ansible 또는 Terraform 선택

로리 맥비티 썸네일
로리 맥비티
2019년 9월 30일 게시

F5 애플리케이션 서비스를 배포하고 운영하려면 두 가지 중 하나 또는 둘 다를 선택하세요.

오픈소스 운동은 언제나 자유에 초점을 맞춰왔습니다. 본인의 기술, 예산, 아키텍처, 목표에 맞춰 가장 적합한 솔루션을 선택할 수 있는 자유. 이 원칙은 오늘날에도 배포 파이프라인을 위한 반복 가능한 인프라를 구축하는 데 있어 중요한 요소로 남아 있습니다.

애플리케이션 서비스의 프로비저닝과 운영을 자동화하기 위한 훌륭한 옵션이 많이 있습니다. 가장 인기 있는 두 가지 선택 사항은 RedHat Ansible과 HashiCorp Terraform입니다. 

여기서 잠깐 멈추고 F5가 AnsibleTerraform을 완벽하게 지원한다는 점을 말씀드리겠습니다. 우리는 상호 운용성과 통합을 보장하기 위해 두 분야 모두와 협력하므로, 여러분은 직접 협력할 필요가 없습니다. 어떤 선택을 하든, 우리가 당신을 지지하겠습니다.

하지만 고객 참여를 통해 일부 작업에서는 Ansible이 뛰어나고 다른 작업에서는 Terraform이 더 뛰어나다는 것을 알게 되었습니다. 파이프라인을 자동화하고 유지관리하려면 서로 다른 작업 집합이 필요하기 때문입니다.

Terraform은 환경 상태를 관리하는 오케스트레이션 에 탁월합니다. 즉, Terraform은 환경이 어떻게 생겼는지, 어떻게 동작해야 하는지 이해한다는 의미입니다. 문제가 있으면 Terraform에서 이를 플래그로 지정하여 검토를 요청할 수 있습니다.

Ansible은 구성 관리 에 매우 뛰어납니다. 즉, 개별 구성 요소의 상태를 유지하는 데 중점을 둡니다. 환경 내 개별 구성 요소에 문제가 있는 경우 Ansible은 구성을 조정하여 문제를 해결할 수 있습니다. 

각 도구의 초점이 다르기 때문에 배포 수명 주기를 자동화하기 위해 이 도구들을 함께 사용하는 것은 놀라운 일이 아닙니다. 

이 두 도구가 F5 애플리케이션 서비스와 어떻게 작동하는지 알아보려면 배포 수명 주기를 보기 위해 공통점을 설정하는 것이 좋습니다. 

배포 라이프사이클

애플리케이션에 해당 전달 파이프라인이 있는 수명 주기가 있는 것처럼, 애플리케이션 서비스에도 해당 배포 파이프라인이 있는 수명 주기가 있습니다. 해당 수명 주기에는 여러 단계가 필요합니다.

  1. 공급
    에이. 프로비저닝은 퍼블릭 클라우드나 프라이빗 클라우드에서 가상 머신이나 컨테이너 등의 인스턴스를 실제로 생성하는 프로세스입니다.
  2. 탑승 중
    에이. 온보딩은 BIG-IP가 구축된 환경에서 작동하는 데 필요한 네트워킹을 설정하는 데 필요합니다.
  3. 배포하다
    에이. 라이프사이클의 배포 단계에서는 애플리케이션 서비스가 정의되고, 구성되고, 시작됩니다.
  4. 작동하다
    에이. 지속적인 운영에는 모니터링과 분석이 필요합니다. F5 Telemetry Streaming을 사용하면 BIG-IP를 원격 측정 파이프라인에 플러그인하여 원하는 지표와 데이터를 공유할 수 있습니다.
  5. 변화
    에이. 변경은 기존 구성을 수정하는 프로세스입니다(배포 단계에서 처음 지정).

Ansible과 Terraform은 모두 5가지 단계 모두에 대한 기본 자동화 공급자가 될 수 있습니다. 그러나 각 단계마다 효과가 다르기 때문에 둘 다 사용하는 것이 실제로 더 나은 전략이 될 수 있습니다. Ansible은 배포 및 변경(구성 관리) 단계에 사용될 가능성이 더 높은 반면, Terraform은 프로비저닝 및 온보딩(오케스트레이션)에 더 자주 사용됩니다.

Ansible과 Terraform 함께

우리는 많은 고객이 툴체인을 표준화하고 싶어한다는 사실도 알고 있습니다. 그럴 만한 이유가 있죠. 여러 도구에 대한 전문 지식을 유지하는 일은 어려울 수 있으며, 여러 도구 체인을 실행하는 데 필요한 인프라를 운영하고 유지관리하는 것은 말할 것도 없습니다. 그렇다면 이러한 멋진 도구 중 어느 것을 표준화할지 선택하는 방법이 있습니다.

  1. 인프라의 빈번하지 않은 변경
    이 시나리오에서는 인프라(예: BIG-IP)가 아닌 애플리케이션 서비스를 변경하게 됩니다. 이는 기존 BIG-IP를 활용하여 새로운 애플리케이션을 배포할 때 자주 발생하는 경우입니다. Ansible은 구성 관리 에 탁월하므로 이 분야에서 좋은 선택입니다. 이것이 바로 여러분이 주로 하게 될 작업입니다. Ansible은 다양한 언어와 API 스타일을 지원하므로 DevOps 및 NetOps 팀 모두가 애플리케이션 서비스를 변경하는 데 매우 적합합니다. Ansible을 사용하면 F5 Ansible 모듈이나 F5 AS3을 통해 F5 애플리케이션 서비스를 구성할 수 있습니다. 귀하의 구체적인 필요에 따라 두 가지를 모두 사용할 수도 있습니다. Ansible 접근 방식을 선택하는 방법에 대해 자세히 알아보려면 Mani Gadde와 Andrius Benokraitis의 훌륭한 블로그를 확인하세요.
  2. 인프라의 빈번한 변경
    클라우드(특히 퍼블릭 클라우드)는 애플리케이션과 이를 지원하는 인프라의 높은 속도의 변경을 용이하게 하기 위해 종종 선택됩니다. 변경 불가능한 인프라는 이런 상황에서 변동성을 관리하는 데 도움이 되는 경우가 많습니다. 즉, 전체 인프라를 철거하고 다시 구축하는 것입니다. Terraform은 전체 인프라를 신속하게 프로비저닝하고 온보딩하는 데 탁월하므로 이런 시나리오에 아주 적합한 선택입니다. 이 솔루션의 설계와 오케스트레이션 에 대한 초점은 특히 클라우드와 같은 불안정한 환경에서 일관되고 반복 가능한 인프라를 대규모로 만드는 데 적합합니다. 
  3. 인프라 및 애플리케이션 서비스에 대한 빈번한 변경
    Terraform과 Ansible은 인프라와 애플리케이션 서비스 전반에서 높은 비율의 변화를 관리하는 데 최적의 조합이 될 수 있습니다. 환경 상태와 개별 구성 요소에 대한 빈번한 변경이 예상되므로 애플리케이션과 이를 지원하는 애플리케이션 서비스의 가용성을 유지하는 데 도움이 되는 변경 관리오케스트레이션 도구가 모두 필요합니다.

Ansible, Terraform 또는 둘 다 선택하든 상관없이 F5는 네이티브 통합 및 사전 패키징된 템플릿과 두 가지 모두에 적극적으로 기여하고 개선하는 커뮤니티를 통해 귀하의 선택을 지원하기 위해 최선을 다하고 있습니다.