안녕하세요.

테라폼 스터디 대망의 마지막(6)주차이다.

6주차 주제는 TFC

TFC란 프로비저닝 대상과 별개로 state를 관리할 수 있도록 SaaS 형태로 하시코프에서 제공해준다.

몇몇 기능은 유료지만 주 목적인 state 관리는 무료.

참고로 스터디에서는 GitHub을 사용하지만 나는 GitLab으로 진행

우선 다음 저장소 포크 : https://github.com/terraform101/terraform-aws-tfc-workflow

리드미 생성 안되도록 하고

빈 프로젝트 생성

Push an existing folder 설명 대로 순서대로 진행하여

디렉토리 포크 완료

main.tf에 조직 이름 수정해주고

커밋 완료

terraform-aws-tfc-workflow 워크스페이스가 생성된것이 확인된다.

plan 에러가 발생한다.

prefix 변수를 추가해준다.

또다시 에러가 난다.

다시보니 오타가..ㅎㅎ

오타 수정해주고 다시 돌려보면

위와같이 에러는 나지만... AWS 관련 설정이 없다는 에러가 나온다. 즉 prefix는 정상적으로 설정됐다는것.

마지막으로 키 넣어주고 다시 플랜을 해보면

정상적으로 동작한다.

위와같이 tfc 페이지에서도 확인이 가능하다.

apply 실행하면 실시간으로 확인 가능

state 파일이 없다.

앞서 말한것처럼 state 파일은 tfc가 관리.

GitLab과 tfc를 연동해보자.

위와같이 VCS 프로바이더를 깃랩으로 설정해주면 입력해야하는 정보들이 확인된다.

유저 설정중 어플리케이션 클릭하고

리다이렉트 URI 입력후 생성하면

다음과같이 어플리케이션 아이디와 시크릿 정보 확인이 가능하다.

위와같이 연결해주면

자동으로 로그인창 출력

인증해주면

성공

다시 버전컨트롤 워크플로우에서 레파지토리 선택하기위해 들어가서 조금 기다리면

계정으로 로그인 가능한 프로젝트리스트가 확인된다.

테스트로 생성한 워크플로우 프로젝트 검색해서 선택해주면

위와같이 몇몇 설정이 나오는데 오토 어플라이 선택한다.

이외에도 브랜치명 입력해주고 트리거 런 선택. Pull 리퀘스트(깃랩에선 머지리퀘스트) 오토매틱 체크해주고..하단의 업데이트 클릭

이렇게 하면 워크스페이스와 VCS간 최초 연동되면 마지막 커밋 내용을 기반으로 Run이 실행

마지막으로 연동테스트를 위해

main.tf에 terraform cloud 항목 모두 주석처리하고

새로운 브렌치 생성한다음

위와같이 MR(PR)을 생성하여 병합을 해보자.

머지하면

tfc에서 동작하는것을 확인할수있다 ! (비록실패했찌만 ㅎㅎ) 어쨌든 연동된것을 확인할수있다~!

5주차 테라폼 주제 : 프로비저닝 파이프라인이다.

스터디에서는 github action을 이용하였는데 블로그 작성은 gitlab CI를 이용해서 실습을 진행해볼것이다. 

추가로 파이프라인 작성을 도와주는 plumber라는 도구를 이용해볼것이다. 아직 클로즈베타라 계정 신청해서 사용이 가능하다. 여러 개발언어에 대한 파이프라인을 제공해줘서 나름 쓸만할것같다.

terraform + gitlab CI 를 이용해서 EC2를 생성하는 파이프라인을 만들어보기.

다음과같이 새로운 프로젝트를 생성해주고..

plumber에서 알려주는 gitlab CI 동작에 필요한 변수들을 등록해준다. 

위와같이 gitlab 페이지에서 프로젝트 변수(또는 그룹변수)를 등록해줘도 되고.

위와같이 파이프라인내에 직접 변수를 등록해줘도 된다. 나는 테스트용이기 때문에 후자로 선택했다. 하지만 협업환경이여서 여러 사람들이 여러 파이프라인을 관리해야한다면 동일하게 사용될 변수들이 있을것이다. 이럴때는 gitlab에서 그룹변수를 지정하는것이 좋을것이다.

프로젝트에 소스 Push.

위와같이 .gitlab-ci.yml을 작성하여 파이프라인을 작성해준다.

gitlab 파이프라인을 rules나 only 를 통해서 if문을 줘서 파이프라인을 동작시킬수있다. 브랜치별로 동작되는 스테이지를 다르게하는등의 효과를 가질수잇다.

