JSON 템플릿에서의 post-processors 레퍼런스
JSON 템플릿에서의 post-processors 레퍼런스
JSON 템플릿에서 post-processor 블록을 구성하는 방법을 설명하는 문서예요. 각 포스트 프로세서 타입의 설정 옵션은 해당 타입의 문서를 참고하세요.
출처: Packer 공식 문서
본문
Note: 이 페이지는 옛 스타일의 JSON Packer 템플릿에 대한 내용이에요. JSON 템플릿은 여전히 Packer 코어가 지원하지만, Packer 코어에 추가된 새 기능은 JSON 템플릿에 구현되지 않을 수 있어요. Packer를 최고의 경험으로 사용하려면 가능한 한 빨리 HCL 템플릿으로 전환하는 것을 권장합니다. 템플릿 업그레이드를 돕기 위해
hcl2_upgrade커맨드를 제공하고 있어요.
설명 (Description)
post-processor 블록은 빌더들이 만든 이미지에 대해 수행할 추가 작업을 정의해요. 예를 들어 post-processor를 구성해서 파일을 압축하고 아티팩트를 업로드할 수 있습니다.
포스트 프로세서는 선택 사항이에요. 템플릿에 포스트 프로세서가 정의되어 있지 않으면 이미지에 대한 추가 처리는 수행되지 않으며, 빌드의 결과 아티팩트는 빌더가 출력한 이미지 그대로입니다.
템플릿 안에서 포스트 프로세서 정의 섹션은 다음과 같이 생겼어요.
{
"post-processors": [
// ... one or more post-processor definitions here
]
}
각 포스트 프로세서 정의에 대해 Packer는 정의된 각 빌더의 결과를 가져와 포스트 프로세서를 통해 보냅니다. 즉, 템플릿에 포스트 프로세서 하나와 빌더 두 개가 정의되어 있으면, 기본적으로 포스트 프로세서는 두 번(빌더마다 한 번) 실행된다는 뜻이에요. 원한다면 포스트 프로세서가 어떤 빌더에 적용되는지 제어하는 방법이 있는데, 이는 나중에 다룰 거예요. 포스트 프로세서가 실행되지 않도록 방지하는 것도 가능합니다.
포스트 프로세서 정의 (Post-Processor Definition)
템플릿의 post-processors 배열 안에서 포스트 프로세서를 정의하는 방법은 세 가지가 있어요. 단순 정의(simple), 상세 정의(detailed), 시퀀스 정의(sequence)가 그것입니다. 다른 방식으로 생각하면 "simple"과 "detailed" 정의는 "sequence" 정의의 shortcut이라고 볼 수 있어요.
단순 정의는 포스트 프로세서의 이름인 문자열 그 자체예요. 예시는 아래와 같습니다. 단순 정의는 포스트 프로세서에 추가 구성이 필요 없을 때 사용됩니다.
{
"post-processors": ["compress"]
}
상세 정의는 JSON 객체예요. 빌더나 프로비저너 정의와 매우 비슷합니다. 포스트 프로세서의 타입을 나타내는 type 필드를 포함하고, 포스트 프로세서에 대한 추가 구성을 포함할 수도 있어요. 상세 정의는 포스트 프로세서에 타입 외의 추가 구성이 필요할 때 사용됩니다. 예시는 아래와 같습니다.
{
"post-processors": [
{
"type": "compress",
"format": "tar.gz"
}
]
}
시퀀스 정의는 다른 단순 또는 상세 정의들로 이루어진 JSON 배열이에요. 배열에 정의된 포스트 프로세서들은 순서대로 실행되며, 각각의 아티팩트가 다음 것으로 전달되고 중간 아티팩트는 폐기됩니다. 시퀀스 정의는 다른 시퀀스 정의를 포함할 수 없어요. 시퀀스 정의는 여러 포스트 프로세서를 체인으로 연결할 때 사용합니다. 아래 예시에서 빌드의 아티팩트는 압축된 뒤 업로드되지만, 압축 결과는 유지되지 않아요.
순서대로 실행해야 하는 포스트 프로세서들은 반드시 시퀀스(sequence)로 묶어야 한다는 점이 매우 중요해요!
{
"post-processors": [
["compress", { "type": "upload", "endpoint": "http://example.com" }]
]
}
짐작할 수 있듯이, 단순 정의와 상세 정의는 요소가 하나뿐인 시퀀스 정의의 shortcut일 뿐입니다.
입력 아티팩트 (Input Artifacts)
포스트 프로세서를 사용할 때 입력 아티팩트(빌더나 다른 포스트 프로세서에서 온)는 포스트 프로세서가 실행된 뒤 기본적으로 폐기돼요. 일반적으로 최종 아티팩트로 가는 도중의 중간 아티팩트는 원하지 않기 때문입니다.
하지만 경우에 따라 중간 아티팩트를 유지하고 싶을 수 있어요. keep_input_artifact 설정을 true로 설정하면 Packer가 이 아티팩트들을 유지하도록 지시할 수 있습니다. 예시는 아래와 같습니다.
{
"post-processors": [
{
"type": "compress",
"keep_input_artifact": true
}
]
}
이 설정은 해당 특정 포스트 프로세서에 대한 입력 아티팩트만 유지해요. 포스트 프로세서 시퀀스를 지정하는 경우, 입력 아티팩트를 유지하도록 명시한 포스트 프로세서의 입력 아티팩트를 제외하면 기본적으로 모든 중간 아티팩트가 폐기됩니다.
Note: 직관적으로 궁금할 수 있는 점은, (시퀀스가 아닌) 여러 포스트 프로세서를 지정하면 어떻게 되는가예요. Packer가 모든 포스트 프로세서에 입력 유지 구성을 요구할까요? 당연히 아닙니다. Packer는 적어도 하나의 포스트 프로세서가 입력 유지를 요청했다는 것을 알아채고 유지해 두는 똑똑함이 있어요.
특정 빌드에서 실행 (Run on Specific Builds)
only 또는 except 필드를 사용해 포스트 프로세서를 특정 빌드에서만 실행할 수 있어요. 이 두 필드는 예상대로 동작합니다. only는 지정된 빌드에서만 포스트 프로세서를 실행하고, except는 지정된 빌드를 제외한 나머지에서 실행해요. 포스트 프로세서 시퀀스는 건너뛰는 포스트 프로세서까지만 실행됩니다.
only가 사용된 예시가 아래에 있지만, except 사용도 사실상 동일해요. only와 except는 "detailed" 필드에만 지정할 수 있습니다. 실행할 포스트 프로세서 시퀀스가 있다면 only와 except는 그 포스트 프로세서에 영향을 주고 시퀀스를 멈춰요.
-except 옵션은 이름이 지정된 포스트 프로세서를 구체적으로 건너뛸 수 있어요. -only 옵션은 포스트 프로세서를 무시합니다.
([
{
"name": "vbox",
"type": "vagrant",
"only": ["virtualbox-iso"]
},
{
"type": "compress"
}
],
[
"compress",
{
"type": "upload",
"endpoint": "http://example.com"
}
])
only 또는 except 안의 값은 빌더 타입이 아니라 빌드 이름이에요. 이름은 HCL에서 필수 블록 레이블이지만, 레거시 JSON에서는 구성에 특정 name 속성이 지정되지 않는 한 빌드 이름은 빌더의 타입(예: docker, amazon-ebs, virtualbox-iso)을 기본값으로 사용합니다.