New Suggest

Suggest edit for "Terraform으로 인프라 관리하기"

Suggestion title

Description

Terraform은 클라우드 인프라를 코드로 관리할 수 있게 해주는 도구(IaC: Infrastructure as Code)로 AWS나 GCP같은 클라우드 제공 업체 홈페이지에서 하나하나 클릭으로 만들지 않고 코드로 정의하고 자동으로 생성할 수 있게 해준다.

테라폼의 핵심요소는 크게 Provider, Resource, State 이 3가지로 나눌 수 있다.

가장 먼저 Provider는 테라폼이 어떤 플랫폼을 다룰지 정하는 설정으로 여러 유명 클라우드 제공 업체와 연동이 가능하다. 심지어 네이버 클라우드 플랫폼도 사용이 가능하다.

```hcl
provider "aws" {
	region = "ap-northeast-2"
}
```

그 다음으로 Resource는 실제로 만들 인프라 자원에 대한 설정이다.
클라우드 업체에서 제공하는 여러 서비스, 예를 들어 AWS라면 EC2, S3 버킷 등을 resource 블럭 내부에서 설정할 수 있다.
```hcl
resource "aws_instance" "web_server" {
  ami           = "ami-xxxxxx"
  instance_type = "t2.micro"
}
```

마지막으로 State는 테라폼이 현재 인프라 상태를 기억하는 파일이다.
테라폼은 코드와 실제 인프라가 같은 상태인지, 내가 만든 EC2인스턴스가 AWS에 실제로 존재하는지등과 같은 정보를 알고 있어야 한다. 이런 정보를 저장하는 것이 바로 Terraform State로 보통 `.tfstate`라는 파일로 관리된다.

테라폼을 사용한다면 일관된 환경을 구성하기가 쉬우므로 개발환경, 테스트 환경, 운영 환경에서 사용되는 인프라르 반복해서 구축할 때 유용하게 사용할 수 있다.

또한 콘솔에서 하나 하나 클릭해가며 인프라를 구성하게되면 설정해놓고 까먹는 부분이나, 놓치는 부분이 생길 수 있는데 테라폼은 코드로 먼저 선언해두고 그걸 바탕으로 인프라를 구성하게 되므로 상대적으로 안정적이다. 또한 설정을 리뷰받기도 편하고 깃을 통해 변경 이력을 관리할 수 있다는 점도 장점이다.

위에서 테라폼이 어떤 도구인지, 무슨 장점을 갖는지 알아보았으니 이제 GCP 콘솔로 관리하던 프로젝트을 테라폼으로 이전해보겠다.

먼저 아래 명령어로 테라폼을 설치한다.
```bash
brew tap hashicorp/tap
brew install hashicorp/tap/terraform
```

내 프로젝트는 이미 GCP에 배포되어있던 상태이므로 테라폼으로 관리하기 위해서는 지금 현재 정보 그대로 테라폼 파일로 변환해주는 과정이 필요하다.

따라서 GCP 구성을 바탕으로 아래와 같이 파일별로 도메인을 분리해서 설정을 나눠주었다.

```text
infra/terraform/production/
  versions.tf
  provider.tf
  compute.tf
  network.tf
  storage.tf
  iam.tf
```

`versions.tf`에는 Terraform과 Provider 버전을 고정한다. Provider 버전을 고정해두면 나중에 다른 환경에서 실행해도 같은 버전의 Provider를 사용하게 되어 예기치 않은 차이를 줄일 수 있다.

```hcl
terraform {
  required_version = ">= 1.6.0"

required_providers {
    google = {
      source  = "hashicorp/google"
      version = "7.23.0"
    }
  }
}
```

`provider.tf`에는 GCP 프로젝트와 기본 리전, zone을 설정한다.

```hcl
provider "google" {
  project = "my-gcp-project"
  region  = "asia-northeast3"
  zone    = "asia-northeast3-a"
}
```

그 다음 기존 VM, 방화벽, GCS 버킷, 서비스 계정을 Terraform resource로 작성했다. 여기서 중요한 점은 새 인프라를 만들기 위한 코드가 아니라, 이미 존재하는 인프라와 최대한 똑같은 코드를 작성해야 한다는 것이다. 그래야 import 이후 `terraform plan`을 실행했을 때 Terraform이 기존 리소스를 바꾸려고 하지 않는다.

운영 VM은 실수로 삭제되면 안 되므로 `prevent_destroy`도 같이 설정했다. 이 옵션을 주면 이 리소스를 삭제하려는 plan이 나오면 테라폼이 적용을 실패시킨다.

```hcl
resource "google_compute_instance" "app" {
  name         = "app-production-vm"
  machine_type = "e2-standard-2"
  zone         = "asia-northeast3-a"

tags = ["http-server", "https-server"]

lifecycle {
    prevent_destroy = true
  }
}
```

기존 리소스를 Terraform 코드로 작성한 뒤에는 바로 `terraform apply`를 실행하면 안 된다. 이미 존재하는 리소스를 Terraform state에 연결하는 `import` 과정이 먼저 필요하다.

```bash
terraform import google_compute_instance.app   projects/my-gcp-project/zones/asia-northeast3-a/instances/app-production-vm
```

`terraform import`는 실제 GCP 리소스를 수정하지 않는다. 단지 Terraform state에 “`google_compute_instance.app`은 GCP에 이미 존재하는 이 VM이다”라고 등록하는 작업이다. 실제 인프라가 코드 기준으로 변경되는 것은 `terraform apply`를 실행할 때다.

import가 끝나면 반드시 `plan`을 확인해야 한다.

```bash
terraform plan
```

이때 목표는 `No changes`에 가깝게 만드는 것이다. 만약 `destroy`, `replace`, `forces replacement` 같은 문구가 보이면 Terraform이 기존 리소스를 삭제하거나 재생성하려는 것이므로 절대 `apply`하면 안 된다. 이 경우에는 Terraform 파일이 실제 GCP 상태와 다르게 작성된 것이므로 HCL을 수정한 뒤 다시 `plan`을 확인해야 한다.

![image](https://api.openlog.kr/api/media/assets/82aa7086-72f9-4214-9669-289fd5017bc1)

import후 `terraform plan`의 수행결과가 no changes로 나온 모습이다. 이러면 현재 서버 구성과 IaC가 일치하는 상태가 됐다는 것이다.

Files changed

No changes yet.

Cancel