쿡북 설치 및 우선 순위 Chef 검색 사용 데이터 백 사용 Berkshelf 사용

Chef 11.10 스택용 레시피 구현

중요

이 AWS OpsWorks Stacks 서비스는 2024년 5월 26일에 수명이 종료되었으며 신규 고객과 기존 고객 모두 사용할 수 없게 되었습니다. 고객은 가능한 한 빨리 워크로드를 다른 솔루션으로 마이그레이션할 것을 강력히 권장합니다. 마이그레이션에 대해 궁금한 점이 있으면 AWS re:Post 또는 Premium AWS Support를 통해 AWS Support 팀에 문의하세요.

Chef 11.10 스택은 Chef 11.4 스택에 비해 다음과 같은 장점이 있습니다.

Chef 실행은 Ruby 2.0.0을 사용합니다. 따라서 레시피가 새로운 Ruby 구문을 사용할 수 있습니다.
레시피는 Chef 검색 및 데이터 백을 사용할 수 있습니다.

Chef 11.10 스택은 많은 커뮤니티 쿡북을 수정 없이 사용할 수 있습니다.
Berkshelf를 사용하여 쿡북을 관리할 수 있습니다.

Berkshelf는 스택에서 사용자 지정 쿡북을 관리하고 커뮤니티 쿡북을 사용하는 훨씬 유연한 방법을 제공합니다.
쿡북은 metadata.rb에서 종속성을 선언해야 합니다.

쿡북이 다른 쿡북에 의존하는 경우 해당 쿡북의 metadata.rb 파일에서 종속성을 포함시켜야 합니다. 예를 들어 쿡북에 include_recipe anothercookbook::somerecipe 같은 문을 사용하는 레시피가 있는 경우 쿡북의 metadata.rb 파일에 depends "anothercookbook" 행이 있어야 합니다.
AWS OpsWorks 스택은 스택에 MySQL 계층이 포함된 경우에만 스택 인스턴스에 MySQL 클라이언트를 설치합니다.
AWS OpsWorks 스택은 스택에 Ganglia 계층이 포함된 경우에만 스택의 인스턴스에 Ganglia 클라이언트를 설치합니다.
배포가 bundle install을 실행하고 설치가 실패할 경우 배포도 실패합니다.

중요

내장 쿡북 이름을 사용자 지정 또는 커뮤니티 쿡북에 재사용하지 마십시오. 내장 쿡북과 이름이 동일한 사용자 지정 쿡북은 실패할 수 있습니다. Chef 11.10, 11.4 및 0.9 스택과 함께 사용할 수 있는 내장 쿡북의 전체 목록은 의 opsworks-cookbook 리포지토리를 참조하십시오. GitHub

Chef 0.9 및 11.4 스택에서 성공적으로 실행되는 비 ASCII 문자를 포함하는 쿡북이 Chef 11.10 스택에서는 실패할 수 있습니다. Chef 11.10 스택은 Chef 실행을 위해 Ruby 1.8.7보다 인코딩이 훨씬 엄격한 Ruby 2.0.0을 사용하기 때문입니다. 그러한 쿡북이 Chef 11.10 스택에서 성공적으로 실행되도록 하려면 비 ASCII 문자를 사용하는 각 파일의 맨 위에 인코딩 관련 힌트를 제공하는 주석이 포함되어야 합니다. 예를 들어 UTF-8 인코딩의 경우 주석은 # encoding: UTF-8이 될 수 있습니다. Ruby 2.0.0 인코딩에 대한 자세한 정보는 Encoding 단원을 참조하세요.

쿡북 설치 및 우선 순위

AWS OpsWorks Stacks 쿡북 설치 절차는 Chef 11.10 스택에서 이전 Chef 버전과 약간 다르게 작동합니다. Chef 11.10 스택의 경우 Stacks가 내장, 사용자 지정 및 Berkshelf 쿡북을 설치한 후 AWS OpsWorks 다음과 같은 순서로 공통 디렉토리에 병합합니다.

내장 쿡북
Berkshelf 쿡북(있는 경우)
사용자 지정 쿡북(있는 경우)

