クイズ: データソースとリソースの違い
한국어 원문으로 표시합니다.
상태 파일에서 data 블록으로 읽은 항목과 resource 로 만든 항목을 가르는 필드는 무엇인가?
- 항목의 provider 필드가 builtin 인지 아닌지로 갈린다
- 항목의 mode 필드가 data 인지 managed 인지로 갈린다
- 항목의 instances 배열이 비어 있는지 아닌지로 갈린다
- 항목의 schema_version 이 0 인지 1 이상인지로 갈린다
이미 적용을 마친 설정에서 tofu destroy 를 돌렸다. data 블록으로 읽고 있던 파일은 어떻게 되는가?
- 상태에서 항목이 지워지고 원본 파일도 함께 지워진다
- 원본 파일은 남지만 다음 계획에서 다시 만들어 달라고 요구한다
- 상태에서 항목은 빠지지만 원본 파일은 그대로 남는다
- destroy 는 데이터 소스를 만나면 경고를 내고 전체를 중단한다
계획 출력에 data.local_file.back will be read during apply 가 나왔다. 가장 그럴듯한 원인은?
- 데이터 소스가 읽을 파일의 이름이 아직 만들어지지 않은 리소스의 속성에 의존한다
- 데이터 소스가 읽을 파일의 크기가 커서 계획 단계에서는 건너뛴다
- 프로바이더 미러가 오프라인이라 계획 단계의 읽기가 막혀 있다
- 이전 apply 가 실패해 상태에 그 데이터 소스의 사본이 없다
이미 디스크에 있는 파일을 읽는 데이터 소스에 depends_on 을 붙였다. 계획에서 달라지는 것은?
- 원본이 있으므로 아무것도 달라지지 않고 계획 단계에서 그대로 읽는다
- 읽기가 적용 시점으로 밀려 그 값과 하류 속성이 알 수 없음으로 나온다
- 계획이 의존 대상의 적용을 기다리며 잠금 시간만큼 멈춰 있다가 진행한다
- 데이터 소스가 managed 로 승격되어 상태에서 소유 항목이 된다
설정 파일은 한 글자도 고치지 않았는데, 데이터 소스가 읽는 원본 파일의 내용이 바뀌자 계획에 하류 리소스의 교체가 떴다. 옳은 설명은?
- 상태가 실물과 어긋난 드리프트이므로 apply -refresh-only 로 상태만 고치면 된다
- 데이터 소스의 상태 사본이 깨진 것이므로 state rm 으로 그 항목을 지워야 한다
- 데이터 소스는 계획마다 다시 읽으므로 원본 변경이 하류의 입력 변경으로 잡힌 것이다
- 프로바이더 버전이 바뀌면서 데이터 소스의 스키마가 달라져 생긴 차이다
terraform_data 블록에 대한 설명으로 옳은 것은?
- 내장 프로바이더가 제공하는 데이터 소스라 상태의 mode 가 data 로 기록된다
- 내장 프로바이더가 제공하는 managed 리소스라 값을 바꾸면 계획에 변경이 잡힌다
- 이름 그대로 상태 파일 전체를 다른 설정에서 읽어 오는 원격 상태 블록이다
- 계획 단계에서만 존재하고 상태에는 아무 항목도 남기지 않는 임시 블록이다