![[OSSCA] Terraform Provider 살펴보기](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FxkvMt%2FbtsIJdCcTkI%2FK2kvYDSonkcMJo1sKtvdK1%2Fimg.webp)
4주차부터는 본격적으로 Terraform 프로바이더에 대해 개발을 진행한다. 개발을 진행하기 앞서 우선적으로 Terraform 프로바이더가 어떤 방식으로 동작하는지에 대해 알아보고 본격적인 개발을 착수하도록 하자.
테라폼 프로바이더
테라폼은 프로비저닝을 수행하는 도구이다. 즉, 테라폼을 이용하면 코드 기반으로 인프라를 정의하고 관리할 수 있다. 그러나 테라폼 자체는 AWS, NCP 등과는 직접적인 관계가 없다. 따라서 특정 클라우드 플랫폼을 테라폼을 통해 사용하려면 해당 플랫폼에 대한 프로바이더(Provider)를 함께 사용해야 한다.
프로바이더는 테라폼이 다양한 클라우드 서비스와 상호 작용할 수 있도록 해주는 플러그인 역할을 한다. 예를 들어, 네이버 클라우드 플랫폼(NCP)의 리소스를 테라폼으로 관리하려면 네이버 클라우드의 API를 이용하는 프로바이더가 필요하다. 이 프로바이더는 테라폼이 네이버 클라우드의 API와 통신하여 리소스를 생성, 수정, 삭제할 수 있도록 해준다.
실제로, AWS, Azure, Google Cloud 등 주요 클라우드 서비스 제공자들은 모두 테라폼 프로바이더를 제공한다. 사용자는 이 프로바이더들을 설치하고 테라폼 설정 파일에 포함시켜 해당 클라우드 서비스의 리소스를 관리할 수 있다. 이렇게 하면 코드 한 줄로 여러 클라우드 서비스의 리소스를 일관되게 관리할 수 있다.
테라폼 코어
테라폼 코어(Terraform Core)는 프레임워크의 역할을 한다. 이는 테라폼의 기본 기능을 제공하며, 프로바이더와 상호 작용하여 리소스를 관리할 수 있게 한다. 테라폼 코어는 상태 파일(state file)을 관리하고, 계획(plan)을 생성하며, 이를 실행(apply)하여 실제 인프라 상태를 변경한다.
테라폼 코어와 프로바이더 간의 동작원리
테라폼은 테라폼 코어(Terraform Core)를 중심으로 동작하게 된다. 테라폼 코어는 사용자가 작성한 구성 파일(config file)을 읽어와 이를 기반으로 인프라를 관리한다.
테라폼 코어는 백엔드를 가지고 있으며, 로컬 백엔드는 사용자의 환경 변수 등을 확인하고, 테라폼 명령어를 가져오는 도구의 역할을 한다. 테라폼이 인프라를 프로비저닝한 후에는 인프라 리소스에 대한 상태(state)를 관리하는 상태 파일(state file)을 생성한다. 이러한 상태 파일은 각 리소스의 현재 상태를 기록하여, 이후 변경 사항을 추적하고 관리하는 데 사용된다.
테라폼 코어는 이러한 모든 정보를 컨텍스트(context)로 관리한다. 이를 통해 각각의 의존성 그래프(dependency graph)를 생성하며, 의존성 그래프에 따라 새로운 리소스를 생성할 때 필요한 순서에 따라 생성 작업을 진행하게 된다.
테라폼은 원격 프로시저 호출(RPC)을 통해 작업을 수행한다. 즉, 테라폼 코어가 직접 작업을 수행하는 것이 아니라, 다른 내부 프로시저를 생성하여 원하는 작업을 수행하도록 한다. 이 과정에서 테라폼 코어는 프로바이더에게 필요한 요청을 보내고, 프로바이더는 해당 요청에 따라 실제 프로비저닝 작업을 수행하게 된다.
사용자가 테라폼을 사용해서 VPC를 사용한다면?
예를 들어, 사용자가 VPC를 생성하려는 경우를 살펴보자. 테라폼 코어는 VPC 생성을 위한 RPC 요청을 보낸다. 만약 프로바이더가 네이버 클라우드 플랫폼(NCP)이라면, NCP의 VPC를 생성하기 위한 API를 호출하게 된다. AWS의 경우도 마찬가지로, Go 언어로 구현된 SDK를 통해 AWS VPC 생성을 위한 API를 호출하게 된다. 이러한 방식으로, 테라폼은 다양한 클라우드 서비스에 대해 일관된 방식으로 리소스를 생성하고 관리할 수 있게 된다.
생성된 결과는 다시 테라폼 코어에 전달되며, 이를 통해 VPC 생성 작업이 완료되었음을 알게 된다. 이 과정에서 몇 개의 VPC가 생성되었는지 등의 정보도 함께 전달된다. 테라폼 코어는 이러한 정보를 바탕으로 상태 파일을 갱신하고, 이후의 작업에 반영한다.
테라폼 프로바이더에서의 인증 및 리소스 정의
테라폼 프로바이더에서의 인증
테라폼 프로바이더는 인증 관련 작업도 수행할 수 있다. 이는 주로 액세스 키(access key)를 작성하거나 환경 변수에 인증 정보를 넣어서 테라폼 명령을 수행할 때 해당 키를 가져다가 인증 과정을 수행하게 된다. 이러한 인증 작업은 보통 SDK(Software Development Kit)를 통해 수행된다.
리소스와 데이터 소스의 정의
테라폼 구성 파일(conf)을 작성할 때, VPC를 생성하고자 한다면 필요한 리소스를 정의하고, 사용하고 싶은 이름을 설정할 수 있다. 예를 들어, 네이버 클라우드 플랫폼(NCP)에서 VPC를 생성하려면 NCP 프로바이더에 정의된 VPC 리소스를 테라폼 구성 파일에 포함시켜야 한다.
네이버 클라우드 플랫폼에 정의된 리소스들은 테라폼 프로바이더에 정의되어 있다. 우리가 사용할 수 있는 리소스들은 모두 프로바이더에 지정된 것들이다. 만약 NCP에서 새로운 리소스가 추가되었고, 이를 테라폼으로 사용하려면 해당 리소스를 테라폼 프로바이더에 추가하여 배포해야 한다. 이를 통해 사용자는 프로바이더에 정의된 새로운 리소스를 사용할 수 있게 된다.
해시코프(HashiCorp) 레지스트리에는 NCP에 대한 정보가 존재한다. 이를 통해 사용자는 NCP 프로바이더와 관련된 다양한 정보를 얻을 수 있으며, 해당 프로바이더를 사용하여 NCP 리소스를 테라폼으로 관리할 수 있다.
gRPC를 통해 Terraform Core에서 호출하는 방식
테라폼 코어와 프로바이더는 원격 프로시저 호출(RPC)을 통해 서로 요청을 주고받는다. 테라폼 코어가 프로바이더로 요청을 보낼 때, 구체적으로 gRPC(Google Remote Procedure Call)를 사용한다. gRPC는 구글에서 개발한 고성능, 오픈 소스 RPC 프레임워크로, 다양한 언어와 플랫폼에서 효율적으로 통신할 수 있도록 해준다.
gRPC를 통해 테라폼 코어는 프로바이더에게 다양한 요청을 보낼 수 있다. 예를 들어, VPC를 생성하는 경우를 살펴보자. 테라폼 코어는 VPC 생성을 위한 RPC 요청을 gRPC를 통해 프로바이더에게 전송한다. 이때 프로바이더가 네이버 클라우드 플랫폼(NCP)이라면, NCP 프로바이더는 해당 요청을 받아 NCP의 API를 호출하여 VPC를 생성한다. 마찬가지로 AWS 프로바이더도 gRPC를 통해 요청을 받아 AWS의 SDK를 사용하여 VPC를 생성하는 API를 호출하게 된다.
생성된 결과는 다시 gRPC를 통해 테라폼 코어에 전달되며, 이를 통해 VPC 생성 작업이 완료되었음을 알게 된다. 이 과정에서 생성된 VPC의 정보도 함께 전달되어 상태 파일에 반영된다. 이러한 방식으로 테라폼 코어와 프로바이더는 gRPC를 활용하여 원활한 통신을 유지하고, 인프라 리소스를 효율적으로 관리할 수 있다.
https://developer.hashicorp.com/terraform/plugin/terraform-plugin-protocol
Plugin Development - Terraform Plugin Protocol | Terraform | HashiCorp Developer
Learn how Terraform communicates with plugins.
developer.hashicorp.com
테라폼의 문서를 확인하고자 한다면, 해시코프(HashiCorp)의 테라폼 IO 웹사이트에서 다양한 도큐멘트를 볼 수 있다. 이 문서들에는 테라폼의 다양한 기능과 사용법에 대한 상세한 정보가 포함되어 있으며, 테라폼 플러그인 프로토콜에 관한 내용도 포함되어 있다. 특히, 테라폼 플러그인 프로토콜에서 gRPC의 사용에 대한 내용을 찾아볼 수 있다.
Terraform Validate
테라폼에서 plan과 apply 명령을 수행하면 자동으로 일련의 과정이 실행된다. 이 과정은 작성한 코드의 내용이 유효한지 검증하는 절차를 포함한다.
이 과정에서는 4개의 RPC 요청이 프로바이더에게 보내진다. 첫 번째 단계는 프로바이더의 스키마를 가져오는 것이다. 사용자가 테라폼 구성 파일을 작성할 때, VPC, 리전(region), ncloud_server와 같은 리소스를 정의하게 된다. 이러한 리소스들이 프로바이더에서 제공하는 여러 가지 리소스 정보를 바탕으로 작성되었는지를 확인하기 위해 스키마 정보를 가져온다.
예를 들어, 사용자가 리전 정보를 입력한 경우, 이 정보가 스키마에 맞는지 검증하는 과정이 필요하다. 프로바이더를 구현할 때는 argument 등의 값에 대한 제약 조건을 설정할 수 있다. 예를 들어, 특정 특수 문자가 포함되지 않도록 제약 조건을 설정할 수 있다. 이러한 제약 조건을 잘 지켜서 작성했는지 검증하는 과정이 필요하다.
또한, 테라폼은 리소스와 데이터 블록 등이 올바른 순서로 잘 작성되었는지 확인한다. 이 과정에서 프로바이더가 제공하는 리소스와 데이터 블록의 스키마 정보를 바탕으로 검증 작업이 수행된다.
테라폼 프로바이더를 개발할 때는 SDK를 이용해서 이러한 작업을 수행할 수 있다. SDK는 프로바이더를 구현하는 데 필요한 다양한 도구와 라이브러리를 제공하여, 효율적으로 프로바이더를 개발할 수 있게 해준다.
Terraform Provider : SDK 에서 Framework로
기존에는 SDK, 새로운 것은 Framework로 해시코프에서 새로 개발한 것이다. 기존 SDK가 가진 한계점이 존재하여, 문제를 개선할 수 있는 다음 버전의 SDK를 출시한게 Framework이다. 해당 차이점에 대해서는 다른 포스팅으로 다뤄보고자 한다.
'Infra > Terraform' 카테고리의 다른 글
[OSSCA] Terraform Provider 개발(1) - Go API 분석하기 (0) | 2024.07.29 |
---|---|
[OSSCA] Terraform Provider SDK 와 Framework 버전 차이를 알아보자 (1) | 2024.07.24 |
[OSSCA] Terraform으로 NCP 사용하기 (6) | 2024.07.23 |
[OSSCA] NCP를 이용하여 인프라 설정하기 (0) | 2024.07.22 |
[OSSCA] Terraform 이란? (0) | 2024.07.22 |
보안 전공 개발자지만 대학로에서 살고 싶어요
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!