DevOps:Infrastructure as Code with 테라폼(Terraform) and AWS - 사전준비 편

본 포스팅은 송주영님의 인프런 DevOps:Infrastructure as Code with 테라폼(Terraform) and AWS를 보고 개인적으로 정리한 내용입니다.

Terraform 기본

구성요소

• provider - 생성할 인프라 종류 ex) AWS
• resource - 실제로 생성할 인프라 자원
• state - 생성한 자원 상태. 테라폼 명령어 실행시 결과값으로 나오므로, 실제 상태와 같게 유지해주는것이 키포인트
• output - 만든 자원을 변수형태로 state에 저장
• module - 재사용 가능한 코드를 모듈형태로 정의
• remote - 다른 경로의 state를 참조. output 변수를 불러올때 주로 사용

기본 명령어

init / plan / apply / import / state / destroy

• init : 다른명령어들을 위한 설정 진행, provider와 state, module 설정이 있음
• plan : 테라폼코드 예측결과 제시, 가장 많이 쓰임
• apply : 실제작성한 코드로 명령어 생성, 인프라에 영향을 끼치므로 주의
• import : 이미 만들어진 자원을 테라폼 state로 옮겨옴
• state : state를 다루는 명령어, 하위 명령어로 mv, push 등
• destroy : 생성된 자원(state)들을 모두 삭제

기본 명령어 프로세스

init - plan - apply

Zsh 및 Oh-my-zsh 설치

세팅

• Zsh 설치
  • sudo yum install zsh - 아마존 리눅스
  • sudo apt-get install zsh - ubuntu
• Zsh 기본 쉘로 설정
  • amazon linux 포함 몇몇 os들은 sudo yum install util-linux-user.x86_64 - ubuntu는 하지 않아도 됨
  • 패스워드 입력해야 할 경우 sudo passwd <username>으로 패스워드 변경
  • chsh -s /bin/zsh
• Oh-my-zsh 설치
  • sudo yum install git으로 git 설치
  • curl -L https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh | sh
• zsh 설정 변경
  • ~/.zshrc에서 테마 변경

이 세팅의 장점

• 중간자 검색을 통한 autocompletion
  • 수십 수백번을 치는 명령어들을 tab 자동완성으로 간단하게 칠 수 있다
• Git UI 개선

AWS CLI 및 Terraform 설치

AWS CLI

• version 1, 2 중 2로 설치(기능이 더 많음) - Amazon Linux는 기본적으로 설치되어있음
• 설치 후 unzip, install(사이트 참조)

Terraform

• wget <link address> - terraform 설치 링크를 넣는다.
• Go 언어로 만들어진 파일이므로, unzip 후 binary 파일을 echo $PATH의 경로에 옮겨준다.

AWS Configure 설정

설정법

IAM 계정에서 진행할것(정석).

• Access Key : AWS security credentials에서 가져옴
• Secret Access Key : AWS security credentials에서 가져옴. 생성할때만 볼수 있으니 다운로드 하든지, 복사해놓든지
• region name : 서울의 경우 ap-northeast-2
• output format : text 혹은 json을 주로 사용

현재 접속한 사용자가 누군지 확인하려면 aws sts get-caller-identity

Terraform 기본

작동원리

Terraform의 3가지 형상

1. Local 코드 : 현재 개발자가 작성/수정하는 코드
2. AWS 실제 인프라 : 실제 AWS에 배포되어 있는 인프라
3. Backend에 저장된 상태 : 가장 최근에 배포한 state파일

가장 중요한 것은 2와 3이 일치하도록 만드는것.

배포되어있는 것과 저장된 state파일이 일치하지 않는 경우의 예는 다음과 같다.

• state 파일에 인프라 상태가 저장되어 있는 채로, 인프라를 콘솔에서 변경하는경우
• 인프라를 변경하여 state 파일을 기록하지 않고, state 파일을 직접 변경하는 경우
• local에서 state 파일을 변경하였으나, 다른 사람과 state 파일의 싱크가 어긋난 경우

과정

• provider, resource 등 작성 이후 init (따로 설정하지 않으면 최초 backend는 로컬)
• plan으로 결과 예상
  • 이 때, plan은 backend의 .tfstate / 실제 리소스 / 로컬 코드(.terraform)를 모두 확인하여 예측결과를 보여준다
  • apply 시, 로컬 코드를 기준으로 상태를 적용시킨다.
• apply로 현재 코드를 실제 인프라에 반영 후 state에 기록
• 현재 state 상태는 state list로 확인
• 인프라에 배포된 서비스를 state로 옮겨오고 싶다면 import 사용

201115 추가

Basic한 테라폼 파일의 분류는 다음과 같다.

1. provider.tf - 리소스를 생성할 프로바이더 명시
2. <resource>.tf - 프로바이더에 생성되는 리소스의 설정 코드
3. .terraform 폴더 - 로컬에서 반영한 테라폼 형상에 대한 설정파일. 로컬 코드 기록만 남으므로 타인의 apply 기록은 남지 않는다.
4. terraform.tfstate - 테라폼 apply로 반영된 형상 결과 저장 코드. 협업 시 자신의 코드와 타인의 코드를 동기화하기 위해 필요하다. 설정한 backend 위치에 저장된다.

즉 terraform.tfstate 코드(파일)는 협업을 위해 공유하는 형상 코드라고 생각하면 된다.