[T101 Study 7주차] 프로덕션 수준의 테라폼 코드

tfenv 설치 : 테라폼 버전 관리 툴

# 설치
brew install tfenv

# 설치 가능 버전 확인
tfenv list-remote | head

# 현재 설치된 버전 확인
tfenv list

# 특정 버전 설치
#(옵션) export TFENV_ARCH=arm64  # mac Apple silicon M1/M2
tfenv install 1.2.3

# 특정 버전 사용
tfenv use 1.2.3 

# 테라폼 버전 확인
terraform version

EC2, ALB, RDS Monitoring

## EC2
while true; do aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output text ; echo "------------------------------" ; sleep 1; done

## ALB
ALBDNS=$(terraform output -raw alb_dns_name)
while true; do curl --connect-timeout 1  http://$ALBDNS/ ; echo; echo "------------------------------"; date; sleep 1; done

## RDS
while true; do aws rds describe-db-instances --query "*[].[Endpoint.Address,Endpoint.Port,MasterUsername]" --output text  ; echo "------------------------------" ; sleep 1; done

프로덕션 수준의 인프라란 ?

• 서버, 데이터 저장소, 로드 밸런서, 보안 기능, 모니터링 및 경고 도구, 파이프라인 구축 및 비즈니스 운영에 필요한 기타 모든 기술을 의미 + 이중화 및 장애 대응 가능

오랜 시간이 걸리는 이유

1. 데브옵스 산업이 성숙되지 않음
   • 아직 산업의 초기 단계이며, ‘Cloud Computing, IaC, DevOps, Docker, k8s’ 등 도구의 출현과 기술이 빠르게 변하고 있으면 충분히 성숙되지 않았음
2. 어떤 목적을 달성하기 위해 원래 목적과 전혀 상관없는 일들을 계속해야 하며 그중 마지막 작업에 해당함
3. 수행해야 하는 작업의 체크 리스트가 너무 많다
   • 문제는 대다수 개발자가 체크 리스트에 있는 대부분의 항목을 알지 못하기 때문에 프로젝트를 평가할 때 중요하고 시간이 많이 걸리는 세부 사항을 잊어버린다

프로덕션 수준 인프라 체크 리스트

프로덕션 수준 인프라 모듈

• 소형 모듈 Small modules
• 합성 가능한 모듈 Composable modules
• 테스트 가능한 모듈 Testable modules
• 릴리스 가능한 모듈 Versioned modules
• 테라폼 모듈 외의 것들 Beyond Terraform modules

소형 모듈

대형 모듈 단점 : 상태 파일 격리에서 알아본 것처럼 ‘개발-스테이징-프로덕션’ 모든 인프라 환경을 단일 파일 또는 단일 모듈로 정의하는 것을 좋지 않을뿐더러 유해한 것으로 간주함

• 속도가 느림 slow : 모든 인프라가 하나의 모듈에 정의되어 있으면 명령 실행 시 오래 걸림. terraform plan 시 20분 걸리기도 함
• 안전하지 않음 insecure : 모든 인프라가 하나의 모듈에 정의되어 있으면 어떤 것을 변경하려면 모든 액세스 권한이 필요함.
  • 따라서 모든 사용자가 관리자 권한이 필요하여 최소 권한 원칙 principle of least privilege 에 위배
• 위험성이 높음 risky : 예를 들어 스테이징 환경에서 프런트엔드 앱을 변경 시 오타나 잘못된 명령으로 프로덕션 데이터베이스를 삭제할 수 있다
• 이해하기 어려움 understand : 한 곳에 코드가 많을수록 한 사람이 모든 것을 이해하기가 더 어려워짐.
• 리뷰하기 어려움 review : 수집 줄의 코드로 구성된 모듈을 리뷰하는 것으 쉽지만, 수천 줄의 코드로 구성된 모듈을 리뷰하는 것은 거의 불가능하다.
  • terraform plan 실행 시 오래 거리고, plan 명령의 출력이 수천 줄이며 아무도 코드를 읽으려 하지 않는다.
  • 이 경우 데이터베이스가 삭제될 것임을 나타내는 빨간색 코드를 누구도 발견하지 못할 수도 있습니다.
• 테스트하기 어려움 test : 인프라 코드 테스트는 어렵다. 다음 장에서 살펴볼 예정

방안 : 소형 모듈로 코드를 작성, 클린 코드 Clean Code 내용

• 함수의 첫 번째 규칙은 작어야 한다는 것입니다. The first rule of functions is that they should be small.
• 함수의 두 번째 규칙은 그보다 더 작아야 한다는 것입니다. The second rule of functions is that they should be smaller than that.

합성 가능한 모듈

재사용 가능하고 합성 가능한 모듈

• 외부에서 상태를 읽는 대신 입력 매개 변수를 통해 전달하고, 외부에 상태를 쓰는 대신 출력 매개 변수를 통해 계산 결과를 반환
• 모든 것을 입력 변수를 통해 전달하고 모든 것을 출력 변수를 통해 반환하며 간단한 모듈들을 결합해 더 복잡한 모듈을 만들수 있다.
• 실제 사용 시에는 더 나은 합성과 재사용을 위해 아래 실습 내용 보다 모듈을 더욱 세분화해야 할 수도 있습니다.

테스트 가능한 모듈

릴리스 가능한 모듈

Validations : 테라폼 0.13 validation blocks 은 입력 변수를 체크

• 아래는 instance_type 으로 t2.micro 와 t3.micro 만 사용할 수 있게 설정

버전 Versioned Modules : 오늘 실행하던, 3년 후에 실행하던 동일한 결과를 얻을 수 있어야 한다!

• 두 가지 유형 버전 고려 : Versioning of the module’s dependencies , Versioning of the module itself
• Versioning of the module’s dependencies : Terraform core, Providers, Modules
  • Terraform core : The version of the terraform binary you depend on → 테라폼 실행 파일 버전
  • Providers : The version of each provider your code depends on, such as the aws provider → 프로바이더 버전
  • Modules : The version of each module you depend on that are pulled in via module blocks → 모듈 버전
• Terraform core 고정 : required_version 사용

테라폼 모듈 외의 것들

• Provisioners
• Provisioners with null_resource
• External data source