본문 바로가기
Infrastructure as Code/Terraform

[T101 Study 3주차] 상태 관리

by 코인선물로부자된다 2022. 11. 21.
반응형

Git : https://github.com/idealistchanu/study-T101Study/tree/main/CHAPTER3

[GitHub - idealistchanu/study-T101Study

Contribute to idealistchanu/study-T101Study development by creating an account on GitHub.

github.com](https://github.com/idealistchanu/study-T101Study/tree/main/CHAPTER2)

Terraform Backend 방법론

AWS S3, Azure Blob Storage, Google Cloud Storage, Consul, Postgres database 등

https://developer.hashicorp.com/terraform/language/settings/backends/local

[Backend Type: local | Terraform | HashiCorp Developer

Terraform can store the state remotely, making it easier to version and work with in a team.

developer.hashicorp.com](https://developer.hashicorp.com/terraform/language/settings/backends/local)

Terraform Backend Configuration

백엔드는 Terraform이 상태 데이터 파일을 저장하는 위치를 정의합니다.

Terraform은 지속형 상태 데이터를 사용하여 관리하는 리소스를 추적합니다. 대부분의 중요하지 않은 Terraform 구성은 Terraform Cloud와 통합 되거나 백엔드를 사용하여 상태를 원격으로 저장합니다. 이를 통해 여러 사람이 상태 데이터에 액세스하고 해당 인프라 리소스 모음에서 함께 작업할 수 있습니다.

  • 상태 파일은 배포할 때마다 변경되는 프라이빗 API private API로, 오직 테라폼 내부에서 사용하기 위한 것입니다.
  • 테라폼 상태 파일직접 편집하거나 직접 읽는 코드로 작성해서는 안됩니다.

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

  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
    • 테라폼 상태 파일의 모든 데이터는 평문으로 저장됨. 민감 정보가 노출될 위험.

3주차에서는 S3, Dynamo DB를 이용하여 Backend 구성하는 것을 실습한다.

Pre-Condition

DynamoDB 테이블 생성 : 테라폼에서 DynamoDB 잠금을 사용하기 위해서는 LockID 라는 기본 키가 있는 테이블을 생성

terraform init 시, backend 적용

Lock Time 을 걸어둘경우 다른 곳에서 변경 접근 시 아래의 이미지와 같이 에러가 발생한다.

버저닝된 파일 확인

local .tfstate 삭제 후, terraform apply, plan 실행 시 오류출력

알아두면 좋을 명령어

# S3 버킷 확인
aws s3 ls

# DynamoDB 테이블 생성 확인
aws dynamodb list-tables --output text
aws dynamodb describe-table --table-name terraform-locks | jq
aws dynamodb describe-table --table-name terraform-locks --output table

# 출력된 EC2 퍼블릭IP로 cul 접속 확인
MYIP=$(terraform output -raw myec2_public_ip)
while true; do curl --connect-timeout 1  http://$MYIP/ ; echo "------------------------------"; date; sleep 1; done

# [터미널1] S3 버킷 모니티렁
NICKNAME=gasida
while true; do aws s3 ls s3://$NICKNAME-t101study-tfstate --recursive --human-readable --summarize ; echo "------------------------------"; date; sleep 1; done

# 버저닝된 파일 확인
aws s3api list-object-versions --bucket gasida-t101study-tfstate | egrep "Key|VersionId|LastModified"

# S3 버킷에 객체 삭제
aws s3 rm s3://$NICKNAME-t101study-tfstate --recursive

# S3 버킷에 버저닝 객체 삭제 
aws s3api delete-objects \
    --bucket $NICKNAME-t101study-tfstate \
    --delete "$(aws s3api list-object-versions \
    --bucket "${NICKNAME}-t101study-tfstate" \
    --output=json \
    --query='{Objects: Versions[].{Key:Key,VersionId:VersionId}}')"

# S3 버킷에 삭제마커 삭제
aws s3api delete-objects --bucket $NICKNAME-t101study-tfstate \
    --delete "$(aws s3api list-object-versions --bucket "${NICKNAME}-t101study-tfstate" \
    --query='{Objects: DeleteMarkers[].{Key:Key,VersionId:VersionId}}')"

다룬 리소스

S3 (aws_s3_bucket, aws_s3_bucket_versioning)

Dynamo DB (aws_dynamodb_table)

Terraform Backend 의 단점

  • 테라폼의 backend 블록에는 변수나 참조를 사용 할 수 없음
  • 그 결과 S3 버킷 이름, 리전, DynamoDB 테이블 이름을 모두 테라폼 모듈에 수동으로 복사붙여녛어야 함, 심지어 key 값은 중복되면 안되며 고유하게 넣어야함
  • partial configuration 을 통해 일부 매개 변수를 전달해서 사용 할 수 있음
  • 다만, 이 경우에도 모듈마다 서로 다른 key 값을 설정해야 하기 때문에 key 매개 변수는 테라폼 코드에 있어야함
  • 부분적으로 구성한 것들을 모두 결합하려면 -backend-config 인수와 함께 terraform init 명령을 실행
    • terraform init -backend-config=backend.hcl
    • 위 단점을 보완해주는 오픈 소스 테라그런트(Terragrunt)가 있음.

TFaaS에 대해서

TFaaS (TerraForm-as-a-Service) team 이 존재하며, 테라폼으로 ‘클라우드’ 와 ‘온프렘’ 둘 다 관리 중

Architecture

CSP는 Azure 사용하며 GitOps 적용하며 Database에 state관리하고 Auth는 AD사용, Backend Storage를 사용하여 관리

Dropbox 사용하여 협업에 대한 효율을 추구