manifest 포스트-프로세서

manifest 포스트-프로세서 (manifest post-processor)

Official

Artifact BuilderId: packer.post-processor.manifest

출처: Packer 공식 문서

본문

manifest 포스트-프로세서는 Packer가 실행 중에 만드는 모든 아티팩트 목록이 담긴 JSON 파일을 작성해요. Packer 템플릿이 여러 빌드를 포함한다면, 어떤 출력 아티팩트(파일, AMI ID, Docker 컨테이너 등)가 어떤 빌드에 해당하는지 추적하는 데 도움이 돼요.

manifest 포스트-프로세서는 빌드가 완료될 때마다 호출되고 manifest 파일의 데이터를 갱신해요. 빌드는 이름과 타입으로 식별되며, 빌드 시간, 아티팩트 ID, 파일 목록을 포함해요.

Packer를 -force 플래그로 실행하면 manifest 파일이 각 Packer 실행 동안 자동으로 잘려요. 그렇지 않으면 이후 빌드가 파일에 추가돼요. 타임스탬프를 사용해서 어느 것이 최신 아티팩트인지 알 수 있어요.

manifest를 두 번 이상 지정해 각 빌드를 자신의 파일로 쓰거나, 모든 빌드를 같은 파일에 쓸 수 있어요. 단순한 빌드에는 manifest를 한 번만 지정하면 되지만(아래 참조), Docker나 Artifice 같은 다른 포스트-프로세서와 체인으로 연결할 수도 있어요.

Configuration (설정)

Optional (선택):

  • output (string) — 매니페스트가 이 파일에 쓰여져요. 기본값은 packer-manifest.json 이에요.
  • strip_path (bool) — 경로 없이 파일 이름만 manifest 파일에 써요. 기본값은 false예요.
  • strip_time (bool) — 출력에서 build_time 필드를 쓰지 않아요.
  • custom_data (map[string]string) — 매니페스트에 추가할 임의의 데이터예요. 이는 템플릿 엔진이에요. 따라서 이 필드에 사용자 변수와 템플릿 함수를 사용할 수 있어요.

참고: 대부분의 다른 포스트-프로세서와 달리, manifest 포스트-프로세서에는 keep_input_artifact 옵션이 적용되지 않아요. 우리는 방금 기록한 파일을 삭제하는 동작을 아무도 기대하지 않으므로, manifest에서는 입력 아티팩트를 항상 유지해요.

Example Configuration (예시 구성)

manifest 포스트-프로세서를 사용하는 최소한의 방법은 다음과 같이 정의만 작성하는 거예요.

HCL2 / JSON

post-processor "manifest" {}

{
  "post-processors": [
    {
      "type": "manifest"
    }
  ]
}

좀 더 완전한 예시:

HCL2 / JSON

post-processor "manifest" {
    output = "manifest.json"
    strip_path = true
    custom_data = {
      my_custom_data = "example"
    }
}

{
  "post-processors": [
    {
      "type": "manifest",
      "output": "manifest.json",
      "strip_path": true,
      "custom_data": {
        "my_custom_data": "example"
      }
    }
  ]
}

예시 manifest 파일은 다음과 같아요.

{
  "builds": [
    {
      "name": "docker",
      "builder_type": "docker",
      "build_time": 1507245986,
      "files": [
        {
          "name": "packer_example",
          "size": 102219776
        }
      ],
      "artifact_id": "Container",
      "packer_run_uuid": "6d5d3185-fa95-44e1-8775-9e64fe2e2d8f",
      "custom_data": {
        "my_custom_data": "example"
      }
    }
  ],
  "last_run_uuid": "6d5d3185-fa95-44e1-8775-9e64fe2e2d8f"
}

빌드를 다시 실행하면 새 빌드 아티팩트가 파일을 대체하는 대신 manifest 파일에 추가돼요. packer_run_uuid 를 사용해서 manifest에서 특정 빌드 아티팩트를 가져올 수 있어요.

위 manifest는 다음 템플릿으로 생성됐어요.

HCL2 / JSON

source "docker" "docker"{
    image = "ubuntu:latest"
    export_path = "packer_example"
    run_command = ["-d", "-i", "-t", "--entrypoint=/bin/bash", "{{.Image}}"]
}

build {
    sources = ["docker.docker"]

    post-processor "manifest" {
        output = "manifest.json"
        strip_path = true
        custom_data = {
          my_custom_data = "example"
        }
    }
}

{
  "builders": [
    {
      "type": "docker",
      "image": "ubuntu:latest",
      "export_path": "packer_example",
      "run_command": ["-d", "-i", "-t", "--entrypoint=/bin/bash", "{{.Image}}"]
    }
  ],
  "post-processors": [
    {
      "type": "manifest",
      "output": "manifest.json",
      "strip_path": true,
      "custom_data": {
        "my_custom_data": "example"
      }
    }
  ]
}

예시 사용법:

manifest는 오래된 아티팩트를 정리하거나, 로그에 중요한 값을 출력하는 데 매우 유용할 수 있어요. 다음 예시는 JSON 출력을 파싱하는 커맨드라인 도구인 jq를 사용해서 빌드로 만든 AMI의 AWS ami-id를 찾아 echo하는 방법을 보여줘요.

#!/bin/bash

AMI_ID=$(jq -r '.builds[-1].artifact_id | split(":") | .[1]' manifest.json)
echo $AMI_ID

더 알아보기 (Learn more)