오랜만입니다. 회사에 입사해서 여러 교육을 받고 팀에 배치받아 열심히 회사생활에 적응 중입니다.
여러 일을 병행하지만, 평소에도 관심 있었던 데브옵스를 주로 맡게 되었습니다.
회사의 대규모 인프라를 테라폼으로 형상화시켜 관리하고 싶어,
멘토이자 항상 감사한 형님이신 정영진 님께 공부법을 여쭤보던 중 좋은 기회로 멘토링을 받게 되었습니다.
당분간 멘토링에서 배운 내용이나, 데브옵스에 대한 내용, 그리고 추가적으로 개발 고려 중인 사이드 프로젝트들을 위주로 블로그를 작성할 것 같습니다 :>
Assignment - Atlantis deploy
우선 영진 님이 제공해 주신(다시 한번 감사 :>) 레포지토리를 클론 해서, atlantis를 배포하고 이를 이용해서 GitOps를 경험해 보았다.
아직 HCL에 익숙하지 않기 때문에 코드를 하나씩 읽으며 VPC, ALB, ECS, IAM 등 주요 구성 요소를 파악을 먼저 했다.
이 과정 중에 배운 것과 문제를 디버깅한 내용 중 일부를 정리해 보겠다.
우선 배운 것은, 코드를 이용해서 인프라 자원을 관리하기 때문에 인프라 상태 관리 파일(tfstate)을 주로 S3에서 관리하는 것이 글로벌 스탠더드이다.
이 경우 인프라 관리 권한을 가지고 있는 누구나 사용할 수 있다면 같은 시간에 같은 인프라를 만약 수정해서 생기는 동시성 문제를 어떻게 해결할까?
여러 가지 방법이 있겠지만 DynamoDB를 이용해서 상태 파일을 Lock 걸어 동시 접근을 방지하고 일관성을 보장하게끔 한다.
좀 더 설명하기 위해 작업 흐름을 서술하자면,
1. 테라폼에 명령을 내림(ex. apply, plan)
2. 테라폼에서 DynamoDB 테이블에 Lock 아이템 생성
2-1. Lock이 없다면? -> Lock을 생성하고 작업을 시작
2-2. Lock이 있다면? -> 다른 사람이 작업 중인 것으로, locked 에러를 발생하고 대기 또는 실패 처리
3. 작업이 끝난다면 Lock 아이템을 삭제
물론 2주 차가 지난 현재 시점에서는 provisioning을 다른 방식으로 진행해서 DynamoDB를 이용하지 않았지만
이에 대해선 2주 차 멘토링 글에서 작성하도록 하겠다.
과제를 하면서 발생한 문제는, 클론 하는 레포지토리를 실수로 atlantis-deploy 관련 레포지토리만 하는 것으로 오해하여
과제에서 설정해야 하는 ACM과 DNS 관련 설정을 false(무효화) 처리하고 진행했다.
물론 실습용으로 로컬에서 작동하고 AWS에 띄워보는 정도라 문제는 없었지만, 이후 회사에서 실제로 사용해 보는 것을 목적으로 멘토링을 받는 상황에서 약식으로 진행한 것이라 이번 주에 다시 제대로 진행할 예정이다.
그래서 이후에는 ACM 등을 제대로 구성하여 HTTPS로 통신하는 프로덕션 환경과 비슷하게 구성해 볼 예정이다.
1차만 진행했던 당시에도, 영진님 실력의 깊이를 엿볼 수 있었고 위에 것들을 제외하고도 웹훅이나, 테라폼 등등 이외에도 많은 것을 배울 수 있었다.
현재 2차 멘토링까지 받은 상태인데 이번에는 더욱 많은 것들을 배우고, 더 많은 것들을 공부해야 하는 상황이 되어서 즐겁다 :>
강연 이후에 여러 커피챗과 연락을 이어나가며 지속적으로 인연을 이어나가고 있는 영진님께,
후학을 위해서 아낌없이 시간을 내어 멘토링해 주셔서 다시 한번 감사하다는 말씀을 드리고 싶다.
꼭 성장한 이후에 누군가에게도 도움 되는 멘토링을 할 수 있을 때까지 열심히 하고 있고, 할 것이다.
아래는 멘토링 중 정리한 개념
Mentoring Content
HCL : 테라폼의 핵심 언어 / main.tf, variables.tf
Provider : AWS, GCP, Azure과 같은 플랫폼에 통신할 수 있게 해주는 플러그인
Resource : 실제로 관리할 인프라 (EC2, S3, VPC 등) - 코드로 관리하기 때문에 인프라 상태를 일관되게 재현 가능
Data Source : 이미 있는 리소스나, 정보(기존 VPC, 특정 태그를 가진 S3)를 읽어서 테라폼에서 활용할 때 사용
Variables :
- input: 외부에서 입력받음 (var 플래그나 변수파일)
- output: 실행 후 결괏값 반환 (예: public IP)
- local: 디렉터리 범위에서만 쓰는 임시 변수 (함수와 결합해서 값 가공 가능)
Module : VPC, ALB, EC2 등 자주 쓰는 패턴을 만든 형태, 환경 별로 변수만 기입하여 반복 사용
Plan : 어떻게 변경되는지 미리 시뮬레이션(dry - run), 오류나 변경 사항을 미리 확인
Apply : Plan의 결과를 실제 클라우드에 생성 / 수정 / 삭제
State :
- 테라폼이 '현재 인프라가 어떤 상태인지' 추적하는 파일, 현업 시 S3 등 외부에 두고, 동시에 여러 명이 같은 인프라를 작업 못하게 lock 걸어둠
- S3에 저장할 때 동시에 작업 못하게 lock 기능 지원 (보통 DynamoDB로 lock 관리)
- S3버킷에 bucket policy, IP 제한 등
- 직접 권한이 없어도 IAM Role - Assume Role을 통해서 필요한 작업만 수행 가능
Atlantis와 GitOps (TACOS : Terraform Automation and COllaboration Sofrware )
Atlantis란?
- 테라폼 작업을 Git PR(pull request) 기반으로 자동화해 주는 툴
- PR 올리면, Atlantis가 plan/apply를 자동 실행(혹은 승인 후 apply)
- IaC의 GitOps(=모든 인프라 작업은 깃 PR로만!) 완성에 핵심
Atlantis Workflow
- dev가 main.tf, variables.tf 등 변경 → PR 생성
- PR에 코멘트로 /plan 입력 → Atlantis가 terraform plan 자동 실행, 결과를 PR에 댓글로 남김
- 리뷰어가 확인 후 /apply 입력 → Atlantis가 terraform apply 실행, 실제 인프라 변경
- webhook으로 Atlantis가 PR 알림 받음
- Atlantis에게는 실제 인프라 리소스를 생성/변경할 admin-level IAM 권한 필요
Multi Account/Assume Role
- 회사에서 AWS 계정이 여러 개일 때, 각 계정별로 Atlantis가 필요한 리소스만 assume role로 들어가서 작업
- 하나의 Atlantis가 여러 계정/환경 관리 가능
😊긴 글 읽어주셔서 감사합니다.
