[T101_3기] 1주차 - Terraform 설명 및 환경 구성 (2/2) - 도전 과제

본 시리즈는 가시다님의 T101(테라폼으로 시작하는 IaC) 3기 진행 내용입니다. (가시다님 노션)

 

도서 정보

https://www.yes24.com/Product/Goods/119179333

테라폼으로 시작하는 IaC - 예스24

실습 코드

https://github.com/terraform101

 

목차

1. Terraform 설명 및 환경 구성 (링크)
2. 도전 과제

 

 

---

2. 도전 과제

 

 

 

 

[도전과제1] EC2 웹 서버 배포 + 리소스 생성 그래프 확인

Ubuntu에 apache(httpd)를 설치하고 index.html 생성(닉네임 출력)하는 userdata를 작성해서 설정 배포 후 웹 접속 - 해당 테라폼 코드(파일)를 작성

제공해 주신 hashicat-azure를 사용하여 테스트

(Azure 계정이 이미 있기에 환경 구성은 생략)

 

그래프 확인

앞서 간단한 aws EC2를 만들었을 때와 달리 많은... 내용들이 출력된다.

실무에 적용했을 때 그래프 명령을 쳐서 보기 두렵지만, 다른 엔지니어들과 일하며 소통하기에 좋을 테니 익혀둬야겠다.

 

배포 확인

 

서비스 확인

이 예제가 상당히 좋았던 부분은 Azure에서는 Public IP에 DNS 이름 레이블을 통해 <Region>.cloudapp.azure.com 도메인을 사용해서 굳이 Public IP를 조회하지 않더라도 도메인 주소를 통해 접속이 가능한데, 이 부분도 테라폼에서 잘 지정해 줬다.

 

 

[도전과제2] AWS S3/DynamoDB 백엔드

Azure의 Blob Storage로 진행

Azure Storage Account - Container

 

팀 단위에서 테라폼 운영 시 문제점

1. 상태 파일을 저장하는 공유 스토리지 Shared storage for state files
   • 각 팀원이 동일한 테라폼 상태 파일 사용을 위해서, 공유 위치에 저장이 필요
2. 상태 파일 잠금 Locking state files
   • 잠금 기능 없이 두 팀원이 동시에 테라폼 실행 시 여러 테라폼 프로세스가 상태 파일을 동시에 업데이트하여 충돌 가능(경쟁 상태 race condition)
3. 상태 파일 격리 Isolating state files
   • 예를 들면 테스트 dev 와 검증 stage 과 상용 prodction 각 환경에 대한 격리가 필요

상태 파일 공유로 버전 관리 시스템 비추천

1. 수동 오류 Manual error
   • 테라폼을 실행하기 전에 최신 변경 사항을 가져오거나 실행하고 나서 push 하는 것을 잊기 쉽습니다(?).
   • 팀의 누군가가 이전 버전의 상태 파일로 테라폼을 실행하고, 그 결과 실수로 이전 버전으로 롤백하거나 이전에 배포된 인프라를 복제하는 문제가 발생 할 수 있음.
2. 잠금 Locking
   • 대부분의 버전 관리 시스템은 여러 명의 팀 구성원이 동시에 하나의 상태 파일에 terraform apply 명령을 실행하지 못하게 하는 잠금 기능이 제공되지 않음.
3. 시크릿 Secrets
   • 테라폼 상태 파일의 모든 데이터는 평문으로 저장됨. 민감 정보가 노출될 위험.

 

※ 사전에 해당 RG와 Storage Account, Container가 존재해야 함.

(이 부분도 terraform으로 배포해보자)

terraform {

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = ">=3.41.0"
    }
  }
}

provider "azurerm" {
  features {
    resource_group {
      prevent_deletion_if_contains_resources = false
    }
  }
}


resource "azurerm_resource_group" "example" {
  name     = "netcloudy-rg"
  location = "Korea Central"
}

resource "azurerm_storage_account" "example" {
  name                     = "netcloudytfstate"
  resource_group_name      = azurerm_resource_group.example.name
  location                 = azurerm_resource_group.example.location
  account_tier             = "Standard"
  account_replication_type = "GRS"

  tags = {
    environment = "dev"
    name = "NetCloudy"
  }
}

※ 이 작업 이후 Container는 따로 만들어줘야 한다.

Container명 : tfstate

 

https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/storage_account

Terraform Registry

 

 

backend를 이렇게 걸어주자.

파일을 받아서 내용 확인해보자 (Blob Storage명과 파일 명이 다른 건 중간에 바꿔서...)

 

그럼 이 상태에서 backend를 잡아두고 terraform을 통해 Azure 리소스들을 배포해보자.

(위에서 고생해준 고양이를 다시 한번 배포)

배포되는 중에도 tfstate가 실시간으로 변경된다.

+ 아쉽게도 Azure는 백엔드를 통해 상태 잠금 및 일관성 검사를 수행할 수 있는 서비스 연동이 없다.

AWS의 DynamoDB가 Azure에서는 CosmosDB인데 왜 연동은... 안되는지 궁금하다.

 

 

 

결론

좋은 책과 스터디를 만났으니, 열심히 갈고 닦자!