엉금엉금 테라폼 적용하기 (2) - MacOS에서 테라폼 설치 및 terraform 명령어 사용법

MacOS에서 테라폼 설치 및 terraform 명령어 사용법

 

Terraform

 

Mac M1 환경에서 테라폼을 설치하고 테라폼 파일의 코드를 파헤쳐보자

 

1.  설치

 

터미널 공식 홈페이지인 아래 링크에서 본인의 로컬 환경에 맞는 파일을 다운로드 받자.

 

https://developer.hashicorp.com/terraform/install

Install | Terraform | HashiCorp Developer

 

나는 Mac M1을 사용하고 있기 때문에 아래 명령어로 테라폼을 설치했다.

테라폼 홈페이지

 

아래 명령어를 터미널에 입력하면 설치 완료다.

brew tap hashicorp/tap
brew install hashicorp/tap/terraform

 

 

2. 설치 확인

 

설치가 성공적으로 이루어졌는지 확인하는 명령어는 아래와 같다.

terraform --version

 

테라폼 설치 확인 명령어 실행

 

이렇게 버전이 출력되면 설치가 완료된 모습이다.

 

 

3. 자동 완성 기능 설정 - 선택 사항

이부분은 선택 사항이다.

 

만약에 터미널에서 'terr' 까지만 치고 tab을 치면 자동으로 'terraform'이 완성되는 자동 완성 기능을 활성화하려면 다음 명령어를 사용하면 된다.

touch ~/.zshrc
terraform -install-autocomplete
cat ~/.zshrc

 

 

🔻 zshrc 파일과 zshrc 파일을 적용하는 명령어가 궁금하다면 아래 링크에 정리되어있다. 🔻

Mac M1에서 iTerm2 꾸미기 - 테마 변경, syntax highlighting 적용

Mac M1에서 iTerm2 꾸미기 - 테마 변경, syntax highlighting 적용

 

 

cat ~/.zshrc 명령어로 파일을 열고 스크롤을 내려서 제일 하단에 보여지는 코드에서 추가된 스크립트는 테라폼 명령어의 자동 완성을 활성화하는 내용을 포함하고 있다.

테라폼 자동완성 설정 추가된 zshrc 화면

 

이 스크립트는 주로 complete -C 형태의 명령어를 포함하며, 테라폼의 실행 가능한 명령어들이 자동으로 완성될 수 있도록 설정해준다.

 

이렇게 확인한 후, 변경사항이 적용되도록 터미널 세션을 새로 시작하거나 .zshrc 파일을 리로드해야 한다. 리로드는 아래 명령어로 수행할 수 있다. 이렇게 하면 테라폼의 자동 완성 기능이 활성화된다.

source ~/.zshrc

 

 

4. 테라폼 캐시 설정 - 선택 사항

이부분은 선택 사항이다.

 

테라폼 캐시 설정은 테라폼이 다운로드하는 프로바이더(Provider) 및 모듈(Module) 파일들을 중앙 위치에 저장하여, 여러 테라폼 프로젝트나 워크스페이스에서 재사용할 수 있도록 하는 기능이다. 이를 통해 네트워크 트래픽과 저장 공간을 절약할 수 있다.

 

캐시 설정의 필요성

 

테라폼은 기본적으로 각 프로젝트의 .terraform 디렉토리 안에 프로바이더와 모듈을 다운로드한다. 여러 프로젝트를 사용할 경우, 동일한 프로바이더와 모듈이 각 프로젝트 별로 중복 다운로드되어 저장 공간을 불필요하게 차지할 수 있다. 캐시 설정을 통해 이러한 파일들을 한 곳에 저장하여 관리하면, 중복 다운로드를 방지하고 더 효율적으로 저장 공간을 활용할 수 있다.

 

캐시 설정 과정

 

1. .terraformrc 파일 생성 및 편집

.terraformrc 파일은 테라폼의 사용자별 구성 파일이다. 이 파일을 통해 테라폼의 동작 방식을 사용자 정의할 수 있다. 다음 명령어는 사용자의 홈 디렉토리에 .terraformrc 파일을 생성하거나 편집하기 위해 vim 편집기를 사용하는 명령어다.

