[Terraform T101 4기 스터디]

스터디/Terraform

[Terraform T101 4기 스터디] - Module & Runner

QwakCheol ㅣ 2024. 7. 8. 10:46

★★cloudNet@ 팀의 가시다 님이 진행하는 Terraform 101 Study 4기 내용과
한빛미디어 테라폼으로 시작하는 IaC 책을 참고하여 정리하였습니다.

Module

▶ 소개

모듈은 코드 재사용성과 구성 관리 용이성을 높이는 기능
테라폼으로 인프라와 서비스를 관리하면 시간이 지날수록 구성이 복잡해지고 관련하는 리소스가 늘어나게 된다
테라폼의 구성 파일과 디렉터리 구성에는 제약이 없기 때문에 단일 파일 구조상에서 지속적으로 업데이트 할 수 있지만, 아래와 같은 문제 발생한다
- 테라폼 구성에서 원하는 항목을 찾고 수정하는 것이 점점 어려워짐
- 리소스들 간의 연관 관계가 복잡해질수록 변경 작업의 영향도를 분석하기 위한 노력이 늘어남
- 개발/스테이징/프로덕션 환경으로 구분된 경우 비슷한 형태의 구성이 반복되어 업무 효율이 줄어듬
- 새로운 프로젝트를 구성하는 경우 기존 구성에서 취해야 할 리소스 구성과 종속성 파악이 어려움
모듈은 루트 모듈과 자식 모듈로 구분
- 루트 모듈 Root Module : 테라폼을 실행하고 프로비저닝하는 최상위 모듈
- 자식 모듈 Child Module : 루트 모듈의 구성에서 호출되는 외부 구성 집합
모듈은 테라폼 구성의 집합이다. 테라폼으로 관리하는 대상의 규모가 커지고 복잡해져 생긴 문제를 보완하고 관리 작업을 수월하게 하기 위한 방안으로 활용
- 관리성 : 모듈은 서로 연관 있는 구성의 묶음. 원하는 구성요소를 단위별로 쉽게 찾고 업데이트할 수 있다.
모듈은 다른 구성에서 쉽게 하나의 덩어리로 추가하거나 삭제할 수 있다. 또한 모듈이 업데이트되면 이 모듈을 사용하는 모든 구성에서 일관된 변경 작업을 진행할 수 있다.
- 캡슐화 : 테라폼 구성 내에서 각 모듈은 논리적으로 묶여져 독립적으로 프로비저닝 및 관리되며, 그 결과는 은닉성을 갖춰 필요한 항목만을 외부에 노출
- 재사용성 : 구성을 처음부터 작성하는 것에는 시간과 노력이 필요하고 작성 중간에 디버깅과 오류를 수정하는 반복 작업이 발생한다. 테라폼 구성을 모듈화하면 이후에 비슷한 프로비저닝에 이미 검증된 구성을 바로 사용할 수 있다.
- 일관성과 표준화 : 테라폼 구성 시 모듈을 활용하는 워크플로는 구성의 일관성을 제공하고 서로 다른 환경과 프로젝트에도 이미 검증한 모듈을 복잡한 구성과 보안 사고를 방지할 수 있다.

모듈 작성 기본 원칙

▶ 기본 원칙 : 모듈은 대부분의 프로그래밍 언어에서 쓰이는 라이브러리나 패키지와 역할이 비슷
[ 아래와 같은 기본 작성 원칙을 제안]

