AWS::CloudFormation::Init - AWS CloudFormation
구문Configsets명령파일그룹패키지서비스소스사용자

AWS::CloudFormation::Init

AWS::CloudFormation::Init 유형을 사용하여 cfn-init 헬퍼 스크립트에 대한 Amazon EC2 인스턴스에 메타데이터를 포함합니다. 템플릿이 cfn-init 스크립트를 호출하는 경우 이 스크립트는 AWS::CloudFormation::Init 메타데이터 키를 루트로 하는 리소스 메타데이터를 찾습니다. cfn-init에 대한 자세한 내용은 cfn-init 단원을 참조하십시오.

cfn-init는 Linux 시스템에 대한 모든 메타데이터 유형을 지원하며, 이어지는 단원에 설명된 조건과 함께 Windows용 메타데이터 유형을 지원합니다.

AWS::CloudFormation::Init 및 cfn-init 헬퍼 스크립트를 사용하여 Linux 스택을 생성하는 예제는 Amazon EC2에 애플리케이션 배포 섹션을 참조하세요. Windows 스택 예제는 AWS CloudFormation Windows 스택 부트스트랩 섹션을 참조하세요.

구문

구성은 여러 섹션으로 나눠져 있습니다. 다음 템플릿 코드 조각은 템플릿 내에서 cfn-init에 대한 메타데이터를 EC2 인스턴스 리소스에 연결하는 방법을 보여줍니다.

이 메타데이터는 config 키로 구성되는데, 이 키는 configset으로 그룹화할 수 있습니다. 템플릿에서 cfn-init을 호출할 때 configset을 지정할 수 있습니다. configset을 지정하지 않을 경우 cfn-init은 config라는 단일 config 키를 찾습니다.

참고

cfn-init 헬퍼 스크립트는 패키지, 그룹, 사용자, 소스, 파일, 명령 및 서비스 순으로 구성 섹션을 처리합니다. 다른 순서가 필요한 경우 섹션을 서로 다른 config 키로 분리한 다음 config 키를 처리해야 할 순서를 지정하는 configset을 사용합니다.

JSON

"Resources": {
  "MyInstance": {
    "Type": "AWS::EC2::Instance",
    "Metadata" : {
      "AWS::CloudFormation::Init" : {
        "config" : {
          "packages" : {
            :
          },
          "groups" : {
            :
          },
          "users" : {
            :
          },
          "sources" : {
            :
          },
          "files" : {
            :
          },
          "commands" : {
            :
          },
          "services" : {
            :
          }
        }
      }
    },
    "Properties": {
      :
    }
  }
}

YAML

Resources: 
  MyInstance: 
    Type: AWS::EC2::Instance
    Metadata: 
      AWS::CloudFormation::Init: 
        config: 
          packages: 
            :
          groups: 
            :
          users: 
            :
          sources: 
            :
          files: 
            :
          commands: 
            :
          services: 
            :
    Properties: 
      :
참고

다음 섹션에는 Bash와 같이 Unix와 유사한 쉘 스크립팅 언어로 작성된 스크립트의 예제가 포함되어 있습니다. 대신 PowerShell용 스크립트를 작성하려면 PowerShell 언어를 잘 알고 있어야 합니다. PowerShell 구문은 Unix와 유사한 쉘과는 다르므로 PowerShell 작업 방식에 익숙해야 합니다.

Configsets

두 개 이상의 config 키를 생성하고 cfn-init을 통해 키를 특정 순서대로 처리하려는 경우 원하는 순서대로 config 키를 포함하는 configset을 생성합니다.

단일 configset

다음 템플릿 코드 조각은 각각 config 키 두 개를 포함하는 ascending 및 descending 이름의 configset을 생성합니다.

JSON

"AWS::CloudFormation::Init" : {
    "configSets" : {
        "ascending" : [ "config1" , "config2" ],
        "descending" : [ "config2" , "config1" ]
    },
    "config1" : {
        "commands" : {
            "test" : {
                "command" : "echo \"$CFNTEST\" > test.txt",
                "env" : { "CFNTEST" : "I come from config1." },
                "cwd" : "~"
            }
        }
    },
    "config2" : {
        "commands" : {
            "test" : {
                "command" : "echo \"$CFNTEST\" > test.txt",
                "env" : { "CFNTEST" : "I come from config2" },
                "cwd" : "~"
            }
        }
    }
}

