Terraform CLI 구성 파일 만들기

Terraform CLI 구성 파일 만들기 (Create a Terraform CLI configuration file)

이 주제는 Terraform CLI의 동작을 사용자 지정하기 위한 구성 파일을 만드는 방법을 설명해요.

출처: 문서

본문

소개 (Introduction)

CLI 구성 파일은 모든 Terraform 작업 디렉터리에 적용되는 CLI 동작에 대한 사용자별 설정을 구성해요. 이 구성은 인프라 구성과는 별개예요. 호스트 운영 체제에 따라 아래에서 설명하는 대로 .terraformrc 또는 terraform.rc라는 파일에 사용자 지정 구성을 정의할 수 있어요.

위치 (Locations)

구성은 호스트 운영 체제에 따라 위치가 달라지는 단일 파일에 배치할 수 있어요.

• Windows에서는 파일 이름이 terraform.rc여야 하며 관련 사용자의 %APPDATA% 디렉터리에 배치해요. 이 디렉터리의 물리적 위치는 Windows 버전과 시스템 구성에 따라 달라져요. 시스템에서 위치를 찾으려면 PowerShell에서 $env:APPDATA를 사용하세요.
• 그 외 모든 시스템에서는 파일 이름이 .terraformrc(앞에 마침표가 있는 점에 주의)여야 하며 관련 사용자의 홈 디렉터리에 직접 배치해요.

Windows에서는 Windows 탐색기가 파일 확장자를 숨기는 기본 동작에 주의하세요. Terraform은 terraform.rc.txt라는 이름의 파일을 CLI 구성 파일로 인식하지 않는데, Windows 탐색기가 그 이름을 terraform.rc로 표시할 수는 있지만요. 파일 이름을 확인하려면 PowerShell 또는 명령 프롬프트에서 dir을 사용하세요.

Terraform CLI 구성 파일의 위치는 TF_CLI_CONFIG_FILE 환경 변수로도 지정할 수 있어요. 그런 파일은 *.tfrc 명명 패턴을 따라야 해요.

구성 파일 문법 (Configuration File Syntax)

구성 파일은 .tf 파일과 동일한 HCL 문법을 사용하지만 다른 속성과 블록을 가져요. 다음 예시는 일반 문법을 보여줘요. 각 설정의 의미는 다음 섹션을 참고하세요.

plugin_cache_dir   = "$HOME/.terraform.d/plugin-cache"
disable_checkpoint = true

사용 가능한 설정 (Available Settings)

CLI 구성 파일에서 설정할 수 있는 설정은 다음과 같아요.

• credentials — HCP Terraform 또는 Terraform Enterprise와 함께 사용할 자격 증명을 구성해요. 자세한 내용은 아래 자격 증명을 참고하세요.
• credentials_helper — HCP Terraform 또는 Terraform Enterprise 자격 증명의 저장과 검색을 위한 외부 헬퍼 프로그램을 구성해요. 자세한 내용은 아래 자격 증명 헬퍼를 참고하세요.
• disable_checkpoint — true로 설정하면 HashiCorp가 제공하는 네트워크 서비스에 접근해야 하는 업그레이드 및 보안 게시판 확인을 비활성화해요.
• disable_checkpoint_signature — true로 설정하면 위에서 설명한 업그레이드 및 보안 게시판 확인을 허용하되, 경고 메시지 중복 제거에 사용되는 익명 ID 사용을 비활성화해요.
• plugin_cache_dir — 플러그인 캐싱을 활성화하고, 문자열로 플러그인 캐시 디렉터리의 위치를 지정해요.
• provider_installation — terraform init이 프로바이더 플러그인을 설치할 때 사용하는 설치 방법을 사용자 지정해요. 자세한 내용은 아래 프로바이더 설치를 참고하세요.

자격 증명 (Credentials)

HCP Terraform은 Terraform과 함께 사용할 여러 원격 네트워크 서비스를 제공하며, Terraform Enterprise는 그 서비스들을 당신의 인프라 안에서 호스팅할 수 있게 해줘요. 예를 들어 이 시스템들은 원격 작업과 프라이빗 모듈 레지스트리를 모두 제공해요.

Terraform 특화 네트워크 서비스와 상호작용할 때 Terraform은 CLI 구성 파일의 credentials 블록에서 API 토큰을 찾을 것으로 기대해요.