vim ~/.terraformrc

 

아래는 vim 편집기로 이동된 모습이다.

vim 편집기 모습

 

2. 캐시 디렉토리 설정

.terraformrc 파일 내에 캐시 디렉토리 경로를 설정한다.

plugin_cache_dir = "$HOME/.terraform.d/plugin-cache"

 

캐시 디렉토리 설정 명령어

 

이 명령어는 테라폼 프로바이더 및 모듈의 캐시 파일들을 저장할 디렉토리를 지정한다. 여기서 $HOME/.terraform.d/plugin-cache는 사용자의 홈 디렉토리 내에 'plugin-cache'라는 새로운 디렉토리를 사용한다는 의미다.

 

이렇게 작성하고 :wq를 쳐서 저장하고 나와준다.

 

3. 캐시 디렉토리 생성

설정한 캐시 디렉토리가 실제로 존재하는지 확인하고, 없다면 생성한다.

mkdir -p ~/.terraform.d/plugin-cache

 

캐시 디렉토리 확인 및 생성

 

mkdir -p 명령어는 지정된 경로에 디렉토리를 생성한다. 여기서 -p 옵션은 필요한 상위 디렉토리도 함께 생성하고, 이미 디렉토리가 존재하는 경우에는 오류 메시지를 출력하지 않도록 한다.

 

이 과정을 완료하면, 테라폼은 이후 다운로드하는 모든 프로바이더와 모듈을 지정된 캐시 디렉토리에 저장하게 된다. 이렇게 함으로써, 테라폼 프로젝트들 간에 공통적으로 사용되는 파일들을 중복 다운로드하지 않고 재사용할 수 있게 되어, 시간과 저장 공간을 절약할 수 있다.

 

 

5. 테라폼 실행 단계 - AWS CLI 설정

테라폼을 사용해 AWS 리소스를 관리하려면 AWS CLI 설정이 필수적이다. 테라폼은 프로비저닝 및 관리 과정에서 AWS CLI를 통해 AWS 서비스와 통신하게 된다. 이를 통해, 테라폼은 AWS의 다양한 리소스에 접근하고, 이를 생성, 수정, 삭제하는 등의 작업을 수행할 수 있다.

 

IAM 계정 생성 및 AWS Access Key 발급

 

AWS 리소스를 테라폼과 연동하기 위해서는 먼저 AWS 관리 콘솔에서 IAM 사용자를 생성해야 한다. (테라폼으로 IAM 계정을 생성하는 방법도 있지만 일단 나는 AWS 콘솔에서 진행했다.)

 

생성 과정에서 사용자에게 필요한 권한을 부여한다. 나는 기존에 'AdministratorAccess' 정책을 가진 계정이 있어서 그걸 그대로 사용했다. 그러나 이 정책은 사용자에게 거의 모든 AWS 서비스에 대한 완전한 접근 권한을 제공하기때문에 보안상의 이유로 필요한 서비스에 대해서만 세분화된 권한을 부여하는 것이 바람직하다.

 

사용자 생성이 완료되면, 이 사용자를 위한 'Access Key ID'와 'Secret Access Key'를 발급받는다. 이 키들은 테라폼이 AWS 서비스에 접근할 때 사용되므로, 안전하게 보관하고 필요할 때만 사용해야 한다. (잃어버리지 않도록 잘 저장해놓거나, csv 파일로 다운로드 받을 수 도 있다.)

 

AWS CLI 버전 확인 및 설정

 

만약 AWS CLI가 설치가 안되어있다면 아래 링크에서 설치 가능하다.

최신 버전의 AWS CLI 설치 또는 업데이트 - AWS Command Line Interface

 

터미널에 다음 명령어를 실행한다.

aws --version
aws configure list

 

aws cli 버전 확인 및 설정 확인

 

만약 AWS configure 설정 안되어있다면

 

만약 AWS Configure 설정이 안되어있다면 직접 설정해줘야한다.

 

우선, 아래 명령어를 터미널에 입력한다.

aws configure

 

그리고 시스템이 AWS Access Key ID를 요청하면, 생성한 IAM 사용자의 Access key ID를 입력한다.

