JSON 템플릿용 프로비저너 참조
JSON 템플릿용 프로비저너 참조 (provisioners reference for JSON templates)
이 문서는 Packer의 JSON 템플릿에서 provisioners 블록에 대한 참조 정보를 제공해요. 특정 프로비저너 타입의 구성 옵션을 알아보려면 해당 타입의 문서를 참고하세요.
출처: Packer 공식 문서
본문
참고: 이 페이지는 구식 스타일의 JSON Packer 템플릿에 관한 것이에요. JSON 템플릿은 여전히 Packer 코어가 지원하지만, Packer 코어에 추가된 새 기능들은 JSON 템플릿에는 구현되지 않을 수 있어요. Packer를 최상의 경험으로 사용하려면 가능한 한 빨리 HCL 템플릿으로 전환하길 권장해요. 템플릿 업그레이드를 돕기 위해 hcl2_upgrade 커맨드를 작성해 두었어요.
Description (설명)
provisioners 블록은 Packer가 실행 중인 머신을 머신 이미지로 바꾸기 전에 그 안에 소프트웨어를 설치·구성하는 데 사용하는 프로비저너들을 담아요.
프로비저너는 선택적이에요. provisioners 블록을 생략하면 Packer는 결과 머신 이미지 안에 기본 소프트웨어만 설치해요.
다음 문법으로 provisioners 블록을 JSON 템플릿에 추가해요.
{
"provisioners": [
// ... one or more provisioner definitions here
]
}
각 정의에 대해 Packer는 구성된 각 빌드에 프로비저너를 실행해요. 프로비저너는 템플릿 안에 정의된 순서대로 실행돼요.
Provisioner Definition (프로비저너 정의)
프로비저너 정의는 최소한 type 키를 포함해야 하는 JSON 객체예요. 이 키는 사용할 프로비저너의 이름을 지정해요. 객체 안의 추가 키는 프로비저너를 구성하는 데 사용되며, 뒤에서 다루는 몇 가지 특수 키는 예외예요.
예를 들어 "shell" 프로비저너는 생성되는 머신 안에서 실행할 셸 스크립트의 경로를 지정하는 script 같은 키가 필요해요.
아래에 프로비저너 정의 예시가 있는데, 셸 프로비저너를 구성해서 머신 안에서 로컬 스크립트를 실행해요.
{
"type": "shell",
"script": "script.sh"
}
Run on Specific Builds (특정 빌드에서만 실행)
only 또는 except 구성을 사용해 특정 빌드에서만 프로비저너를 실행할 수 있어요. 이 두 구성은 예상대로 동작해요. only 는 지정된 빌드에서만 프로비저너를 실행하고, except 는 지정된 빌드를 제외한 모든 것에서 프로비저너를 실행해요.
only 사용 예시는 아래와 같지만, except 의 사용법도 사실상 동일해요.
{
"type": "shell",
"script": "script.sh",
"only": ["virtualbox-iso"]
}
only 또는 except 안의 값은 빌더 타입이 아니라 빌드 이름이에요. 기억한다면, 빌드 이름은 기본적으로 빌더 타입 그 자체예요. 하지만 사용자 정의 name 파라미터를 지정했다면, 타입 대신 그 값을 사용해야 해요. except 안의 값은 포스트-프로세서 이름일 수도 있어요.
On Error Provisioner (오류 시 프로비저너)
error-cleanup-provisioner 라는 단일 특수 프로비저너 필드를 선택적으로 만들 수 있어요. 이 프로비저너는 일반 프로비저닝 실행이 실패하지 않는 한 실행되지 않아요. 일반 프로비저닝 실행이 실패하면, 이 특수 오류 프로비저너가 인스턴스가 종료되기 전에 실행돼요. 이를 통해 Packer가 스스로 정리하지 못할 수 있는 마지막 순간의 변경과 정리 동작을 할 수 있어요.
예를 들어 사용자들은 이 프로비저너를 사용해 인스턴스가 빌드 실행 중에 연결했던 서비스에서 제대로 구독 해제되는지 확인할 수 있어요.
오류 정리 스크립트의 예시 사용:
{
"builders": [
{
"type": "null",
"communicator": "none"
}
],
"provisioners": [
{
"type": "shell-local",
"inline": ["exit 2"]
}
],
"error-cleanup-provisioner": {
"type": "shell-local",
"inline": ["echo 'rubber ducky'> ducky.txt"]
}
}
Build-Specific Overrides (빌드별 재정의)
Packer의 목표는 동일한 머신 이미지를 만드는 것이지만, 머신이 결국 동일해지기 전에 서로 다른 상태를 가져야 하는 경우도 있어요. 이런 경우 빌드에 따라 프로비저너에 다른 구성이 필요할 수 있어요. 이는 빌드별 재정의(build-specific overrides)로 할 수 있어요.
이것이 필요할 수 있는 예시는 EC2 AMI와 VMware 머신을 동시에 빌드할 때예요. 소스 EC2 AMI는 기본적으로 관리 권한이 있는 사용자를 설정할 수 있는 반면, VMware 머신에는 이 권한이 없어요. 이 경우 셸 스크립트가 다르게 실행되어야 할 수 있어요. 물론 목표는 셸 스크립트가 이 두 이미지를 동일하게 수렴시키는 것이지만, 처음에는 다르게 실행되어야 할 수 있어요.
이 예시는 아래와 같아요.
{
"type": "shell",
"script": "script.sh",
"override": {
"vmware-iso": {
"execute_command": "echo 'password' | sudo -S bash {{.Path}}"
}
}
}
보시다시피 override 키가 사용돼요. 이 키의 값은 또 다른 JSON 객체인데, 그 키는 빌더 정의의 이름이에요. 그 값은 다시 또 다른 JSON 객체예요. 이 JSON 객체는 정상적으로 프로비저너 구성을 담아요. 이 구성은 기본 프로비저너 구성에 병합돼요.
Pausing Before Running (실행 전 일시 정지)
특정 프로비저너는 실행 전에 일정 시간 일시 정지하는 것이 바람직할 때가 있어요. 특히 프로비저너가 머신을 재부팅하는 경우, 다음 프로비저너를 시작하기 전에 일정 시간 기다리고 싶을 수 있어요.
Packer 템플릿의 모든 프로비저너 정의는 pause_before 라는 특수 구성을 받을 수 있는데, 이는 해당 프로비저너를 실행하기 전에 일시 정지할 시간이에요. 기본적으로 일시 정지는 없어요. 예시는 아래와 같아요.
{
"type": "shell",
"script": "script.sh",
"pause_before": "10s"
}
위 프로비저너의 경우 Packer는 셸 스크립트를 업로드하고 실행하기 전에 10초를 기다려요.
Retry on error (오류 시 재시도)
특정 프로비저너는 실패할 때 재시도하는 것이 바람직한 경우가 있어요. 특히 프로비저너가 아직 끝나지 않은 외부 프로세스에 의존하는 경우요.
Packer 템플릿의 모든 프로비저너 정의는 max_retries 라는 특수 구성을 받을 수 있는데, 이는 프로비저너가 오류 시 재시도할 최대 횟수예요. 기본적으로 max_retries 는 0이고 오류 시 재시도가 없어요. 예시는 아래와 같아요.
{
"type": "shell",
"script": "script.sh",
"max_retries": 5
}
위 프로비저너의 경우 Packer는 실패를 멈출 때까지 최대 5번 재시도해요. 5번 재시도 후에도 여전히 실패하면 전체 빌드가 실패해요.
Timeout (타임아웃)
가끔 커맨드가 예상보다 훨씬 오래 걸릴 수 있어요.
Packer 템플릿의 모든 프로비저너 정의는 timeout 이라는 특수 구성을 받을 수 있는데, 이는 프로비저너가 실패한 것으로 간주하기 전에 기다릴 시간이에요. 기본적으로 타임아웃은 없어요. 예시는 아래와 같아요.
{
"type": "shell",
"script": "script.sh",
"timeout": "5m"
}
위 프로비저너의 경우 Packer는 스크립트가 5분 이상 걸리면 취소해요.
타임아웃은 디버그 모드에서는 효과가 없어요.
더 알아보기 (Learn more)
- 이 페이지는 Packer 공식 문서에서 가져왔어요.