credentials "app.terraform.io" {
  token = "xxxxxx.atlasv1.zzzzzzzzzzzzz"
}

웹 브라우저가 있는 컴퓨터에서 Terraform CLI를 대화형으로 실행한다면 terraform login 명령을 사용해 자격 증명을 얻고 CLI 구성에 자동으로 저장할 수 있어요. 그렇지 않다면 credentials 블록을 직접 작성할 수 있어요.

여러 호스트의 서비스를 정기적으로 사용한다면 credentials 블록을 여러 개 가질 수 있어요. 많은 사용자는 HCP Terraform(app.terraform.io에서) 또는 조직 자체의 Terraform Enterprise 호스트 중 하나만 구성해요. 각 credentials 블록에는 해당 호스트에 사용할 API 토큰을 주는 token 인자가 포함돼요.

중요: HCP Terraform 또는 Terraform Enterprise를 사용한다면, 제공하는 토큰은 반드시 사용자 토큰 또는 팀 토큰이어야 해요. 조직 토큰은 명령줄 Terraform 작업에는 사용할 수 없어요.

참고: 자격 증명 호스트 이름은 모듈 소스 및/또는 백엔드 구성의 호스트 이름과 일치해야 해요. Terraform Enterprise 인스턴스가 여러 호스트 이름에서 사용 가능하다면 그중 하나만 일관되게 사용하세요. HCP Terraform은 현재 호스트 이름 app.terraform.io와 과거 호스트 이름 atlas.hashicorp.com 모두에서 API 호출에 응답해요.

환경 변수 자격 증명 (Environment Variable Credentials)

참고: 환경 변수 자격 증명은 Terraform v1.2.0 이상에서 지원돼요.

API 토큰을 CLI 구성에 직접 저장하고 싶지 않다면 호스트별 환경 변수를 사용할 수 있어요. 환경 변수 이름은 도메인 이름에 TF_TOKEN_ 접두사를 붙이고 마침표를 밑줄로 인코딩해야 해요. 예를 들어 TF_TOKEN_app_terraform_io라는 변수의 값은 CLI가 app.terraform.io 호스트 이름에 서비스 요청을 할 때 bearer 권한 부여 토큰으로 사용돼요.

비 ASCII 문자가 포함된 도메인 이름은 ACE 접두사와 함께 punycode 등가물로 변환해야 해요. 예를 들어 例えば.com에 대한 토큰 자격 증명은 TF_TOKEN_xn--r8j3dr99h_com이라는 변수에 설정해야 해요.

하이픈은 호스트 이름 안에서 유효하지만 변수 이름으로는 보통 유효하지 않으므로 이중 밑줄로 인코딩될 수 있어요. 예를 들어 도메인 이름 café.fr에 대한 토큰은 TF_TOKEN_xn--caf-dma.fr, TF_TOKEN_xn--caf-dma_fr 또는 TF_TOKEN_xn____caf__dma_fr로 설정할 수 있어요. 여러 변수가 같은 호스트 이름으로 평가되면 Terraform은 운영 체제의 변수 테이블에서 마지막에 정의된 것을 선택해요.

자격 증명 헬퍼 (Credentials Helpers)

credentials_helper를 구성해 Terraform이 다른 자격 증명 저장 메커니즘을 사용하도록 지시할 수 있어요.

credentials_helper "example" {
  args = []
}

credentials_helper는 CLI 구성에서 최대 한 번 나타날 수 있는 구성 블록이에요. 그 라벨(위의 "example")은 사용할 자격 증명 헬퍼의 이름이에요. args 인자는 선택이며 헬퍼 프로그램에 추가 인자를 전달할 수 있어요. 예를 들어 자격 증명을 위해 접근할 원격 호스트의 주소로 구성해야 할 때가 있어요.

구성된 자격 증명 헬퍼는 이전 섹션에서 설명한 것처럼 credentials 블록에 명시적으로 구성되지 않은 호스트의 자격 증명을 가져오는 데만 사용돼요. 반대로 말하면, credentials_helper 블록과 함께 특정 호스트 이름에 대해 credentials 블록을 작성하면 헬퍼가 반환하는 자격 증명을 덮어쓸 수 있어요.

Terraform은 기본 배포에 자격 증명 헬퍼를 포함하지 않아요. 기존 사내 자격 증명 관리 시스템과 통합되는 자체 자격 증명 헬퍼를 작성하고 설치하는 방법은 자격 증명 헬퍼 내부 안내를 참고하세요.

