HashiTalk 2021 에서 Terraform 도입과 파이프라인 구축 및 운영 주제로 발표한 슬라이드 입니다. Youtube: https://www.youtube.com/watch?v=kmZSnpqRcq4

1. DevOps Eng. at HAECHI-LABS
김주형
he/him
Terraform 도입과 파이
프라인 구축 및 운영

2. 발표 내용
▪ Terraform 도입 배경과 도입 초기 시행착오들
▪ Terraform 환경에서 팀원과 효과적인 협업과 안정적인 배포를 위해 했었던 일
들

3. Terraform 도입 배경과
도입 초기 시행착오들

4. 새로운 프로젝트?
▪ 비트코인 수탁 등 법인, 기관 투자자를 위한 디지털 자산 수탁 서비스
▪ KB, Hashed, HAECHI-LABS 합작 법인 KODA 서비스
▪ 장기적으로 지속될 가능성이 높은 프로젝트였다.
▪ 우선은 혼자 인프라 구축을 시작하지만 가까운 시일내에 팀원이 합류할 계획이
었다.

5. 고민했던 것들
▪ 어떻게 하면 여러 환경(dev, qa, prod)에 대해 비슷한 형태의 인프라를
효율적으로 만들고 관리할 수 있을까?
▪ 인프라를 구성하면서 문서화는 최소한으로 할 수 있고 쉽게 현재 인프
라 구성을 공유할 수 있는 방법은 어떤 것이 있을까?

6. Terraform을 이용하면 해결할 수 있지 않을까
?
▪ 여러가지 환경에 유사한 인프라 구축 과정에서 반복되는 작업을 없애고 휴먼 에
러를 줄일 수 있지 않을까 기대
▪ 코드를 통해 인프라 구성이 표현되므로 문서화를 최소화할 수 있고 온보딩 기간
을 단축할 수 있지 않을까 기대

7. 초기 Terraform 패키지 구조
▪ Google Cloud security foundations guide 을 주
로 참고
▪ 전체 클라우드 리소스를 큰 티어로 구분
(org, networks, workloads ...)
▪ 리소스의 성격, 업데이트 빈도, 리소스의 중
요도
▪ 각 티어 패키지 안에는 각 환경별, 서비스별 리
소스가 포함되어 있는 구조
▪ 사용하다보니 장단점이 느껴짐

8. 초기 Terraform 패키지 구조
▪ Google Cloud security foundations guide 을 주
로 참고
▪ 전체 클라우드 리소스를 큰 티어로 구분
(org, networks, workloads ...)
▪ 리소스의 성격, 업데이트 빈도, 리소스의 중
요도
▪ 각 티어 패키지 안에는 각 환경별, 서비스별 리
소스가 포함되어 있는 구조
▪ 사용하다보니 장단점이 느껴짐

9. 초기 Terraform 패키지 구조
▪ Google Cloud security foundations guide 을 주
로 참고
▪ 전체 클라우드 리소스를 큰 티어로 구분
(org, networks, workloads ...)
▪ 리소스의 성격, 업데이트 빈도, 리소스의 중
요도
▪ 각 티어 패키지 안에는 각 환경별, 서비스별 리
소스가 포함되어 있는 구조
▪ 사용하다보니 장단점이 느껴짐

10. Terraform으로 관리하기 어려운 클라우드 리
소스들이 존재했다.
▪ 처음엔 모든 클라우드 리소스에 대해서 Terraform으로 관리하고자 했었다.
▪ GCP Provider가 지원하지 않는 리소스도 존재한다.
▪ 관리하기위해 너무 많은 권한이 필요한 리소스도 존재했고 이를 고려하지 못했
다.
▪ Folder, Project, IAM …

11. Terraform으로 관리하기 어려운 부분들은 과
감하게 버리자
▪ 주로 관리하기 위해 높은 권한이 필요한 리소
스에 대해서 삭제
▪ 삭제된 리소스에 대해서는 어떻게 관리할지
에 대해 문서화
▪ org, environments 와 같이 많은 권한이 필요
한 모듈들은 삭제, networks, workloads 등
관리할 수 있는 모듈들을 집중해서 관리

12. 모듈이 늘어나면서 버전 관리가 어려워졌다. 그
리고 반복되는 코드들이 너무 많이 보인다.
▪ 각 모듈마다 Terraform required_version과 Provider required_version이 다름
▪ 엔지니어마다 다른 버전의 Terraform을 사용
▪ Terraform, Provider 버전을 모듈 내 versions.tf 라는 파일에 작성하는데 모듈
을 만들 때마다 versions.tf 이라는 파일을 만들고 같은 코드를 계속 작성
해줘야 함
▪ 모든 환경에 대해 동일한 변수들도 존재
▪ region 과 같은 값들은 모든 환경에서 동일한 값이 사용됨