YAML

AWS::CloudFormation::Init: 
  configSets: 
    ascending: 
      - "config1"
      - "config2"
    descending: 
      - "config2"
      - "config1"
  config1: 
    commands: 
      test: 
        command: "echo \"$CFNTEST\" > test.txt"
        env: 
          CFNTEST: "I come from config1."
        cwd: "~"
  config2: 
    commands: 
      test: 
        command: "echo \"$CFNTEST\" > test.txt"
        env: 
          CFNTEST: "I come from config2"
        cwd: "~"

관련 cfn-init 호출

다음 예제에서는 cfn-init을 호출하여 이전 예제 configset을 참조합니다. 예제 호출은 명확성을 위해 생략되었습니다. 전체 구문은 cfn-init의 내용을 참조하세요.

  • cfn-init 호출이 ascending configset을 지정하는 경우:

    cfn-init -c ascending

    스크립트가 config1을 처리하고 나서 config2를 처리하면 test.txt 파일에 I come from config2 텍스트가 포함됩니다.

  • cfn-init 호출이 descending configset을 지정하는 경우:

    cfn-init -c descending

    스크립트가 config2을 처리하고 나서 config1를 처리하면 test.txt 파일에 I come from config1 텍스트가 포함됩니다.

여러 configset

configset을 여러 개 생성하고 cfn-init 스크립트를 사용하여 일련의 configset을 호출할 수 있습니다. 각 configset에는 config 키 또는 다른 configset에 대한 참조 목록을 포함할 수 있습니다. 예를 들면 다음 템플릿 코드 조각은 configset 세 개를 생성합니다. 첫 번째 configset인 test1에는 1이라는 config 키 하나가 포함됩니다. 두 번째 configset인 test2에는 test1 configset의 참조와 2라는 config 키 하나가 포함됩니다. 세 번째 configset인 default에는 test2 configset의 참조가 포함됩니다.

JSON

"AWS::CloudFormation::Init" : {
    "configSets" : {
        "test1" : [ "1" ],
        "test2" : [ { "ConfigSet" : "test1" }, "2" ],
        "default" : [ { "ConfigSet" : "test2" } ]
    },
    "1" : {
        "commands" : {
            "test" : {
                "command" : "echo \"$MAGIC\" > test.txt",
                "env" : { "MAGIC" : "I come from the environment!" },
                "cwd" : "~"
            }
        }
    },
    "2" : {
        "commands" : {
            "test" : {
                "command" : "echo \"$MAGIC\" >> test.txt",
                "env" : { "MAGIC" : "I am test 2!" },
                "cwd" : "~"
            }
        }
    }
}

YAML

AWS::CloudFormation::Init:
  1:
    commands:
      test:
        command: "echo \"$MAGIC\" > test.txt"
        env:
          MAGIC: "I come from the environment!"
        cwd: "~"
  2:
    commands:
      test:
        command: "echo \"$MAGIC\" >> test.txt"
        env:
          MAGIC: "I am test 2!"
        cwd: "~"
  configSets: 
    test1:
      - "1"
    test2:
      -
        ConfigSet: "test1"
      - "2"
    default:
      -
        ConfigSet: "test2"

관련 cfn-init 호출

다음 예제에서는 cfn-init을 호출하여 이전 템플릿 코드 조각에 선언된 configset을 참조합니다. 예제 호출은 명확성을 위해 생략되었습니다. 전체 구문은 cfn-init의 내용을 참조하세요.

  • test1만 지정하는 경우:

    cfn-init -c test1

    cfn-init은 config 키 1만 처리합니다.

  • test2만 지정하는 경우:

    cfn-init -c test2

    cfn-init은 config 키 1을 처리하고 나서 config 키 2를 처리합니다.

  • default configset(또는 configset 없음)을 지정하는 경우:

    cfn-init -c default

    configset test2를 지정할 때와 똑같이 작동합니다.

명령

command 키를 사용하여 EC2 인스턴스에서 명령을 실행할 수 있습니다. 명령은 이름별 영문자 순으로 처리됩니다.

키 필수 설명

명령

 필수

실행할 명령을 지정하는 어레이나 문자열입니다. 어레이를 사용하는 경우 특수 문자를 이스케이프하거나 명령 파라미터를 따옴표로 묶을 필요가 없습니다. 어레이를 사용하여 여러 명령을 지정하지 마십시오.