AWS Secret Access key를 요청하면, Secret access key를 입력한다.

Default region name을 요청하면, 기본적으로 사용할 AWS 리전(예: us-west-2, ap-northeast-2 등)을 입력한다.

Default output format을 요청하면 출력 포맷(예: json, text, table 등)을 입력한다.

$ aws configure
AWS Access Key ID [None]: TESTACCESSKEYID1234567
AWS Secret Access Key [None]: TESTSECRETACCESSKEY1234567890abcdef
Default region name [None]: ap-northeast-2
Default output format [None]: json

 

Access key ID와 Secret access key는 매우 민감한 정보다. 안전하게 관리하고 절대로 공개되지 않도록 주의해야 한다.

 

필요에 따라 다른 AWS 계정이나 환경에 대해 다른 프로필을 설정할 수 있다. 이를 위해서는 아래 명령어를 사용할 수도 있다.

aws configure --profile [프로필명]

 

이렇게 테라폼을 실행하기 전에 AWS 계정을 연결하는 이유

 

AWS 계정을 테라폼과 연결하는 이유는 로컬 환경에서 AWS 리소스에 안전하고 효율적으로 접근하기 위함이다.

주요 목적은 다음과 같다:

 

• AWS 자격 증명 제공: 'aws configure'를 설정함으로써, AWS 액세스 키와 시크릿 액세스 키가 로컬 환경에 저장된다. 테라폼은 이 자격 증명을 활용해 AWS API에 접근하고, 리소스를 생성, 수정, 삭제하는 작업을 수행한다.
• 보안 유지: 테라폼 코드 내에 직접적으로 AWS 자격 증명을 포함시키지 않음으로써, 코드의 보안을 유지할 수 있다. 자격 증명이 코드에 포함되면, 코드가 외부에 노출되었을 때 보안 문제가 발생할 수 있다.
• 환경 분리: 다양한 AWS 계정이나 환경을 관리하는 개발자에게 'aws configure'는 각 환경에 맞는 다른 자격 증명을 쉽게 설정하고 전환할 수 있는 방법을 제공한다. 이는 개발, 테스트, 운영 환경을 분리하여 관리하는 데 큰 도움이 된다.
• 자동화와 통합 용이: AWS CLI 자격 증명 설정은 스크립트나 다른 자동화 도구와의 통합을 용이하게 하여, 테라폼 작업을 자동화하는 데에 유리하다. 이는 복잡한 인프라스트럭처 관리 작업을 간소화하는 데에 큰 장점을 제공한다.

 

결론적으로, 'aws configure'는 로컬에서 테라폼을 사용하여 AWS 리소스를 관리할 때 중요한 도구로, 안전하고 편리하게 자격 증명을 제공한다.

 

 

6. 테라폼 실행 단계 - 코드 작성하기

 

💡 vsCode에는 테라폼 코드를 작성하기 적합한 플러그인이 있다. 나는 Terraform 플러그인과 HashiCorp Terraform 플러그인을 설치해서 테라폼 코드를 작성했다.

 

vsCode에서 테라폼 관련 플러그인

 

Terraform 플러그인

이 플러그인은 Terraform 코드의 문법을 강조하고, 자동 완성 기능을 제공하여 Terraform 코드 작성을 더 편리하게 해준다. 또한, Terraform plan 및 apply와 같은 명령을 VS Code 내에서 직접 실행할 수 있게 해준다.

 

HashiCorp Terraform 플러그인

이 플러그인은 HashiCorp에서 직접 제공하는 공식 VS Code 확장이다. 이 플러그인은 Terraform의 HCL(HashiCorp Configuration Language)에 대한 더 향상된 지원을 제공한다. 예를 들어, HCL 구문 강조, 자동 완성, Terraform 파일 내의 리소스 및 데이터 소스에 대한 문서 링크 등의 기능을 포함하고 있다.

 

 

테라폼 코드를 작성하는 방법은 여러가지가 있다. 그중에서 main.tf라는 파일에 모든 코드를 작성하는 방법이 있고, 각각의 리소스들을 파일로 묶어서 모듈화 시키고 이를 모듈화 외부에 존재하는 main.tf에서 이를 가져다가 쓰는 방법이 있다. 일단 두가지 간략하게 설명해보겠다.

 

