HashiTalk 2021 – Terraform 도입과 CI/CD 파이프라인 구축 및 운영

HashiTalk 2021 발표를 했었다. KODA 서비스 인프라 구축할 당시 Terraform을 도입하고 파이프라인을 구축하면서 있었던 일들에 대해서 발표했다.

이렇게 공개적인 자리에서 발표했던게 꽤 오래전이라 준비하는데 꽤 힘들었다. 특히 회사일이랑 같이 준비하려니 좀 더 부담이 됐던 것 같다. 블로그 글이랑 발표 내용은 확실히 다르다는 것을 다시 한 번 더 느낄 수 있었다. 좀 더 간결하고 엄청 복잡하지 않은 내용으로 메세지를 전달해야하는 것 같다. 발표 사전에 동료들에게 피드백을 요청했었고 이 피드백이 아니었으면 정말 이 정도로 발표를 할 수 없었을 것이다. 너무 감사하다.

발표 내용은 예전에 작성했던 ‘Terraform CI/CD 파이프라인 구축과 운영 기록’ 포스팅을 바탕으로 준비했다. 이 포스팅 내용과 조금 달라진 내용은 KODA가 ISMS 준비하면서 더 이상 CloudBuild를 사용할 수 없었고, 대신 self-hosting이 가능한 Jenkins로 바뀌었다.

Self-hosting이 필요했던 이유는 GCP 프로젝트에 방화벽, 좀 더 정확히는 VPC Perimeter를 두면서 특정 IP에서만 해당 서비스 프로젝트에 접근할 수 있게 변경되었다 (더 자세한 내용은 이 포스팅에서도 더 찾아볼 수 있다). 그래서 CloudBuild와 같이 outbound IP range가 불분명한 서비스는 더이상 사용할 수 없게 되었다.

Terraform pipeline using CloudBuild
VPC Perimeter IP 접근 제어때문에 더 이상 CloudBuild를 사용할 수 없게 되었다

처음 self-hosting 할 서비스로 고려했던 것은 Terraform Enterprise 였다. 그런데 아직 서비스 초기 스테이지에서 이걸 쓰기에는 너무나도 비쌌다. 그래서 발표 내용을 보면 알겠지만 사용했던 것이 Jenkins 이다.

GKE 상에 Jenkins 클러스터를 갖춰놓고 outbound IP range를 고정시키기 위해서 NAT를 사용했다. 모든 Jenkins 서비스는 private IP를 가진다. 그리고 NAT를 GKE가 관리하는 VPC에 연결시켜놓고 NAT의 고정 public IP를 VPC Perimeter에 등록하는 것으로 네트워크 문제를 해결할 수 있었다.

Terraform CI/CD pipeline with self-hosting service
Cloud NAT를 통해 outbound IP range를 고정시키고 이를 VPC Perimeter에 등록하였다

답글 남기기

이메일 주소는 공개되지 않습니다.