Terraform - 기초 : 인스턴스 생성, 사용자 데이터 작성
1교시
테라폼도 Cloudformation처럼 문서 페이지가 있으니 참고해서 작성하면 된다.
- IaC(Infrastructure as Code. 코드형 인프라)
코드를 작성/실행하여 인프라를 생성/배포/수정/정리하는 것
-> 운영의 모든 측면(HW적 측면 등)을 소프트웨어적으로 전환하여 생각한다.
DevOps의 핵심은 거의 모든 것을 코드로 관리할 수 있다는 것.
IaC에는 5가지 범주가 있다.
- 애드혹 스크립트(Ad hoc script)
수행할 작업을 단계별로 나누고 특정 언어를 사용하여 각 단계를 코드로 정의한다.
작성된 스크립트를 서버에서 수동으로 실행한다.
-> 소규모 일회성 작업에 적합하다
대충 bash shell 스크립트 파일이나 EC2에서 사용했던 User Data 작성 같은 것이라고 생각하면 된다.
- 구성 관리 도구
대상 서버에 SW를 설치하고 관리 : Chef, Puppet, Ansible 등
애드혹 스크립트와 비교해 장점은
-> 코딩 규칙 : 일관되고 예측 가능한 코딩 규칙이 있어 코드를 쉽게 탐색 가능
-> 멱등성 : 실행 횟수에 관계없이 올바르게 동작하는 코드로 작성 가능
-> 분산형 구조에서의 배포 : 애드혹 스크립트는 단일 로컬 머신에서만 실행되지만, 구성 관리 도구는 원격의 수많은 서버를 관리할 수 있도록 설계되어 있다.
- 서버 템플릿 도구
여러 서버를 시작하고 각각 동일한 코드를 실행하는 방식으로 서버를 구성하는 것이 기존 방식.
서버 템플릿 도구는 OS, SW, 파일 등 모든 내용을 포함하고 있는 스냅숏으로 이미지를 생성.
- 오케스트레이션 도구
서버 템플릿 도구는 특정 상황에서의 관리가 어렵다.
-> VM/컨테이너를 HW에 효율적으로 배포하기
-> 기존 VM/컨테이너를 효율적으로 업데이트/롤백하기
-> VM/컨테이너의 상태를 모니터링하고 오류가 난 부분을 자동 복구
-> 발생하는 트래픽에 따라 VM/컨테이너의 수를 조절(자동 확장)
-> VM/컨테이너의 트래픽 분산(부하 분산)
-> VM/컨테이너가 다른 네트워크에 있더라도 서로 식별하고 통신이 가능하게 작업(서비스 검색)
그래서 Kubernetes/AWS ECS/Docker Swarm 등을 사용
- 프로비전 도구
서버 자체를 생성 - Terraform, AWS CloudFormation, OpenStack Heat 등
서버를 생성하는 것 뿐만 아니라 DB, Cache, Load Balancer, Queue, Monitoring, Subnet 구성, 방화벽 설정, 라우팅 규칙 설정, SSL 인증서 등 인프라에 관한 모든 것을 프로비저닝 가능
IaC의 장점
-> 자급식 배포(Self-Service)
코드를 수동으로 배포하면 배포 명령어를 알고 있는 소수의 시스템 관리자만 프로덕션 환경에 접속/배포 가능.
IaC로 인프라를 정의하면 전체 프로세스를 자동화할 수 있으며 개발자는 필요할 때마다 자체적으로 배포 진행 가능
-> 속도와 안정성(Speed and Safety)
사람이 진행하는 것보다 훨씬 빠르게 배포 진행 가능.
자동화된 프로세스는 일관되고, 반복 가능하며 수동으로 진행했을 때보다 오류가 적게 발생한다.
-> 문서화(Documentation)
누구나 읽을 수 있는 소스 파일로 인프라 상태를 나타낼 수 있다.
시스템 관리자가 부재 중일 경우에도 조직의 모든 사람이 인프라 구조를 이해하고 업무를 처리할 수 있게 한다.
-> 버전 관리(Version Control)
인프라의 변경 내용이 모두 기록된 IaC 소스 파일을 저장할 수 있기에 버전 관리가 쉬워진다.
인프라 변경 내역이 남아 있기에 시스템에 문제가 생겼을 때 문제 발생 지점을 찾기 수월하다.
문제 내용 확인 후 문제가 없던 이전 버전으로 되돌리면 문제 해결.
-> 유효성 검증(Validation)
코드가 변경될 때마다 검증을 수행하고 자동화된 테스트 실행 가능. 분석 프로그램에 코드를 전달하여 오류 발생 위험을 줄일 수 있다.
-> 재사용(Reuse)
인프라를 재사용 가능한 모듈로 패키징 가능. 모든 제품을 처음부터 배포하는 대신 문서화되고 검증된 모듈로 일관되게 배포할 수 있다.
-> 행복(Happiness)
반복적이고 지루한 배포/관리 업무에서 벗어나 자동화된 작업 가능
API 인증 절차를 거치기 위한 사용자 생성
AWS IAM > 아래 정책 권한을 가진 사용자 생성
AmazonEC2FullAccess, AmazonS3FullAccess, CloudWatchFullAccess, IAMFullAccess,
AmazonDynamoDBFullAccess, AmazonRDSFullAccess
2교시
그냥 AdministratorAccess 정책 있는 사용자로 쓰자.
Terraform by HashiCorp
Terraform is an open-source infrastructure as code software tool that enables you to safely and predictably create, change, and improve infrastructure.
www.terraform.io
여기 들어가서 쭉 둘러보자.
우측 상단의 Download CLI > OS에 맞는 파일 다운로드 > 받은 파일 압축 풀기
CLI라 설치하는 것은 아니고, 환경 변수에 경로를 추가해줘야 한다.
-> 사용자 환경 변수 Path에 파일이 있는 경로 추가 후 재부팅
이제 터미널에서 terraform을 쳐보고 작동하는지 확인
https://registry.terraform.io/providers/hashicorp/aws/latest/docs
https://registry.terraform.io/providers/hashicorp/aws/latest/docs
registry.terraform.io
테라폼 문서 링크. 자주 보게 될 것이다.
테라폼은 AWS CLI와도 호환이 되니 aws configure로 등록해도 된다.
등록 후 실습할 경로로 이동해서 main.tf 파일 생성
-> 테라폼 파일도 들여쓰기 필수 : 2칸 띄우기
대충 인프라 공급자를 AWS로 하겠다는 코드 부분
3교시
tf 파일 편집은 편한 곳에서 하면 된다. 메모장이든 Notepad++ 든 VSCode든...
각 유형의 공급자마다 다양한 종류의 resource가 있다.
Terraform에서 리소스 생성은
resource "공급자 유형" "이름" {
설정
}
이런 식으로 작성.
공급자 유형은 Cloudformation에서처럼 정해져 있는 것이니 찾아서 갖다 쓰면 된다.
이제 만든 파일을 배포해 보자.
terraform init : 테라폼에 코드 스캔을 지시해서 공급자 확인 및 플러그인 다운로드
-> 테라폼 파일이 있는 경로에 .terraform 폴더가 생기고, 파일 실행에 필요한 플러그인이 여기 설치된다.
terraform validate : 테라폼 템플릿 문법 검사
terraform plan : 테라폼 빌드 검증 테스트. 실제 변경 전에 수행할 작업 확인
-> +(추가), -(제거), ~(수정)
위 사진은 실행 결과의 일부분이고, 뭐가 쭉 길게 나온다.
terraform apply [--auto-approve] : 테라폼 템플릿 적용
-> 실행하면 plan 내용을 실행할 것인지 물어보는데, yes를 치면 된다.
yes 치기 귀찮으면 --auto-approve 옵션 써서 강제 적용.
terraform show : 테라폼에 의해 구성된 리소스에 대한 상태 정보 확인
terraform destroy : 테라폼 상태 정보 파일을 참조하여 모든 리소스 제거
-> apply처럼 확인 메시지 나오면 yes 입력.
4교시
테라폼에서 User data 설정 : 웹 서버 배포하기
-> 아마존 리눅스 AMI로는 안된다고 한다. 실습에서는 우분투 18.04 AMI 사용.
보안 그룹을 설정해야 한다 : 공급자 유형 "aws_security_group"
ingress : 트래픽이 인스턴스로 들어올 때 적용
egress : 트래픽이 인스턴스에서 나갈 때 적용
보안 그룹을 만들었으니 인스턴스와 연결해야 한다.
-> aws_instance 리소스에서 사용하는 인수 : vpc_security_group_ids
CloudFormation에서 !Ref로 다른 작업의 특정 반환값을 참조했듯, 테라폼에도 동일한 기능이 있다.
-> <provider type>.<name>.<attribute>
인스턴스에서 보안 그룹을 연결할 때, 해당 보안 그룹의 id를 가져오는 코드.
테라폼으로 배포한 상태에서 이렇게 수정을 거치고 다시 apply를 하면?
-> 새로운 인스턴스로 교체된다
아까 만든 것은 destroy 했으니 다시 init > plan > apply 진행
5교시
DRY(Don't Repeat Yourself)
-> 중복된 내용을 코드에는 반복해서 사용하지 말자.
ex) 포트 번호라는 변수에 8080이라는 값을 할당했다고 치면, 앞으로는 변수명으로 할당해주면 된다.
값의 수정이 필요하면 변수값을 수정하면 된다.
변수 구성
variable "name" {
설정
}
설정에 들어갈 수 있는 매개변수는 description, default, type
변수에 값을 전달하는 방법은
-> 명령줄에서 -var 옵션으로 전달
-> -var-file 옵션으로 파일로 보내기
-> 환경 변수로 보내기
이런 방식이 정의되어 있지 않으면 default 값 전달.
기본값도 없으면 테라폼이 대화식으로 사용자에게 변수 정보를 묻는다.
type은 변수의 유형 지정. 지정하지 않으면 any로 인식한다.
대충 description으로 설명, type으로 자료형, default로 값
main.tf와 같은 경로에 변수 정보만 작성한 tf 파일을 생성
(일단 default 값은 비워놓고)
이렇게 변수를 작성한 파일을 만들고, 이 변수를 다른 파일(main.tf)에서 사용하려면
이렇게 사용하거나
이렇게 사용한다. var는 고정이다.
이제 terraform plan을 실행해 보면?
대화식으로 값을 물어본다. 아니면
이번에는 variables.tf에 default 주석 처리를 해제하고 해 보자.
-> 값을 따로 물어보지 않고 진행된다.
만든 인스턴스의 IP 주소를 알고 싶다면?
-> 콘솔로 다시 들어가긴 귀찮다
-> CloudFormation에서는 Output으로 받을 수 있었다
-> Terraform에서도 유사한 기능이 있다.
위에서 만든 variables.tf는 입력 변수였고, 이번에는 출력 변수를 뽑아보자.
main.tf에 코드를 작성해 받을 수도 있지만, 식별하기 좋게끔 파일을 분리하는 것이 좋다.
[리소스 타입].[logical ID].[속성]
-> 이런 식으로 뽑아온다.
-> 리소스 타입은 provider type이고, logical ID는 해당 리소스의 이름, 속성은 해당 리소스가 반환하는 속성 중 하나.
(해당 리소스 타입이 어떤 속성을 반환하는지는 문서 참고)
이제 plan > apply로 배포해 보면?
이렇게 마지막에 출력된다.
6교시
이제는 클러스터 배포 - 오토 스케일링을 사용한 - 을 구성해 보자. 단일 서버가 아닌 클러스터.
-> 인스턴스 상태 모니터링, 실패한 인스턴스 교체, 부하에 따른 클러스터 사이즈 조정
여기서 사용할 유형은 aws_autoscaling_group과 aws_launch_configuration 등이 있다.
aws_launch_configuration에서 lifecycle을 사용하는 이유는?
-> 시작 구성 내용을 변경한 후 기존 인스턴스를 삭제하기 전에 새로운 구성에 의한 인스턴스를 생성 후 기존 인스턴스 삭제
7교시
기본 VPC에 배포한다고 해도, 어떤 서브넷을 사용할지는 지정해줘야 한다.
-> 그런데 기본 VPC ID나 시본 서브넷 ID는 모른다 : 콘솔에서 긁어와야 하나?
이럴 때 사용하는 것이 '데이터 소스'
-> 테라폼을 실행할 때마다 공급자에서 가져온 읽기 전용 정보
Terraform 문서를 보면, 각 항목 하위에 Resources 탭과 Data Sources 탭이 있다.
-> 이름이 같아도 이게 다르면 다른 작업이다.
문서를 잘 봐야 한다.
어떤 데이터를 가져올 수 있는지, 데이터를 가져온 후 리소스에서 사용할 때 어떤 이름으로 가져오는지 모두 문서에 적혀 있다.
-> 가져오는 값은 Attributes Reference다.
-> Attributes Reference에 없으면 빼올 수 없다 : 만든 VPC라면 리소스 반환값에 ID가 어차피 있다.
기본 VPC의 ID는 서브넷을 통해 간접적으로 빼오는 것.
오토 스케일링 그룹을 만들었으니, ALB를 만들어 보자.
-> ALB와 리스너가 있어야 한다.
ALB에는 서브넷 2개 필수, 가용 영역이 2개로 나눠지는 것도 필수
8교시
main.tf 배포 이전에 구성된 정보는 데이터 소스로 받아오고, 같은 파일 내에 있으면 유형.이름.속성 <- 이렇게 받아오고.
테라폼 변수 중 [ ]로 묶는 것과 묶지 않는 것의 차이?
-> 변수의 타입이 변수인가, 리스트인가 차이 : 변수라면 [ ]로 묶지 않고, 리스트라면 [ ]로 묶는다.
정작 만들고 보니 타깃 그룹이 비어 있다. 내일 계속
5교시 초반(14:32~40) DRY 규칙 설명 다시 듣기
6교시 후반(16:10 ~ 16:30) lifecycle 설명 다시 듣기
7~8교시는 빠르게 훑자
'교육' 카테고리의 다른 글
| [94일 차] 21.12.06 : Terraform 3 (0) | 2021.12.06 |
|---|---|
| [93일 차] 21.12.03 : Terraform 2 (0) | 2021.12.03 |
| [91일 차] 21.12.01 : Python 6 (0) | 2021.12.01 |
| [90일 차] 21.11.30 : Python 5 (0) | 2021.11.30 |
| [89일 차] 21.11.29 : Python 4 (0) | 2021.11.29 |
댓글