하나의 파일에 모든 코드를 작성하는 경우

 

만약 모든 테라폼 코드를 단일 파일에 작성한다면, 보통은 main.tf라는 파일 하나에 모든 것을 넣게 된다.

# AWS 프로바이더 설정
provider "aws" {
  region = "us-west-2"
}

# EC2 인스턴스 생성을 위한 리소스
resource "aws_instance" "my_instance" {
  ami           = "ami-123456"  # 예시 AMI ID
  instance_type = "t2.micro"

  tags = {
    Name = "MyExampleInstance"
  }
}

 

provider "aws"

AWS 클라우드 서비스를 사용하기 위한 선언이다. 여기서 provider는 테라폼의 예약어로, 특정 클라우드 제공자를 지정하는 데 사용된다. aws는 AWS 프로바이더를 나타내며, 이는 사용자가 AWS 대신 다른 클라우드 서비스를 사용하고자 할 때 변경될 수 있다.

 

region = "us-west-2"

AWS의 리전을 선택하는 부분이며, 필요에 따라 다른 리전으로 변경할 수 있다.

 

resource "aws_instance" "my_instance"

AWS에서 EC2 인스턴스를 생성하기 위한 리소스 정의이다. 여기서 resource는 테라폼의 예약어로, 관리할 리소스의 타입과 이름을 지정하는 데 사용된다. "aws_instance"는 EC2 인스턴스 리소스를 나타내고, "my_instance"는 사용자가 정의한 이 인스턴스의 이름이다. 이 이름은 사용자가 원하는 대로 변경할 수 있다.

 

ami = "ami-123456"

이부분은 사용할 Amazon Machine Image(AMI)의 ID를 지정하는 부분이다. 이 ID는 AWS에서 제공하는 이미지 중 하나를 선택하거나, 사용자가 생성한 이미지의 ID일 수 있다.

 

  💡 ami에 어떤 값을 넣어야 하는가?

AMI (Amazon Machine Image)는 AWS에서 EC2 인스턴스를 시작할 때 사용하는 템플릿으로, 운영 체제(OS), 애플리케이션 서버 및 애플리케이션 소프트웨어를 포함한 사전 구성된 정보의 세트를 담고 있다. ami = "ami-123456" 부분에서 지정하는 AMI ID는 인스턴스에 사용될 특정 운영 체제와 구성을 결정한다.

예를 들어, 만약 AMI가 Ubuntu, CentOS, 또는 Amazon Linux와 같은 리눅스 배포판을 기반으로 한다면, 생성되는 EC2 인스턴스도 해당 리눅스 배포판을 실행하게 된다. 반면에, Windows 기반 AMI를 선택하면 인스턴스는 Windows 운영 체제를 실행하게 된다.

AWS는 다양한 운영 체제 및 구성을 가진 표준 AMI를 제공한다. 사용자는 이 중에서 필요에 맞는 것을 선택할 수 있다. 또한, 사용자는 자신만의 AMI를 생성하여 특정 소프트웨어, 구성, 운영 체제 설정이 미리 설치된 인스턴스를 빠르게 시작할 수 있다.

ami-123456는 예시로 사용된 AMI ID이며, 실제 환경에서는 해당 운영 체제 및 구성 요구 사항에 맞는 적절한 AMI ID로 변경해야 한다. 이러한 선택은 인스턴스의 운영 체제 및 필요한 소프트웨어 환경을 결정하는 데 중요한 부분이다.

 

 

instance_type = "t2.micro"

인스턴스의 유형을 지정하며, 이는 요구 사항에 맞게 다른 유형으로 변경될 수 있다.

 

tags

태그 부분은 인스턴스에 메타데이터를 추가하기 위해 사용된다. 여기서 Name = "MyExampleInstance"는 인스턴스에 Name이라는 태그를 할당하고, 그 값으로 MyExampleInstance를 사용한다. 이 태그와 값은 사용자가 자유롭게 정의하며, 리소스를 쉽게 식별하고 관리할 수 있게 해준다.

 

