워크플로 개인 워크플로
Write : 프로비저닝하려는 목적에 따라 테라폼 코드를 작성
개인 작업이더라도 반복적인 사용성을 고려
복잡하게 작성하여 가독성을 줄이는 행위는 지
Plan : 적용하기 위한 실행 계획을 통해 리뷰
테라폼의 Plan뿐 아니라, terraform fmt를 통해 코드 형태를 포멧팅하고 변경되는 리소스를 리뷰한다.
또한 테라폼과 함께 동작하는 tfsec이나 terrascan 같은 보안 취약성 점검 툴 등을 활용하는 것도 좋은 방안이다.
Apply : 코드로 실제 인프라를 프로비저닝
실행 계획상으로는 정상이지만 실제 프로비저닝하는 단계에서 인수 값, 생성 순서, 종속성에 따라 오류가 발생할 수 있다.
성공적인 완료를 위해 Write > Plan > Apply 단계를 반복하고 성공하는 경우 코드 관리를 위해 VCS에 코드를 병합한다.
다중 작업자 워크플로
Write
VCS 와 같은 형상관리 도구에 익숙해져야 한다.작업자는 작업 전에 미리 원격 저장소 의 코드 를 받고(Pull) 깃에서는 브랜치 를 활용해 개별적 으로 작업 한다.
개인의 워크플로에서 고려한 변수화와 더불어 패스워드와 인증서 같은 민감 데이터가 포함되지 않도록 코드를 설계한다. 또한 개인 작업 환경에서만 사용되는 변수는 공유하지 않는다.
작업자 개인의 변수 는 terraform.tfvars 에 선언
.gitignore 에 추가해 개별적으로 테스트할 수 있는 환경을 구성할 수 있다
개별 작업 환경과 별개로 병합되는 코드 가 실제 운영 중인 인프라에 즉시 반영되면 실행 후 발생할 오류 예측이 어려워 부담이 될 수 있다.
이를 보완하기 위해 프로비저닝 대상의 환경을 검증 과 운영 , 또는 그 이상의 환경 으로 구성 가능하도록 구조화 한다.
이때 사용하는 방식은 디렉터리 기반 격리 와 깃 기반의 브랜치 격리 다.
Plan
둘 이상의 작업자는 프로비저닝 이전에 팀원 간 리뷰 를 거쳐 변경된 내역을 확인하고 공통 저장소에 병합 해야 한다.
리뷰 단계에서는 추가, 삭제, 수정된 내역을 관련 작업자가 검증, 질의, 배움의 단계를 거쳐 복기함으로써 코드 상태를 개선 유지하고 작업자 간에 의도를 공유한다.
코드 자체 외에도 테라폼의 Plan 결과를 풀 리퀘스트 단계에 같이 제공하면 영향을 받는 리소스와 서비스 중단에 대한 예측이 더 쉬워진다.
CI 툴과 연계하거나 Terraform Cloud/Enterprise의 VCS 통합 기능으로 자동화할 수 있다.
Apply
코드가 최종 병합되면 인프라 변경이 수행됨을 알리고 변경되는 대상 환경의 중요도에 따라 승인이 필요할 수 있다.
또한 변경하는 코드가 특정 기능, 버그 픽스, 최종 릴리즈를 위한 병합인가에 따라 이 단계에 추가로 코드 병합이 발생할 수 있다.
관리하는 단위를 나누는 기준은 조직 R&R, 서비스, 인프라 종류 등으로 구분된다.
다수 팀의 워크플로
Write
대상 리소스가 하나의 모듈에서 관리되지 않고 R&R 에 의해 워크스페이스가 분리 된다.
서로 다른 워크스페이스에서 구성된 리소스 데이터를 권한이 다른 팀에게 공유하기 위해, 저장된 State 접근 권한을 제공하고 output을 통해 공유 대상 데이터를 노출한다.
테라폼 코드 작성 시 다른 워크스페이스에서의 변경 사항을 데이터 소스 로 받아 오는 terraform_remote_state 또는 별도 KV-store 를 활용하는 코드 구성이 요구된다.
또한 관리 주체가 다른 곳에서 생긴 변경 사항의 영향을 최소화하도록 리모트 데이터 소스의 기본값을 정의하거나 코드적인 보상 로직을 구현하는 작업이 필요하다.
Plan
코드 기반으로 진행되는 리뷰는 반영되는 다른 팀의 인프라를 VCS상의 코드 리뷰만으로도 공유받고 영향도를 검토할 수 있다.
병합을 승인하는 단계에 영향을 받는 다른 팀의 작업자도 참여해야 한다.
Apply
프로비저닝 실행과 결과에 대한 안내가 관련 팀에 알려져야 하므로 파이프라인 구조에서 자동화하는 것을 추천한다.
실행 후의 영향도가 여러 팀이 관리하는 리소스에 전파될 수 있으므로 코드 롤백 훈련이 필요하다.
생성된 결과에 다른 워크스페이스에서 참조되는 output 값의 업데이트된 내용을 다른 팀이 확인하는 권한 관리가 필요하다
프로비저닝 파이프라인 설계 - 깃허브 저장소 forkhttps://github.com/terraform101/terraform-aws-github-action
MyGit=<각자 자신의 깃허브 계정>
git clone https://github.com/$MyGit/terraform-aws-github-action
# 확인
tree terraform-aws-github-action
cd terraform-aws-github-action
git remote get-url origin
# 예시) https://github.com/hyungwook0221/terraform-aws-github-action
실습에서 사용되는 Github Action에 정의된 동작의 설명 Feature Branch - main Branch 나눠서 작업 Feature Branch에서 개발자는 기능 테스트 후 PR(Pull Request) PR에 대한 SCAN 후 코드 검증 및 결과 공지 Terraform Plan 수행 후 승인권자는 main Branch 병합 main Branch에 병합 후 SCAN 후 코드 검증 및 결과 공지 Terraform Apply 수행 후 State Backend에 결과반영
Job ‘Scan ’ : 테라폼 코드 검증
Check out code : 검증을 위해 저장소의 코드를 체크아웃
Run terrascan : 테라폼 코드 검증 도구인 Terrascan 을 실행
Upload SARIF file : 검증의 결과(정적 분석 결과 표준 포맷)을 업로드
Job ‘Terraform ’ : 테라폼 실행 ← Job ‘Scan’ 이후 실행
Check out code : 검증을 위해 저장소의 코드를 체크아웃
Configure AWS credentials : AWS 환경을 프로비저닝하기 위한 Credential 설정
Terraform fmt : 표준 스타일 수정 대상 확인
Terraform init : 테라폼 실행을 위한 init 수행
Terraform validate : 코드 문법 오류 검사
Terraform plan : 실행 계획 확인
env.TF_LOG: info : 로그 수즌을 info로 출력해 실행 디버깅
Plan output : 풀 리퀘스트인 경우 실행 계획을 정리해 출력
Terraform apply : 메인 브랜치 변경 시에만 Apply 수행
예시의 동작 외에도 프로비저닝 이후의 테스트를 위한 terratest 도구와 비용 예측을 위한 terracost, infracost 도구들도 추가해 볼 수 있다.
실습
느낀점 워크플로에 대한 개념은 대략은 이해했는데, 
