[T1012] 7주차 - 워크플로 (마지막)

해당 내용은 T1012 스터디에 나온 내용과 '테라폼으로 시작하는 IaC' 책을 기준으로 정리 했습니다

워크플로(workflow)란?
work + flow -> 작업 흐름으로 작업 절차를 통한 정보 또는 업무의 이동을 의미

8. 워크플로

8.1 규모에 따른 워크플로

테라폼 워크플로: write -> plan -> apply, 워크스페이스 별로 접근 권한을 관리하고 중앙에서 관리되는 실행 환경을 설계하여 규모에 맞는 워크플로 설계가 필요하다

개인 워크플로

개인이 테라폼으로 일하는 방식의 예

개인 사용자 워크플로

Write

프로비저닝 하려는 목적에 따라 테라폼 코드를 작성

• 개인이 작업하더라도 반복적인 사용성을 고려할것
• 인수에 할당되는 값을 입력 변수화 하고 반복적인 구조가 발생하는 경우 리소스 단위별로 반복문을 사용할지 다수의 리소스를 모듈화 할지 결정한다

Plan

적용하기 위한 실행 계획을 통해 리뷰

• 테라폼의 plan뿐만 아니라, terraform fmt를 통해 코드 형태를 포맷팅 하고 변경되는 리소스를 리뷰
• 또한 테라폼과 함께 동작하는 tfsec이나 terrascan 같은 보안 취약성 점검 툴 등을 사용하는 것도 좋은 방안

Apply

코드로 실제 인프라를 프로비저닝

• 실행 계획상으로 정상이지만 실제 프로비저닝 하는 단계에서 인수 값, 생성 순서, 종속성에 따라 오류가 발생할수 있음
• 성공적인 완료를 위해 write -> plan -> apply 단계를 반복하고 성공하는 경우 코드 관리를 위해 VCS에 코드를 병합한다

다중 작업자 워크플로

다중 작업자 워크플로

Write

• 여러 작업자의 테라폼 코드가 충돌하지 않도록 VCS와 같은 형상관리 도구에 익숙해져야 한다.
• 작업자는 작업 전에 미리 원격 저장소의 코드를 받고 깃에서는 브랜치를 활용해 개별적으로 작업한다.
• 개인의 워크플로에서 고려한 변수화와 더불어 패스워드와 인증서 같은 민감 데이터가 포함되지 않도록 코드를 설계한다.
• 또한 개인 작업 환경에서만 사용되는 변수는 공유하지 않는다.
• 깃을 사용한다면 작업자 개인의 변수는 terraform.tfvars 에 선언하고 .gitignore에 추가해 개별적으로 테스트할 수 있는 환경을 구성할 수 있다
• 이 단계에서 개별 작업자는 작은 단위의 개별 워크플로 (Write > Plan > Apply)를 반복해야 한다.
• 개별 작업 환경과 별개로 병합되는 코드가 실제 운영 중인 인프라에 즉시 반영되면 실행 후 발생할 오류 예측이 어려워 부담이 될 수 있다.
• 이를 보완하기 위해 프로비저닝 대상의 환경을 검증과 운영, 또는 그 이상의 환경으로 구성 가능하도록 구조화한다.
• 이때 사용하는 방식은 디렉터리 기반 격리와 깃 기반의 브랜치 격리다.

Plan

• 둘 이상의 작업자는 프로비저닝 이전에 팀원 간 리뷰를 거쳐 변경된 내역을 확인하고 공통 저장소에 병합해야 한다.
• 리뷰 단계에서는 추가, 삭제, 수정된 내역을 관련 작업자가 검증, 질의, 배움의 단계를 거쳐 복기함으로써 코드 상태를 개선 유지하고 작업자 간에 의도를 공유한다.
• 코드 자체 외에도 테라폼의 Plan 결과를 풀 리퀘스트 단계에 같이 제공하면 영향을 받는 리소스와 서비스 중단에 대한 예측이 더 쉬워진다.
• CI 툴과 연계하거나 Terraform Cloud/Enterprise의 VCS 통합 기능으로 자동화할 수 있다.

Apply

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

다수 팀의 워크플로

R&R이 분리된 다수 팀 또는 조직의 경우

다수팀의 워크플로

Write

• 대상 리소스가 하나의 모듈에서 관리되지 않고 R&R에 의해 워크스페이스가 분리된다.
• 서로 다른 워크스페이스에서 구성된 리소스 데이터를 권한이 다른 팀에게 공유하기 위해, 저장된 State 접근 권한을 제공하고 output을 통해 공유 대상 데이터를 노출한다.
• 테라폼 코드 작성 시 다른 워크스페이스에서의 변경 사항을 데이터 소스로 받아 오는 terraform_remote_state 또는 별도 KV-store를 활용하는 코드 구성이 요구된다.
• 또한 관리 주체가 다른 곳에서 생긴 변경 사항의 영향을 최소화하도록 리모트 데이터 소스의 기본값을 정의하거나 코드적인 보상 로직을 구현하는 작업이 필요하다.

