IaC·Terraform과 재현 가능한 운영

01명령 순서와 원하는 상태를 코드로 표현하는 방식

• 명령형명령형 스크립트는 디렉터리를 만들고 파일을 쓰고 서비스를 시작하는 순서를 직접 기술한다.
• 선언적·구성선언적 구성은 원하는 자원의 속성이나 상태를 표현하고 도구가 현재 상태와 비교하여 필요한 작업을 결정한다.
• 명령형·선언형의 조합둘은 완전히 분리된 세계가 아니라 한 자동화 안에서 결합할 수 있다.

  • 어떤 방식이든 입력 대상·버전·권한·오류 처리·변경 결과가 정의되어야 재현할 수 있다.
• IaCIaC는 클라우드 전용 또는 컨테이너의 다른 이름이 아니다.
• API·provider온프레미스 가상화·네트워크·DNS·외부 API 자원도 도구와 provider가 지원하면 코드로 관리할 수 있다.

  • 같은 명령을 두 번 실행했다는 사실만으로 원하는 상태가 재현된 것은 아니며 패키지 저장소·이미지·시간에 따라 결과가 달라질 수 있어 의존성 버전과 입력도 기록한다.

02Terraform의 구성·provider·state가 연결되는 방식

• Terraform·구성Terraform 구성은 어떤 provider의 어떤 자원을 어떤 속성으로 관리할지 표현한다.
• provider·APIprovider는 특정 API와 상호작용하는 플러그인 역할을 한다.
• state·구성state는 구성에 있는 자원 주소와 실제 원격 객체의 식별 관계 등을 기록한다.
• 기존 자원과 state 연결코드 파일만 있고 기존 객체와의 연결 정보가 없으면 도구가 어느 객체를 관리해야 하는지 다르게 판단할 수 있다.

  • state는 단순한 실행 로그나 운영체제 백업이 아니다.
• state의 민감정보원격 자원의 속성과 비밀값이 포함될 수 있으므로 코드 저장소와 동일하게 아무에게나 공개해서는 안 된다.

  • 백엔드의 접근 통제·버전 보관·잠금 지원을 고려한다.
• statestate를 직접 편집하거나 삭제한다고 실제 인프라 자원이 정상적으로 제거·복원되는 것도 아니며 관리 관계와 실제 객체를 분리해서 이해해야 한다.

03참조가 의존 그래프와 생성 순서를 만든다

• 구성VM 구성에서 네트워크 자원의 ID를 참조하면 VM은 그 네트워크가 준비된 뒤 생성되어야 한다.
• 의존 그래프·병렬 처리이런 속성 참조는 의존 관계를 표현하고 도구는 독립적인 자원은 병렬로 처리할 수 있다.
• 그래프와 병렬 처리파일에 적힌 줄 순서만으로 모든 실제 생성 순서가 결정된다고 생각하면 안 된다.
• 명시적 Depends_on명시적 depends_on은 속성 참조로 드러나지 않는 의존성이 있을 때 제한적으로 사용한다.
• 교체·provider변경이 속성 갱신으로 가능한지 기존 객체 교체를 요구하는지는 자원과 provider 규칙에 달려 있다.
• 변경과 교체 조건VM의 이름 변경과 기반 디스크 변경을 똑같은 가벼운 편집으로 볼 수 없다.
• 교체·계획그래프는 삭제와 교체 순서에도 관여하므로 계획에 replace나 destroy가 나타날 때 연결된 데이터·서비스 수명을 함께 검토한다.
• provider아래 HCL은 실제 provider 자원을 배포하지 않는 입력 규칙 예다.

variable "service_name" {
  type = string
  validation {
    condition     = can(regex("^[a-z][a-z0-9-]{2,30}$", var.service_name))
    error_message = "Use 3-31 lowercase letters, digits, or hyphens; start with a letter."
  }
}

교육용 예시. 실제 원격 접속·설정 변경·배포는 실행하지 않았다.

