Infrastructure as Code의 필요성
수동으로 인프라를 설정하는 것의 장/단점
장점
- 수동설정은 쉽게 서비스를 제공하고, 아키텍처를 빠르게 실험해볼 수 있다는 점에서 유리하지만 단점이 많다.
단점
- 휴먼 에러 때문에 서비스를 설정할 때에 잘못 설정하기 쉽습니다.
- 설정을 통해 예측되는 상태를 관리하기 어렵습니다.
- 환경 설정에 대한 내용을 다른 팀 멤버에 전달하기 어렵습니다.
IaC(Infrastructure as Code)
IaC는 설정을 코드로 작성하여 클라우드 인프라스트럭처의 생성/수정/삭제를 자동화하는 방법
이는 서버, 데이터베이스, 네트워크, 배포 프로세스, 테스트 등 거의 모든 것을 코드로 관리할 수 있다는 의미
-> IaC는 인프라스트럭처의 설계도가 될 수 있다.
IaC 장점
- 인프라를 만드는 과정이 자동화되므로, 오류가 훨씬 덜 발생하고 안전합니다.
- IaC는 쉽게 공유할 수 있고, 버전 관리에도 용이합니다.
- 코드와 현재 상태를 비교하여, 추후 인프라 상태의 변경에 따르는 위험을 분석하고 검증할 수 있습니다.
- 배포 과정을 소수의 시스템 관리자만 진행하는 것이 아닌, 개발자 스스로가 배포하고 인프라를 통제할 수 있는 환경으로 만들 수 있습니다.
선언형 IaC와 절차형 IaC의 차이
선언형 IaC
선언형 언어 JSON, YAML 등을 사용합니다. 실제 인프라가 적용된 결과(기대하는 상태)와 적용할 내용(YAML 등)이 직관적으로 매핑
선언형 IaC 종류
- CloudFormation (AWS에서만 사용가능)
- Terraform: 어떤 클라우드 서비스에도 적용되는 범용 IaC
- 엔서블, 쉐프, 퍼핏, 솔트 등
절차형 IaC
프로그래밍 언어를 이용해서 직접 순차적으로 인프라를 생성하도록 코드를 작성하는 방법
선언형에 비해 더 강력한 일들을 할 수 있으나, 실제 적용된 결과를 가늠하기 어렵고, 코드읽기에 직관적이지 않음.
테라폼(Terraform)의 특징 및 장점을 통해 테라폼의 주 사용 목적
특징
Terraform의 설정 파일은 HashiCorp가 만든 설정 언어인 HCL을 사용함
장점
- 모든 클라우드 플랫폼을 지원하는 놀라운 유연성을 갖춘 오픈 소스
- 직관적으로 알 수 있는 선언형
가변적(mutable) 인프라와 불변적(immutable) 인프라
시대적 흐름에 따라 On-premise에서 On-Demand형식으로 감에 따라 가변인프라에서 불변 인프라로 변경하는중
불변적 인프라는 가변적 인프라에 대부분의 단점을 상쇄함
불변적 인프라의 단점
- 상황에 따라 가변적 인프라가 필요 할 수 있음 (절충안이필요)
Question
Q1) 가변적(mutable) 인프라와 불변적(immutable) 인프라의 차이는 무엇인가요?
가장 근본적인 차이는 핵심이 되는 정책의 차이이다. 가변 인프라의 경우 구성요소가 배포가 되면 점점 원래의 것이 업그레이드 되는 형식 불변 인프라는 구성요소는 배포 이후 절때 변경되지 않고 업데이트 시 새 버전의 애플리케이션이 탑재된 서버를 생성하고 궁극적으로 완전히 교체 되도록 만들어짐.
가변적 인프라에 경우 여러 번 업그레이드한 오래된 시스템은 필연적으로 보이지 않는 문제를 키울 수 있고, *Configuration Drift 현상이 일어 날 수 있음. 불변적 인프라는 인프라 변경을 막아 Configuration Drift현상을 사전 예방하고, 인프라 환경 변경을 쉽게 해줌.
적절한 비유 - 개념적 차이: 애완동물 vs 소떼(Pets vs Cattle)
전통적인 가변 인프라에서의 서버는 항상 작동하고 있어야 하는 대체할 수 없는 유일한 시스템이다. 이러한 점을 고려해보면 가변 인프라는 독특하고 아무나 따라할 수 없으며, 손으로 돌봐줘야 하는애완동물(pets)과 같다. 반면, 불변 인프라의 서버는 폐기할 수 있고 자동화 된 툴로 쉽게 교체하거나 확장할 수 있다. 이러한 특징을 생각해 보면 불변 인프라는 각각의 서버가 동일하진 않고 유니크하거나 대체 불가능하지 않은 소떼(cattle)에 비유될 수 있다.
Configuration Drift : 예상치 못한 인프라의 변경에 따른 사고와 미치는 영향을 말함
참고 : https://www.digitalocean.com/community/tutorials/what-is-immutable-infrastructure
예상치 못한 인프라 변경을 어떻게 대비?
접근 방법에 따라 조금씩 다르나 AWS 기준
- 잘못 된것을 찾기 위해서 사용되는 도구 : AWS Config
(바른 설정을 지정해놓고, 찾아서 고칠 수 있게 해줌) - 사고 방지 도구 :AWS CloudFormation Drift Detection
Terraform 을 이용한 솔루션
- 정상 작동 상태를 파일로 저장하고 인프라의 실제 상태와의 비교 대상으로서 현재 상황을 진단/점검할 수 있습니다.
Q2) Terraform의 선언적 방식으로 작성된 코드는 항상 인프라의 최신 상태를 의미합니다. Terraform은 어떤 방식으로 인프라를 최신 상태로 유지할 수 있는 걸까요?
테라폼을 통해 생성한 인프라의 정보는 테라폼 상태 파일에 기록됩니다. 기본적으로 실행한 위치에 terraform.tfstate 파일이 생성되고 테라폼 구성 파일의 리소스를 실제 인프라 리소스와 매핑할 수 있는 형태로 기록됩니다.
하지만 실제 팀 단위 운영환경에서 최신 상태로 유지하려면 조건이 필요하다.
- 상태 파일을 위한 공유 스토리지
모든 팀원이 동일한 상태 파일에 접근하기 위해 공유 스토리지에 위치해야 합니다. - 상태 파일 동시 접근 제어를 위한 잠금기능
상태 파일이 공유 스토리지에 위치하기 위해서는 잠금 기능이 필요합니다. 여러 팀원이 동시에 접근하여 상태 파일을 업데이트하는 경우 데이터가 손실되거나 파손될 우려가 있기때문. - 상태 파일의 환경별 격리
구성파일 변경의 영향을 받는 범위를 해당 환경으로 격리하는 것이 좋습니다. 사용자의 실수로 개발이나 테스트 환경의 변경이 운영환경에 영향을 미쳐 장애로 이어지는 상황이 발생할 수 있습니다.
-출처 : http://blog.hwahae.co.kr/all/tech/tech-tech/8207/
여래님 답변)
생성한 인프라 정보는 .tfstate파일에 저장됨
aws_instancd를 3개 생성한 채로 카운터를 1로 변경 후 terraform apply다시 하면 생성된 인스텐스를 확인 후 2개를 자동으로 지워줌
