패키지 생성

패키지를 생성하려면 설치 가능한 소프트웨어 또는 자산을 운영 체제 플랫폼마다 파일 1개씩 준비합니다. 파일이 1개 이상 있어야만 패키지를 생성할 수 있습니다.

여러 플랫폼에서 동일한 파일을 사용하는 경우도 있을 수 있지만 패키지에 연결한 모든 파일은 매니페스트의 Files 섹션에 나열되어 있어야 합니다. 콘솔에서 단순 워크플로를 사용해 패키지를 생성하는 경우에는 매니페스트가 자동으로 생성됩니다. 단일 문서에 연결할 수 있는 파일의 최대 개수는 20개입니다. 각 파일의 최대 크기는 1GB입니다. 지원되는 플랫폼에 대한 자세한 내용은 지원되는 패키지 플랫폼 및 아키텍처 섹션을 참조하세요.

패키지를 생성할 때 시스템에서 새 SSM 문서를 생성합니다. 이 문서를 사용하면 관리형 노드에 패키지를 배포할 수 있습니다.

데모용인 예제 패키지 ExamplePackage.zip을 웹 사이트에서 다운로드할 수 있습니다. 예제 패키지에는 완료된 JSON 매니페스트와 PowerShell v7.0.0용 설치 프로그램이 포함된 .zip 파일 3개가 들어 있습니다. 설치 및 제거 스크립트에는 유효한 명령이 포함되어 있지 않습니다. 고급(Advanced) 워크플로에서는 소프트웨어 설치 파일과 스크립트를 .zip 파일로 압축해야 패키지를 생성할 수 있지만 단순(Simple) 워크플로에서는 설치 가능한 자산을 압축하지 않습니다.

패키지 생성(단순)

이 섹션에서는 Distributor 콘솔을 사용해 단순(Simple) 패키지 생성 워크플로를 선택하여 Distributor에서 패키지를 생성하는 방법에 대해 알아봅니다. Distributor는 AWS Systems Manager의 기능입니다. 패키지를 생성하려면 설치 가능한 자산을 운영 체제 플랫폼마다 파일 1개씩 준비합니다. 파일이 1개 이상 있어야만 패키지를 생성할 수 있습니다. 단순(Simple) 패키지 생성 프로세스에서는 설치 및 제거 스크립트와 파일 해시, 그리고 JSON 형식의 매니페스트가 자동으로 생성됩니다. 단순(Simple) 워크플로우를 선택하면 설치 파일을 업로드하여 ZIP 파일로 압축하는 프로세스와 새로운 패키지를 비롯해 연결된 SSM 문서를 생성하는 프로세스가 처리됩니다. 지원되는 플랫폼에 대한 자세한 내용은 지원되는 패키지 플랫폼 및 아키텍처 섹션을 참조하세요.

심플 메서드를 사용하여 패키지를 만들면 Distributor에서 install 및 uninstall 스크립트가 생성됩니다. 그러나 인플레이스 업데이트를 위한 패키지를 생성하는 경우에는 업데이트 스크립트(Update script) 탭에서 자체 update 스크립트 내용을 제공해야 합니다. update 스크립트에 대한 입력 명령을 추가할 때 Distributor은 install 및 uninstall 스크립트와 함께 생성된 .zip 패키지에 이 스크립트를 포함합니다.

참고

In-place 업데이트 옵션을 사용하여 연결된 애플리케이션을 오프라인으로 전환하지 않고도 기존 패키지 설치에 새 파일이나 업데이트된 파일을 추가합니다.

패키지를 생성하려면(단순)