env

 선택 사항

명령에 대한 환경 변수를 설정합니다. 이 속성은 기존 환경을 추가하는 것이 아니라 덮어씁니다.

cwd

 선택 사항

작업 디렉터리입니다.

테스트

 선택 사항

cfn-init이 command 키에 지정된 명령을 실행하는지 여부를 결정하는 테스트 명령입니다. 테스트를 통과하면 cfn-init이 명령을 실행합니다. cfn-init 스크립트는 Bash 또는 cmd.exe 같은 명령 인터프리터에서 테스트를 실행합니다. 테스트 통과 여부는 인터프리터가 반환하는 종료 코드에 따라 달라집니다.

Linux의 경우, 테스트를 통과하려면 테스트 명령이 종료 코드 0을 반환해야 합니다. Windows의 경우, 테스트 명령이 %ERRORLEVEL% 0을 반환해야 합니다.

ignoreErrors

 선택 사항

command 키에 포함된 명령이 실패할 경우 cfn-init이 계속 실행되는지 여부를 결정하는 부울 값입니다(0이 아닌 값 반환). 명령이 실패하더라도 cfn-init이 계속 실행되도록 하려면 true로 설정합니다. 명령이 실패할 경우 cfn-init의 실행이 중지되도록 하려면 false로 설정합니다. 기본값은 false입니다.

waitAfterCompletion

 선택 사항

Windows 시스템에만 해당합니다. 명령으로 인해 재부팅해야 하는 경우 명령이 완료된 후 대기 시간(초)을 지정합니다. 기본값은 60초이며 "forever" 값을 지정하면 cfn-init이 종료되고 재부팅이 완료된 후에만 재개됩니다. 모든 명령에 대해 대기하지 않으려면 이 값을 0으로 설정합니다.

예

다음 예제 코드 조각은 ~/test.txt 파일이 존재하지 않을 경우 echo 명령을 호출합니다.

JSON

"commands" : {
    "test" : {
        "command" : "echo \"$MAGIC\" > test.txt",
        "env" : { "MAGIC" : "I come from the environment!" },
        "cwd" : "~",
        "test" : "test ! -e ~/test.txt",
        "ignoreErrors" : "false"
    },
    "test2" : {
        "command" : "echo \"$MAGIC2\" > test2.txt",
        "env" : { "MAGIC2" : "I come from the environment!" },
        "cwd" : "~",
        "test" : "test ! -e ~/test2.txt",
        "ignoreErrors" : "false"
    }
}

YAML

commands:
  test:
    command: "echo \"$MAGIC\" > test.txt"
    env:
      MAGIC: "I come from the environment!"
    cwd: "~"
    test: "test ! -e ~/test.txt"
    ignoreErrors: "false"
  test2:
    command: "echo \"$MAGIC2\" > test2.txt"
    env:
      MAGIC2: "I come from the environment!"
    cwd: "~"
    test: "test ! -e ~/test2.txt"
    ignoreErrors: "false"

파일

files 키를 사용하여 EC2 인스턴스에서 파일을 생성할 수 있습니다. 콘텐츠는 템플릿에서 인라인이거나 내용을 URL에서 가져올 수 있습니다. 파일은 사전 순서로 디스크에 작성됩니다. 다음 표에는 지원되는 키가 나열되어 있습니다.

키 설명

content

문자열 또는 올바른 형식의 JSON 객체입니다. JSON 객체를 content로 사용할 경우 JSON이 디스크의 파일에 기록됩니다. JSON 객체를 디스크에 기록하기 전에 Fn::GetAtt 또는 Ref 같은 내장 함수를 평가합니다. symlink를 만드는 경우 symlink 대상을 content로 지정합니다.

참고

symlink를 만드는 경우 헬퍼 스크립트가 대상 파일의 권한을 수정합니다. 현재는 대상 파일의 권한을 수정하지 않고는 symlink를 만들 수 없습니다.

source

파일을 로드할 URL입니다. 이 옵션은 content 키와 함께 지정할 수 없습니다.

인코딩

인코딩 형식입니다. content가 문자열인 경우에만 사용됩니다. source를 사용 중인 경우 enconding이 적용되지 않습니다.

유효한 값: plain | base64

그룹

이 파일을 소유하는 그룹의 이름입니다. Windows 시스템에는 지원되지 않습니다.

owner

