[T101] 4-1. Terraform - Provider

 

이 스터디는 CloudNet@에서 진행하는 T101 스터디를 참여하면서 공부하는 내용을 기록하는 블로그 포스팅입니다.

CloudNet@에서 제공해주는 자료들과 테라폼으로 시작하는 IaC 를 바탕으로 작성되었습니다.

 

Provider

테라폼은 terraform binary 파일을 시작으로 로컬 환경이나 배포 서버와 같은 원격 환경에서 원하는 대상을 호출하는 방식으로 실행됩니다. 이때 '원하는 대상'은 호출하는 방식이 서로 다르지만 대상의 공급자(프로바이더)가 제공하는 API를 호출하여 상호작용합니다. 각 프로바이더의 API 구현은 서로 다르지만 테라폼의 고유 문법으로 동일한 동작을 수행하도록 구현되어있습니다. 

또한, 프로바이더는 플러그인 형태로 테라폼에 결합되어 대상이 되는 클라우드, SaaS, 기타 API를 사용하여 동작을 수행하고 각 프로바이더는 테라폼이 관리하는 리소스 유형과 데이터 소스를 사용할 수 있도록 연결합니다. 

Upstream APIs
보통 Upstream API는 데이터와 요청을 전당하는 시스템 구조에서 사용되는 용어입니다. 즉, 주로 데이터나 서비스를 제공하는 소스 시스템을 의미합니다. Terraform에서 UpstreamAPIs는 클라우드 제공자의 API로서 테라폼이 인프라를 관리하기 위해 호출하는 클라우드 제공자(예. AWS, Azure, GCP등)의 API들을 의미합니다. 테라폼은 이러한 제공자의 API를 통해 인프라를 생성, 수정, 삭제합니다.

 

 

즉, 테라폼은 프로바이더 없이는 어떤 종류의 인프라와 서비스도 관리할 수 없다는 의미입니다. 대부분의 프로바이더는 대상 인프라 환경이나 서비스 환경에 대하여 리소스를 관리하므로, 프로바이더를 구성할 때는 대상과의 연결과 인증에 필요한 정보(예. AWS 자격증명 등)가 제공되어야 합니다. 

 

프로바이더 구성

테라폼 레지스트리

https://registry.terraform.io/browse/providers

각 프로바이더는 테라폼 실행 파일과는 별도로 자체 관리되고 게시됩니다. 테라폼 레지스트리에서 주요 프로바이더와 관련된 문서를 확인하실 수 있습니다. local 프로바이더처럼 프로바이더를 위한 별도 구성이 필요하지 않은 경우도 있지만, AWS와 같은 클라우드 프로바이더의 경우는 AWS 자격증명 정보와 region등을 정의해야 합니다.

 

 

테라폼 레지스트리의 목록에는 유지보수 및 게시에 대한 권한에 따라 Tier 정보가 제공됩니다.

 

프로바이더 식별 정보

 

 

AWS 프로바이더 사용 정의 확인

지정하는 프로바이더의 요구사항을 정의할 때는 레지스트리의 Overview 항목 오른쪽에 있는 [USE PROVIDER] 버튼을 클릭하여 현재 버전에 맞는 정의 방법을 확인합니다.

 

로컬 이름과 프로바이더 지정

terraform 블록의 required_providers 블록 내에 <로컬 이름> = { } 으로 여러 개의 프로바이더를 정의할 수 있습니다. 여기서 사용되는 로컬 이름은 테라폼 모듈 내에서 고유해야 합니다. 로컬 이름과 리소스 접두사는 독립적으로 선언되며, 각 프로바이더의 소스 경로가 지정되면 프로바이더의 고유 접두사가 제공됩니다. 만약, 동일한 접두사를 사용하는 프로바이더가 선언되는 경우 로컬 이름을 달리하여 관련 리소스에서 어떤 프로바이더를 사용하는지 명시적으로 지정할 수 있습니다.

 

terraform {
  required_providers {
    architech-http = {
      source = "architect-team/http"
      version = "~> 3.0"
    }
    http = {
      source = "hashicorp/http"
    }
    aws-http = {
      source = "terraform-aws-modules/http"
    }
  }
}