1. AWS Systems Manager 콘솔(https://console.aws.amazon.com/systems-manager/)을 엽니다.

2. 탐색 창에서 Distributor를 선택합니다.

3. Distributor 홈페이지에서 패키지 생성(Create package)과 단순(Simple)을 차례대로 선택합니다.

4. 패키지 생성(Create package) 페이지에서 패키지 이름을 입력합니다. 패키지 이름은 문자, 숫자, 마침표, 대시 및 밑줄을 포함할 수 있습니다. 이 이름은 모든 버전의 패키지 연결에 적용할 수 있을 정도로 충분히 일반적이어야 하지만 패키지의 목적을 식별할 수 있을 정도로 구체적이어야 합니다.

5. (선택 사항) 버전 이름(Version name)에 버전 이름을 입력합니다. 버전 이름은 최대 512자로 구성되며, 여기에 특수 문자가 포함될 수 없습니다.

6. 위치(Location)에서 버킷 이름 및 접두사를 사용하거나 버킷 URL을 사용하여 버킷을 선택합니다.

7. 소프트웨어 업로드(Upload software)에서 소프트웨어 추가(Add software)를 선택한 다음, .rpm, .msi, .deb 확장을 사용하여 설치 가능한 소프트웨어 파일을 검색합니다. 파일 이름에 공백이 있으면 업로드가 실패합니다. 소프트웨어 파일은 한 번에 1개 이상 업로드할 수 있습니다.

8. 대상 플랫폼(Target platform)에서 설치 파일마다 표시된 대상 운영 체제 플랫폼이 정확한지 확인합니다. 운영 체제가 잘못 표시되어 있으면 드롭다운 목록에서 정확한 운영 체제를 선택합니다.

   단순(Simple) 패키지 생성 워크플로의 경우, 설치 가능한 파일마다 한 번씩 업로드하기 때문에 Distributor에서 다수의 운영 체제에 단일 파일을 대상으로 지정하도록 명령하기 위한 추가 단계가 필요합니다. 예를 들어 이름이 Logtool_v1.1.1.rpm인 소프트웨어 설치 파일을 업로드하는 경우에는 단순(Simple) 워크플로우에서 기본값을 몇 가지 변경해야만 동일한 소프트웨어를 Amazon Linux 운영 체제와 Ubuntu 운영 체제에 업로드할 수 있습니다. 여러 플랫폼을 대상으로 지정할 때는 다음 중 하나를 수행합니다.

   • 시작하기 전에 고급 워크플로를 사용해 각 설치 파일을 zip 파일로 압축한 다음 설치 파일을 다수의 운영 체제 플랫폼 또는 버전에 업로드할 수 있도록 매니페스트를 직접 작성합니다. 자세한 내용은 패키지 생성(고급) 단원을 참조하십시오.

   • zip 파일이 다수의 운영 체제 플랫폼 또는 버전으로 업로드될 수 있도록 심플 워크플로에서 매니페스트 파일을 직접 편집합니다. 자세한 내용은 2단계: JSON 패키지 매니페스트 생성 단원에서 4단계 마지막을 참조하십시오.

9. 플랫폼 버전(Platform version)에서 표시된 운영 체제 플랫폼 버전이 _any, 와일드카드 뒤에 오는 주 릴리스 버전(7.*) 또는 소프트웨어를 적용하려는 정확한 운영 체제 릴리스 버전인지 확인합니다. 운영 체제 플랫폼 버전을 지정하는 방법에 대한 자세한 내용은 2단계: JSON 패키지 매니페스트 생성 단원에서 4단계를 참조하십시오.

10. 아키텍처(Architecture)의 드롭다운 목록에서 설치 파일마다 정확한 프로세서 아키텍처를 선택합니다. 지원되는 프로세서 아키텍처에 대한 자세한 내용은 지원되는 패키지 플랫폼 및 아키텍처 섹션을 참조하세요.

11. (선택 사항) 스크립트를 확장하고 설치 가능한 소프트웨어에 대해 Distributor에서 생성되는 스크립트를 검토합니다.

12. (선택 사항) 인플레이스 업데이트에 사용할 업데이트 스크립트를 제공하려면 스크립트를 확장하고 Update script(업데이트 스크립트) 탭을 선택한 다음, 업데이트 스크립트 명령을 입력합니다.

    Systems Manager는 사용자를 대신하여 업데이트 스크립트를 생성하지 않습니다.

13. 소프트웨어 설치 파일을 추가하려면 Add software(소프트웨어 추가)를 선택합니다. 아니면 다음 단계로 이동합니다.

14. (선택 사항) Manifest(매니페스트)를 확장하여 Distributor에서 설치 가능한 소프트웨어에 생성한 JSON 패키지 매니페스트를 살펴봅니다. 이번 절차를 시작한 이후 플랫폼 버전, 대상 플랫폼 등 소프트웨어에 대한 정보를 변경하였다면 Generate manifest(매니페스트 생성)을 선택하여 업데이트된 패키지 매니페스트를 확인합니다.

    8단계에서 설명한 것처럼 소프트웨어 설치 파일을 다수의 운영 체제에 업로드하는 경우에는 매니페스트를 수동으로 편집할 수 있습니다. 매니페스트 편집에 대한 자세한 내용은 2단계: JSON 패키지 매니페스트 생성 섹션을 참조하세요.

15. Create package(패키지 생성)를 선택합니다.

Distributor에서 소프트웨어 업로드 및 패키지 생성을 마칠 때까지 기다립니다. 각 설치 파일의 업로드 상태가 Distributor에 표시됩니다. 이 작업은 추가하는 패키지 수와 크기에 따라 몇 분까지 걸릴 수 있습니다. Distributor에서 새로운 패키지의 [패키지 세부 정보(Package details)] 페이지로 자동 리디렉션되지만 소프트웨어가 업로드된 후에도 이 페이지를 열도록 직접 선택할 수 있습니다. Distributor가 패키지 생성 프로세스를 마칠 때까지 [패키지 세부 정보(Package details)] 페이지에 패키지에 대한 모든 정보가 표시되지 않습니다. 업로드 및 패키지 생성 프로세스를 중지하려면 취소를 선택합니다.

Distributor에서 일부 소프트웨어 설치 파일을 업로드하지 못하는 경우에는 [업로드 실패(Upload failed)] 메시지가 표시됩니다. 업로드를 다시 시도하려면 Retry upload(업로드 재시도)를 선택합니다. 패키지 생성 실패에 따른 문제 해결 방법에 대한 자세한 내용은 AWS Systems ManagerDistributor 문제 해결 섹션을 참조하세요.

패키지 생성(고급)

이 섹션에서는 고급 사용자가 설치 및 제거 스크립트와 JSON 매니페스트 파일로 설치 가능한 자산을 압축하여 Amazon S3 버킷으로 업로드한 후 Distributor에서 패키지를 생성할 수 있는 방법에 대해서 알아보겠습니다.

패키지를 생성하려면 설치 가능한 자산의 .zip 파일을 운영 체제 플랫폼당 하나의 .zip 파일로 준비합니다. 패키지를 생성하려면 하나 이상의 .zip 파일이 필요합니다. 다음으로, JSON 매니페스트를 생성합니다. 매니페스트에는 패키지 코드 파일에 대한 포인터가 포함되어 있습니다. 필요한 코드 파일을 폴더 또는 디렉터리에 추가했고 매니페스트가 올바른 값으로 채워진 경우 S3 버킷에 패키지를 업로드합니다.

예제 패키지 ExamplePackage.zip은 Amazon 웹사이트에서 다운로드할 수 있습니다. 예제 패키지에는 완료된 JSON 매니페스트와 .zip 파일 3개가 들어 있습니다.

주제

• 1단계: ZIP 파일 생성
• 2단계: JSON 패키지 매니페스트 생성
• 3단계: Amazon S3 버킷에 패키지 및 매니페스트 업로드
• 4단계: Distributor에 패키지 추가

1단계: ZIP 파일 생성

소프트웨어 또는 설치 가능한 자산의 .zip 파일 하나 이상이 패키지의 바탕을 이룹니다. 여러 운영 체제에 하나의 .zip 파일을 설치할 수 없는 경우 패키지에는 지원하려는 운영 체제당 .zip 파일이 하나씩 포함됩니다. 예를 들어 Red Hat Enterprise Linux 및 Amazon Linux 인스턴스는 일반적으로 동일한 .RPM 실행 파일을 실행할 수 있으므로 두 운영 체제를 지원하려면 이 패키지에 .zip 파일을 하나만 연결해야 합니다.

필수 파일

각 .zip 파일에 다음 항목이 필요합니다.

• install 및 uninstall 스크립트. Windows Server 기반 관리형 노드에는 PowerShell 스크립트(스크립트 이름이 install.ps1 및 uninstall.ps1)가 필요합니다. Linux 기반 관리형 노드에는 셸 스크립트(스크립트 이름: install.sh 및 uninstall.sh)가 필요합니다. SSM Agent가 install 및 uninstall 스크립트의 명령을 실행합니다.

  예를 들어, 설치 스크립트는 설치 프로그램(예: .rpm 또는 .msi)을 실행할 수 있고, 파일을 복사하거나 구성 설정을 지정할 수 있습니다.

• 실행 파일, 설치 프로그램 패키지(rpm, .deb, .msi 등), 기타 스크립트 또는 구성 파일 등

옵션 파일

각 .zip 파일에서 다음 항목은 선택 사항입니다.

• update 스크립트입니다. 업데이트 스크립트를 제공하면 In-place update 옵션을 사용하여 패키지를 설치할 수 있습니다. 기존 패키지 설치에 새 파일이나 업데이트된 파일을 추가하려는 경우 In-place update 옵션은 업데이트를 수행하는 동안 패키지 애플리케이션을 오프라인으로 전환하지 않습니다. Windows Server 기반 관리형 노드에는 PowerShell 스크립트(update.ps1라는 스크립트)가 필요합니다. Linux 기반 관리형 노드에는 셸 스크립트(update.sh라는 이름의 스크립트)가 필요합니다. SSM Agent은 update 스크립트의 명령을 실행합니다.

패키지 설치 또는 업데이트에 대한 자세한 내용은 패키지 설치 또는 업데이트 섹션을 참조하세요.

샘플 install 및 uninstall 스크립트를 포함한 .zip 파일의 예를 살펴보려면 예제 패키지인 ExamplePackage.zip을 다운로드하십시오.

2단계: JSON 패키지 매니페스트 생성

설치 파일을 준비하여 ZIP 파일로 압축하고 JSON 매니페스트를 생성합니다. 다음은 템플릿입니다. 이 단원의 절차에는 매니페스트 템플릿의 일부에 대한 설명이 나와 있습니다. JSON 편집기를 사용해 매니페스트를 별도의 파일로 생성할 수 있습니다. 또한 패키지를 생성할 때 AWS Systems Manager 콘솔에서 매니페스트를 작성할 수 있습니다.

{
  "schemaVersion": "2.0",
  "version": "your-version",
  "publisher": "optional-publisher-name",
  "packages": {
    "platform": {
      "platform-version": {
        "architecture": {
          "file": ".zip-file-name-1.zip"
        }
      }
    },
    "another-platform": {
      "platform-version": {
        "architecture": {
          "file": ".zip-file-name-2.zip"
        }
      }
    },
    "another-platform": {
      "platform-version": {
        "architecture": {
          "file": ".zip-file-name-3.zip"
        }
      }
    }
  },
  "files": {
    ".zip-file-name-1.zip": {
      "checksums": {
        "sha256": "checksum"
      }
    },
    ".zip-file-name-2.zip": {
      "checksums": {
        "sha256": "checksum"
      }
    }
  }
}

JSON 패키지 매니페스트를 생성하려면

1. 매니페스트에 스키마 버전을 추가합니다. 이 릴리스에서 스키마 버전은 항상 2.0입니다.

   { "schemaVersion": "2.0",

2. 매니페스트에 사용자 정의 패키지 버전을 추가합니다. Distributor에 패키지를 추가할 때 지정하는 [버전 이름(Version name)]의 값이기도 합니다. 이 값은 패키지를 추가할 때 Distributor에서 생성한 AWS Systems Manager 문서의 일부가 됩니다. 또한 최신 패키지 이외의 패키지 버전을 설치하려면 AWS-ConfigureAWSPackage 문서에 입력값으로 이 값을 제공합니다. version 값에는 문자, 숫자, 밑줄, 하이픈 및 마침표를 사용할 수 있으며 길이는 최대 128자입니다. 배포 시 정확한 패키지 버전을 쉽게 지정할 수 있으려면 사람이 읽을 수 있는 패키지 버전을 사용하는 것이 좋습니다. 다음은 예입니다.

   "version": "1.0.1",

3. (선택 사항) 게시자 이름을 추가합니다. 다음은 예입니다.

   "publisher": "MyOrganization",

4. 패키지를 추가합니다. "packages" 단원에는 패키지의 .zpi 파일에서 지원하는 플랫폼, 릴리스 버전 및 아키텍처에 대한 설명이 들어 있습니다. 자세한 내용은 지원되는 패키지 플랫폼 및 아키텍처 단원을 참조하십시오.

   platform-version은 와일드카드 값인 _any일 수 있습니다. 이 값을 사용하면 .zip 파일이 모든 플랫폼 릴리스를 지원함을 나타냅니다. 모든 부 버전이 지원되도록 주 릴리스 버전 뒤에 와일드카드를 지정할 수도 있습니다(예: 7.*). 특정 운영 체제 버전에 대한 platform-version 값을 지정하도록 선택한 경우 대상 운영 체제 AMI의 정확한 릴리스 버전과 일치하는지 확인합니다. 다음은 운영 체제의 올바른 값을 얻을 수 있도록 제안되는 리소스입니다.

   • Windows Server 기반 관리형 노드에서 릴리스 버전은 WMI(Windows Management Instrumentation) 데이터로 사용할 수 있습니다. 다음 명령 프롬프트에서 명령을 실행해 버전 정보를 얻은 다음 version에 대한 결과를 구문 분석할 수 있습니다. 이 명령은 Windows Server Nano의 버전은 표시하지 않습니다. Windows Server Nano의 버전 값은 nano입니다.

     wmic OS get /format:list

   • Linux 기반 관리형 노드에서는 운영 체제 릴리스를 처음 스캔하여 버전을 확인할 수 있습니다(다음 명령). VERSION_ID의 값을 찾아보십시오.

     cat /etc/os-release

     필요한 값을 반환하지 않은 경우 다음 명령을 실행해 /etc/lsb-release 파일에서 LSB 릴리스 정보를 가져오고 DISTRIB_RELEASE의 값을 찾아봅니다.

     lsb_release -a

     이러한 방법이 실패하면 일반적으로 배포를 기준으로 릴리스를 확인할 수 있습니다. 예를 들어, Debian Server에서는 /etc/debian_version 파일을, Red Hat Enterprise Linux에서는 /etc/redhat-release 파일을 스캔할 수 있습니다.

     hostnamectl

   "packages": {
       "platform": {
         "platform-version": {
           "architecture": {
             "file": ".zip-file-name-1.zip"
           }
         }
       },
       "another-platform": {
         "platform-version": {
           "architecture": {
             "file": ".zip-file-name-2.zip"
           }
         }
       },
       "another-platform": {
         "platform-version": {
           "architecture": {
             "file": ".zip-file-name-3.zip"
           }
         }
       }
     }

   다음은 예입니다. 이 예제에서 운영 체제 플랫폼은 amazon이고, 지원되는 릴리스 버전은 2016.09이고, 아키텍처는 x86_64이고, 이 플랫폼을 지원하는 .zip 파일은 test.zip입니다.

   {
       "amazon": {
           "2016.09": {
               "x86_64": {
                   "file": "test.zip"
               }
           }
       }
   },

   패키지가 상위 요소의 모든 버전을 지원함을 나타내기 위해 와일드카드 값 _any를 추가할 수 있습니다. 예를 들어 패키지가 Amazon Linux의 모든 릴리스 버전에서 지원된다고 나타내려면 패키지 구문이 다음과 비슷해야 합니다. 버전 또는 아키텍처 수준에서_any 와일드카드를 사용하여 플랫폼의 모든 버전, 버전의 모든 아키텍처 또는 플랫폼의 모든 버전 및 아키텍처를 지원할 수 있습니다.

   {
       "amazon": {
           "_any": {
               "x86_64": {
                   "file": "test.zip"
               }
           }
       }
   },

   다음 예에서는 _any를 추가해 첫 번째 패키지 data1.zip이 Amazon Linux 2016.09의 모든 아키텍처에 대해 지원됨을 보여줍니다. 두 번째 패키지 data2.zip은 Amazon Linux의 모든 릴리스에 대해 지원되지만 아키텍처가 x86_64인 관리형 노드만 지원합니다. 2016.09 및 _any 버전은 둘 다 amazon 아래에 있는 항목입니다. 여기에는 지원되는 버전, 아키텍처 및 연결된 .zip 파일이 아니라 하나의 플랫폼(Amazon Linux)이 있습니다.

   {
       "amazon": {
           "2016.09": {
               "_any": {
                   "file": "data1.zip"
               }
           },
           "_any": {
               "x86_64": {
                   "file": "data2.zip"
               }
           }
       }
   }

   .zip 파일이 플랫폼을 두 개 이상 지원하는 경우에는 매니페스트의 "packages" 섹션에서 .zip 파일을 두 번 이상 참조할 수 있습니다. 예를 들어 Red Hat Enterprise Linux 7.x 버전과 Amazon Linux를 둘 다 지원하는 .zip 파일이 있는 경우 다음 예제에 표시된 것처럼 "packages" 섹션에는 동일한 .zip 파일을 가리키는 항목이 2개 있습니다.

   {
       "amazon": {
           "2018.03": {
               "x86_64": {
                   "file": "test.zip"
               }
           }
       },
       "redhat": {
           "7.*": {
               "x86_64": {
                   "file": "test.zip"
               }
           }
       }
   },

5. 4단계에서 이 패키지의 일부인 .zip 파일 목록을 추가합니다. 각 파일 항목에는 파일 이름과 sha256 해시 값 체크섬이 필요합니다. 설치 실패를 방지하기 위해 매니페스트의 체크섬 값은 압축된 자산에 sha256 해시 값과 일치해야 합니다.

   설치 가능 항목에서 정확한 체크섬을 얻기 위해 다음 명령을 실행할 수 있습니다. Linux에서 shasum -a 256 file-name.zip 또는 openssl dgst -sha256 file-name.zip을 실행합니다. Windows의 경우 PowerShell에서 Get-FileHash -Path path-to-.zip-file cmdlet을 실행합니다.

   매니페스트의 "files" 섹션에는 패키지의 각 .zip 파일에 대한 참조가 하나씩 들어 있습니다.

   "files": {
           "test-agent-x86.deb.zip": {
               "checksums": {
                   "sha256": "EXAMPLE2706223c7616ca9fb28863a233b38e5a23a8c326bb4ae241dcEXAMPLE"
               }
           },
           "test-agent-x86_64.deb.zip": {
               "checksums": {
                   "sha256": "EXAMPLE572a745844618c491045f25ee6aae8a66307ea9bff0e9d1052EXAMPLE"
               }
           },
           "test-agent-x86_64.nano.zip": {
               "checksums": {
                   "sha256": "EXAMPLE63ccb86e830b63dfef46995af6b32b3c52ce72241b5e80c995EXAMPLE"
               }
           },
           "test-agent-rhel5-x86.nano.zip": {
               "checksums": {
                   "sha256": "EXAMPLE13df60aa3219bf117638167e5bae0a55467e947a363fff0a51EXAMPLE"
               }
           },
           "test-agent-x86.msi.zip": {
               "checksums": {
                   "sha256": "EXAMPLE12a4abb10315aa6b8a7384cc9b5ca8ad8e9ced8ef1bf0e5478EXAMPLE"
               }
           },
           "test-agent-x86_64.msi.zip": {
               "checksums": {
                   "sha256": "EXAMPLE63ccb86e830b63dfef46995af6b32b3c52ce72241b5e80c995EXAMPLE"
               }
           },
           "test-agent-rhel5-x86.rpm.zip": {
               "checksums": {
                   "sha256": "EXAMPLE13df60aa3219bf117638167e5bae0a55467e947a363fff0a51EXAMPLE"
               }
           },
           "test-agent-rhel5-x86_64.rpm.zip": {
               "checksums": {
                   "sha256": "EXAMPLE7ce8a2c471a23b5c90761a180fd157ec0469e12ed38a7094d1EXAMPLE"
               }
           }
       }

6. 패키지 정보를 추가한 후에는 매니페스트 파일을 저장한 다음 닫습니다.

다음은 완성된 매니페스트의 예입니다. 이 예제에서는 플랫폼을 두 개 이상 지원하지만 "files" 섹션에서 한 번만 참조되는 .zip 파일인 NewPackage_LINUX.zip이 있습니다.

{
    "schemaVersion": "2.0",
    "version": "1.7.1",
    "publisher": "Amazon Web Services",
    "packages": {
        "windows": {
            "_any": {
                "x86_64": {
                    "file": "NewPackage_WINDOWS.zip"
                }
            }
        },
        "amazon": {
            "_any": {
                "x86_64": {
                    "file": "NewPackage_LINUX.zip"
                }
            }
        },
        "ubuntu": {
            "_any": {
                "x86_64": {
                    "file": "NewPackage_LINUX.zip"
                }
            }
        }
    },
    "files": {
        "NewPackage_WINDOWS.zip": {
            "checksums": {
                "sha256": "EXAMPLEc2c706013cf8c68163459678f7f6daa9489cd3f91d52799331EXAMPLE"
            }
        },
        "NewPackage_LINUX.zip": {
            "checksums": {
                "sha256": "EXAMPLE2b8b9ed71e86f39f5946e837df0d38aacdd38955b4b18ffa6fEXAMPLE"
            }
        }
    }
}

패키지 예제

예제 패키지 ExamplePackage.zip은 Amazon 웹사이트에서 다운로드할 수 있습니다. 예제 패키지에는 완료된 JSON 매니페스트와 .zip 파일 3개가 들어 있습니다.

3단계: Amazon S3 버킷에 패키지 및 매니페스트 업로드

모든 .zip 파일을 폴더 또는 디렉터리로 복사하거나 이동하여 패키지를 준비합니다. 유효한 패키지에는 2단계: JSON 패키지 매니페스트 생성에서 생성한 매니페스트 및 매니페스트 파일 목록에 지정된 모든 .zip 파일이 필요합니다.

Amazon S3에 패키지 및 매니페스트를 업로드하려면

1. 매니페스트에서 지정한 모든 .zip 아카이브 파일을 폴더 또는 디렉터리로 복사하거나 이동합니다. .zip 아카이브 파일 및 매니페스트 파일을 이동하려는 폴더 또는 디렉터리를 압축하지 않습니다.

2. 버킷을 생성하거나 기존 버킷을 선택합니다. 자세한 내용은 Amazon Simple Storage Service 시작 안내서의 버킷 생성을 참조하세요. AWS CLI 명령을 실행하여 버킷을 생성하는 방법에 대한 자세한 내용은 AWS CLI Command Reference의 mb를 참조하세요.

3. 버킷에 폴더나 디렉터리를 업로드합니다. 자세한 내용은 Amazon Simple Storage Service 시작 안내서의 버킷에 객체 추가를 참조하세요. JSON 매니페스트를 AWS Systems Manager 콘솔에 붙여 넣으려는 경우 매니페스트를 업로드하지 않습니다. AWS CLI 명령을 실행하여 파일을 업로드하는 방법에 대한 자세한 내용은 AWS CLI Command Reference의 mv를 참조하세요.

4. 버킷의 홈 페이지에서 업로드한 폴더나 디렉터리를 선택합니다. 파일을 버킷의 하위 폴더로 업로드하였다면 해당하는 하위 폴더(접두사로도 알 수 있음)를 기록해야 합니다. 패키지를 Distributor에 추가할 때 접두사가 필요하기 때문입니다.

4단계: Distributor에 패키지 추가

AWS Systems Manager 콘솔, AWS 명령줄 도구(AWS CLI 및 AWS Tools for PowerShell) 또는 AWS SDK를 사용하여 Distributor에 새 패키지를 추가할 수 있습니다. 패키지를 추가할 때 새 SSM 문서를 추가합니다. 이 문서를 사용하면 관리형 노드에 패키지를 배포할 수 있습니다.

주제

• 패키지 추가(콘솔)
• 패키지 추가(AWS CLI)

패키지 추가(콘솔)

AWS Systems Manager 콘솔을 사용하여 패키지를 만들 수 있습니다. 3단계: Amazon S3 버킷에 패키지 및 매니페스트 업로드에서 패키지를 업로드한 버킷 이름을 준비합니다.

Distributor에 패키지를 추가하려면(콘솔)

1. AWS Systems Manager 콘솔(https://console.aws.amazon.com/systems-manager/)을 엽니다.

2. 탐색 창에서 Distributor를 선택합니다.

3. Distributor 홈페이지에서 Create package(패키지 생성)과 고급을 차례대로 선택합니다.

4. 패키지 생성(Create package) 페이지에서 패키지 이름을 입력합니다. 패키지 이름은 문자, 숫자, 마침표, 대시 및 밑줄을 포함할 수 있습니다. 이 이름은 모든 버전의 패키지 연결에 적용할 수 있을 정도로 충분히 일반적이어야 하지만 패키지의 목적을 식별할 수 있을 정도로 구체적이어야 합니다.

5. Version name(버전 이름)에 매니페스트 파일 내 version 항목의 정확한 값을 입력합니다.

6. [S3 버킷 이름(S3 bucket name)]에서 3단계: Amazon S3 버킷에 패키지 및 매니페스트 업로드에서 .zip 파일과 매니페스트를 업로드한 버킷의 이름을 선택합니다.

7. S3 키 접두사에 .zip 파일과 매니페스트가 저장되는 버킷의 하위 폴더를 입력합니다.

8. .zip 파일이 저장된 Amazon S3 버킷에 업로드한 매니페스트를 사용하려면 [매니페스트(Manifest)]에서 [패키지에서 추출(Extract from package)]을 선택합니다.

   (옵션) .zip 파일이 저장된 S3 버킷에 JSON 매니페스트를 업로드하지 않았다면 [새 매니페스트(New manifest)]를 선택합니다. JSON 편집기 필드에서 전체 매니페스트를 작성하거나 붙여넣을 수 있습니다. JSON 매니페스트를 생성하는 자세한 방법은 2단계: JSON 패키지 매니페스트 생성 섹션을 참조하세요.

9. 매니페스트 작성을 마치면 [패키지 생성(Create package)]을 선택합니다.

10. Distributor가 .zip 파일과 매니페스트에서 패키지를 생성할 때까지 기다립니다. 이 작업은 추가하는 패키지 수와 크기에 따라 몇 분까지 걸릴 수 있습니다. Distributor에서 새로운 패키지의 Package details(패키지 세부 정보) 페이지로 자동 리디렉션되지만 소프트웨어가 업로드된 후에도 이 페이지를 열도록 직접 선택할 수 있습니다. Distributor가 패키지 생성 프로세스를 마칠 때까지 [패키지 세부 정보(Package details)] 페이지에 패키지에 대한 모든 정보가 표시되지 않습니다. 업로드 및 패키지 생성 프로세스를 중지하려면 취소를 선택합니다.

패키지 추가(AWS CLI)

AWS CLI을 사용하여 패키지를 생성할 수 있습니다. 3단계: Amazon S3 버킷에 패키지 및 매니페스트 업로드에서 패키지를 업로드한 버킷에서 해당 URL을 사용할 준비가 되었습니다.

Amazon S3에 패키지 추가(AWS CLI)

1. AWS CLI를 사용하여 패키지를 생성하려면 다음 명령을 실행합니다. package-name을 해당 패키지 이름으로 바꾸고 path-to-manifest-file은 JSON 매니페스트 파일의 파일 경로로 바꾸십시오. DOC-EXAMPLE-BUCKET은 전체 패키지가 저장되는 Amazon S3 버킷의 URL입니다. Distributor에서 create-document 명령을 실행할 때 --document-type에 대해 Package 값을 지정합니다.

   Amazon S3 버킷에 매니페스트 파일을 추가하지 않은 경우 --content 파라미터 값은 JSON 매니페스트 파일에 대한 파일 경로입니다.

   aws ssm create-document \
       --name "package-name" \
       --content file://path-to-manifest-file \
       --attachments Key="SourceUrl",Values="DOC-EXAMPLE-BUCKET" \
       --version-name version-value-from-manifest \
       --document-type Package

   다음은 예입니다.

   aws ssm create-document \
       --name "ExamplePackage" \
       --content file://path-to-manifest-file \
       --attachments Key="SourceUrl",Values="https://s3.amazonaws.com/DOC-EXAMPLE-BUCKET/ExamplePackage" \
       --version-name 1.0.1 \
       --document-type Package

2. 패키지가 추가되었는지 확인하고 다음 명령을 실행하되 package-name은 패키지의 이름으로 바꿔 패키지 매니페스트를 표시합니다. (패키지의 버전과 같지 않은) 문서의 특정 버전을 확인하려면 --document-version 파라미터를 추가할 수 있습니다.

   aws ssm get-document \
       --name "package-name"

create-document 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 AWS CLI Command Reference의 AWS Systems Manager 섹션에 있는 create-document를 참조하세요. get-document 명령과 함께 사용할 수 있는 다른 옵션에 대한 자세한 내용은 get-document를 참조하십시오.