이 파일을 소유하는 사용자 이름입니다. Windows 시스템에는 지원되지 않습니다.

mode

이 파일의 모드를 나타내는 6자리 8진수 값입니다. Windows 시스템에는 지원되지 않습니다. symlink에는 처음 세 자리를 사용하고 설정 권한에는 마지막 세 자리를 사용합니다. symlink를 만들려면 120xxx를 지정합니다. 이때 xxx는 대상 파일의 권한을 정의합니다. 파일의 권한을 지정하려면 마지막 세 자리를 사용합니다(예: 000644).

authentication

사용할 인증 방법의 이름입니다. 이 키를 지정하면 기본 인증이 재정의됩니다. 이 속성을 사용하면 AWS::CloudFormation::Authentication 리소스를 사용하여 정의하는 인증 방법을 선택할 수 있습니다.

context

Mustache 템플릿으로 처리해야 할 파일의 컨텍스트를 지정합니다. 이 키를 사용하려면 pystache 외에 aws-cfn-bootstrap 1.3~11 이상이 설치되어 있어야 합니다.

예시

다음 예제 코드 조각은 setup.mysql 파일을 더 큰 설치의 일부로서 생성합니다.

JSON

"files" : {
  "/tmp/setup.mysql" : {
    "content" : { "Fn::Join" : ["", [
      "CREATE DATABASE ", { "Ref" : "DBName" }, ";\n",
      "CREATE USER '", { "Ref" : "DBUsername" }, "'@'localhost' IDENTIFIED BY '",
                       { "Ref" : "DBPassword" }, "';\n",
      "GRANT ALL ON ", { "Ref" : "DBName" }, ".* TO '", { "Ref" : "DBUsername" },
                       "'@'localhost';\n",
      "FLUSH PRIVILEGES;\n"
      ]]},
    "mode"  : "000644",
    "owner" : "root",
    "group" : "root"
  }
}

YAML

files: 
  /tmp/setup.mysql: 
    content: !Sub |
      CREATE DATABASE ${DBName};
      CREATE USER '${DBUsername}'@'localhost' IDENTIFIED BY '${DBPassword}';
      GRANT ALL ON ${DBName}.* TO '${DBUsername}'@'localhost';
      FLUSH PRIVILEGES;
    mode: "000644"
    owner: "root"
    group: "root"

전체 템플릿은 https://s3.amazonaws.com/cloudformation-templates-us-east-1/Drupal_Single_Instance.template에서 확인할 수 있습니다.

다음 예제 코드 조작은 기존 파일 /tmp/myfile2.txt를 가리키는 symlink /tmp/myfile1.txt를 생성합니다. 대상 파일 /tmp/myfile1.txt의 권한은 모드 값 644로 정의됩니다.

JSON

"files" : {
  "/tmp/myfile2.txt" : {
    "content" : "/tmp/myfile1.txt",
    "mode" : "120644"
  }
}

YAML

files:
  /tmp/myfile2.txt:
    content: "/tmp/myfile1.txt"
    mode: "120644"

Mustache 템플릿은 기본적으로 구성 파일을 생성하는 데 사용됩니다. 예를 들면 S3 버킷에 구성 파일을 저장하고 Fn::Join을 사용하는 대신에 템플릿에서 Refs 및 GetAtts를 보간할 수 있습니다. 다음 예제 코드 조각은 Content for test9를 /tmp/test9.txt로 출력합니다.

JSON


"files" : {
    "/tmp/test9.txt" : {
        "content" : "Content for {{name}}",
        "context" : { "name" : "test9" }
    }
}

YAML

files:
  /tmp/test9.txt:
    content: "Content for {{name}}"
    context:
      name: "test9"

Mustache 템플릿 작업 시 다음 사항에 유의하십시오.

  • 처리해야 할 파일에 대해 context 키가 존재해야 합니다.

  • context 키는 키-값 맵이어야 하지만, 중첩될 수도 있습니다.

  • content 키를 사용하여 인라인 콘텐츠를 포함하는 파일을 처리할 수 있으며 source 키를 사용하여 원격 파일을 처리할 수 있습니다.

  • Mustache 지원은 pystache 버전에 따라 달라집니다. 버전 0.5.2는 Mustache 1.1.2 사양을 지원합니다.

그룹

groups 키를 사용하여 Linux/UNIX 그룹을 생성하고 그룹 ID를 할당할 수 있습니다. groups 키는 Windows 시스템에는 지원되지 않습니다.

