Terraform-101-Study Week7 - [워크플로]

Week7

1. 워크 플로우

1) 개인 규모의 워크프로우

• 기본적인 테라폼 워크플로우 이다. 다른 사람과의 협업을 고려할 필요가 없다.

(1) Write

• Terraform 을 활용하여 infra를 코드로 반영한다.
• 재사용성을 고려하여 모듈화, 지속적으로 사용하는 값들을 변수화 하는 것을 고려한다.

(2) Plan

• 작성한 코드들이 배포되기전 본인이 의도한 바로 코드가 반영되는지 확인한다
• 이 과정에서 외부 기능인 tfsec , terrascan 등을 활용하여 취약성 점검을 실행할 수 있다

(3) Apply

• 실제 코드들을 반영하는 단계이다.
• plan에서 정상적으로 실행되더라도 Apply 단계에서 오류가 발생할 수 있음으로 오류를 확인한다.

2) 다중 작업자의 워크 플로우

(1) Write

• 개인 작업자의 워크플로우와 비슷하나 작업자 별로 각각의 작업 장소 (VCS Branch 등) 에서 작업을 실시 한다.
• 협업을 위해 Variable 사용을 고려하고, 민간 데이터가 포함되지 않도록 코드 설계를 한다.
• 코드가 인프라에 바로 반영된다면 위험하므로, 환경을 나누어 배포하는 방법이 있다. ( 디렉터리 기반 격리, 깃 기반의 브랜치 격리)

(2) Plan

• 개인으로 작업했던 Terraform 코드들을 오류가 나지 않게 정확하게 병합하는 과정이다.
• 이 단계에서는 추가, 삭제, 수정 내역을 작업자 별로 리뷰하여 복기해야한다.
• Ci 툴 및 TFC의 VCS 통합 기능을 통해 자동화가 가능하다

(3) Apply

• 코드가 최종 병합되면 인프라 변경이 수행됨을 알리고 변경되는 대상 환경의 중요도에 따라 승인이 필요하다
• 또한 변경하는 코드가 특정 기능, 버그 픽스, 최종 릴리즈를 위한 병합인가에 따라 이 단계에 추가로 코드 병합이 발생 가능하다
• 관리하는 단위를 나누는 기준은 조직 R&R, 서비스, 인프라 종류 등으로 구분한다

3) 다중 팀의 워크 플로우

(1) Write

• 리소스가 하나의 모듈에서 관리되는 것이 아닌, R&R에 의해 워크스페이스를 분리하여 관리한다.
• 다른 워크스페이스의 리소스를 참조하기 위해 state 접근 권한과, output을 활용하여 데이터를 노출한다
• 다른 스페이스의 변경사항을 참조하기위해 terraform_remote_state 및 별도의 KV-store 를 활용해야한다
• 다른 워크스페이스 에서 발생된 변경 사항에 대해 영향을 최소화 할수 있도록 리모트 데이터 소스의 기본값을 정의하거나 코드적인 보상 로직을 구현해야한다.

(2) Plan

• 코드 기반으로 진행되는 리뷰는 해당 코드로 이내 영향 받는 다른 팀의 인프라를 VCS상의 코드 리뷰 만으로 공유 가능하다
• 병합을 승인하는 단계에서 코드 변경으로 인해 영향을 받는 다른 팀의 작업자도 참가가 필요하다

(3) Apply

• 프로비저닝 실행과 결과에 대해 관련 팀에게 모두 전달되어야 한다. 그러므로 파이프라인 구조에서 자동화하는 것을 추천한다.
• 코드 롤백을 고려하여 훈련을 진행해 놓아야한다 ( 다른 팀에 어떠한 영향을 끼칠지 모르므로 )
• 다른 워크스페이스에서 우리 팀의 state를 참조 할 수 있도록 output에 대한 접근 권한을 부여한다.

2. 격리 구조

• Terraform 수준 에서 격리는 State 분리에목적을 둔다

두가지 방식이 존재한다

(1) 모놀리식

• 장점
  • 단일, 소수 인원 관리 용이
  • 통합된 시나리오 검증 용이
  • 쉬운 배포가가 가능함
• 단점
  • 규모가 커진다면 코드의 관리가 어려워짐
  • 신규 작업자가 전체를 이해해야함 ( 신규 인력 투입의 어려움 )
  • 하나의 오류가 전체에 영향을 끼침

(2) 마이크로 서비스 방식

• 장점
  • 소규모 기능 단위로 배포와 테스트가 용이함
  • 단위별로 새로운 구성 적용이 용이함
  • 서비스가 각각 독립적으로 실행됨
• 단점
  • 다수의 배포를 위해 프로세스 구현 필요
  • 단위별 연계를 위한 로직 구현 필요
  • 서비스를 나누는 기준의 확립이 필요

3. 프로비저닝 파이프 라인 설계

• 실제 서비스가 실행되는 대상을 프로비저닝하면 테라폼의 Plan과 Apply 과정상에 추가로 코드 검증, 실행 계획 검증, 실행 후 결과 확인과 같은 추가 동작을 자동화해 연계할 필요성이 생긴다.
• 도구 : 젠킨스, Github Action, TFC/TFE
• Github Action : 깃허브 환경에서 제공하는 CI/CD 자동화 도구 - 워크플로를 설계하고 다양한 라이브러리들을 이용해 다양한 작업 구성이 가능
• 저장소 포크 : https://github.com/terraform101/terraform-aws-github-action
• Github Action은 별도의 State 저장소를 제공하지 않음 , State를 저장할 수 있는 방안 마련 필요

4. VCS 연동

(1) Setting → Version Contorl → Providers 로 이동

(2) Add a VCS provider 클릭

(3) Gitlab.com 선택

(4) Provider 설정

• Register a new OAuth Application 선택

(5) Gitlab OAuth 설정

• Add a new application 선택

• Terraform Enterprise 화면 확인
  • Name , Redirect Url 복사

• Gitlab - Applications 설정
  • Name, Redirect URL 에 매칭되는 내용 복사/붙여넣기

• Scopes 는 api 체크
• Save application 클릭

 

• Application ID , Secret 복사 붙여 넣기
  • Gitlab 화면

• Terraform Enterprise에 Gitlab 에서의 application id 값과 secret값 기입

(6) Terraform Enterprise Authorize

• Authorize 클릭

---