코드형 인프라(Infrastructure as Code, IaC)란 코드 형태로 인프라를 작성, 정의, 배포, 업데이트하는 것을 의미한다. 물리 장비를 설정하는 것뿐만 아니라 모든 운영을 코드 형태로 한다는 인식 전환이 중요하다. 실제로 데브옵스는 서버, 데이터베이스, 네트워크, 로그 파일, 애플리케이션 설정, 자동화된 검증 절차, 배포 방법 등 모든 것을 코드 형태로 관리한다.
--- p.4
테라폼 코드는 tf 확장자인 하시코프 설정 언어(HCL, HashiCorp Configuration Language)로 작성되어 있다. 테라폼은 구성하고자 하는 인프라를 설명할 수 있도록 선언형 언어로 구성되어 있으며, 테라폼이 구성정보에 따라 각 인프라 제공자의 API를 사용하여 리소스를 생성하고 구성하는 단계를 지원한다. 또한, 테라폼은 아마존 웹 서비스, 애저, 구글 클라우드, 디지털오션 등 다양한 플랫폼에 종속적이지 않게 인프라를 생성할 수 있다.
--- p.39
실제로 환경을 넘어서 ‘구성 요소(component)’ 수준으로 격리 개념을 가져올 수 있으며, 이 구성 요소는 일반적으로 함께 배포되는 리소소의 집합이다. 예를 들어, 인프라의 기본적인 네트워크 형상(topology)를 구성하였을 때 아마존 웹 서비스에서는 VPC와 연동된 서브넷, 라우팅 규칙, VPN, 네트워크 ACL을 몇 달에 한 번 수정할 것이다. 하지만 웹 서버의 정보들은 변경사항이 많을 것이다. 만약 인프라 관리에서 VPC 구성 요소와 웹 서버 구성 요소를 하나의 테라폼 설정으로 관리한다면 하루에도 몇 번이나 네트워크 형상에 불필요한 변경 위험을 일으킬 것이다.
--- p.83
ASG와 함께 create_before_destroy를 사용하는 것은 무중단 배포를 위한 훌륭한 기술이지만, 자동 확장 정책에서는 작동하지 않는다는 한 가지 제약 사항이 있다. 정확하게 말하면 각 배포 후에 ASG 크기를 min_.size로 다시 설정한다. 자동 확장 정책을 사용하여 실행 중인 서버의 수를 늘리면 문제가 될 수 있다.
--- p.157
코드를 통해 인프라를 관리하는 경우 위험을 완화하는 더 나은 방법으로 테스트 자동화가 있다. 아이디어는 인프라 코드가 예상대로 작동하는지 확인하는 코드를 작성하는 것이다. 모든 커밋 후에 테스트를 실행하고 실패한 커밋을 되돌려야 한다. 이렇게 하면 코드 베이스에 적용되는 모든 변경 사항이 작동하고 대부분 문제는 배포 시가 아닌 빌드 시에 발견된다.
--- p.169