data "http" "example" {
  provider = aws-http
  url = "https://checkpoint-api.hashicorp.com/v1/check/terraform"

  request_headers = {
    Accept = "application/json"
  }
}

 

위는 동일한 http 접두사를 사용하는 다수의 프로바이더를 사용하는 코드입니다. 동일한 http 이름을 사용하는 다수의 프로바이더가 있는 경우 각 프로바이더에 고유한 이름을 부여하고 리소스와 데이터 소스에 어떤 프로바이더를 사용할 지 provider 인수에 명시합니다. 단, 동일한 source에 대해 다수의 정의는 불가능합니다.

 

단일 프로바이더의 다중 정의

동일한 프로바이더를 사용하지만 다른 조건을 갖는 경우에 사용되는 리소스마다 별도로 선언된 프로바이더를 지정해야 할 수 있습니다. 예를 들면, AWS 프로바이더를 사용하는데 서로 다른 권한의 IAM을 갖는 AccessID 또는 대상 region을 지정해야 하는 경우입니다. 이때는 프로바이더 선언에서 alias를 명시하고 사용하는 리소스와 데이터 소스에서는 provider 메타 이수를 사용하여 특정 프로바이더를 지정할 수 있습니다. provider 메타인수에 지정되지 않은 경우 alias가 없는 프로바이더가 기본 프로바이더로 동작합니다. 

provider "aws" {
  region = "ap-southeast-1"
}

provider "aws" {
  alias = "seoul"
  region = "ap-northeast-2"
}

resource "aws_instance" "app_server1" {
  ami           = "ami-06b79cf2aee0d5c92"
  instance_type = "t2.micro"
}

resource "aws_instance" "app_server2" {
  provider      = aws.seoul
  ami           = "ami-0ea4d4b8dc1e46212"
  instance_type = "t2.micro"
}

위의 코드는 region을 다르게 구성한 AWS 프로바이더를 aws_instance에 각각 지정하는 코드입니다.

 

프로바이더 요구사항 정의

테라폼 실행 시 요구되는 프로바이더 요구 사항은 terraform 블록의 required_providers 블록에 여러 개 지정할 수 있습니다. 

terraform {
  required_providers {
    <프로바이더 로컬 이름> = {
      source = [<호스트 주소>/]<네임스페이스>/<유형>
      version = <버전 제약>
    }
    ...
  }
}

source에는 프로바이더 다운로드 경로를 입력하고, version에는 사용할 버전을 명시합니다.

• 호스트 주소 : 프로바이더를 배포하는 주소로서 기본값은 registry.terraform.io
• 네임스페이스 : 지정된 레지스트리 내에서 구분하는 네임스페이스로, 공개된 레지스트리 및 Terraform Cloud의 비공개 레지스트리의 프로바이더를 게시하는 조직을 의미
• 유형 : 프로바이더에서 관리되는 플랫폼이나 서비스 이름으로 일반적으로 접두사와 일치하나 일부 예외가 있을 수 있음

프로바이더는 기능이나 조건이 시간이 지남에 따라 변경될 수 있습니다. 그렇기에 특정 버전을 명시하여 정의가 가능하고 이 값이 생략된 경우 terraform init을 하는 당시의 가장 최신 버전으로 선택됩니다. 

 

프로바이더 설치

테라폼을 실행하기 전 terraform init 명령을 통해 정의된 프로바이더를 다운로드, 복사, 캐시에서 읽어오게 됩니다. 항상 지정된 구성에 대해 동일한 프로바이더를 설치하도록 하려면 테라폼 구성에 사용되는 프로바이더에 대해 명시적으로 terraform 블록에 정의하거나 .terraform.lock.hcl 잠금 파일을 코드 저장소에 공유하는 방안을 활용합니다. required_providers에 지정된 프로바이더가 있는 경우 코드 구성에서 사용 여부에 관계 없이 프로바이더를 다운로드하게 되고, 지정하지 않더라도 테라폼 구성 코드상에서 사용된 프로바이더를 terraform이 추론하여 최신 버전의 프로바이더를 다운로드합니다.

 