Plan

• 코드 기반으로 진행되는 리뷰는 반영되는 다른 팀의 인프라를 VCS상의 코드 리뷰만으로도 공유받고 영향도를 검토할 수 있다.
• 병합을 승인하는 단계에 영향을 받는 다른 팀의 작업자도 참여해야 한다.

Apply

• 프로비저닝 실행과 결과에 대한 안내가 관련 팀에 알려져야 하므로 파이프라인 구조에서 자동화하는 것을 추천한다.
• 실행 후의 영향도가 여러 팀이 관리하는 리소스에 전파될 수 있으므로 코드 롤백 훈련이 필요하다.
• 생성된 결과에 다른 워크스페이스에서 참조되는 output 값의 업데이트된 내용을 다른 팀이 확인하는 권한 관리가 필요하다

8.2 격리 구조

테라폼수준의 격리 목표: state를 분리

테라폼은 파일이나 하위 모듈로 구분하더라도 동작 기준은 실행하는 루트 모듈에서 코드를 통합하고 하나의 state로 관리

애플리케이션 구조가 모놀리식(+아키텍처)에서 MSA로 변화하는 과정은 테라폼의 IaC 특성과도 비슷하다

	모놀리식	MSA
장점	단일, 소수 인원으로 개발 편리 통합된 시나리오 검증이 쉬움 배포 반편	소규모 기능 단위로 배포와 테스트가 용이 단위별 새로운 구성 적용이 수월 서비스가 독립적으로 실행
단점	규모가 커지면 코드 추가,수정,삭제가 어려움 신규 작업자가 전체를 리뷰 해야함 부분적인 오류가 전체에 영향을 줌	다수의 배포를 위한 프로세스 구현 필요 단위별 연계를 위한 로직 구현 필요 나누는 기준 마련 필요

• 테라폼 또한 사용하는 리소스가 적고 구조가 단순하면 모놀리식 방식으로 구성하는 것이 인프라 프로비저닝 구축속도는 빠를수 있다
• 하지만 유지보수, 인수인계, 운영의 관점에서는 프로비저닝 단위별로 분류하는, 마치 MSA와도 같은 분산된 설계가 매몰비용과 기술부채를 줄이는 데 효과적이다.
• 규모가 큰 워크플로를 만들기 위해서는 간단하고 조합 가능한 부분들이 모여 집합을 이루어야 한다.
• 이러한 집합에서 발생하는 정보는 다른 집합과 교환할수 있지만, 각 집합은 독립적으로 실행되며 다른 집합에 영향을 받지 않는 격리된 구조가 필요
• 초기 테라폼 적용 단계에서 단일 또는 소수의 작업자는 단일 대상에 대해 IaC를 적용하고 하나의 루트 모듈에 많인 기능을 포함시킬 가능성이 높다.

8.3 프로비저닝 파이프라인 설계 - 깃허브

GitHub - terraform101/terraform-aws-github-action: [Chapter 8] CICD - GitHub Action

실습할 repo를 fork하여 가져온다

#
MyGit=<각자 자신의 깃허브 계정>
MyGit=gasida
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

github action을 사용하기 위해 workflow권한이 충분한지 확인

github action은 state관리를 해주지 않기 때문에 TFC 설정

# 그리고 .github/workflow/action.yml 내용 수정
env:
  MY_PREFIX: DEV
  TF_VERSION: 1.2.6 # 1.2.5에서 변경
---
git add main.tf
git add .github/workflow/action.yml
git commit -m "init"
git push
---
#
terraform init
tree .terraform

TFC에 해당 워크스페이스에서 실행모드를 Local로 변경

github action에서 terraform을 실행할때 AWS 토큰, TFC 토큰 등의 정보가 없기 때문에

Actions에 secret, variable를 등록

확인

변수를 잘 가져오는지 확인하기 위해 수정을 해주었는데...

처음에 repo 지정을 잘못해서 내 계정의 repo가 아닌  fork한 원본 repo에다가 request를 날려버렸다... (잘 확인하자)

action이 잘 작동한다

설정된 step대로 실행된다

TFC + VCS 연계하기

TFC에서 VCS providers를 추가해준다

출력된 정보를 그대로 github에 등록

"generate a new client secret" 으로 생성

SSH는 skip and finish를 눌러 넘어가도 된다

 

T1012 스터디를 끝내며

T1012 스터디에서 7주차까지 참여해보며 느낀점은 "편하다"

자율적인 학습이 부족한 나로써는 누군가 지식을 떠먹여 준다는건 정말 감사한 일이다

스터디장님과 조력자 분들이 기획, 진행을 하여 이미 테스트 해본 내용들을

설명과 실습을 통해 알아서 중요한 내용들만 필터 해주니...

처음 배우는 입장에서 감사하게 느낀 스터디였다

그리고 다른 분들의 사용사례, 경험을 발표해주어

얼마나 응용하여 사용할수 있는지도 간접적으로 경험할수 있어 좋았다