테라폼 기초

가시다 님이 진행하는 테라폼 기초 입문 스터디의 첫 시간을 가졌습니다. 첫시간에 나온 기초를 정리 해 보았습니다.

데브옵스 : 소프트웨어를 효율적으로 전달하는 프로세스

코드형 인프라 : IaC 란 코드를 작성 및 실행하여 인프라를 생성, 배포, 수정, 정리하는 것 - 5가지 범주

1. 애드혹 스크립트 : ad hoc script, 수행 각 단계를 코드로 정의하고 작성된 스크립트를 서버에서 수동으로 실행하는 것
2. 구성 관리 도구 : Chef, Puppet, Ansible 등은 대상 서버에 소프트웨어를 설치하고 관리하도록 설계되어 있음
   • 애드혹 스크립트 대비 장점 : 코딩 규칙(coding convention), 멱등성(Idempotence, 항상 같은 결과값), 분산형 구조(Distribution, 다수 원격 서버 관리)
3. 서버 템플릿 도구 : docker, packer, vagrant 같이 하나의 코드로 서버 배포와 설정 가능
   • 아래는 패커를 사용하여 웹 서버가 설치된 서버 이미지 생성 후 앤서블과 같은 배포 도구를 사용하여 모든 서버에 이미지를 설치
   • 이미지 작업을 위한 도구 : 가상 머신, 컨테이너
   • 서버 템플릿은 불변 인프라 immutable infrastructure 로 전환하는 데 있어 핵심적인 구성 요소입니다.
   • 불변 인프라 개념은 함수형 프로그래밍에서 사용하는 불변 변수 immutable variable 개념에서 영감을 얻어 등장한 것입니다.
   • 함수형 프로그래밍에서는 변수를 설정한 후에는 해당 변수를 다시 설정할 수 없습니다. 그러므로 값을 변경해야 하는 경우 새로운 변수를 만들어야 합니다. 변수 값이 바꾸지 않기 때문에 코드를 추론하기 휠씬 쉬워집니다.
   • 볼편 인프라는 이러한 함수형 프로그램과 비슷합니다. 한번 배포된 서버는 다시 변경되지 않습니다. 그렇기 때문에 함수형 프로그래밍에서 새 버전의 코드를 배포하는 것과 같이 서버를 변경해야 하는 경우 서버 템플릿에서 새 이미지를 만들어 새 서버를 배포해야 합니다.
4. 오케스트레이션 도구 : 관리를 위한 쿠버네티스를 통해 파드를 배포하는 것
5. 프로비전 도구 : 2~4는 각 서버에서 실행되는 코드를 정의한다면, 테라폼/클라우드포메이션은 서버 자체를 생성함

테라폼 : Terraform’s configuration language is declarative, meaning that it describes the desired end-state for your infrastructure

작동 방식 : 하시코프사가 Go 언어로 개발한 오픈 소스 도구, OS 마다 바이너리 파일이 존재하는데, Go코드는 하나의 바이너리 파일로 컴파일되며 terraform 명령어로 실행

• terraform 바이너리가 AWS/GCP 등의 공급자를 대신해 API를 호출하여 리소스를 생성
• 테라폼은 인프라 정보가 담겨 있는 테라폼 구성 파일을 생성하여 API를 호출

동작

1. Scope - Identify the infrastructure for your project.
2. Author - Write the configuration for your infrastructure.
3. Initialize - (초기화/준비) Install the plugins Terraform needs to manage the infrastructure.
   • 지정한 backend에 상태 저장을 위한 .tfstate 파일을 생성합니다. 여기에는 가장 마지막에 적용한 테라폼 내역이 저장됩니다.
   • init 작업을 완료하면, local에는 .tfstate에 정의된 내용을 담은 .terraform 파일이 생성됩니다.
   • 기존에 다른 개발자가 이미 .tfstate에 인프라를 정의해 놓은 것이 있다면, 다른 개발자는 init작업을 통해서 local에 sync를 맞출 수 있습니다.
4. Plan - (예측) Preview the changes Terraform will make to match your configuration.
   • 정의한 코드가 어떤 인프라를 만들게 되는지 미리 예측 결과를 보여줍니다. 단, plan을 한 내용에 에러가 없다고 하더라도, 실제 적용되었을 때는 에러가 발생할 수 있습니다.
   • Plan 명령어는 어떠한 형상에도 변화를 주지 않습니다.
5. Apply - (생성) Make the planned changes.
   • 실제로 인프라를 배포하기 위한 명령어입니다. apply를 완료하면, AWS 상에 실제로 해당 인프라가 생성되고 작업 결과가 backend의 .tfstate 파일에 저장됩니다.
   • 해당 결과는 local의 .terraform 파일에도 저장됩니다.

기본 개념

• resource : 실제로 생성할 인프라 자원을 의미
• provider : Terraform으로 정의할 Infrastructure Provider를 의미
• output : 인프라를 프로비저닝 한 후에 생성된 자원을 output 부분으로 뽑을 수 있음. Output으로 추출한 부분은 이후에 remote state에서 활용 가능
• backend : terraform의 상태를 저장할 공간을 지정하는 부분. backend를 사용하면 현재 배포된 최신 상태를 외부에 저장하기 때문에 다른 사람과의 협업이 가능
• module : 공통적으로 활용할 수 있는 인프라 코드를 한 곳으로 모아서 정의하는 부분. Module을 사용하면 변수만 바꿔서 동일한 리소스를 손쉽게 생성할 수 있음
• remote state : remote state를 사용하면 VPC, IAM 등과 같이 여러 서비스가 공통으로 사용하는 것을 사용할 수 있음. tfstate파일이 저장되어 있는 backend 정보를 명시하면, terraform이 해당 backend에서 output 정보들을 가져옴

코드형 인프라 장점

• 자급식 배포 Self-service : 배포 프로세스를 자동화 할 수 있으며, 개발자는 필요할 때마다 자체적으로 배포를 진행 할 수 있음
• 속도와 안정성 Speed and safety : 자동, 일관되고 오류 적음
• 문서화 Documentation : 시스템 관리자 조직만 인프라에 관한 정보를 독점하는 것이 아니라 누구나 읽을 수 있는 소스 파일로 인프라 상태를 나타낼수 있음
• 버전 관리 Version control : 인프라의 변경 내용이 모두 기록된 코드형 인프라 소스 파일을 저장할 수 있으므로 버전을 쉽게 관리할 수 있음, 문제 발생 시 코드 원복
• 유효성 검증 Validation : 인프라 상태가 코드로 정의되어 있으면 코드가 변경될 때마다 검증을 수행하고 일련의 자동화된 테스트를 실행할 수 있음
• 재사용성 Reuse : 인프라를 재사용 가능한 모듈로 패키징할 수 있어 검증된 모듈로 일관되게 배포할 수 있음
• 행복 Happiness