Terraform
- 모듈 : 모듈 호출, 지역 변수, 모듈 출력, 입력 매개변수
- 반복문 : count 매개변수
1교시
루트 모듈 : 인프라 구축 코드(모듈 코드)가 실제로 작동한 위치
global\s3에서 init > plan > apply 하고, stage에서 진행하고.
모듈에 있는 main.tf 파일은 배포할 목적이 아니다. 다른 곳에서 이 파일을 끌어다 쓰는 것.
-> 모듈 코드에 리전 정보나 인프라 이름 등은 작성할 필요가 없다
2교시
이 코드를 이해하는 것이 중요하다.
-> user-data.sh라는 파일을 모듈이 있는 경로에서 가져온다
-> server_port는 현재 경로에 있는 variables.tf 파일에서 가져온다
-> db_address/db_port는 현재 main.tf의 terraform_remote_state 유형의 db라는 이름의 작업에서 가져오는데...
terraform_remote_state.db는 백엔드 기능에 의해 S3 버킷에 저장된 상태 정보 파일을 가리킨다.
즉 상태 저장 파일을 보고 outputs를 확인해서 address와 port 출력 값을 가져오는 것이다.
- 모듈과 지역 변수
모듈을 끌어와 사용할 때 입력 변수를 작성했는데, 하드 코딩으로 하나하나 박아넣는 것은 불편하다.
locals라는 블록으로 묶어서 variables.tf에 작성하지 않고 현재 main.tf에서 사용할 지역 변수를 선언한다.
-> 이제 입력 변수에 local.[변수명] 으로 작성하면 된다.
이걸 보안 그룹 코드에 적용해 보자.
인프라가 많아질수록 반복적으로 적용되는 값이 많아진다.
-> 지역 변수를 적용하면 한 번에 수정할 수 있다
보안 그룹 생성 시 더 세세하게 쪼갤 수 있다.
기존에는 보안 그룹 생성 시(aws_security_group) 바로 ingress와 egress 규칙을 작성했는데, 이걸 더 잘게 쪼갤 수 있다.
[보안 그룹 생성 + 보안 규칙 적용] 이렇게 쪼갠 것이다.
위 코드처럼 쪼개면 다른 작업에서 이 정보들을 끌어다 쓰기 더 편해진다.
3~4교시
테라폼 코드에서 경로를 작성할 때 슬래쉬( / )를 쓰면 한 번 쓰면 되고, 역 슬래쉬( \ )를 쓰면 2번 써야 한다(\\)
-> \를 쓰던 \\를 쓰던 뒤에 붙은 문자와 결합되어 이스케이프 문자로 취급된다. 에러 발생
module.~~ 로 모듈의 출력 값을 끌어오려면 모듈 폴더의 outputs.tf에 해당 이름의 출력 값이 있어야 한다.
모듈 폴더의 outputs.tf에 아래 내용을 추가
출력 값 작성 전에 해당 속성(aws_autoscaling_group)의 반환 값에 name이 있는지 확인해야 한다.
루트 모듈에서 모듈의 속성을 참조하려면 출력 변수에 적어줘야 한다.
모듈 코드에서 path.module은 모듈 폴더의 경로를 의미하는데, 루트 모듈에서 모듈을 사용할 때 넣는 매개변수인 source에 모듈 폴더의 경로를 작성하게 된다.
블록 내부에 있는 블록(ex : 보안 그룹 안의 ingress/egress 블록)을 인라인 블록이라 하는데, 모듈을 만들 때는 항상 별도의 리소스를 사용하는 것이 좋다(= 쪼개는 것이 좋다)
-> 보안 그룹 생성/인바운드 규칙 추가/아웃바운드 규칙 추가, 총 3개의 리소스로 나누는 것이 좋다는 의미
왜?
-> 모듈을 호출한 루트 모듈이 보안 그룹을 불러올 때, 보안 그룹 리소스 내의 igress/egress 규칙을 추가할 수 없다.
-> 모듈 호출 시 사용자가 보안 그룹의 규칙 추가를 위해 aws_security_group 리소스를 aws_security_group 리소스와 aws_security_group_rule 리소스로 나눈다.
나누거나, 합치거나 둘 중 한 가지 방법만 사용해야 한다.
-> ingress는 인라인으로 두고, egress는 분리시키거나 이러는 방식은 불가
5~6교시
테라폼에 있는 모든 구성 파일은 모듈이다.
-> 현재 작업 디렉터리의 모듈은 루트 모듈
모듈을 사용할 때에는 입력 매개변수, 값, 매개변수를 구분해야 한다.
리소스 구성 시 내부 요소를 인라인 블록이나 별도의 리소스로 설정할 수 있다.
-> 인라인 블록으로 하면 모듈로 사용될 때 내부 요소에 접근할 수 없다.
-> 별도의 리소스로 구성하는 것이 좋다
7교시
테라폼은 파이썬과 호환이 가능한 부분이 있다.
-> 반복문, 조건문 일부 사용 가능 : 결과는 같은데 문법이 좀 다르다
테라폼은 선언적 언어다 : 실제 배포된 내용을 정확하게 나타내며, 추론하기 쉽다
-> 마지막 상태에 대해서만 정의하면 된다.
-> 코드를 더 작게 유지할 수 있다.
선언적 언어(테라폼), 절차적 언어(쉐프, 앤서블)
-> 절차적 언어는 최종 상태를 달성하는 방법을 단계별로 지정
테라폼에는 for 반복문 역할을 하는 문법이 없다. 그렇다면 같은 리소스를 여러 개 만드는 반복을 어떻게 처리하는가?
if 조건문 문법도 없다. 조건에 따라 리소스를 구성하는 모듈을 어떻게 생성하는가?
-> 무중단 배포와 같은 절차적 아이디어를 어떻게 구현하는가?
count 매개 변수, for_each/for 표현식, create_before_destroy 블록, 3항 연산자 등의 기능 제공
count 매개 변수 : 리소스를 반복
for_each 표현식 : 리소스 내에서 리소스 및 인라인 블록 반복
for 표현식 : 리스트와 맵을 반복
for 문자열 지시어 : 문자열 내에서 리스트와 맵을 반복
count 매개 변수 예시들
콘솔에서 확인해 보면 사용자 neo.0 ~ 2까지 있다.
위와 같은 방식은 이름에 의미를 부여할 수 없다.
같은 폴더에 variables.tf 파일을 생성하고, 변수 user_names를 리스트 타입으로 생성해 사용했다.
※ 리스트를 통해 생성한다고 해도 작업 순서가 꼭 리스트 정방향인 것은 아니다.
리소스에 count를 사용하면 해당 리소스는 하나의 리소스가 아니라 리소스의 배열이 된다.
-> output으로 출력 값으로 제공할 때 리소스 이름 뒤에 인덱스 번호를 명시해야 한다.
-> Provider_type.Name[Index].Attribute
8교시
리스트 인덱스를 명시하거나, *로 전부임을 명시하거나.
count 매개 변수에는 유용성을 저해하는 제약이 있다.
1. 전체 리소스를 반복할 수는 있지만 리소스 내에서 인라인 블록을 반복할 수는 없다.
2. 변경할 때 문제 발생
-> 리스트의 요소 중 하나를 삭제하면 삭제된 후 뒤의 요소들이 앞으로 당겨진다.
-> 이 변경이 문제가 된다
[0] = 네오
[1] = 트리니티
[2] = 모피어스
이 구조에서 [1] = 트리니티를 삭제하면?
[2] = 모피어스 요소가 [1] = 모피어스 가 된다.
기존에 [2]를 가리키던 코드들에서 에러 발생
-> [1]이 변경되고 [2]가 삭제되는 상황 발생. 의도했던 결과와 다르다.
5~6교시 모듈 복습 내용 빠르게 훑기
'교육' 카테고리의 다른 글
[97일 차] 21.12.09 : Terraform 6 (0) | 2021.12.09 |
---|---|
[96일 차] 21.12.09 : Terraform 5 (0) | 2021.12.08 |
[94일 차] 21.12.06 : Terraform 3 (0) | 2021.12.06 |
[93일 차] 21.12.03 : Terraform 2 (0) | 2021.12.03 |
[92일 차] 21.12.02 : Terraform 1 (0) | 2021.12.02 |
댓글