모듈 디렉터리 형식을 terraform-<프로바이더 이름>-<모듈 이름> 형식을 제안.
이 형식은 Terraform Cloud, Terraform Enterprise에서도 사용하는 방식으로
1) 디렉터리 또는 레지스트리 이름이 테라폼을 위한 것
2) 어떤 프로바이더의 리소스를 포함
3) 부여된 이름이 무엇인지 판별
할 수 있도록 한다
테라폼 구성은 궁긍적으로 모듈화가 가능한 구조로 작성할 것을 제안
처음부터 모듈화를 가정하고 구성파일을 작성하면 단일 루트 모듈이라도 후에 다른 모듈이 호출할 것을 예상하고 구조화할 수 있다
또한 작성자는 의도한 리소스 묶음을 구상한 대로 논리적인 구조로 그룹화할 수 있다
각각의 모듈을 독립적으로 관리하기를 제안한다
리모트 모듈을 사용하지 않더라도 처음부터 모듈화가 진행된 구성들은 때로 루트 모듈의 하위 파일 시스템에 존재하는 경우가 있다
하위 모듈 또한 독립적인 모듈이므로 루트 모듈 하위에 두기보다는 동일한 파일 시스템 레벨에 위치하거나 별도 모듈만을 위한 공간에서 불러오는 것을 권장
이렇게 하면 VCS를 통해 관리하기가 더 수월
공개된 테라폼 레지스트리의 모듈을 참고하기를 제안
대다수의 테라폼 모듈은 공개된 모듈이 존재하고 거의 모든 인수에 대한 변수 처리, 반복문 적용 리소스, 조건에 따른 리소스 활성/비활성 등을 모범 사례로 공개
물론 그대로 가져다 사용하는 것보다는 프로비저닝하려는 상황에 맞게 참고하는 것을 권장
작성된 모듈은 공개 또는 비공개로 게시해 팀 또는 커뮤니티와 공유하기를 제안
모듈의 사용성을 높이고 피드백을 통해 더 발전된 모듈을 구성할 수 있는 자극이 된다

모듈을 독립적으로 관리하기 위해 디렉터리 구조를 생성할 때 모듈을 위한 별도 공간을 생성하는 방식으로 진행
특정 루트 모듈 하위에 자식 모듈을 구성하는 경우 단순히 복잡한 코드를 분리하는 요도로 명시되며 종속성이 발생하므로 루트 모듈 사이에 모듈 디렉터리를 지정

모듈화 해보기

▶ 모듈화 소개

모듈의 기본적 구조는 테라폼 구성으로 입력 변수를 구성하고 결과를 출력하기 위한 구조로 구성
'모듈화'라는 용어는 이런 구조를 재활용하기 위한 템플릿 작업을 말한다
애플리케이션 개발시에도 자주 사용되는 용어로 테라폼은 작성된 모듈을 다른 루트 모듈에서 가져다 사용하며 이를 통해 재사용성과 표준화 구조를 구성할 수 있다
모듈에서 필요한 값은 variable로 선언해 설정하고, 모듈에서 생성된 값 중 외부 모듈에서 참조하고 싶은 값은 output으로 설정한다. 마치 자바 개발 시 getter, setter로 캡슐화된 클래스를 활용하는 것과 비슷

▶ 모듈 작성 실습

하나의 프로비저닝에서 사용자와 패스워드를 여러 번 구성해야 하는 경우를 가상의 시나리오로 삼아 모듈화를 진행
- random_pet는 이름을 자동으로 생성하고, random_password는 사용자의 패스워들 설정한다
- random_password는 random 프로바이더 리소스로 난수 형태로 패스워드를 만들 수 있다

[ 자식 모듈 작성 ]

디렉터리 생성 및 06-module-training/modules/terraform-random-pwgen/main.tf variable.tf output.tf 파일 생성

[ 자식 모듈 호출 실습 ]

다수의 리소스를 같은 목적으로 여러 번 반복해서 사용하려면 리소스 수만큼 반복해 구성 파일을 정의해야 하고 이름도 고유하게 설정해줘야 하는 부담이 있지만, 모듈을 활용하면 반복되는 리소스 묶음을 최소화할 수 있다
디렉터리 생성 및 06-module-traning/06-01-basic/main.tf 파일 생성

모듈 사용 방식

▶ 모듈과 프로바이더

모듈에서 사용되는 모든 리소스는 관련 프로바이더의 정의가 피ㅣㄹ요하다
여기서 사용자는 프로바이더 정의를 모듈 안 or 밖 고민이 필요하다

(유형1) 자식 모듈에서 프로바이더 정의

모듈에서 사용하는 프로바이더 버전과 구성 상세를 자식 모듈에서 고정하는 방법
- 프로바이더 버전과 구성에 민감하거나, 루트 모듈에서 프로바이더 정의 없이 자식 모듈이 독립적인 구조일 때 고려할 방법
- 하지만 동일한 프로바이더가 루트와 자식 양쪽에 또는 서로 다른 자식 모듈에 버전 조건 합의가 안되면, 오류가 발생하고 모듈에 반복문을 사용할 수 없다는 단점이 있어 잘 사용하지 않는다