AWS OpsWorks Stacks는 이 병합을 수행할 때 레시피를 포함한 디렉터리의 전체 콘텐츠를 복사합니다. 중복 항목이 있을 경우 다음 규칙이 적용됩니다.

Berkshelf 쿡북의 콘텐츠가 내장 쿡북보다 우선합니다.
사용자 지정 쿡북의 콘텐츠가 Berkshelf 쿡북보다 우선합니다.

이 프로세스가 작동하는 방법을 예시하기 위해, 세 개의 쿡북 디렉터리 모두 mycookbook이라는 쿡북을 포함하고 있는 시나리오를 생각해 봅시다.

내장 쿡북 - mycookbook은 someattributes.rb라는 속성 파일, sometemplate.erb이라는 템플릿 파일 및 somerecipe.rb라는 이름의 레시피를 포함합니다.
Berkshelf 쿡북 - mycookbook은 sometemplate.erb 및 somerecipe.rb을(를) 포함합니다.
사용자 지정 쿡북 - mycookbook은 somerecipe.rb을(를) 포함합니다.

병합된 쿡북은 다음 항목을 포함합니다.

내장 쿡북의 someattributes.rb
Berkshelf 쿡북의 sometemplate.erb
사용자 지정 쿡북의 somerecipe.rb

중요

전체 내장 쿡북을 리포지토리로 복사한 후 쿡북의 일부를 수정하여 Chef 11.10 스택을 사용자 지정하면 안 됩니다. 그러면 레시피를 포함하여 전체 내장 쿡북을 재정의합니다. AWS OpsWorks Stacks가 해당 쿡북을 업데이트하는 경우 개인 사본을 수동으로 업데이트하지 않는 한 스택은 해당 업데이트의 이점을 얻을 수 없습니다. 스택을 사용자 지정하는 방법에 대한 자세한 정보는 스택 사용자 지정 AWS OpsWorks 단원을 참조하세요.

Chef 검색 사용

레시피에서 Chef search 메서드를 사용하여 스택 데이터를 쿼리할 수 있습니다. Chef 서버와 동일한 구문을 사용하지만 AWS OpsWorks Stacks는 Chef 서버를 쿼리하는 대신 로컬 노드 객체에서 데이터를 가져옵니다. 이 데이터에는 다음이 포함됩니다.

인스턴스의 스택 구성 및 베포 속성
인스턴스의 내장 및 사용자 지정 쿡북 속성 파일의 속성
Ohai가 수집한 시스템 데이터

스택 구성 및 배포 속성에는 스택에 있는 각 온라인 인스턴스의 호스트 이름 및 IP 주소와 같은 데이터를 포함하여 레시피가 일반적으로 검색을 통해 얻는 대부분의 정보가 포함됩니다. AWS OpsWorks 스택은 각 라이프사이클 이벤트에 대해 이러한 속성을 업데이트하여 현재 스택 상태를 정확하게 반영하도록 합니다. 이는 스택에서 검색 의존형 커뮤니티 레시피를 수정 없이 자주 사용할 수 있음을 의미합니다. 검색 메서드는 여전히 해당 데이터를 반환합니다. 데이터는 서버가 아니라 스택 구성 및 배포 속성으로부터 가져옵니다.

AWS OpsWorks Stacks 검색의 주요 제한 사항은 로컬 노드 개체의 데이터, 특히 스택 구성 및 배포 속성만 처리한다는 것입니다. 이러한 이유 때문에 다음 형식의 데이터는 검색을 통해 가져오지 못할 수 있습니다.

다른 인스턴스의 로컬에서 정의된 속성

레시피가 속성을 로컬로 정의하는 경우 해당 정보는 AWS OpsWorks Stacks 서비스에 다시 보고되지 않으므로 검색을 사용하여 다른 인스턴스에서 해당 데이터에 액세스할 수 없습니다.
사용자 지정 deploy 속성