프로바이더 간 전환 여부

클라우드를 대상으로 테라폼을 사용하는 경우 다른 프로바이더로 전환이 불가능합니다. 테라폼은 인프라에 대한 단일 프로비저닝 도구로 사용되지만 대상이 되는 환경은 서로 다른 API로 구현된 프로바이더가 제공됩니다. 

Resource	AWS	GCP
VPC, Subnet	aws_vpc aws_subner	google_compute_network google_compute_subnetwork
Load Balancer	aws_elb	google_compute_backend_service google_compute_target_http_proxy
Virtual Machine	aws_instance	google_compute_instance
DataBase	aws_db_instance	google_sql_database_instance

 

프로바이더 에코 시스템

테라폼의 에코시스템은 사용자가 사용하는 방식과 구조에 테라폼을 적용할 수 있도록 설계됩니다. 에코시스템을 위한 테라폼 통합은 워크플로 파트너와 인프라 파트너로 나뉩니다.

워크플로 파트너

워크플로 파트너는 테라폼 실행 및 TerraformCloud/Enterprise와 연계하여 동작하는 기능을 제공합니다. 대표적으로 테라폼 구성을 관리하기 위한 VCS를 제공하는 GitHub, GitLab, BitBucket, AzureDevOps등이 있습니다.

인프라 파트너

사용자가 테라폼으로 대상 플랫폼의 API로 상호작용 가능한 리소스를 관리할 수 있도록 합니다. 프로바이더의 경우 인프라 파트너에 해당하는데, VCS의 워크플로 파이터인 GitHub는 테라폼으로 프로비저닝 가능한 인프라 파트너이기도 합니다. 사용자는 테라폼을 사용하여 Github의 사용자, 팀, 저장소, 브랜치 등을 프로비저닝하고 관리할 수 있습니다.

인프라 파트너의 분류와 프로바이더 대상은 아래와 같습니다.

 

퍼블릭 클라우드

• IaaS, SaaS 및 PaaS를 포함한 다양한 서비스를 제공하는 대규모 글로벌 클라우드 제공

컨테이너 오케스트레이션

• 컨테이너 프로비저닝 및 배포를 지원

IaaS(Infrastructure-as-a-Service)

• 스토리지, 네트워킹 및 가상화와 같은 솔루션을 제공하는 인프라 및 IaaS 제공

보안 및 인증

• 인증 및 보안 모니터링 플랫폼

자산 관리

• 소프트웨어 라이선스, 하드웨어 자산 및 클라우드 리소스를 비롯한 주요 조직 및 IT 리소스의 자산 관리를 제공

CI/CD

• 지속적인 통합 및 지속적인 제공/배포

로깅 및 모니터링

• 로거, 측정 도구 및 모니터링 서비스와 같은 서비스를 구성하고 관리하는 기능

유틸리티

• 임의 값 생성, 파일 생성, http 상호 작용 및 시간 기반 리소스와 같은 도우미 기능

클라우드 자동화

• 구성 관리와 같은 전문화된 클라우드 인프라 자동화 관리 기능

데이터 관리

• 데이터 센터 스토리지, 백업 및 복구 솔루션

네트워킹

• 라우팅, 스위칭, 방화벽 및 SD-WAN 솔루션과 같은 네트워크별 하드웨어 및 가상화된 제품과 통합

VCS(버전 제어 시스템)

• Terraform 내에서 VCS(버전 제어 시스템) 프로젝트, 팀 및 리포지토리에 중점

통신 및 메시징

• 통신, 이메일 및 메시징 플랫폼과 통합

데이터베이스

• 데이터베이스 리소스를 프로비저닝 및 구성하는 기능

PaaS(Platform-as-a-Service)

• 다양한 하드웨어, 소프트웨어 및 애플리케이션 개발 도구를 제공하는 플랫폼 및 PaaS

웹 서비스

• 웹 호스팅, 웹 성능, CDN 및 DNS 서비스