(유형2) 루트 모듈에서 프로바이더 정의

자식 모듈은 루트 모듈의 프로바이더 구성에 종속되는 방식
디렉터리 구조로는 분리되어 있지만 테라폼 실행 단계에서 동일 계층으로 해석되므로 프로바이더 버전과 구성은 루트 모듈의 설정이 적용된다. 프로바이더를 모듈 내 리소스와 데이터 소스에 일괄 적용하고, 자식 모듈에 대한 반복문 사용에 자유로운 것이 장점.
자식 모듈에 특정 프로바이더 구성의 종속성은 반영할 수 없으므로 자식 모듈을 프로바이더 조건에 대해 기록하고, 자식 모듈을 사용하는 루트 모듈에서 정의하는 프로바이더에 맞게 업데이트 해야 한다.
다음은 동일한 모듈에 사용되는 프로바이더 조건이 다른 경우 각 모듈별로 프로바이더를 맵핑하는 방안
리소스와 데이터 소스에 provider 메타인수로 지정하는 방식과 비슷하나 모듈에는 다수의 프로바이더가 사용될 가능성이 있으므로 map 타입으로 구성하는 provider로 정의

루트 모듈에서 init 시 자식 모듈을 호출하므로 modules.json 파일 생성

▶ 모듈의 반복문

모듈 또한 리소스에서 반복문을 사용하듯 구성 가능
모듈이라는 리소스 정의 묶음을 원하는 수량으로 프로비저닝할 수 있으므로 모듈 없이 구성하는 것과 대비해 리소스 종속성 관리와 유지 보수에 장점이 있다. count를 사용한 반복문 사용은 리소스에서의 사용 방식처럼 module 블록 내에 선언

: 모듈 묶음에 일관된 구성과 구주로 프로비저닝이 되는 경우라면 count가 간편한 방안이지만,
동일한 모듈 구성에 필요한 인수 값이 다르다면 for_each를 활용

(실습) 동일한 모듈에 개발과 상용에 대한 입력 변수를 다르게 처리하는 방식

: 각각의 인스턴스 타입에 맞게 배포

모듈 소스 관리

▶ 모듈 소스 관리

Module 블록에 정의된 소스 구성으로 모듈의 코드 위치를 정의
terraform init을 수행할 때 지정된 모듈을 다운로드해 사용
- 로컬 디렉터리 경로
- 테라폼 레지스트리
- 깃허브
- 비트버킷
- 깃
- HTTP URLs
- S3 Bucket
- GCS Bucket
테라폼 공식 문서 안내와 같이 루트 경로에 모듈을 배치하는 것 외에 패키지 하위 데릭터리 경로를 참조하는 것도 하나의 방안

로컬 디렉터리 경로

로컬 경로를 지정할 때는 테라폼 레지스트리와 구분하기 위해 하위 디렉터리는 ./로, 상위 디렉터리는 ../로 시작
대상 모듈은 이미 같은 로컬 파일 시스템에 존재하므로 다운로드 없이 바로 사용한다.
앞서 언급한 대로 재사용성이 고려된다면 상위 디렉터리에 별도 관리하는 것을 권장하고, 항상 루트 모듈과 함께 동작해야 하는 경우 하위 디렉터리에 모듈을 정의한다.
코드 예시) 작업 환경을 기준으로 하는 로컬 경로 상위에 위치한 모듈 경로 선언

module "local_module" {
  source = "../modules/my_local_module"
}

테라폼 레지스트리

테라폼 모듈 레지스트리는 테라폼의 프로토콜을 사용해 모듈을 사용하는 방식
공개된 테라폼 모듈을 사용하거나 Terraform Cloud, Terraform Enterprise에서 제공되는 비공개 테라폼 모듈을 사용할 때 설정하는 소스 지정 방식
공개된 모듈
공개된 테라폼 모듈을 source에 선언할 때는 <네임스페이스>/<이름>/<프로바이더> 형태로 설정

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.1.0"
}