파이프라인이 실행되고 위와같이 정상적으로 terraform으로 어플라이가 실행됐다. 테스트이기 때문에 바로 destroy도 해주었다.

테라폼 init이 정상적으로 파이프라인에서 동작된것이 확인된다.

SAST도 잘 실행됐다.

terraform plan도 정상적으로 실행됐다.

위와같이 terraform apply도 정상적으로 동작돼서 AWS 리소스도 정상적으로 생성됐음이 확인된다.

위와같이 파이프라인에 대한 결과들(각종 테스트 결과와 있다면 도커 이미지등)이 아티팩트로 생성되는것을 확인할수있다. 

만약 여러 사람들과 협업하면서 코드를 리뷰하고 승인을 받는 절차가 필요하다면 4주차때 작성한것처럼 리뷰/승인 절차를 gitlab 파이프라인에 추가해주는것도 좋은 협업환경이 될것이다.

1. State 란

책과 책갈피 예시:
책은 여러 페이지로 구성되어 있으며, 각 페이지에는 다양한 내용이 담겨 있습니다.
책갈피는 책을 읽다가 멈춘 특정 페이지를 표시하여, 다음에 책을 읽을 때 어디서부터 시작해야 하는지를 알려줍니다.
Terraform과 State 예시:
Terraform은 여러 리소스(서버, 데이터베이스 등)로 구성되어 있으며, 각 리소스에는 다양한 설정이 담겨 있습니다.
State는 Terraform으로 인프라를 구성하다가 현재 어떤 리소스가 어떤 상태인지를 저장하여, 다음에 인프라를 변경할 때 어떤 리소스를 어떻게 변경해야 하는지를 알려줍니다.
상세 설명:
책갈피 없이 책 읽기:
책갈피가 없다면, 매번 책을 읽을 때마다 어디까지 읽었는지를 기억하거나 찾아야 합니다.
State 없이 Terraform 사용하기:
State가 없다면, Terraform은 매번 인프라의 현재 상태를 알 수 없어서, 어떤 리소스를 생성, 수정, 삭제해야 하는지를 판단하기 어렵습니다.

Serial을 기준으로 State Backup을 관리한다.

위와 같이 테라폼 내용을 수정/배포하면 Serial이 변경되는것을 확인할 수 있다.

팀 단위로 테라폼을 운영할때는 팀 모두가 동일한 state를 이용해야 하기 때문에 공유 위치에 state파일을 저장해야한다.

워크스페이스를 분리하여 운영할수도 있다.

개발, 테스트, 스테이징, 운영등의 환경을 워크스페이스로 분리하면 리스크를 관리하고 리소스를 최적화, 개발 효율성도 높일수 있을것이다. 또한 배포 관리도 가능할것이고.

위와같이 dev 라는 workspace에서는 Dev.txt 파일이 생성된것을 볼수있다.

그럼 다시 

prod workspace에서는 prod.txt 가 생성된것을 확인할 수 있다.

2. 모듈

모듈이란 재사용 가능한 코드블록으로 여러 리소스와 설정을 그룹화하여 관리가 가능하다. 코드의 재사용성과 관리효율성을 향상시킨다.

위와같이 모듈을 사용하여 사용자 아이디와 패스워드가 생성되는것을 볼수있다.

모듈에 사용할 프로바이더는 루트모듈에서 프로바이더를 정의한다.

테라폼 레지스트리를 통해 모듈을 다운받을수도 있다.

https://registry.terraform.io/

위와 같이 AWS s3-bucket 모듈을 사용해볼것이다.

위와같이 모듈에의해 버킷이 생성된것을 확인할수있다.

얼른삭제해준다.

정삭적으로 삭제됐다.

테라폼은 결국 코드이기 때문에 버전 형상관리를 해줘야한다.

VCS 도구중 가장 대표적인 git, gitlab을 통한 형상관리가 가능하다.

다만 하나의 원격 저장소를 여러 개발자가 사용한다면 충돌이 발생한다. 그래서 항상 push 전에 Pull 을 해주는 방안도 있지만 매우 귀찮은 일이다.

이때 사용할수 있는게 git branch를 사용하는것이다. 

플로우는 이런식으로...

깃랩에서는 이렇게 여러개의 브랜치를 이용할수있고

머지 리퀘스트를 생성해서 병합요청을 진행한다.

병합 진행하기전 코드에 문제가 없는지 리뷰를 진행해줄 리뷰어도 지정하고...

리뷰가 완료되면 최종적으로 병합을 진행한다. 

이때 approval을 지정하여 단계별 승인자도 지정해줄수있다.