그룹을 생성하려면 새 그룹 이름을 그룹 ID(선택 사항)로 매핑하는 새 키-값 페어를 추가합니다. groups 키에는 하나 이상의 그룹 이름이 포함될 수 있습니다. 다음 표에는 가용 키가 나열되어 있습니다.

키 설명

gid

그룹 ID 번호입니다.

그룹 ID를 지정했으며 그룹 이름이 이미 존재하는 경우 그룹이 생성되지 않습니다. 다른 그룹에 해당 그룹 ID를 지정한 경우 OS에서 그룹 생성을 거부할 수도 있습니다.

예시: { "gid" : "23" }

예제 코드 조각

다음 코드 조각은 그룹 ID를 할당하지 않은 groupOne 이름의 그룹과 그룹 ID 값 groupTwo를 지정한 45 이름의 그룹을 지정합니다.

JSON

"groups" : {
    "groupOne" : {},
    "groupTwo" : { "gid" : "45" }
}

YAML

groups:
  groupOne: {}
  groupTwo:
    gid: "45"

패키지

packages 키를 사용하여 사전 패키징된 애플리케이션 및 구성 요소를 다운로드 및 설치할 수 있습니다. Windows 시스템에서는 packages 키가 MSI 설치 프로그램만 지원합니다.

지원되는 패키지 형식

cfn-init 스크립트는 현재 apt, msi, python, rpm, rubygems, yum 및 Zypper 패키지 형식을 지원합니다. 패키지는 rpm, yum/apt/zypper 및 rubygems와 python 순서로 처리됩니다. rubygems와 python 사이에는 순서가 정해져 있지 않으며, 각 패키지 관리자 안에 있는 패키지는 특정 순서대로 설치해야 할 수도 있습니다.

버전 지정

각 패키지 관리자 내에서 각 패키지는 패키지 이름과 버전 목록으로 지정됩니다. 버전은 문자열, 버전 목록 또는 빈 문자열이나 목록일 수 있습니다. 빈 문자열이나 목록은 최신 버전 사용을 나타냅니다. rpm 관리자에서 버전은 디스크의 파일 경로 또는 URL로 지정됩니다.

패키지 버전을 지정하는 경우 cfn-init은 패키지의 새 버전이 인스턴스에 이미 설치되었더라도 해당 버전을 설치하려고 합니다. 일부 패키지 관리자는 여러 버전을 지원하지만 다른 패키지 관리자는 지원하지 않을 수도 있습니다. 자세한 내용은 패키지 관리자 설명서를 확인하세요. 버전을 지정하지 않았으며 패키지 버전이 이미 설치된 경우, cfn-init 스크립트가 새 버전을 설치할 수 없습니다. 이 스크립트는 사용자가 기존 버전을 유지하고 사용하고자 한다고 가정합니다.

예제 코드 조각

RPM, yum, Rubygems 및 Zypper

다음 코드 조각은 rpm용 버전 URL을 지정하고, yum 및 Zypper의 최신 버전과 rubygems의 chef 0.10.2 버전을 요청합니다.

JSON
"rpm" : {
  "epel" : "http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm"
},
"yum" : {
  "httpd" : [],
  "php" : [],
  "wordpress" : []
},
"rubygems" : {
  "chef" : [ "0.10.2" ]
},
"zypper" : {
  "git" : []
}
YAML
rpm:
  epel: "http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm"
yum:
  httpd: []
  php: []
  wordpress: []
rubygems:
  chef:
    - "0.10.2"
zypper:
  git: []

MSI 패키지

다음 코드 조각은 MSI 패키지의 URL을 지정합니다.

JSON
"msi" : {
  "awscli" : "https://s3.amazonaws.com/aws-cli/AWSCLI64.msi"
}
YAML
msi:
  awscli: "https://s3.amazonaws.com/aws-cli/AWSCLI64.msi"

서비스

services 키를 사용하여 인스턴스가 실행될 때 활성화되거나 비활성화될 서비스를 정의할 수 있습니다. Linux 시스템에서 이 키는 sysvinit 또는 systemd를 사용하여 지원됩니다. Windows 시스템에서는 Windows 서비스 관리자를 사용하여 지원됩니다.