자격 증명 소스 우선순위 (Credentials Source Priority Order)

특정 서비스 호스트에 대해 위에서 설명한 환경 변수에서 찾은 자격 증명은 terraform login이 설정한 CLI 구성의 자격 증명보다 우선해요. 둘 다 설정되지 않았다면 구성된 자격 증명 헬퍼가 조회돼요.

참고: terraform-credentials-helper 사용자에게 이 우선순위는 Terraform 1.2 릴리스 이후 사실상 뒤집혔어요. 이전에는 CLI 구성 안에서 찾은 자격 증명이나 terraform login이 설정한 자격 증명이 TF_TOKEN_* 변수보다 우선했어요.

프로바이더 설치 (Provider Installation)

프로바이더 플러그인을 설치하는 기본 방법은 프로바이더 레지스트리에서 설치하는 것이에요. 프로바이더의 원본 레지스트리는 registry.terraform.io/hashicorp/aws처럼 프로바이더 소스 주소에 인코딩돼 있어요. 일반적인 경우의 편의를 위해 Terraform은 registry.terraform.io의 프로바이더에 대해 호스트 이름 부분을 생략할 수 있게 해주므로 hashicorp/aws처럼 더 짧은 공개 프로바이더 주소를 쓸 수 있어요.

하지만 플러그인을 원본 레지스트리에서 직접 다운로드하는 것이 항상 적절한 것은 아니에요. 예를 들어 조직 내 방화벽 제한이나 지역적 이유로 Terraform을 실행하는 시스템이 원본 레지스트리에 접근하지 못할 수 있어요.

이런 상황에서 Terraform 프로바이더를 사용할 수 있게 하기 위해, 프로바이더 플러그인을 Terraform에서 사용 가능하게 만드는 몇 가지 대체 옵션이 있어요. 다음 섹션에서 설명할게요.

명시적 설치 방법 구성 (Explicit Installation Method Configuration)

CLI 구성의 provider_installation 블록은 Terraform의 기본 설치 동작을 덮어쓸 수 있어서, 사용하려는 프로바이더 중 일부 또는 전부에 대해 Terraform이 로컬 미러를 사용하도록 강제할 수 있어요.

provider_installation 블록의 일반적인 구조는 다음과 같아요.

provider_installation {
  filesystem_mirror {
    path    = "/usr/share/terraform/providers"
    include = ["example.com/*/*"]
  }
  direct {
    exclude = ["example.com/*/*"]
  }
}

provider_installation 블록 안의 각 중첩 블록은 하나의 설치 방법을 지정해요. 각 설치 방법은 특정 설치 방법이 어떤 프로바이더에 사용될 수 있는지 지정하는 include와 exclude 패턴을 모두 받아들일 수 있어요. 위 예시에서 원본 레지스트리가 example.com에 있는 프로바이더는 /usr/share/terraform/providers의 파일시스템 미러에서만 설치할 수 있고, 그 외 모든 프로바이더는 원본 레지스트리에서만 직접 설치할 수 있도록 지정해요.

특정 설치 방법에 include와 exclude를 모두 설정하면 제외 패턴이 우선해요. 예를 들어 registry.terraform.io/hashicorp/*를 포함하면서 registry.terraform.io/hashicorp/dns를 제외하면, 그 설치 방법은 hashicorp/dns를 제외한 hashicorp 네임스페이스의 모든 것에 적용돼요.

기본 구성의 프로바이더 소스 주소와 마찬가지로, 와일드카드를 사용할 때도 공개 Terraform 레지스트리를 통해 배포되는 프로바이더의 registry.terraform.io/ 접두사를 생략할 수 있어요. 예를 들어 registry.terraform.io/hashicorp/*와 hashicorp/*는 동일해요. */*는 */*/*가 아니라 registry.terraform.io/*/*의 축약형이에요.

지원되는 두 가지 설치 방법 타입은 다음과 같아요.

