Providers

  • Official : Terraform (AWS, GCP, Azure…)
  • Verified : 3rd party. heroku …
  • Community

terraform init

여러번 수행해도 아무 문제 없다.

단순히 Provider Plugin을 받는것. ~/.terraform/Plugin 에 설치

Hostname/Organizational Namespace/type 형태로 설치됨

Plugin은 최신 버전으로 다운 받는다.



Configuration Directory

테라폼은 해당 경로에서 확장자가 tf인 파일은 전부 다 읽어서 처리함

보통 main.tf , variable.tf, output.tf, provider.tf 로 지정


Variables

variable 로 시작하여 선언

var.변수명으로 사용

type이 LIst인 경우: var.변수명[0] 부터 시작. 인덱스는 0부터 시작

type이 Map인 경우 : var.변수명[“키명”]

type이 set인 경우 : list와 비슷하지만, 중복할 수 없다. 중복 요소가 있는 경우 에러 발생

type이 Tuple인 경우 : 리스트와 비슷하지만, 각각의 요소들이 각각의 type을 가질 수 있다.

Variable에 default 값을 입력하지 않을 경우, terraform 명령 수행시 직접 입력해야 한다.

Variable 선언 방식

Environment Variable : export TF_VAR_변수명

*.tfvars 파일에 선언

*.auto.tfvars 파일에 선언

명령어로 선언

variable.auto.tfvars 에 입력하면 자동으로 var 입력이 된다.

variable 입력 순서. 뒤로 갈수록 앞의 순번의 것을 덮어쓰므로 더 우선순위가 된다.

1번. Environment Vairables : $export TF_VAR_filename=”/root/cats.txt”

2번. terraform.tfvars : terraform.tfvars에 선언

3번 variable.auto.tfvars : 파일에 선언

4번 명령어 플래그 : terraform apply -var “filename=/root/cats.txt”

Resource Dependencies

Implicit Dependency : 암묵적으로 다른 리소스의 속성을 가져다 쓰는경우. 먼저 지워야한다.($resource_type.resource_name.attribute)

Explicit Dependency : depends on으로 명시적으로 기술한 경우 (왜 이걸 쓰는지 확인 필요)

Output Variables

output 블럭 사용

output “변수명” {
value = variable_value
….
}

$ terraform output 으로 모든 output 변수를 확인할 수 있다.
$ terraform output 변수명 으로 해당 변수명에 대한 값을 확인할 수 있다.

앤서블이나 쉘 스크립트에서 사용가능하다.

Terraform state

terraform init : plugin 받는다

terraform plan :

terraform apply :

terraform.tfstate : 테라폼 스테이트 파일. apply 명령어로 생성됨. json 데이터 구조. 테라폼 명령어로 생성된 모든 인프라가 적혀 있음. single source of truth 로 사용됨
plan 시 tfstate 파일과 비교해서 작성하게 됨

tfstate 파일 사용
– 종속관계 파악 : 리소스들간의 종속성을 파악하여, 생성/삭제 시 디펜던시가 있는 리소스 먼저 삭제한다.
– 성능 : tfstate 파일을 직접 사용할 뿐만 아니라 캐싱 처리도 해둠. 대규모 인프라를 사용하는 곳에서는 매번 tfstate 파일을 refresh 하면 시간이 많이 걸리기 때문에 terraform plan –refresh=false와 같은 명령어로 캐시에서도 사용가능함
– Collaboration : 팀으로 일하는 경우 terraform.tfstate 파일을 팀원간에 공유하여 remote state로 관리한다.

tfstate 고려할점
– state 파일은 민감한 정보를 포함한 인프라의 모든 정보를 다 담고 있다. DB라면 비밀번호도 가지고 있다.
– state 파일은 안전한 스토리지에 저장해두어야 한다.
– tf 파일은 깃헙 정도면 되지만, state 파일은 S3나 gcp bucket 같은 안전한곳에 보관한다.
– tfstate 파일을 직접 건드리지 않는다.

terraform 명령어

– terraform validate : tf 파일이 유효한지 확인한다.
– terraform fmt : tf파일을 보기 좋은 형태(cannonical format)로 변경해준다.
– terraform show : 생성된 인프라의 모든 정보를 다 보여준다.(-json 플래그로 json 형태로 표시가능)
– terraform providers : provider 정보를 다 보여준다.
– terraform output : 결과로 생성되는 변수를 다 보여준다.
– terraform refresh : 테라폼으로 만든 인프라를 수동으로 수정한 경우, tfstate 파일을 현재 상태에 맞도록 수정한다.
– terraform graph : apt install graphviz -y 설치하여 terraform graph | dot -Tsvg > graph.svg 로 파일 생성 후 파일 열면, 리소스 간의 형태를 그래프형태로 볼수 있다.

Mutalbe vs Immutable Infrastructure

테라폼은 왜 인프라를 다 부셨다가 다시 만들까? 서버의 버전을 올린다고 생각해보면, 서버 여러대를 운영할 경우 기존 서버를 업그레이드 하는 건 업그레이드 과정에서 여러가지 이슈가 발생할 수 있다.(configuration drift) 서버들이 운영 중에 미묘하게 차이가 날 수 있다.

따라서 버전이 올라간 서버를 새로 만들고, 오래된 버전의 서버를 폐기한다. -> Immutable Infrastructure 버전을 올린 서버에 문제가 생긴 경우, 다시 이전 버전의 서버를 살린다. 인프라 스트럭처에 버저닝을 하는건 롤백도 쉽고, 운영도 쉽다.

'cloudnative' 카테고리의 다른 글

ArgoCD 사용자 계정 설정(권한)  (0) 2023.01.25