[ Modules Use registry modules in configuration ]

Review configuration

terraform.tf : 테라폼 블록 확인
main.tf : 모듈 블록 확인(모듈 소스, 버전) - arguments 확인, ec2 count 2 확인

input variable - https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/3.14.0?tab=inputs
: input 원하는 값을 넣어서 원하는 환경 구성 가능

: 각각의 input 값은 위의 링크에서 확인 가능

terraform get ???

terraform get -h 로 하여 상세 내용 확인 가능

▶ 깃허브

깃의 원격 저장소로 널리 알려진 깃허브는 테라폼 구성에 대한 CI 용도로 사용할 수 있고, 저장된 구성을 테라폼 모듈의 소스로 선언할 수도 있다.
6.3에서 사용한 06-module-traning/modules/terraform-aws-ec2/ 를 깃허브에 업로드하는 과정
1. 깃허브에 로그인
2. 새로운 깃허브 저장소 생성 [New repository]
- Owner : 원하는 소유자 선택
- Repository name : 예시)terraform-module-repo
- Public 선택
- Add .gitignore의 드롭박스에서 [Terraform]을 선택
3. 맨 아래 [Create repository] 클릭
4. 해당 저장소에 예시) terraform-aws-ec2 디렉터리 생성 후 main.tf, variable.tf,. output.tf 추가 후 업로드

Terraform Runner

[국내]

Terraform을 GitOps 방식으로 사용하기 위한 도구 선택 - Link
Atlantis 란? (Terraform Pull Request Automation) - Link
펫프렌즈가 DevOps 조직없이 인프라를 관리하는 방법 - Link
Atlantis 배포하기 - Link
Github에서 Atlantis를 이용한 Terraform 협업 환경 구축 - Link Github
Jenkins + terraform + tfsec 로 정적 분석 자동화 구성 하기 - Link

[해외]

install-atlantis-docker-container-in-amazon-linux-integrate - Link Github
Hacking Atlantis - Youtube
[CNCF] How Breaking up Our Infrastructure Monorepos Saved Us from Pul... Donnie Laughton - Youtube

Atlantis

: 여러명이 동시에 타겟대상을 배포할 때 관리가 통하는데 관리는 Git을 통해 하고 Git Hub에 있는 코드가 Atlantis 에 전달되면 인프라 생성
: Atlantis Server - 상호통신 서버 ( .GIT Hub가 코드 전송하면 terraform plan/apply 결과를 Git hub에 전달 )

: Pull Request 기반으로 Terraform 워크플로우를 자동화하는 오픈 소스 도구
(Terraform 코드 변경 사항을 검토하고 승인하며 자동으로 적용하는 데 도움을 줌)

[ Atlantis 핵심 기능 ]
: Terraform Atlantis는 인프라 코드를 관리하는 팀들에게 매우 유용한 도구
: 여러 팀원이 Terraform 코드를 사용하여 변경하는 경우, 코드 검토, 승인 및 적용 프로세스를 자동화하고 효율화하는 데 큰 도움이 됨

Pull Request 기반 자동화 : 새로운 Pull Request가 발생하면 Atlantis가 자동으로 Terraform Plan 및 Apply 단계를 수행하여 코드 변경 사항이 인프라에 미치는 영향을 확인하고 실제 적용
승인 및 검토 : 코드 변경 사항이 적용되기 전에 팀원들의 승인을 요구하여 오류나 의도하지 않은 변경 방지
심층적인 검사 로그 : 모든 인프라 변경 사항, 승인 및 사용자 작업에 대한 자세한 로그를 제공하여 투명성을 높이고 문제 해결을 용이하게 함
Git 통합 : GitHub, GitLab, Bitbucket 등 다양한 Git 플랫폼과 통합되어 원활하게 작업할 수 있다

MYKEYNAME=kp-gasida aws cloudformation deploy --template-file t101-atlantis-ec2.yaml --stack-name t101 --parameter-overrides KeyName=$MYKEYNAME SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32 --region ap-northeast-2 # [모니터링] CloudFormation 스택 상태

SgIngressSshCidr -> 보안 그룹 ( 모든 프로토콜로 허용 )