04init·plan·apply와 drift의 관찰

• init·providerinit는 작업 디렉터리의 provider·모듈·백엔드 등 필요한 구성을 준비한다.
• 구성validate는 구성의 구조적 유효성을 검사하고 plan은 현재 조회 상태와 원하는 구성을 비교해 예정 변경을 보여 준다.
• apply·계획apply는 선택한 계획을 실제 API 작업으로 수행한다.
• planplan은 실제 시스템 변경이 아니라 비교 결과이지만 상태 조회·provider 동작과 외부 데이터 조회가 있을 수 있어 실행 환경 권한과 입력을 가진 과정이다.
• 실제 자원·drift관리자가 콘솔에서 직접 값을 바꾸면 코드와 실제 자원이 어긋나는 drift가 생긴다.
• 계획다음 계획에서 그 차이가 보일 수 있고 선언한 값으로 되돌리거나 코드를 새 의도에 맞게 변경할 수 있다. 계획 생성 후 실제 상태가 달라질 수 있으므로 저장된 plan을 적용할 때도 그 유효성과 팀의 실행 순서를 관리한다.
• Terraform같은 자원을 Terraform과 별도 스크립트가 경쟁하여 고치면 끝없이 서로 덮어쓸 수 있다.

terraform init
terraform validate
terraform plan
# 위 단계의 의미를 학습하는 예시이며 실제 provider·계정이 준비돼야 한다.
# apply는 별도의 실제 자원 변경 단계다.

교육용 예시. 실제 원격 접속·설정 변경·배포는 실행하지 않았다.

08Terraform·Ansible·Compose·Kubernetes의 관리 범위

• TerraformTerraform으로 VM·네트워크·디스크 같은 API 자원을 준비한 뒤 Ansible로 게스트 계정·패키지·서비스 설정을 관리할 수 있다.
• Compose컨테이너 이미지는 프로그램과 사용자 공간 의존성을 담고 Docker Compose는 여러 서비스·네트워크·볼륨의 로컬 구성을 정의한다.
• KubernetesKubernetes는 클러스터에서 원하는 워크로드 상태를 관찰하고 조정하는 오케스트레이션 시스템이다. K3s는 Kubernetes 배포판이며 이 도구들이 순서대로 이전 기술을 대체하는 고정 성숙도 단계는 아니다.
• providerWindows VM도 provider가 자원과 이미지·템플릿을 지원하면 준비할 수 있다.

  • 그러나 guest 내부의 WinRM·계정·정책 구성은 별도 초기화 또는 설정 관리 범위다.
• 관리 계층의 경계각 층의 입력과 출력 경계를 정하면 VM 생성 성공, 원격 접속 가능, 서비스 준비 완료라는 서로 다른 완료 기준을 명확히 할 수 있다.

09코드 변경에서 검토·배포·복구까지 연결하기

• 변경 검토·적용 단계인프라 코드의 변경은 Git에서 차이를 검토하고 형식·정적 검사, 작은 테스트 환경, 계획 검토를 거친 뒤 실제 대상에 적용하는 구조로 만들 수 있다.
• 비밀값비밀값은 코드나 CI 출력에 직접 넣지 않고 권한이 제한된 자격 증명 공급 경로를 사용한다.
• providerprovider와 모듈 버전이 바뀌면 같은 구성도 다른 동작을 할 수 있으므로 버전 선택과 잠금 파일의 의미를 유지한다.
• 코드코드를 이전 commit으로 되돌리는 것이 데이터까지 과거로 돌린다는 보장은 없다.
• API·복구삭제된 DB, 마이그레이션된 스키마, 외부 API 변경은 별도의 복구 경로가 필요하다.
• 부분 생성 후 재계획작업 중 일부 자원만 생성된 상태도 가능하므로 실패 뒤 현재 상태를 다시 조회하고 다음 계획을 판단한다.
• 재현·복원·가용성코드의 재현성과 데이터의 복원성, 인프라의 가용성을 서로 다른 목표로 설계해야 한다.