• direct: 프로바이더에 대한 정보를 원본 레지스트리에서 직접 요청하고 레지스트리가 표시하는 위치에서 네트워크로 다운로드해요. 이 방법은 추가 인자를 기대하지 않아요.
• filesystem_mirror: 로컬 디스크의 디렉터리에서 프로바이더 사본을 조회해요. 이 방법은 어느 디렉터리를 찾을지 나타내는 추가 인자 path를 요구해요.
  • Terraform은 주어진 디렉터리가 중첩 디렉터리 구조를 포함할 것으로 기대하는데, 경로 세그먼트들이 함께 사용 가능한 프로바이더에 대한 메타데이터를 제공해요. 다음 두 가지 디렉터리 구조가 지원돼요.
    • Packed 레이아웃: HOSTNAME/NAMESPACE/TYPE/terraform-provider-TYPE_VERSION_TARGET.zip — 프로바이더의 원본 레지스트리에서 얻은 배포 zip 파일.
    • Unpacked 레이아웃: HOSTNAME/NAMESPACE/TYPE/VERSION/TARGET — 프로바이더 배포 zip 파일의 추출 결과를 담은 디렉터리.
  • 두 레이아웃 모두에서 VERSION은 2.0.0 같은 문자열이고, TARGET은 darwin_amd64, linux_arm, windows_amd64 같은 형식을 사용해 특정 대상 플랫폼을 지정해요.
  • Unpacked 레이아웃을 사용하면 Terraform은 프로바이더를 설치할 때 디렉터리의 깊은 복사본을 만드는 대신 미러 디렉터리에 대한 심볼릭 링크를 만들려고 시도해요. Packed 레이아웃은 설치 중에 zip 파일을 추출해야 하므로 이를 방지해요.
  • 검색할 여러 다른 디렉터리를 지정하기 위해 filesystem_mirror 블록을 여러 개 포함할 수 있어요.
• network_mirror: 어떤 레지스트리 호스트에 속하든 특정 HTTPS 서버에서 프로바이더 사본을 조회해요. 이 방법은 미러 기본 URL을 나타내는 추가 인자 url을 요구하며, https: 스키마를 사용하고 끝에 슬래시를 붙여야 해요.
  • Terraform은 주어진 URL이 프로바이더 네트워크 미러 프로토콜 구현의 기본 URL일 것으로 기대하는데, 이 프로토콜은 일반적인 정적 웹사이트 호스팅 메커니즘으로 비교적 쉽게 구현할 수 있도록 설계됐어요.
  • 경고: 신뢰하지 않는 network_mirror URL은 구성하지 마세요. 프로바이더 미러 서버는 신원을 검증하기 위해 TLS 인증서 확인의 대상이 되지만, TLS 인증서가 있는 네트워크 미러가 악성 콘텐츠가 들어 있는 업스트림 프로바이더의 수정된 사본을 제공할 수 있어요.

Terraform은 include와 exclude 패턴이 주어진 프로바이더와 일치하는 모든 지정된 방법을 시도하고, 그 방법들 전체에서 각 Terraform 구성에 주어진 버전 제약 조건과 일치하는 가장 새로운 사용 가능 버전을 선택해요. 특정 프로바이더의 로컬 미러가 있고 Terraform이 그 로컬 미러만 사용하도록 하려면, direct 설치 방법을 아예 제거하거나 그 exclude 인자로 특정 프로바이더에 대한 사용을 비활성화해야 해요.

암시된 로컬 미러 디렉터리 (Implied Local Mirror Directories)

CLI 구성에 provider_installation 블록이 전혀 없다면 Terraform은 암시된 구성을 만들어요. 암시된 구성은 filesystem_mirror 방법들의 선택과 then direct 방법을 포함해요.

Terraform이 파일시스템 미러로 선택할 수 있는 디렉터리 집합은 Terraform을 실행하는 운영 체제에 따라 달라져요.

• Windows: %APPDATA%/terraform.d/plugins 및 %APPDATA%/HashiCorp/Terraform/plugins
• Mac OS X: $HOME/.terraform.d/plugins, ~/Library/Application Support/io.terraform/plugins, /Library/Application Support/io.terraform/plugins
• Linux 및 기타 Unix 계열 시스템: 유효한 XDG Base Directory 데이터 디렉터리(예: $XDG_DATA_HOME/terraform/plugins) 안에 있는 $HOME/.terraform.d/plugins 및 terraform/plugins. XDG 환경 변수가 없으면 Terraform은 ~/.local/share/terraform/plugins, /usr/local/share/terraform/plugins, /usr/share/terraform/plugins를 사용해요.

