목차
배경지식
전통적인 Deployment 과정
(HW)물리적인 서버실 설치 -> 네트워크 설정(RAID) -> QA 네트워크 설정 -> DevOps Install .. 등의 복잡한 과정이 필요했다.
리눅스를 설치하고 Application을 설치하고 Deploy 과정을 진행했던 것이 전통의 Deploy 과정이다.
이는 너무나도 오랜 시간 걸리는 과정이다. 비용적인 측면 역시도 존재했다.
가상화의 등장
시간이 지나면서, 클라우드가 발전함에 따라(특히 AWS가 많은 발전이 있었다.) Script만으로도 자연스럽게 스케일을 잡아 원격 서버를 구축할 수 있게 되었다.
다만, 이 경우 pem키나 ssh 등으로 원격 접속할 경우 '누가 어떤 요청을 했는지' 관리가 어려웠기 때문에 대규모의 서버 접근 방식에서 관리와 유지보수가 힘들어진다는 단점이 발생했다.
그렇기 때문에 회사들은 in-house application 등을 통해 이를 제어할 수 있는 방법들을 고민했다.
인프라를 코드를 통해 관리하자 (종류)
대부분의 인프라 접근 관리를 API 호출이나 코드를 통해 관리할 수 있게 되었다.
이렇게 사용한다면 누가 어떤 목적으로, 어떤 서버 관리 요소를 호출하고 변경했는지 관리할 수 있게 되는 것이다.
Configuration management :
install이나 management 관리 도구.
기본적인 인프라를 유지할 수 있는 도구이다.
Server Templating :
서버 템플릿의 경우 Docker나 Packer가 존재한다.
소프트웨어를 이미지 등을 통해 VM에 image의 형태로 올리는 경우 등이다.
Provisioning tools :
서버 Deploy용으로 사용 (immutable)
Server나 DB, Network 등..
Provider에서 대부분을 제공한다.
terraform은 provisioning tools로 코드를 통해 퍼블릭 코드와 연경한다.
Provider라는 객체를 통해 요청과 호출을 보내고, 인프라 요청을 코드로 관리하고 목적을 달성할 수 있게 되었다.
Terraform
what is terraform
여러 번 돌려도 항상 똑같은 state를 제공하는 도구.
또한 코드를 모듈화(인스턴스화) 하여 효율적으로 요청을 관리할 수 있다.
How it works
AWS, GCP, Azure 같은 Provider들이 기본적인 기능들을 제공한다.
Configuration Files을 생성하고, Command를 통해 계획을 작성하고, 이를 실행하는 방식으로 동작한다.