3강 Infrastructure as Code 의 최고 인기Terraform(테라폼) 현직 DevOps 엔지니어, AWS Hero 가 이야기하는 Terraform 기본설명!

<3강 Infrastructure as Code 의 최고 인기Terraform(테라폼) 현직 DevOps 엔지니어, AWS Hero 가 이야기하는 Terraform 기본설명!>

 

3월 24일~29일

 

 

복습 

=====================================================================================

Infrastructure as Code, 코드로써의 인프라

:인프라를 이루는 서버, 미들웨어 그리고 서비스 등, 인프라 구성요소들을 코드를 통해 구축하는 것.

 

코드로써의 장점

-작성용이성

-재사용성

-유지보수

 

 

Terraform 구성요소

 

provider                 테라폼으로 생성할 인프라의 종류를 의미한다.

resource                테라폼으로 실제로 생성할 인프라 자원의 의미한다.

state                      테라폼을 통해 생성한 자원의 상태를 의미한다.(파일 형태로 남게 된다.)

output                    테라폼으로 만든 자원을 변수 형태로 state에 저장하는 것을 의미한다.

module                  공통적으로 활용할 수 있는 코드를 문자 그대로 모듈 형태로 정의하는것을 의미.
                              (재사용하는데 굉장히 강점이 있고 중급, 고급 과정으로 갈 수록 모듈 사용을 빼놓을 수가 없다.)

 

remote                  다른 경로의 state를 참조하는것을 말한다. output 변수를 불러올때 주로 사용한다.

                              (다양한 스테이트 파일을 생성하게 될텐데, 다른 경로의 스테이트 파일을 참조하는 것을 말한다.) 

 

=====================================================================================

 

 

 

 

 

실제 프로바이더들이 여기 위치(노란AWS)하게 되고 그 프로바이더들마다 각각의 인자값이 들어가게 된다.

보통 내부적으로 만약 aws라면

aws 리소스를 다루기 위한 파일들을 다운로드 하는 역활을 한다.(SDK같은 파일들을 다운로드 하는 역활)

 

 

<리소스>

resource

=>코드형태는 resource가 가장 먼저 오게 되고,

"aws_vpc"

=>그 리소스의 이름이 오게 된다. aws_vpc 어떤 리소스를 만들지에 대한 명시이다.

aws_lb 이런 것들이 있다.

"example"

=>실제 이름이 된다.

이런 또 인자값이 들어가게되고 각 리소스 마다 수많은 인자값들이 존재하게 된다.

 

 

위 코드는 aws_vpc를 만드는 코드이다.

 

 

<테라폼 스테이트>

테라폼으로 작성한 코드를 실제로 실행하게 되면 생성되는 파일인 것이다.

현업에서는 계속 작성하게 되면 수천줄, 수만 줄까지도 늘어나게 된다.

 

==>테라폼 명령어를 실행하게 되서 생성한 리소스들의 결과값이지 우리 인프라의 실제 상태는 아니라는 것이다.

즉, 스테이트 파일과 현재 인프라의 상태를 똑같이 유지하는게 키포인트이다.

스테이트 파일은 원격 저장소인 'backend'에도 저장 될 수 있다.

대부분 이제 협업에서는 backend들을 사용하고 있다.

 

이런 lineage 값들은 나중에는 알아야만 하는 값들이다.

 

 

 

<아웃풋>

위와 같이 aws vpc코드를 만들었다고 보면 

vpc ID나 cidr값들이 생기는데 그런것들을 참조해서 vpc id란 형태의 변수를 스테이트 파일로 저장을 하는 것이다.

 

03-28

 이 값들은 리모트를 사용해서 재사용을 할 수가 있다.

모듈은 보통 이렇게 명시를 하게 되어있다.

실제 모듈 코드, 리소스에 대한 코드는 

이렇게 경로로써 포함하게 되고, 이 하위 경로로 TF파일들 = 리소스 파일들이 이제 위취 하게 된다.

그리고 여기 안에 들어갈 인자값들 ->Variable 값들을 이렇게 넣어 주게 되는 것이고,

한번 만들어진 테라폼코드들을 같은 형태로 반복적으로 만들어야 할때 주로 사용하게 되는 것이다.