현재 작업 디렉터리에 terraform.d/plugins 디렉터리가 존재하면 운영 체제와 무관하게 Terraform은 그 디렉터리도 포함해요. 이 동작은 init 명령에서 -chdir 옵션을 사용할 때 바뀌어요. 그 경우 Terraform은 -chdir로 지정한 디렉터리가 아니라 실행 디렉터리(launch directory)에서 terraform.d/plugins 디렉터리를 확인해요.

Terraform은 위 각 경로가 존재하는지 확인하고, 존재하면 파일시스템 미러로 취급해요. 따라서 각 내부의 디렉터리 구조는 명시적 설치 방법 구성에서 filesystem_mirror 블록에 대해 설명한 두 구조 중 하나와 일치해야 해요.

Terraform은 0개 이상의 암시된 filesystem_mirror 블록에 더해 암시된 direct 블록도 만들어요. Terraform은 모든 파일시스템 미러 디렉터리를 스캔해 어떤 프로바이더가 배치되어 있는지 확인하고, 그 프로바이더들을 암시된 direct 블록에서 자동으로 제외해요. (이 자동 exclude 동작은 암시적 direct 블록에만 적용돼요. 명시적 provider_installation을 사용한다면 의도한 제외를 직접 작성해야 해요.)

프로바이더 플러그인 캐시 (Provider Plugin Cache)

기본적으로 terraform init은 플러그인을 작업 디렉터리의 하위 디렉터리에 다운로드해서 각 작업 디렉터리가 자족적(self-contained)이 되게 해요. 결과적으로 같은 프로바이더를 사용하는 구성이 여러 개 있으면 각 구성에 대해 별도의 플러그인 사본이 다운로드돼요.

프로바이더 플러그인은 꽤 클 수 있으므로(수백 MB 정도), 이 기본 동작은 느리거나 데이터 사용량이 제한된 인터넷 연결을 가진 사람에게 불편할 수 있어요. 따라서 Terraform은 선택적으로 로컬 디렉터리를 공유 플러그인 캐시로 사용할 수 있게 해서, 각각의 개별 플러그인 바이너리가 한 번만 다운로드되게 해요.

플러그인 캐시를 활성화하려면 CLI 구성 파일에서 plugin_cache_dir 설정을 사용해요. 예를 들어:

plugin_cache_dir = "$HOME/.terraform.d/plugin-cache"

이 디렉터리는 Terraform이 플러그인을 캐시하기 전에 이미 존재해야 해요. Terraform은 디렉터리를 직접 만들지 않아요.

Windows에서는 구성 파일 파서가 백슬래시를 이스케이프 시퀀스의 시작으로 간주하므로, 관례적인 백슬래시(\) 대신 슬래시(/) 구분자를 사용해야 해요.

영구 설정에는 구성 파일에서 이 설정을 지정하는 것이 권장되는 방법이에요. 대안으로 TF_PLUGIN_CACHE_DIR 환경 변수를 사용해 특정 셸 세션에서 캐싱을 활성화하거나 기존 캐시 디렉터리를 덮어쓸 수 있어요.

export TF_PLUGIN_CACHE_DIR="$HOME/.terraform.d/plugin-cache"

플러그인 캐시 디렉터리가 활성화되면 terraform init 명령은 여전히 구성되거나 암시된 설치 방법을 사용해 어떤 플러그인이 사용 가능한지에 대한 메타데이터를 얻지만, 적절한 버전이 선택되면 먼저 선택된 플러그인이 캐시 디렉터리에 이미 있는지 확인해요. 있으면 Terraform은 이전에 다운로드된 사본을 사용해요.

선택된 플러그인이 캐시에 아직 없으면 Terraform은 그것을 먼저 캐시에 다운로드한 다음, 현재 작업 디렉터리 아래의 올바른 위치로 거기서 복사해요. 가능하면 Terraform은 캐시된 플러그인의 별도 사본을 여러 디렉터리에 저장하지 않도록 심볼릭 링크를 사용해요.

플러그인 캐시 디렉터리는 구성된 또는 암시된 파일시스템 미러 디렉터리 중 하나와 동일해서는 안 돼요. 캐시 관리 로직이 같은 디렉터리에서 작업할 때 파일시스템 미러 로직과 충돌하기 때문이에요.

Terraform은 플러그인이 캐시에 배치된 후에는 그 플러그인을 캐시에서 직접 삭제하지 않아요. 시간이 지나 플러그인이 업그레이드되면 캐시 디렉터리는 수동으로 삭제해야 하는 사용되지 않는 여러 버전으로 커질 수 있어요.