services 키를 사용하면 소스, 패키지 및 파일에 대한 종속성을 지정할 수 있으므로 설치하려는 파일로 인해 재시작해야 하는 경우 cfn-init이 서비스 재시작을 처리합니다. 예를 들어 Apache HTTP Server 패키지를 다운로드하는 경우 패키지 설치는 스택 생성 프로세스 중에 Apache HTTP Server를 자동으로 시작합니다. 하지만 Apache HTTP Server 구성이 스택 생성 프로세스의 뒷부분에서 업데이트되는 경우 Apache 서버를 다시 시작하지 않으면 업데이트가 적용되지 않습니다. services 키를 사용하여 Apache HTTP 서비스가 다시 시작되도록 할 수 있습니다.

다음 표에는 지원되는 키가 나열되어 있습니다.

키 설명

ensureRunning

cfn-init이 완료된 후에도 서비스를 실행 중인 상태로 유지하려면 true로 설정합니다.

cfn-init이 완료된 후 서비스가 실행되지 않도록 하려면 false로 설정합니다.

서비스 상태를 변경하지 않으려면 이 키를 생략합니다.

enabled

서비스가 부팅 시 자동으로 시작되도록 하려면 true로 설정합니다.

서비스가 부팅 시 자동으로 시작되지 않도록 하려면 false로 설정합니다.

이 속성을 변경하지 않으려면 이 키를 생략합니다.

files

파일 목록입니다. cfn-init이 파일 블록을 통해 직접 한 번 변경하는 경우 이 서비스가 다시 시작됩니다.

sources

디렉터리 목록입니다. cfn-init이 이러한 디렉터리 중 하나로 아카이브의 압축을 푸는 경우 이 서비스가 다시 시작됩니다.

packages

패키지 관리자와 패키지 이름 목록 간 맵입니다. cfn-init이 이러한 패키지 중 하나를 설치하거나 업데이트하는 경우 이 서비스가 다시 시작됩니다.

명령

명령 이름 목록입니다. cfn-init이 지정된 명령을 실행하면 이 서비스가 다시 시작됩니다.

예시

Linux

다음 Linux 코드 조각은 다음과 같이 서비스를 구성합니다.

  • cfn-init에 의해 /etc/nginx/nginx.conf 또는 /var/www/html이 수정된 경우 nginx 서비스가 다시 시작됩니다.

  • cfn-init이 yum을 사용하여 php 또는 spawn-fcgi를 설치하거나 업데이트하는 경우 php-fastcgi 서비스가 다시 시작됩니다.

  • sendmail 서비스는 systemd를 사용하여 중지되고 비활성화됩니다.

JSON
"services" : {
  "sysvinit" : {
    "nginx" : {
      "enabled" : "true",
      "ensureRunning" : "true",
      "files" : ["/etc/nginx/nginx.conf"],
      "sources" : ["/var/www/html"]
    },
    "php-fastcgi" : {
      "enabled" : "true",
      "ensureRunning" : "true",
      "packages" : { "yum" : ["php", "spawn-fcgi"] }
    }
  },
  "systemd": {
    "sendmail" : {
      "enabled" : "false",
      "ensureRunning" : "false"
    }
  }
}
YAML
services:
  sysvinit:
    nginx:
      enabled: "true"
      ensureRunning: "true"
      files:
        - "/etc/nginx/nginx.conf"
      sources:
        - "/var/www/html"
    php-fastcgi:
      enabled: "true"
      ensureRunning: "true"
      packages:
        yum:
          - "php"
          - "spawn-fcgi"
  systemd:
    sendmail:
      enabled: "false"
      ensureRunning: "false"

서비스와 함께 systemd를 사용하려면 서비스에 시스템 단위 파일이 구성되어 있어야 합니다. 다음 단위 파일을 사용하면 systemd가 다중 사용자 서비스 대상에서 cfn-hup 대몬(daemon)을 시작 및 중지할 수 있습니다.

[Unit]
Description=cfn-hup daemon
[Service]
ExecStart=/usr/bin/cfn-hup -v
PIDFile=/var/run/cfn-hup.pid
[Install]
WantedBy=multi-user.target

이 구성에서는 cfn-hup가 /usr/bin 디렉터리 아래에 설치되어 있다고 가정합니다. 그러나 cfn-hup가 설치되는 실제 위치는 플랫폼에 따라 다를 수 있습니다. 다음과 같이 /etc/systemd/system/cfn-hup.service.d/override.conf에 재정의 파일을 생성하여 이 구성을 재정의할 수 있습니다.