10구성과 실제 자원을 비교해 계획 만들기

• Terraform·구성Terraform 구성은 어떤 자원을 원하는지 선언하고 Provider는 해당 플랫폼의 API와 상호작용한다.
• 구성과 실제 객체의 연결state는 코드의 자원 주소와 실제 자원 식별자 등을 연결하는 데 사용된다.
• Plan의 상태 비교일반적인 plan은 기존 객체의 현재 정보를 읽어 구성과 비교하고 필요한 변경을 계산한다.

  • 코드·state·실제 자원은 서로 다른 정보다.
• State의 관리 대상코드에 이름이 있다는 것과 state가 특정 실제 VM을 관리 대상으로 알고 있다는 것을 구분해야 삭제·교체의 영향을 해석할 수 있다.
• 교체원하는 속성 하나를 바꿔도 플랫폼과 Provider의 제약에 따라 제자리 갱신이 아니라 기존 자원을 지우고 새로 만드는 교체가 필요할 수 있다.
• 계획·교체계획에서 추가·갱신·교체·삭제와 의존 자원의 연쇄 변화를 확인한다.
• Plan의 읽기 동작plan 자체는 제안한 변경을 적용하지 않지만 데이터 소스 조회나 Provider 통신 등 읽기 동작은 수행할 수 있다.
• 계획·state저장된 계획과 state에도 민감한 값이 포함될 수 있으므로 일반적인 공개 문서나 빌드 결과와 같은 경로로 취급하지 않는다.

1. 원하는 자원 정의변수와 버전을 포함해 구성 내용을 해석한다.
2. 관리 객체 연결자원 주소와 기존 실제 객체의 연결 정보를 제공한다.
3. 현재 상태 조회Provider를 통해 관리 객체의 실제 속성을 읽는다.
4. 변경 계획추가·갱신·교체·삭제와 의존 관계를 계산한다.
5. 검토된 변경 적용별도 적용 단계에서 API에 변경을 요청한다.
6. 결과 상태 기록성공·부분 완료 결과에 맞춰 관리 정보를 갱신한다.

11드리프트와 부분 실패 뒤의 관찰

• 계획운영 콘솔에서 긴급하게 바꾼 실제 값이 코드와 다르면 다음 계획에 차이로 나타날 수 있다.

  • 그 차이가 의도된 긴급 조치인지 실수인지 판단하지 않고 무조건 적용하면 필요한 조치가 사라질 수 있다.
• 드리프트 처리 방식코드에 반영할 변경과 되돌릴 변경을 결정하고 같은 자원을 다른 도구가 동시에 관리하는지도 확인한다.
• TerraformTerraform으로 VM을 준비하고 Ansible로 내부 서비스를 설정하는 경우 두 도구가 책임질 경계를 문서화하면 충돌을 줄일 수 있다.
• 부분 실패와 실제 상태일부 자원 생성 후 나머지가 실패할 수 있으므로 오류 메시지만 보고 전체 작업이 원상복구됐다고 가정하지 않는다.
• 실제 자원·state실제 자원과 state를 확인한 뒤 재계획하고 상태 파일을 임의 편집·삭제해 문제를 숨기지 않는다.
• 협업과 state 잠금협업에서는 backend의 접근 권한과 지원되는 잠금 기능, 동시 실행 정책을 준비한다.
• 재현·복구의 준비 조건인프라 코드도 다른 코드처럼 검토·버전 관리가 필요하지만 배포 대상 계정과 변수, 비밀 공급·백업·복구 절차까지 있어야 같은 결과를 안정적으로 재현할 수 있다.
• 멱등성멱등성은 잘못 정의된 상태를 반복 적용해도 올바른 서비스가 된다는 보증이 아니다.

  • 원하는 상태의 정의와 실제 배포 결과를 함께 검토한다.