이 코드는 AWS에서 EC2 인스턴스를 간단히 생성하는 기본적인 예시로, 실제 사용 시에는 보다 복잡한 설정, 변수 사용, 출력 값 설정 등이 포함될 수 있다. 이러한 기본 구조를 이해하는 것은 테라폼을 사용한 인프라 관리의 첫걸음이다.

 

모듈화를 사용하는 경우

 

테라폼 프로젝트가 커짐에 따라, 코드를 여러 파일로 나누는 것이 필요해진다. 이때 모듈화는 큰 도움이 된다. 모듈은 특정 기능이나 구성을 캡슐화하여 재사용하기 쉽게 하며, 각각의 디렉토리에 필요한 파일들(main.tf, outputs.tf, variables.tf)을 가지고 있다.

 

우리 프로젝트는 테라폼을 이용해 ECS 클러스터 생성, 서비스 생성, 태스크 정의 생성, ALB 연동, ASG 생성 등 다양한 작업을 진행하고 있어서 모듈화로 구성했다. 해당 내용은 다음 글에서 상세하게 설명하겠다.

 

이 디렉토리 구성은 modules/example_modules 안에 모듈을 작성하고 외부에 이 모듈을 실제로 사용하는 main.tf가 있는 모습이다. 

모듈을 사용하는 테라폼 폴더 구조

모듈 디렉토리의 구성

 

모듈 디렉토리는 다음과 같이 구성된다:

• main.tf: 이 파일은 모듈의 핵심 리소스와 로직을 정의한다. 예를 들어, AWS EC2 인스턴스 생성 코드가 여기에 포함될 수 있다.
• outputs.tf: 생성된 리소스에 대한 정보를 외부로 출력한다. 이 정보는 다른 테라폼 모듈이나 사용자에게 중요한 정보를 제공한다.
• variables.tf: 테라폼 코드에서 사용할 변수들을 정의한다. 변수를 정의함으로써, 코드의 재사용성과 유지보수성이 향상된다.

이 모듈 디렉토리를 /modules/example_module 이라고 가정해보자.

 

1. main.tf (모듈 내부)

 

이 파일은 모듈의 핵심 리소스와 로직을 정의한다. 예를 들어, 다음 코드는 AWS에서 EC2 인스턴스를 생성한다:

provider "aws" {
  region = var.region
}

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "ExampleInstance"
  }
}

 

여기서 provider "aws"는 AWS를 프로바이더로 설정하고, region은 입력 변수로부터 값을 받는다. resource "aws_instance" "example"은 EC2 인스턴스를 생성하며, AMI와 인스턴스 타입 등을 설정한다.

 

2. outputs.tf (모듈 내부)

 

이 파일은 모듈이 생성한 리소스에 대한 정보를 외부로 출력한다.

output "instance_ip_addr" {
  value = aws_instance.example.public_ip
  description = "The public IP address of the EC2 instance."
}

 

이 코드는 EC2 인스턴스의 공용 IP 주소를 출력한다. 이 값은 모듈을 사용하는 다른 코드에서 참조될 수 있다.

 

3. variables.tf (모듈 내부)

 

이 파일은 모듈에서 사용할 변수를 정의한다.

variable "region" {
  description = "The AWS region to create resources in."
  default     = "us-west-2"
}

variable "instance_type" {
  description = "The type of instance to start."
  default     = "t2.micro"
}

 

여기서 variable "region"과 variable "instance_type"은 AWS 리전과 인스턴스 타입을 위한 변수를 정의한다. 이 변수들은 main.tf에서 사용될 수 있다.

 

모듈을 호출하는 외부 main.tf

 

프로젝트의 루트 또는 다른 디렉토리에 있는 main.tf 파일은 위에서 작성한 모듈을 실제로 호출하고 사용한다. 이 파일에서는 모듈에 필요한 입력 값을 설정하고, 모듈에서 제공하는 출력 값을 사용한다:

module "example_module" {
  source = "./modules/example_module"
  region = "us-east-1"
  instance_type = "t2.micro"
}

output "external_instance_ip" {
  value = module.example_module.instance_ip_addr
}

 

여기서 module "example_module"은 모듈을 정의하고, source는 모듈의 위치를 나타내며, region과 instance_type 같은 필수 입력 변수들을 제공한다.

 