앱을 배포할 때 사용자 지정 JSON을 지정할 수 있습니다. 그러면 해당 배포에서 스택의 인스턴스에 해당 속성이 설치됩니다. 하지만 사용자가 선택한 인스턴스에만 배포하는 경우 속성이 이러한 인스턴스에만 설치됩니다. 사용자 지정 JSON 속성에 대한 쿼리는 다른 모든 인스턴스에서 실패합니다. 또한 사용자 지정 속성은 특정 배포에 대해서만 스택 구성 및 배포 JSON에 포함됩니다. 이들 속성은 다음 번 수명 주기 이벤트가 새로운 스택 구성 및 배포 속성 세트를 설치할 때까지만 액세스할 수 있습니다. 스택에 대해 사용자 지정 JSON을 지정할 경우 속성은 모든 수명 주기 이벤트에서 모든 인스턴스에 설치되고 언제나 검색을 통해 액세스할 수 있습니다.
다른 인스턴스의 Ohai 데이터

Chef의 Ohai 도구는 인스턴스의 다양한 시스템 데이터를 가져와 노드 객체에 추가합니다. 이 데이터는 로컬에 저장되고 AWS OpsWorks Stacks 서비스로 보고되지 않습니다. 따라서 검색이 다른 인스턴스의 Ohai 데이터에 액세스할 수 없습니다. 하지만 이 데이터 중 일부가 스택 구성 및 배포 속성에 포함될 수도 있습니다.
오프라인 인스턴스

스택 구성 및 배포 속성은 온라인 인스턴스에 대한 데이터만 포함합니다.

다음 레시피 코드는 검색을 사용하여 PHP 계층 인스턴스의 프라이빗 IP 주소를 가져오는 방법을 보여줍니다.



appserver = search(:node, "role:php-app").first
Chef::Log.info("The private IP is '#{appserver[:private_ip]}'")

참고

AWS OpsWorks Stacks가 스택 구성 및 배포 속성을 노드 개체에 추가하면 실제로 각각 동일한 데이터를 가진 두 세트의 레이어 속성이 생성됩니다. layers네임스페이스에 한 세트가 있는데, AWS OpsWorks 스택이 데이터를 저장하는 방식입니다. 다른 한 세트는 role 네임스페이스에 위치합니다. 이것은 Chef 서버가 데이터를 저장하는 방법입니다. role네임스페이스의 목적은 Chef 서버용으로 구현된 검색 코드를 Stacks 인스턴스에서 실행할 수 있도록 하는 것입니다. AWS OpsWorks AWS OpsWorks 스택용으로 특별히 코드를 작성하는 경우 이전 role:php-app 예제에서 layers:php-app 또는 둘 중 하나를 사용할 수 있으며 search 동일한 결과가 반환됩니다.

데이터 백 사용

레시피에서 Chef data_bag_item 메서드를 사용하여 데이터 백의 정보를 쿼리할 수 있습니다. Chef 서버에서와 동일한 구문을 사용하지만, AWS OpsWorks Stacks는 인스턴스의 스택 구성 및 배포 속성에서 데이터를 가져옵니다. 그러나 AWS OpsWorks Stacks는 현재 Chef 환경을 지원하지 않으므로 node.chef_environment 항상 반환됩니다. _default

사용자 지정 JSON으로 하나 이상의 속성을 [:opsworks][:data_bags] 속성에 추가하여 데이터 백을 생성합니다. 다음 예제는 사용자 지정 JSON에서 데이터 백을 생성하는 일반 형식을 보여줍니다.

참고

데이터 백을 쿡북 리포지토리에 추가하여 생성할 수는 없습니다. 반드시 사용자 지정 JSON을 사용해야 합니다.



{
  "opsworks": {
    "data_bags": {
      "bag_name1": {
        "item_name1: {
          "key1" : “value1”,
          "key2" : “value2”,
          ...
        }
      },
      "bag_name2": {
        "item_name1": {
          "key1" : “value1”,
          "key2" : “value2”,
          ...
        }
      },
      ...
    }
  }
}