역시 재사용에 대한 강점이 있다.

모듈을 어떻게 쓰느냐에 따라 테라폼을 굉장히 잘 쓰냐 안 쓰냐를 판단하기도 한다.

 

<리모트 스테이트>

리모트는 원격 참조 개념으로 이해하면 된다. 

==>고유값이다.

bucket     ==> 보안 어떤 버킷, 백인드 s3 버킷을 의미한다.

 

region     ==>어떤 리전값

 

kdy          ==>거기에 대한 키값을 명시하게 되면 

여기에 저장된 스테이트 값을 참조할 수 있게 되는 것이다.

라는 값으로 참조 한다.

결국에 스테이트 파일에서 아웃풋으로 저장된 변수들을 가져오 게 된 것이다.

=========>실습예정

 

03-29

<3-2강 Terraform 기본 명령어>

IaC 도구인 Terraform구성요소와 기본 명령어

 

테라폼 명령어 

●init               

테라폼 명령어 사용을 위해 각종 설정을 진행한다.

(최초의 테라폼 명령어를 실행할때 해주어야 하는 명령어이다)

 

●plan          

테라폼으로 작성한 코드가 실제로 어떻게 만들어질지에 대한 예측 결과를 보여준다.

(실제로 가장 많이 쓰이는 명령어이다.)

 

●apply           

테라폼 코드로 실제 인프라를 생성하는 명령어 이다.

 

●import           

이미 만들어진 자원을 테라폼 state 파일로 옮겨주는 명령어 이다.

(aws에 미리 route53같은 걸 만들었는데 그런 것들을 스테이트 파일로 옮겨주는 명령어이다.

이미 만들어진 자원을 코드로 만들고 싶을 때 주로 사용하게 되는 명령어)

 

●state             

테라폼 state 를 다루는 명령어 이다. 하위 명령어로 mv, push와 같은 명령어가 있다.

(다양한 하위 명령어를 가지고 있다. 스테이트 파일을 다를 때 사용하는 명령어 이다.

자주는 아니지만 꼭 언젠가는 사용하게 되는 명령어라서 알아 두고 있어야 하는 명령어 이다.)

 

●destroy       

 생성된 자원들 state 파일 모두 삭제하는 명령어이다.

("다시 만들어야지"할때 쓰는 명령어이다.)

 

 

 

 

<프로세스>

Init

앞단에 작성한 코드가 있다는 가정을 할 경우

보통 프로세스가 init을 처음하게 되고 plan을 하게 되고, 이제 Apply를 하게 된다.

 

Plan

기본적으로 Plan에 문제가 없어야 apply에 문제가 없을 확률이 높지만 100%는 아니다. Plan의 결과가 100%제대로 생성할 거를 보장해 주지는 않는다. 우리가 생성해야 할 리소스 같은 것들이 굉장히 복잡한 경우에는 문법 실수도 있고 그런 경우를 100% 보장해 주지는 않는다.

 

Apply

실제로 작성한 코드를 테라폼 명령으로 자원을 생성하는 명령어 이다. 실제 인프라에 영향을 끼치는 명령이기 때문에 굉장히 주의깊게 실행을 해야 한다. 그래서 항상 플랜을 치는 것을 습관화 하는것을 권장한다. 이걸 바꿔도 플랜을 한번 해보고 이런 걸 습관을 들이는 게 중요하다는 것이다. 왜냐면 이 코드를 다루는 것보다 실제로 인프라에 apply를 한다는 건 실제 우리의 서비스가 돌아가고 있는 서버에 변경을 한다는 건 굉장히 큰 결과로돌아올 수 있다. 따라서 굉장히 주의 깊게 실행을 해야 한다. 한 번 확인하고 두 번 확인하고 

 

이밖에도 다른 명령어가 많지만, 기본 명령어 습득 이후에 시작해도 괜찮다

:테라폼은 정말 다양한 기능을 지원한다. 하지만 기본 명령어가 충분히 익숙해지고 시작해도 전혀 늦지 않다.

실제로 기본 명령의 사용 빈도가 90% 이상을 차지한다. 쓰면서 배우면 된다!

 

 

출처: https://www.youtube.com/watch?v=3qSpwqckvXQ