# In this example, cfn-hup executable is available under /usr/local/bin
[Service]
ExecStart=
ExecStart=/usr/local/bin/cfn-hup -v

Windows

다음 Windows 코드 조각은 cfn-hup 서비스를 시작하고 [Automatic]으로 설정한 다음 cfn-init가 지정된 구성 파일을 수정하는 경우 서비스를 다시 시작합니다.

JSON
"services" : {
  "windows" : {
    "cfn-hup" : {
      "enabled" : "true",
      "ensureRunning" : "true",
      "files" : ["c:\\cfn\\cfn-hup.conf", "c:\\cfn\\hooks.d\\cfn-auto-reloader.conf"]
    }
  }
}
YAML
services:
  windows:
    cfn-hup:
      enabled: "true"
      ensureRunning: "true"
      files:
        - "c:\\cfn\\cfn-hup.conf"
        - "c:\\cfn\\hooks.d\\cfn-auto-reloader.conf"

소스

sources 키를 사용하여 아카이브 파일을 다운로드한 후 EC2 인스턴스의 대상 디렉터리에 압축을 풉니다. 이 키는 Linux 및 Windows 시스템에서 모두 완벽하게 지원됩니다.

지원되는 형식

지원되는 형식:

  • tar

  • tar+gzip

  • tar+bz2

  • zip

예시

GitHub

GitHub를 소스 제어 시스템으로 사용하는 경우 cfn-init과 소스 패키지 메커니즘을 사용하여 애플리케이션의 특정 버전을 가져올 수 있습니다. GitHub를 사용하면 다음과 같이 URL을 통해 특정 버전에서 zip 또는 tar를 생성할 수 있습니다.

https://github.com/<your directory>/(zipball|tarball)/<version>

예를 들면 다음 코드 조각은 main 버전을 .tar 파일로 풀다운합니다.

JSON
"sources" : {
  "/etc/puppet" : "https://github.com/user1/cfn-demo/tarball/main"
  }
YAML
sources:
  /etc/puppet: "https://github.com/user1/cfn-demo/tarball/main"

S3 Bucket

다음 예제에서는 S3 버킷에서 tarball을 다운로드하여 /etc/myapp에 압축을 풉니다.

참고

소스로 인증 자격 증명을 사용할 수 있습니다. 하지만 소스 블록에 인증 키를 추가할 수는 없습니다. 대신에 S3AccessCreds 블록에 버킷 키를 포함합니다. Amazon S3 인증 자격 증명에 대한 자세한 내용은 AWS::CloudFormation::Authentication 단원을 참조하십시오.

예제를 보려면 https://s3.amazonaws.com/cloudformation-templates-us-east-1/S3Bucket_SourceAuth.template을 참조하십시오.

JSON
"sources" : {
  "/etc/myapp" : "https://s3.amazonaws.com/amzn-s3-demo-bucket/myapp.tar.gz"
  }
YAML
sources:
  /etc/myapp: "https://s3.amazonaws.com/amzn-s3-demo-bucket/myapp.tar.gz"

사용자

users 키를 사용하여 EC2 인스턴스에서 Linux/UNIX 사용자를 생성할 수 있습니다. users 키는 Windows 시스템에는 지원되지 않습니다.

다음 표에는 지원되는 키가 나열되어 있습니다.

키 설명

uid

사용자 ID. 다른 사용자 ID의 사용자 이름이 존재하는 경우 생성 프로세스가 실패합니다. 해당 사용자 ID가 기존 사용자에게 이미 할당된 경우 운영 체제에서 생성 요청을 거부할 수 있습니다.

그룹

그룹 이름 목록. 사용자는 목록의 각 그룹에 추가됩니다.

homeDir

사용자의 홈 디렉터리.

예

사용자는 /sbin/nologin 셸을 사용하여 비대화형 시스템 사용자로 생성됩니다. 이러한 생성은 설계에 따른 것이므로 수정할 수 없습니다.

JSON

"users" : {
    "myUser" : {
        "groups" : ["groupOne", "groupTwo"],
        "uid" : "50",
        "homeDir" : "/tmp"
    }
}

YAML

users:
  myUser:
    groups:
      - "groupOne"
      - "groupTwo"
    uid: "50"
    homeDir: "/tmp"