HashiTalk 2021 - Terraform 도입과 파이프라인 구축 및 운영
Download as PPTX, PDF0 likes75 views
HashiTalk 2021 에서 Terraform 도입과 파이프라인 구축 및 운영 주제로 발표한 슬라이드 입니다. Youtube: https://www.youtube.com/watch?v=kmZSnpqRcq4
HashiTalk 2021 - Terraform 도입과 파이프라인 구축 및 운영
- 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에 대한 정 보는 마스킹되어 출력 ▪ 승인 과정 구현 가능
- 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