만약 호출된 모듈에서 생성된 데이터를 외부에서 사용하고 싶다면, 그 때 output을 사용할 수 있다. 예를 들어, 모듈이 생성한 리소스의 IP 주소나 다른 중요한 정보를 외부에서 참조하고 싶을 때 사용할 수 있다.. 하지만 이것은 필수 사항은 아니고, 필요에 따라 사용하는 것이다.

 

이렇게 모듈 내부의 각 파일과 모듈 디렉토리 외부의 main.tf 파일이 상호 작용하면서, 테라폼 코드의 체계적인 관리와 재사용성을 높여준다.

 

결론

 

모듈 디렉토리는 특정 기능을 캡슐화하는 파일들(main.tf, variables.tf, outputs.tf)을 포함한다. 프로젝트의 main.tf 파일은 이 모듈들을 호출하고, 모듈의 입력과 출력을 관리한다. 이렇게 모듈과 메인 프로젝트 파일을 분리함으로써, 코드의 재사용성과 관리의 용이성을 향상시킬 수 있다.

 

모듈을 사용하는 방식은 코드를 더 체계적이고 관리하기 쉽게 만든다. 모듈을 호출하는 외부 main.tf에서 올바른 값을 제공해야 모듈이 제대로 작동한다는 점도 중요하다.

 

 

7. 테라폼 실행 단계 - 명령어로 실행

 

1. 테라폼 프로젝트 디렉토리 설정

 

첫 번째 단계는 테라폼 코드가 있는 디렉토리로 이동한다.

만약 당신의 테라폼 프로젝트가 ~/my-terraform-project에 위치해 있다면, 다음과 같이 입력한다:

cd ~/my-terraform-project

 

2. 테라폼 초기화 및 실행 계획 확인

 

이 단계에서는 두 가지 작업을 수행한다.

• 초기화 (terraform init): 이 명령어는 테라폼 프로젝트를 초기화하고 필요한 테라폼 모듈과 플러그인을 다운로드한다. 이는 프로젝트를 처음 시작할 때 또는 프로바이더 설정을 변경할 때 필요하다.

다음은 terraform init 명령어를 실행한 터미널 모습이다. 결과적으로 Terraform이 성공적으로 초기화되었음을 알 수 있고, 다음 단계로 넘어갈 준비가 되었다는 내용이다.

terraform init 명령어 실행

 

 

• 실행 계획 확인 (terraform plan): terraform plan 명령어는 테라폼이 수행할 변경사항을 미리 보여준다. 이는 실제 리소스를 생성하거나 변경하기 전에 어떤 작업이 수행될지 미리 확인할 수 있는 유용한 단계다.

terraform plan 명령어 실행

terraform plan 명령어 실행 결과

 

다음은 terraform plan 명령어를 실행한 터미널 모습이다. 

terraform plan 명령어의 결과인 'Plan: 1 to add, 0 to change, 0 to destroy.'는 현재 Terraform 코드를 기반으로 해서 인프라에 새롭게 추가할 자원이 하나 있고, 변경하거나 제거할 자원은 없다는 것을 의미한다.

• Plan: 1 to add: 새로운 AWS 인스턴스가 생성될 예정임을 의미한다. 여기서 '1 to add'는 Terraform이 실행될 때 인프라에 새롭게 추가될 자원의 수를 나타낸다.
• Changes to Outputs: 'external_instance_ip' 출력값이 추가될 예정임을 의미한다. 이 값은 terraform apply가 실행된 후에 인스턴스의 실제 IP 주소로 해석되어 사용자에게 표시된다.

마지막 주의 사항은 -out 옵션을 사용하지 않았기 때문에, 이 계획을 나중에 다시 사용하려면 terraform apply를 실행할 때 정확히 같은 조치를 보장받을 수 없다는 내용이다. 계획을 파일로 저장하고 싶다면, terraform plan -out=somefile을 사용해서 실행한 계획의 결과를 파일로 저장할 수 있다. 그러면 이 파일을 사용하여 terraform apply 명령을 실행할 때 동일한 변경 사항을 적용할 수 있게 된다.

 

3. 계획 적용

 

