확장 가능한 테라폼 코드 관리를 위한 원칙
테라폼 모듈을 사용하라
외부 모듈을 사용하지 마라
모듈의 버전을 관리하라
두 종류의 테라포 모듈을 관리하라
코드와 데이터를 분리하라
하나의 워크스페이스에 모든 것을 담지 마라
워크스페이스간의 의존성을 관리하라
모든 것을 테라폼으로 관리하려하지마라
확장 가능한 코드..?
읽어야 하는 코드의 양이 적다 (가독성)
수정해야 하는 코드의 양이 적다 (유지보수)
테라폼 모듈을 사용하라
1. 중첩 루프
nested loop를 직접 짜면 어려운데 모듈 쓰면 간단하다.
2. 캡슐화
객체의 모듈화가 잘 이뤄지면 모듈 단위의 재사용이 매우 용이하다.
-> 간편한 유지보수
외부 모듈을 사용하지 마라
테라폼 레지스트리
외부에 공개된 테라폼 모듈
github :
terraform-aws-modules
cloud posse
tedilabs
모듈에 심각한 보안 문제점을 찾아 당장 고쳐야 한다면?
AWS 프로바이더 신규 버전에서 추가된 기능을 적용하고 싶은데, 모듈 내에 추상화 되어 건들 수가 없다면?
리소스에서는 지원해주는 기능인데, 모듈에서 해당 기능에 대한 인터페이스를 제공해주지 않고 있다면?
-> 외부의 테라폼 모듈을 바로 사용하게 될 경우, 코드의 통제권이 조직 내에 없어 여러 문제를 겪을 수 있다.
해결책
1. DIY
조직 내에서 직접 테라폼 모듈을 설계하고 작성하여 관리
2. Use after fork
외부 모듈을 사용하고자 한다면 조직 내부에 복제 후 사용
-> 테라폼 모듈을 직접 작성하거나, 외부 모듈의 복제본을 사용하여 코드의 통제권을 조직에서 가지고 있어야 한다.
모듈의 버전을 관리하라
테라폼 모듈을 로컬 파일 경로를 통해 사용하면 편리하지만 모듈의 버전을 선택 할 수 없다.
이때, 여러 워크스페이스에서 사용중인 로컬 모듈에 잘못된 수정을 한다면?
그럼 전체 모듈에 영향을 끼치게 되고 생각지 못한 부작용이 생길 수 있다.
-> Git, 테라폼 레지스트리, 테라폼 클라우드 등 원격 모듈을 사용한다면 특정 버전의 모듈을 사용하도록 지정할 수 있다.
각 워크스페이스에서 원격 모듈의 특정 버전을 사용한다면 모듈을 변경하더라도 영향을 받지 않도록 할 수 있다.
버전 제약 조건(Version Constraint)
모듈 블록 내 version은 버전 제약 조건식을 지원한다.
이를 잘 이용하면 불필요한 버전 값 업데이트 빈도수를 줄일 수 있다.
1.2.0 : 1.2.0 버전
= 1.2.0 : 1.2.0 버전
>= 1.2.0 : 1.2.0 버전 이상 중 최신 버전
>= 1.2.0, < 2.0.0 : 1.2.0 버전 이상 2.0.0 버전 미만 중 최신 버전
~> 1.2.0 : 1.2.x 버전 중 최신 버전
~> 1.0 : 1.x 버전 중 최신 버전
두 종류의 테라포 모듈을 관리하라
모듈을 사용하기에 앞서, 어떠한 모듈들을 만들어 운용할지 잘 고민해야 한다.
DevOps A : 우리 조직의 표준과 컨벤션이 적용된 S3 버킷 모듈을 만들자! 앞으로 S3 버킷이 필요하면 이 모듈을 가지고 동일한 표준과 컨벤션을 적용할 수 있을거야. 굳이 S3 버킷의 모든 옵션을 설정할 수 있도록 자유도를 줄 필요는 없잖아?
DevOps B : 나중에 예외케이스가 발생했을 때 대응하기 어려워지면 어떻게 해? 모듈이 기존 리소스의 기능을 제한시키면 안된다고 생각해. 우선 S3 버킷과 관련된 리소스들의 관계를 파악해서 잘 추상화된 하나의 객체로 표현할 수 있도록 모듈을 만드는게 어때?
발표자분은 두 종류의 모듈을 만드신대
모듈(Module)
기존 리소스들을 유의미한 객체 단위로 다시 추상화한 리소스 모음
조직의 정보를 담고 있지 않도록 한다
어떠한 조직에서든 용도에 무관하게 재사용하기 쉽도록 하는 것이 목적
스택(Stack)
조직의 기술 표준과 컨벤션이 적용되어 제한된 인터페이스만 제공하는 테라폼 모듈
스택은 리소스와 모듈의 모음으로 구성
사용 용도와 옵션을 제한하여 사용성을 향상시키고 기술 표준을 강제 적용하는 것이 목적
예시1)
AWS resources -> Module -> Stack
ex. aws_ecr_repository -> ecr-repository(Module) -> ecr-repository (Stack)
레포지토리 정책 설정 자유, 이미지 라이프사이클 정책 설정 자유[Module] -> 레포지토리 정책 설정 제한적 설정 허용(IAM Policy Deny 정책으로 권한 제한), 이미지 라이프사이클 정책 설정 불가 (미리 설정된 라이프사이클 정책)[Stack]
예시2)
micro-backend
여러 module (ecr-repository, eks-irsa, kms-key, secrets-manager-secret, ...) -> stack (micro-backend)
백엔드 마이크로서비스 인프라 리소스를 추상화한 스택
서비스 이름, 환경, DB 사용 여부 및 설정, Redis 사용 여부 및 설정 등
최소한의 옵션만 인터페이스로 노출
코드와 데이터를 분리하라
데이터가 하드코딩된 코드 -> 코드 재사용성이 꽝!
YAML로 데이터 주입하기
(자세한 내용은 필요할 때 유튜브 링크 보기)
하나의 워크스페이스에 모든 것을 담지 마라
모놀리식 워크스페이스
jenkins:
vpc, auto-scaling-group, application-load-balancer, subnet, ami, route53-record, route table, launch-template, acm-certificate, security-group, secrets-manager-secret, kms-key, iam-role, waf-rule
간혹 특정 서비스 배포를 위한 테라폼 코드를 살펴보면, 네트워크, 도메인, 서버, 데이터 저장소, 로드 밸런서 등 인프라 전반적인 리소스를 모두 포함하고 있는 경우를 보곤 한다.
조직의 구성이나 일하는 방법에 따라 나누는게 좋다
network-vpc:
vpc, subnet, route table, nacl
network-lb:
alb, nlb, gwlb
jenkins:
auto-scaling-group, ami, launch-template, secrets-manager-secret, iam-role, security-group
domain-zone:
route53-zone, route53-record
domain-cert:
acm-amazon-cert, acm-private-cert
security-kms:
kms-key
security-waf:
waf-rule, waf-ip-list
워크스페이스간의 의존성을 관리하라
여러 워크스페이스로 분리하여 관리하면 당연히 각 워크스페이스 간의 의존성이 발생하게 된다.
각 워크스페이스가 어떠한 의존도를 가지고 있는지 관리 할 필요가 있다.
워크스페이스 간 관계에서 순환 참조(Cycle)가 발생하면 관리가 복잡해지고, 예상치 못한 이슈를 만날 수 있으니 조심해야 한다.
모든 것을 테라폼으로 관리하려하지마라
스스로에게 질문해보기:
동일한 작업에 대해 기존 작성된 테라폼 코드가 있는가?
새롭게 테라폼 코드를 작성할만큼 시간적 여유가 있는가?
추후에 동일한 작업이 발생했을 때 소요 기간을 단축시켜주는가?
IaC의 장점(Audit, Code Review, Documentation 등)이 해당 코드에 대해 유효한가?
이미 다른 방법으로 만들어진 동일 리소스가 있다면 모두 테라폼으로 마이그레이션을 진행할 수 있는가?
-> 모든 것을 테라폼으로 관리하려는 욕심은 넣어둘 필요가 있다.
| 프로바이더 | 분류 | 리소스 | 테라폼 관리 여부 |
| AWS | VPC | VPC | O |
| AWS | VPC | Subnet | O |
| AWS | VPC | NACL | X |
| AWS | Route53 | HostedZone | O |
| AWS | Route53 | HostedZone Record | X, NS/TXT 레코드만 관리 |
| Github | Organization | Team | O |
| Github | Repository | Secret | X |
팀 내에 테라폼으로 관리하는 리소스 종류에 대한 합의를 만드는 것이 중요하다.
내가 테라폼 코드로 작성하기 시작하면, 동료도 동일하게 작업을 해야 한다는 것을 잊으면 안된다.
테라폼 관리 커버리지 측정
driftctl
테라폼 상태 데이터와 실제 인프라 리소스를 비교하여 IaC 커버리지 측정
테라폼 관리 리소스 중 외부 변경사항 추적
AWS / Azure / GCP / Github 프로바이더 지원
IaC 커버리지 : 전체 리소스 중 IaC(테라폼 코드)로 관리되고 있는 리소스의 비중
-> driftctl와 같은 도구를 이용하면 테라폼 관리 리소스에 대한 추적을 쉽게 할 수 있다.
misc
테라폼 버전 관리자
tfswitch -> 추천!
가장 활발하게 관리되고 있는 테라폼 버전 관리자
tfenv보다 다양한 기능을 제공
tfenv
가장 많이 사용되는 테라폼 버전 관리자
rbenv에 영감을 받아 개발
테라폼 클라우드
프라이빗 프로바이더 / 모듈 저장소 무료 제공
상태 저장소 무료 제공 (Lock 기능 제공)
팀원 5명까지 무료
적은 인원이 테라폼 코드를 관리한다면 테라폼 클라우드를 사용하여 무료로 다양한 기능을 활용할 수 있다.
Remote 실행 모드
테라폼 클라우드에서 관리하는 에이전트에서 테라폼 코드 원격 실행
Local 실행 모드
사용자 랩탑에서 테라폼 코드 실행 (상태저장소만 테라폼 클라우드 이용)
최근댓글