13. Terragrunt comes to the rescue!
▪ Terragrunt 활용
▪ 반복되는 Terraform 코드를 줄여줄 수 있는
도구
▪ Terraform wrapper로 구현됨
▪ terragrunt plan, terragrunt plan

14. Terragrunt comes to the rescue!
▪ tfenv, tgenv
▪ nvm, pyenv와 동일한 역할을 해주는 도구
▪ .terraform-version, .terragrunt-version
파일을 통해 엔지니어들은 정해진 버전의
Terraform, Terragrunt를 사용할 수 있도록 강제

15. Terragrunt comes to the rescue!
▪ Terraform, Provider 버전을 명시하는 설정
(versions.tf) 은 글로벌하게 한 곳에서 관리
▪ terragrunt.global.hcl
/terragrunt.global.hcl
/networks/service-x/qa/terragrunt.hcl

16. Terragrunt comes to the rescue!
▪ .terraform.global.tfvars 파일과 각 모듈의
terragrunt.hcl 파일을 통해 전역 변수 관리
/terragrunt.global.hcl

17. Terraform 환경에서 팀원과 효과적인
협업과 안정적인 배포를 위해 했었던
일들

18. 새로운 팀원과 현재 인프라 상태를 실시간으
로 공유할 수 없다
▪ 이전에는 현재 인프라 상태를 나타내는 tfstate 파일을 git에서 관리
▪ 그렇기 때문에 특정 구성원의 작업물이 remote에 merge 되기 전에는 최신 상태
를 알기 어려운 문제가 존재

19. 팀원과 상태를 실시간으로 공유할 수 있도록
백엔드 스토리지를 사용하자
▪ Google Cloud Storage (GCS)에 state
를 관리함으로써 실시간으로 인프라
상태를 알 수 있다.
▪ 공식 문서에 설명이 자세히 나와있고
마이그레이션 과정도 쉬웠다.

20. 다음 스테이지로 배포하기 위해서 너무 많은
변경이 필요하다
▪ 점점 인프라 복잡도가 증가
▪ staging에서 충분히 테스트한 설정들을 최대한 변경 없이 production에 배포할
수 있어야 한다.
▪ 당시에는 많은 설정들을 다음 스테이지에 배포하기 위해 가져와야 했고 휴먼 에
러 가능성이 높았다.

21. 다음 스테이지로 배포하기 위해서 너무 많은
변경이 필요하다
▪ 다음 스테이지로 넘어가기 위해 많은 설정들을 빠진 것 없는지 체크하며 가져와
야 함

22. 다음 스테이지로 배포하기 위해서 너무 많은
변경이 필요하다
▪ 다음 스테이지로 넘어가기 위해 많은 설정들을 빠진 것 없는지 체크하며 가져와
야 함
networks/dev/main.tf networks/qa/main.tf

23. 변경을 줄이기 위해 하위 모듈을 묶어 추상화
된 모듈을 만듦
▪ 인프라 구성의 큰 부분을 다시 묶어 추상화

24. 변경을 줄이기 위해 하위 모듈을 묶어 추상화
된 모듈을 만듦
▪ 인프라 구성의 큰 부분을 다시 묶어 추상화
networks/base/main.tf networks/{dev|qa|prod}/main.tf

25. 팀원과 원활하게 협업할 수 있는 환경이 필요
하다
▪ 새로운 팀원도 Terraform에 대해서 숙련되지 않은 상황
▪ 실수 없이 퀄리티를 유지하며 태스크를 진행하기 위해서는 서로의 작업을 먼저
리뷰하고 배포할 수 있는 환경이 절실히 필요했음

26. GitOps 방식의 Terraform CI/CD 파이프라인
을 만들자
▪ 설정이 코드로 관리되기 때문에 PR을 이용하여 코드를 리뷰하고 merge 되었을
때 해당 작업물이 실제로 클라우드에 반영되는 방식을 생각
▪ 당시 2주라는 여유가 존재했고, 이 기간동안 다른 일은 모두 멈추고
Terraform CI/CD 파이프라인 구축하는데 집중

27. GitOps 방식의 Terraform CI/CD 파이프라인
을 만들자 - Dev, QA

28. GitOps 방식의 Terraform CI/CD 파이프라인
을 만들자 - Prod

29. 왜 Jenkins를 사용했나?
▪ Self-hosting 가능한 구조
▪ Credential 관리가 가능
▪ RBAC를 통해 권한 분리 가능
▪ 빌드 로그에서 Credential에 대한 정
보는 마스킹되어 출력
▪ 승인 과정 구현 가능

30. getoutsidedoor.com
github.com/zeroFruit
@FruitZero
Thank You

31. ● https://services.google.com/fh/files/misc/google-cloud-security-
foundations-guide.pdf
● https://github.com/terraform-google-modules/terraform-example-
foundation
● https://www.terraform.io/docs/language/settings/backends/gcs.ht
ml
● https://terragrunt.gruntwork.io/
Reference