서버, 네트워크, 스토리지 등 인프라스트럭처의 구성을 수작업이 아니라 코드(정의 파일)로 기술하고, 도구로 자동으로 생성·변경하는 방법. 선언적인 도구에서는 '바람직한 구성'을 쓰고 도구가 실제 상태와의 차분만 적용하므로, 같은 정의를 몇 번 적용해도 같은 결과가 된다(멱등성). 정의를 Git 등으로 관리하면 변경 이력, 리뷰, 같은 환경의 재현이 쉬워진다.
일본어 명칭: IaC(Infrastructure as Code)
IaC(Infrastructure as Code)은(는) 클라우드와 컨테이너의 기초 등 1개 분야의 연습 문제 1개에 나와요.
분야: 클라우드와 컨테이너의 기초
선언적인 기술 방식에서는 '가상 머신을 2대'처럼 결과를 쓰고, 도구가 지금의 상태와 비교하여 필요한 조작을 정합니다. 절차적인 기술 방식에서는 '가상 머신을 1대 만든다'처럼 조작을 순서대로 쓰므로, 두 번 실행하면 4대가 되는 등 지금의 상태를 고려하여 써야 합니다. 인프라스트럭처의 구성에는 멱등성을 얻기 쉬운 선언적인 방법이 자주 사용됩니다.
누군가 관리 화면 등에서 수작업으로 설정을 바꾸면 실제 상태가 코드와 어긋납니다(드리프트). 선언적인 도구는 적용 전에 차분을 표시하여 이런 어긋남을 찾아낼 수 있습니다. 변경은 반드시 코드를 통해 수행한다는 운용으로 하면 환경의 상태가 코드와 계속 일치합니다.
정의 파일을 프로그램과 마찬가지로 Git으로 관리하면 누가 언제 무엇을 바꾸었는지가 남고, 변경을 적용하기 전에 리뷰할 수 있습니다. 같은 정의로 스테이징과 운영 환경을 만들면 환경 차이로 인한 문제도 줄일 수 있습니다. 비밀번호 같은 기밀 값은 정의 파일에 직접 쓰지 않고 전용 구조로 관리합니다.
정답: A. 정의와 실제 상태에 차이가 없으므로 아무것도 변경되지 않는다
선언적인 IaC에서는 절차가 아니라 '바람직한 구성'을 코드로 쓰고, 도구가 실제 상태와 비교하여 차이만큼만 생성, 변경, 삭제합니다. 그래서 같은 정의를 몇 번 적용해도 결과는 같아지며(멱등성), 두 번째에는 변경이 일어나지 않습니다. 누군가 수작업으로 설정을 바꾸어 실제 상태가 정의에서 어긋난 경우(구성 드리프트)에는 다음 적용으로 정의의 상태로 되돌려집니다. 정의를 Git으로 관리하면 변경 이력의 확인이나 리뷰도 프로그램과 마찬가지로 수행할 수 있습니다.
많은 작업을 코드로 만들 수 있지만, 최초의 인증 설정 등 수작업이 남는 부분도 있습니다. 중요한 것은 수작업으로 바꾼 부분을 방치하지 않고 코드에 반영하여, 코드와 실제 상태를 일치시켜 두는 것입니다.
IaC는 네트워크나 가상 머신, 클러스터 등의 기반을 만드는 데 사용되며, 그 위에서 동작하는 애플리케이션은 컨테이너 이미지로 배포되는 경우가 많습니다. Kubernetes의 매니페스트도 바람직한 상태를 선언한다는 점에서 IaC와 같은 사고방식에 서 있습니다.
선언적인 IaC에서는 절차가 아니라 '바람직한 구성'을 코드로 쓰고, 도구가 실제 상태와 비교하여 차이만큼만 생성, 변경, 삭제합니다.
선언적인 IaC(Infrastructure as Code) 도구로, 네트워크와 가상 머신 2대의 구성을 정…Git 가용 영역(Availability Zone) 공동 책임 모델(Shared Responsibility Model) 관측 가능성(Observability) 블루-그린 배포(Blue-Green Deployment) 서버리스(Serverless) 오브젝트 스토리지(Object Storage) 오토 스케일링(Autoscaling) 이뮤터블 인프라스트럭처(Immutable Infrastructure) 카나리 릴리스(Canary Release)