코드를 실행하는 단계에서는 terraform apply 명령어를 사용한다. 이 명령은 테라폼이 계획한 대로 실제 클라우드 리소스를 생성하거나 변경한다. 이 과정에서 사용자의 승인이 요구될 수 있다.

terraform apply 명령어 실행

terraform apply 실행 결과 화면

 

terraform apply의 결과 내용으로 Terraform은 계획대로 '1 to add, 0 to change, 0 to destroy'의 작업을 수행할 것이며, 현재 어떠한 변경도, 제거도 필요하지 않다고 알려주고 있다.

 

마지막으로, Terraform은 실제로 이 변경 사항을 적용하기 전에 사용자의 승인을 요청하고 있다. 'yes'를 입력하면 Terraform이 리소스를 생성하고, 아무 것도 입력하지 않거나 'no'를 입력하면 아무런 작업도 수행되지 않는다.

 

이제 'yes'를 입력하기만 하면, 계획된 인스턴스가 AWS에 성공적으로 생성되고, 그 결과로 인스턴스의 IP 주소를 포함한 모든 세부 정보를 알 수 있게 된다.

 

terraform apply 하고 로컬에서 테라폼 코드를 수정해도 수정된 내용이 자동으로 반영되지 않는다.

 

변경사항을 적용하기 위해서는 다음과 같은 단계를 거쳐야 한다:

- 코드 수정: 먼저, 로컬에서 테라폼 코드를 수정한다. 이 수정은 `.tf` 파일 내에서 리소스 정의나 설정을 변경하는 것을 포함할 수 있다.

- terraform plan 실행: 수정한 후에는 `terraform plan` 명령어를 실행해야 한다. 이 단계는 수정된 코드가 실제로 어떤 변경을 가져올지 시뮬레이션하여 보여준다. 이는 변경사항을 적용하기 전에 어떤 리소스가 생성, 변경, 삭제될지 확인할 수 있는 중요한 단계다.

- terraform apply 실행: `terraform plan`에서 확인한 변경사항이 올바른 것으로 확인되면, `terraform apply` 명령어를 실행하여 실제 클라우드 환경에 변경사항을 적용한다. 이 단계에서도 사용자의 승인이 요구될 수 있다.

이 과정을 통해 로컬에서의 코드 변경사항이 실제 클라우드 인프라에 반영된다. 따라서 코드를 수정한 후에는 항상 `terraform plan`과 `terraform apply` 단계를 거쳐야 한다. 이는 안전하게 인프라 변경을 관리하는 데 필수적인 절차다.

 

4. 변경사항 삭제

 

마지막으로, 생성된 리소스를 제거할 때는 terraform destroy 명령어를 사용한다. 이 명령어는 .tfstate 파일을 참조하여 관리하는 모든 리소스를 삭제한다.

 

중요한 개념들

• .tfstate 파일: 이 파일은 테라폼이 관리하는 리소스의 현재 상태를 저장한다. 이 파일은 매우 중요하므로 안전하게 관리되어야 한다.
• 테라폼 모듈과 프로바이더: 테라폼은 다양한 클라우드 제공자(예: AWS, Azure, GCP 등)를 지원하기 위해 프로바이더 플러그인을 사용한다. 또한 코드 재사용을 위해 모듈을 사용할 수 있다.

이러한 단계를 따르면 테라폼을 통해 인프라를 관리하는 과정이 훨씬 수월해질 것이다.

 

 

이렇게 테라폼의 기본 설치 및 설정 방법을 자세히 살펴보았다. 이 단계들은 어떤 클라우드 인프라 프로젝트를 시작하기 전에 필수적인 기초 작업들이다.

 

다음 글에서는 이 기초 위에 더욱 발전시켜, 실제로 우리 프로젝트에서 어떻게 테라폼을 적용하고 모듈화한 코드를 구성했는지를 구체적으로 다룰 예정이다.

 

 

이 포스트는 Team chillwave에서 사이드 프로젝트 중 적용했던 부분을 다시 공부하며 기록한 것입니다.

시간이 괜찮다면 팀원 '개발자의 서랍'님의 블로그도 한번 봐주세요 :)

개발자의 서랍