일반적으로 스택에 대해 사용자 지정 JSON을 지정합니다. 그러면 이후의 각 수명 주기 이벤트에서 사용자 지정 속성이 모든 인스턴스에 설치됩니다. 앱을 배포할 때 사용자 지정 JSON을 지정할 수도 있습니다. 하지만 이들 속성은 해당 배포에만 설치되고 선택된 인스턴스 집합에만 설치될 수 있습니다. 자세한 정보는 앱 배포을 참조하세요.

다음 사용자 지정 JSON 예제는 myapp이라는 데이터 백을 생성합니다. 이 데이터 백은 하나의 항목 mysql을 포함하며 키-값 페어가 두 개입니다.



{ "opsworks": {
    "data_bags": {
      "myapp": {
        "mysql": { 
          "username": "default-user",
          "password": "default-pass"
        }
      }
    }
  }
}

레시피에서 데이터를 사용하려면 다음 코드에 나온 대로 data_bag_item을 호출하고 여기에 데이터 백 및 값 이름을 전달할 수 있습니다.



mything = data_bag_item("myapp", "mysql")
Chef::Log.info("The username is '#{mything['username']}' ")

데이터 백의 데이터를 수정하려면 사용자 지정 JSON을 수정하면 됩니다. 그러면 JSON이 다음 번 수명 주기 이벤트에서 스택의 인스턴스에 설치됩니다.

Berkshelf 사용

Chef 0.9 및 Chef 11.4 스택에서는 사용자 지정 쿡북 리포지토리를 하나만 설치할 수 있습니다. Chef 11.10 스택의 경우 Berkshelf를 사용하여 쿡북과 해당 종속성을 관리할 수 있습니다. 그러면 여러 리포지토리로부터 쿡북을 설치할 수 있습니다. (자세한 설명은 로컬로 쿡북 종속성 패키징 섹션을 참조하십시오.) 특히 Berkshelf를 사용하면 AWS OpsWorks Stacks와 호환되는 커뮤니티 쿡북을 사용자 지정 쿡북 리포지토리로 복사할 필요 없이 해당 리포지토리에서 직접 설치할 수 있습니다. 지원되는 Berkshelf 버전은 운영 체제에 따라 다릅니다. 자세한 정보는 AWS OpsWorks 스택 운영 체제을 참조하세요.

Berkshelf를 사용하려면 사용자 지정 쿡북 설치 섹션에서 설명하는 대로 명시적으로 Berkshelf를 활성화해야 합니다. 그런 다음 Berksfile 파일을 쿡북 리포지토리의 루프 디렉터리(설치할 쿡북을 지정)에 포함시킵니다.

Berksfile에서 외부 쿡북 소스를 지정하려면 기본 리포지토리 URL을 지정하는 파일의 맨 위에 소스 속성을 포함시킵니다. Berkshelf는 리포지토리가 명시적으로 지정되지 않은 한 소스 URL에서 쿡북을 찾습니다. 그런 다음 설치하려는 각 쿡북을 다음 형식으로 한 줄에 포함시킵니다.



cookbook 'cookbook_name', ['>= cookbook_version'], [cookbook_options]

cookbook 다음의 필드는 특정 쿡북을 지정합니다.

cookbook_name – (필수) 쿡북의 이름을 지정합니다.

다른 어떤 필드도 포함시키지 않을 경우 Berkshelf는 지정된 소스 URL로부터 쿡북을 설치합니다.
cookbook_version – (선택) 쿡북 버전을 지정합니다.

= 또는 >= 같은 접두사를 사용하여 특정 버전 또는 허용 가능한 버전 범위를 지정할 수 있습니다. 버전을 지정하지 않을 경우 Berkshelf는 최신 버전을 설치합니다.
cookbook_options – (선택) 마지막 필드는 리포지토리 위치 같은 옵션을 지정하는 하나 이상의 키-값 페어를 포함하는 해시입니다.

예를 들어 git 키를 포함시켜 특정 Git 리포지토리를 지정하고 tag 키를 포함시켜 특정 리포지토리 브랜치를 지정할 수 있습니다. 리포지토리 브랜치 지정은 일반적으로 선호하는 쿡북이 설치되도록 보장하는 최선의 방법입니다.