참고: 플러그인 캐시 디렉터리는 동시성 안전성이 보장되지 않아요. 여러 terraform init 호출이 있는 환경에서 프로바이더 설치 프로그램의 동작은 정의되지 않아요.

프로바이더 플러그인 캐시가 의존성 잠금 파일을 깨뜨리는 것 허용 (Allowing the Provider Plugin Cache to break the dependency lock file)

참고: 여기서 설명하는 옵션은 비정상적이고 예외적인 상황에서만 사용하기 위한 것이에요. 확실히 필요하다고 확신하고 그 결과를 완전히 이해하지 않는 한 이 옵션을 설정하지 마세요.

기본적으로 Terraform은 글로벌 캐시 디렉터리의 패키지가 그 프로바이더에 대한 의존성 잠금 파일에 기록된 체크섬 중 적어도 하나와 일치할 때만 사용해요. 이렇게 해서 Terraform이 특정 구성에서 새 프로바이더를 처음 사용할 때 항상 완전하고 올바른 의존성 잠금 파일 항목을 생성할 수 있음을 보장해요.

하지만 일부 특수한 상황에서 팀이 의도한 대로 의존성 잠금 파일을 사용하지 못했고, 권장대로 버전 관리에 포함하지 않고 Terraform이 프로바이더를 설치할 때마다 다시 생성하게 하는 경우가 있다는 것을 알고 있어요.

실행 사이에 의존성 잠금 파일을 버전 관리 시스템에 보존하지 않는 팀을 위해, Terraform은 확인해줄 의존성 잠금 파일 항목이 이미 없더라도 캐시 디렉터리의 패키지를 항상 유효한 것으로 취급하라고 Terraform에 지시하는 추가 CLI 구성 설정을 허용해요.

plugin_cache_may_break_dependency_lock_file = true

대안으로, TF_PLUGIN_CACHE_MAY_BREAK_DEPENDENCY_LOCK_FILE 환경 변수를 빈 문자열 또는 0 이외의 값으로 설정할 수 있는데, 이는 위 설정과 동일해요.

이 옵션을 설정하면 Terraform CLI가 캐시를 사용해 프로바이더를 설치할 수 있다면 그 프로바이더에 대한 불완전한 의존성 잠금 파일 항목을 만들 권한을 얻어요. 그 상황에서 의존성 잠금 파일은 현재 시스템에서는 사용에 유효하지만, 다른 운영 체제나 CPU 아키텍처를 가진 다른 컴퓨터에서는 유효하지 않을 수 있어요. 글로벌 캐시의 패키지 체크섬만 포함하기 때문이에요.

대부분의 사용자는 이 옵션을 설정하지 않은 채 두는 것을 권장해요. 그 경우 Terraform은 특정 구성에서 처음 사용할 때 항상 프로바이더를 업스트림에서 설치하지만, 의존성 잠금 파일이 프로바이더 패키지에 대한 유효한 체크섬을 기록한 후에는 이후 실행에서 캐시 항목을 재사용할 수 있어요.

참고: Terraform 팀은 향후 버전에서 의존성 잠금 파일 메커니즘을 더 많은 상황에서 사용할 수 있도록 개선할 계획이에요. 그때 이 옵션은 조용히 무시될 거예요. 이 옵션 사용에 의존하는 워크플로우라면 GitHub 이슈를 열어 상황에 대한 세부 정보를 공유해서, 의존성 잠금 파일을 깨뜨리지 않고 지원할 방법을 고려할 수 있게 해주세요.

프로바이더 개발자를 위한 개발 오버라이드 (Development Overrides for Provider Developers)

참고: 개발 오버라이드는 Terraform v0.14 이상에서만 작동해요. CLI 구성에서 dev_overrides 블록을 사용하면 Terraform v0.13이 구성을 유효하지 않은 것으로 거부해요.

일반적으로 Terraform은 모든 작업이 의도된 버전의 프로바이더로 이루어지도록 하고 작성자가 통제된 방식으로 새 프로바이더 버전으로 점진적으로 업그레이드할 수 있도록, 프로바이더에 대한 버전 선택과 체크섬을 검증해요.

