적용 후(post-apply) 작업 수행하기

Terraform으로 만들고 관리하는 리소스를 서비스에 투입하기 위해 파일을 업로드하거나, 명령과 스크립트를 실행하거나, 기타 다른 작업을 수행해야 할 수 있어요. Terraform은 주로 불변(immutable) 인프라 작업을 위해 설계됐으므로, 적용 후 작업을 수행할 때는 목적에 맞게 만들어진(purpose-built) 해결책을 사용하는 걸 강력히 권장해요.

출처: 문서

본문

실습: Provision Infrastructure with Cloud-Init 튜토리얼을 해보세요.

개요

구성을 적용한 후 리소스를 서비스에 투입하기 위해 다음 방법을 사용할 수 있어요:

프로바이더의 cloud-init 구현을 사용해 리소스에 데이터 전달하기.
cloudinit-config 데이터 소스 사용하기.
필요한 도구와 패키지로 머신 이미지를 준비하기.
구성 관리(configuration management) 도구 사용하기.

프로바이더가 리소스에서 CLI 명령과 스크립트를 실행하는 것 같은 적용 후 작업을 지원할 수도 있어요. 리소스 프로바이더 문서를 참고해 안내를 확인하세요. 프로바이더에 리소스와 상호작용하는 메커니즘이 없다면, 프로바이더에 기능 요청(feature request) 티켓을 열어 보세요. 목적에 맞게 만들어진 해결책을 사용할 수 없을 때는 Terraform에 내장된 프로비저너(provisioners)라는 기능을 사용할 수 있어요.

요구 사항

구성 관리나 자동화 소프트웨어 같은 타사(third-party) 소프트웨어를 사용해 리소스를 서비스에 투입한다면, 특정 요구 사항에 대해서는 벤더의 문서를 참고하세요.

컴퓨트 리소스에 데이터 전달하기

가상 머신이나 이와 유사한 컴퓨트 리소스를 배포할 때 리소스에 데이터를 전달할 수 있어요. 대부분의 클라우드 컴퓨팅 플랫폼은 인스턴스 생성 시점에 데이터를 전달하는 메커니즘을 제공해요. 이렇게 하면 시스템 부팅 시 데이터가 즉시 사용 가능해져요.

Cloud-init

많은 Linux 배포판 디스크 이미지에는 cloud-init이 포함되어 있어, 시스템 부팅 시 스크립트를 실행하고 시스템을 구성할 수 있어요. 일부 프로바이더는 가상 머신의 게스트 운영체제에서 cloud-init을 구성할 수 있게 해줘요. cloud-init을 지원하는 프로바이더의 경우 user_data와 custom_data 인자가 데이터를 전달하는 흔한 방법이에요. 자세한 내용은 프로바이더 문서를 참고하세요.

다음 예시에서 azurerm_linux_virtual_machine 리소스의 custom_data 인자는 시작 시 리소스에 전달할 데이터를 포함한 파일을 지정해요:

resource "azurerm_linux_virtual_machine" "example" {
  # . . .
  custom_data = base64encode(file("custom-data.sh"))
}

커스텀 머신 이미지를 만든다면, 런타임에 user_data나 metadata를 사용해 리소스에 전달된 데이터에 접근할 수 있을지도 몰라요. 자세한 내용은 벤더 문서를 참고하세요.

이 접근 방식은 클라우드 프로바이더가 그룹의 서버를 자동으로 실행하고 삭제하게 할 때 필요해요. 개별 서버는 Terraform이 프로비저닝할 수 없을 때 무인(unattended)으로 실행되기 때문이에요.

Terraform으로 개별 서버를 직접 배포하더라도 user_data나 metadata를 사용해 데이터를 전달하면 부팅 시간이 더 빨라져요. 또한 Terraform에서 새 서버로의 직접적인 네트워크 접근과 원격 접근 자격 증명 제공을 피할 수 있어 배포가 단순해져요.

입력 인자(input arguments)

각각의 컴퓨트 리소스에 데이터를 전달하는 방법은 다음 프로바이더 리소스를 참고하세요. cloud-config 파일을 값으로 지정할 수도 있다는 점에 유의하세요. cloudinit_config 데이터 소스를 사용해 cloud-config 파일을 렌더링할 수 있어요. 자세한 내용은 cloudinit_config 문서를 참고하세요.

`cloud-config` 데이터 소스를 사용해 데이터 전달하기

Terraform 구성에 cloudinit_config 데이터 소스를 추가하고 text/cloud-config 콘텐츠로 프로비저닝하려는 파일을 지정할 수 있어요. cloudinit_config 데이터 소스는 cloud-init과 함께 사용할 다중 파트(multi-part) MIME 구성을 렌더링해요. write_files 블록을 사용해 content 필드에 파일을 YAML 인코딩된 구성으로 전달하세요.

다음 예시에서 my_cloud_config 데이터 소스는 cloud.conf라는 text/cloud-config MIME 파트를 지정해요. part.content 필드는 write_files JSON 객체를 YAML로 인코딩해 시스템이 참조하는 파일을 프로비저닝할 수 있게 하는 yamlencode로 설정돼요.

data "cloudinit_config" "my_cloud_config" {
  gzip          = false
  base64_encode = false

  part {
    content_type = "text/cloud-config"
    filename     = "cloud.conf"
    content = yamlencode(
      {
        "write_files" : [
          {
            "path" : "/etc/foo.conf",
            "content" : "foo contents",
          },
          {
            "path" : "/etc/bar.conf",
            "content" : file("bar.conf"),
          },
          {
            "path" : "/etc/baz.conf",
            "content" : templatefile("baz.tpl.conf", { SOME_VAR = "qux" }),
          },
        ],
      }
    )
  }
}

머신 이미지에 구성을 포함시키기

HashiCorp Packer나 비슷한 시스템을 사용해 시스템 구성 단계를 커스텀 이미지에 포함시킬 수 있어요. Packer는 구성 관리 프로비저너를 사용해서, 재사용할 수 있는 시스템 디스크 이미지를 만들기 전에 빌드 과정 중 설치 단계를 실행할 수 있어요.

중앙 서버 구성 요소를 사용하는 구성 관리 소프트웨어는 구성 과정의 일부로 소프트웨어를 등록해야 할 수 있어요. 최종 시스템이 커스텀 이미지에서 부팅될 때까지 등록 단계를 지연해야 해요. 리소스가 SSH나 WinRM으로 Terraform으로부터 명령을 받지 않아도, 부팅 즉시 구성 관리 소프트웨어가 중앙 서버에 스스로 등록할 수 있도록 필요한 정보를 리소스에 전달해 등록을 지연시킬 수 있어요.

실습: Provision Infrastructure with Packer 튜토리얼을 해보세요.

CLI 명령 실행하기

프로바이더가 리소스에서 CLI 명령 실행을 지원할 수도 있어요. 대상 시스템에서 CLI를 호출하는 방법은 리소스 프로바이더 문서를 참고하세요. 프로바이더가 리소스 CLI와 상호작용하는 메커니즘을 포함하지 않는다면, 프로바이더에 기능 요청(feature request) 티켓을 여는 걸 권장해요.

원격 스크립트 실행하기

프로바이더가 스크립트를 실행하는 메커니즘을 포함하지 않는다면, 프로바이더에 기능 요청(feature request) 티켓을 여는 걸 권장해요.

적용 후(post-apply) 작업 수행하기