[ Atlantis 실습 ]

1. t101-atlantis-ec2.yaml 파일 다운로드 받기

2. yaml 파일이 있는 경로에서 아래와 같이 CloudFormation 스택 배포

MYKEYNAME=<각자 자신의 AWS EC2 서울 리전 Keypair 이름>
aws cloudformation deploy --template-file t101-atlantis-ec2.yaml --stack-name t101 --parameter-overrides KeyName=$MYKEYNAME SgIngressSshCidr=$(curl -s ipinfo.io/ip)/32 --region ap-northeast-2

# [모니터링] CloudFormation 스택 상태
while true; do 
  date
  AWS_PAGER="" aws cloudformation list-stacks \
    --stack-status-filter CREATE_IN_PROGRESS CREATE_COMPLETE CREATE_FAILED DELETE_IN_PROGRESS DELETE_FAILED \
    --query "StackSummaries[*].{StackName:StackName, StackStatus:StackStatus}" \
    --output table
  sleep 1
done

# EC2 공인 IP 확인
aws cloudformation describe-stacks --stack-name t101 --query 'Stacks[*].Outputs[0].OutputValue' --output text

▶ 공인IP 혹은 도메인 노출 설정

# URL 변수 지정
URL="http://$(curl -s ipinfo.io/ip):4141"
echo $URL

★ 집에서 자신의 PC에 Atantis 설치 후 사용 시에는, (iptime) 공유기에 tcp 4141 포트 포워딩 설정

▶ Git Repo (Private) 생성

▶ Git Token 생성

: Settings - Developer settings - Personal access tokens - Tokens (classic)

- Create an access to token for Atlantis

TOKEN="{YOUR_TOKEN}"

- Create a Webhook Secret

# Create a random string of any length (you can use random.org) and set an environment variable:
SECRET="{YOUR_RANDOM_STRING}"

- Add Webhook : check the boxes ( Issue comments, Pull request reviews, Pushes, Pull requests)

▶ Start Atlantis

USERNAME="{the username of your GitHub, GitLab or Bitbucket user}"
REPO_ALLOWLIST="$YOUR_GIT_HOST/$YOUR_USERNAME/$YOUR_REPO"

# 변수 설정 확인
echo $URL $USERNAME $TOKEN $SECRET $REPO_ALLOWLIST

# Atlantis 서버 실행
./atlantis server \
--atlantis-url="$URL" \
--gh-user="$USERNAME" \
--gh-token="$TOKEN" \
--gh-webhook-secret="$SECRET" \
--repo-allowlist="$REPO_ALLOWLIST"

* error 발생
- error message : Not a valid object name : 'main'.

원인 : 최초 commit을 하지 않았기 때문
해결 방법 : git add . , git commit -m "first commit" 실행 후 branch 생성 시 성공

[ aws iam user 생성 ]

▶ AWS S3 버킷 생성 : Terraform Backend State 저장용도
-> Atlantis는 Local State를 지원하지 않으므로 S3나 Terraform Cloud를 사용하여 Remote Backend 설정 필요

▶ Local에서 Git 코드 작업

▶ Github(Create a pull request) -> Atlantis 확인

Add a comment => apply 결과 화면 확인

* error 발생
- error message : Running atlantis apply is disabled.

원인 : atlantis apply enable 필요
해결 방법 : atlantis 웹 페이에서 ENABLE APPLY COMMANDS 클릭 필요

[ 리소스 삭제 ]

▶ Local에서 Git 코드 작업

실습 자원 삭제

1. CMD 작업

2. GitHub Repo 삭제

3. GitHub Token 삭제

4. 로컬 Github 코드 삭제

'스터디 > Terraform' 카테고리의 다른 글

[Terraform T101 4기 스터디] - OpenTofu (1)	2024.07.29
[Terraform T101 4기 스터디] - 테라폼으로 AWS EKS 배포 (0)	2024.07.22
[Terraform T101 4기 스터디] - Provider & State (2) (1)	2024.07.02
[Terraform T101 4기 스터디] - Provider & State (0)	2024.07.01
[Terraform T101 4기 스터디] - 기본 사용 (3)_2 (0)	2024.06.24

QwakCheol