하지만 프로바이더를 개발할 때는 이 버전과 체크섬 규칙이 불편해요. 아직 연관된 버전 번호도 없고 프로바이더 레지스트리에 공식 체크섬 집합도 없는 개발 빌드의 프로바이더에 대해 테스트 구성을 시도하고 싶은 경우가 많기 때문이에요.

프로바이더 개발의 편의를 위해 Terraform은 provider_installation 블록에서 특별한 추가 블록 dev_overrides를 지원해요. 이 블록의 내용은 다른 모든 구성된 설치 방법을 사실상 덮어쓰므로, 이런 타입의 블록은 항상 시퀀스에서 먼저 나타나야 해요.

provider_installation {

  # Use /home/developer/tmp/terraform-null as an overridden package directory
  # for the hashicorp/null provider. This disables the version and checksum
  # verifications for this provider and forces Terraform to look for the
  # null provider plugin in the given directory.
  dev_overrides {
    "hashicorp/null" = "/home/developer/tmp/terraform-null"
  }

  # For all other providers, install them directly from their origin provider
  # registries as normal. If you omit this, Terraform will _only_ use
  # the dev_overrides block, and so no other providers will be available.
  direct {}
}

개발 오버라이드가 적용된 상태에서 terraform init 명령은 여전히 프로바이더의 적절한 게시 버전을 선택해 의존성 잠금 파일에 기록해 향후 사용을 위해 설치하려고 시도해요. 하지만 terraform apply 같은 다른 명령은 hashicorp/null에 대한 잠금 파일 항목을 무시하고 주어진 디렉터리를 사용해요. 새 변경 사항이 프로바이더의 게시 릴리스에 포함되면 terraform init -upgrade로 의존성 잠금 파일에서 새 버전을 선택하고 개발 오버라이드를 제거할 수 있어요.

특정 프로바이더에 대한 오버라이드 경로는 프로바이더를 배포할 때 .zip 파일에 포함될 것과 유사한 디렉터리여야 해요. 최소한 프로바이더 타입인 null을 가진 terraform-provider-null 같은 접두사로 이름이 지어진 실행 파일을 포함해야 해요. 프로바이더가 배포 패키지에서 다른 파일을 사용한다면 그 파일들도 오버라이드 디렉터리에 복사할 수 있어요.

프로바이더 개발에 적극적으로 작업하는 셸 세션에서만 개발 오버라이드를 활성화하고 싶을 수도 있어요. 그렇다면 개발 디렉터리에 위와 같은 내용의 로컬 CLI 구성 파일(예를 들어 dev.tfrc라고 이름)을 작성하고, TF_CLI_CONFIG_FILE 환경 변수로 Terraform이 기본 구성 대신 그 로컬 CLI 구성을 사용하도록 지시할 수 있어요.

export TF_CLI_CONFIG_FILE=/home/developer/tmp/dev.tfrc

개발 오버라이드는 Terraform이 로컬 파일시스템에서 프로바이더를 찾게 하는 일반적인 방법으로 의도되지 않았어요. 릴리스된 프로바이더의 사본을 로컬 파일시스템에 두려면 암시된 로컬 미러 디렉터리 또는 명시적 설치 방법 구성을 대신 참고하세요.

이 개발 오버라이드 메커니즘은 더 원활한 프로바이더 개발을 가능하게 하는 실용적인 방법으로 의도됐어요. 동작 방식, 구성 방법, 의존성 잠금 파일과의 상호작용에 대한 세부 사항은 향후 Terraform 릴리스에서 파괴적 변경을 포함해 모두 진화할 수 있어요. 따라서 개발 오버라이드는 프로바이더 개발 작업 중에만 일시적으로 사용할 것을 권장해요.

제거된 설정 (Removed Settings)

다음 설정은 Terraform 0.12 이하에서 지원되지만 더 이상 사용이 권장되지 않아요.

• providers — 각 명명된 프로바이더에 대한 특정 플러그인의 위치를 지정할 수 있게 하는 구성 블록. 이 메커니즘은 각 프로바이더에 대한 버전 번호와 소스를 지정할 수 없기 때문에 deprecated예요. Terraform 0.13 이상에서 이 설정의 대체 방법은 위 프로바이더 설치를 참고하세요.

더 알아보기 (Learn more)

• Terraform CLI 환경 변수
• 프로바이더 네트워크 미러 프로토콜
• 자격 증명 헬퍼 내부 안내