중요

Berksfile에 metadata 행을 포함시키고 metadata.rb에서 쿡북 종속성을 선언하여 쿡북을 선언하지 마십시오. 이 방법이 제대로 작동하려면 두 파일이 모두 동일한 디렉터리에 있어야 합니다. AWS OpsWorks Stacks를 사용하면 Berks파일은 저장소의 루트 디렉터리에 있어야 하지만 파일은 해당 쿡북 디렉터리에 있어야 합니다. metadata.rb 대신에 Berksfile에서 외부 쿡북을 명시적으로 선언해야 합니다.

다음은 쿡북을 지정하는 다양한 방법을 보여주는 Berksfile의 예제입니다. Berksfile을 생성하는 방법에 대한 자세한 정보는 Berkshelf를 참조하세요.



source "https://supermarket.chef.io"

cookbook 'apt'
cookbook 'bluepill', '>= 2.3.1'
cookbook 'ark', git: 'git://github.com/opscode-cookbooks/ark.git'
cookbook 'build-essential', '>= 1.4.2', git: 'git://github.com/opscode-cookbooks/build-essential.git', tag: 'v1.4.2'

이 파일은 다음 쿡북을 설치합니다.

커뮤니티 쿡북 중 최신 버전의 apt
커뮤니티 쿡북 중 최신 버전의 bluepill(버전 2.3.1 이상)
지정된 리포지토리로부터 최신 버전의 ark

이 예제의 URL은 퍼블릭 커뮤니티 쿡북 리포지토리의 URL이지만 GitHub, 프라이빗 리포지토리를 포함한 다른 리포지토리에서 쿡북을 설치할 수 있습니다. 자세한 정보는 Berkshelf를 참조하세요.
지정된 리포지토리의 v1.4.2 브랜치로부터 build-essential 쿡북

사용자 지정 쿡북 리포지토리에는 Berksfile 이외에 사용자 지정 쿡북이 포함될 수 있습니다. 이 경우 AWS OpsWorks Stacks는 두 쿡북 세트를 모두 설치하므로 인스턴스에 쿡북 리포지토리가 세 개까지 있을 수 있습니다.

내장 쿡북은 /opt/aws/opsworks/current/cookbooks에 설치됩니다.
사용자 지정 쿡북 리포지토리에 쿡북이 포함되어 있는 경우 이러한 쿡북은 /opt/aws/opsworks/current/site-cookbooks에 설치됩니다.
Berkshelf가 활성화되어 있고 사용자 지정 쿡북 리포지토리에 Berksfile이 포함되어 있는 경우 지정된 쿡북은 /opt/aws/opsworks/current/berkshelf-cookbooks에 설치됩니다.

기본 제공 쿡북과 사용자 지정 쿡북은 설정 중에 각 인스턴스에 설치되며 Update Custom Cookbook stack 명령을 수동으로 실행하지 않는 한 이후에 업데이트되지 않습니다. AWS OpsWorks 스택은 모든 Chef berks install 실행에 대해 실행되므로 Berkshelf 쿡북은 다음 규칙에 따라 각 라이프사이클 이벤트에 대해 업데이트됩니다.

리포지토리에 새 쿡북 버전이 있을 경우 이 작업은 리포지토리로부터 쿡북을 업데이트합니다.
그렇지 않을 경우 이 작업은 로컬 캐시로부터 Berkshelf 쿡북을 업데이트합니다.

참고

이 작업은 Berkshelf 쿡북을 덮어쓰므로 쿡북의 로컬 복사본을 수정한 경우 변경 사항을 덮어쓰게 됩니다. 자세한 정보는 Berkshelf를 참조하세요.

또한 사용자 지정 쿡북 업데이트 스택 명령을 실행하여 Berkshelf 쿡북을 업데이트할 수도 있습니다. 이 경우 Berkshelf 쿡북 및 사용자 지정 쿡북 모두 업데이트됩니다.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

레시피 구현: Chef 12

레시피 구현: Chef 11.4