웹사이트 검색

Chef에서 역할 및 환경을 사용하여 서버 구성을 제어하는 방법


소개

인프라를 구축함에 따라 많은 서버, 서비스, 사용자 및 애플리케이션을 관리하는 것이 매우 빠르게 어려워질 수 있습니다. 구성 관리 시스템을 사용하여 이러한 혼란을 관리할 수 있습니다.

Chef는 전체 시스템의 다양한 구성 요소를 매우 쉽게 구성할 수 있는 뛰어난 구성 관리 시스템입니다. 이전 가이드에서는 간단한 쿡북을 만들어 구성을 관리하는 방법에 대해 설명했습니다.

이 가이드에서는 Chef를 사용하여 환경을 관리하는 방법을 계속 살펴보겠습니다. 이번에는 역할과 환경을 사용하여 어떤 기능을 나타내야 하는지에 따라 서버와 서비스를 차별화하는 방법에 대해 이야기하겠습니다.

서버, 워크스테이션 및 클라이언트를 설치했고 마지막 가이드에서 생성한 쿡북을 사용할 수 있다고 가정합니다.

역할 및 환경

역할이란 무엇입니까?

조직에서 더 높은 트래픽 요구를 충족하기 위해 인프라가 확장되면 모두 동일한 기본 작업을 수행하는 여러 개의 중복 서버가 있을 수 있습니다. 예를 들어 로드 밸런서가 요청을 전달하는 웹 서버일 수 있습니다. 그들은 모두 동일한 기본 구성을 가지며 각각 동일한 \역할\을 만족한다고 말할 수 있습니다.

역할에 대한 Chef의 관점은 일반 정의와 거의 완전히 동일합니다. Chef의 역할은 특정 시스템이 해야 할 작업을 설명하는 범주입니다. 어떤 책임이 있으며 어떤 소프트웨어 및 설정을 제공해야 합니다.

여러 상황에서 둘 이상의 역할을 처리하는 특정 시스템이 있을 수 있습니다. 예를 들어, 소프트웨어를 테스트하는 경우 하나의 서버에 데이터베이스와 웹 서버 구성 요소가 포함될 수 있지만 프로덕션 환경에서는 이들을 별도의 서버에 배치할 계획입니다.

Chef를 사용하면 첫 번째 서버를 두 역할에 할당한 다음 각 역할을 생산 시스템의 별도 컴퓨터에 할당하는 것만큼 쉽습니다. 각 역할에는 특정 역할을 수행하기 위해 시스템을 완전한 작동 상태로 전환하는 데 필요한 구성 세부 정보가 포함됩니다. 즉, 패키지 설치, 서비스 구성, 해당 역할에 대한 특수 속성 등을 처리할 쿡북을 수집할 수 있습니다.

환경이란 무엇입니까?

역할 개념과 관련된 것은 Chef 환경의 개념입니다. 환경은 단순히 관리자가 서버가 속한 프로덕션 프로세스의 단계를 알 수 있도록 돕기 위한 지정입니다. 각 서버는 정확히 하나의 환경에 속할 수 있습니다.

기본적으로 "_default\라는 환경이 생성됩니다. 다른 환경이 지정되지 않는 한 각 노드는 이 환경에 배치됩니다. 서버를 프로세스 그룹의 일부로 태그 지정하도록 환경을 생성할 수 있습니다.

예를 들어, 한 환경은 "테스트\라고 하고 다른 환경은 "프로덕션\이라고 할 수 있습니다. 프로덕션 시스템에서 아직 테스트 중인 코드를 원하지 않기 때문에 각 시스템은 하나의 환경에만 있을 수 있습니다. 그런 다음 테스트 환경의 시스템에 대한 하나의 구성과 프로덕션 환경의 컴퓨터에 대해 완전히 다른 구성을 가질 수 있습니다.

역할에 제공된 위의 예에서 테스트 환경에서 웹 및 데이터베이스 서버 역할이 단일 시스템에 있도록 지정할 수 있습니다. 프로덕션 환경에서 이러한 역할은 개별 서버에서 처리해야 합니다.

환경은 테스트 프로세스 자체에도 도움이 됩니다. 프로덕션에서 요리책이 안정적인 버전이어야 한다고 지정할 수 있습니다. 그러나 컴퓨터가 테스트 환경의 일부인 경우 최신 버전의 쿡북을 받을 수 있도록 지정할 수 있습니다.

역할 사용 방법

Ruby DSL을 사용하여 역할 생성

워크스테이션의 chef-repo 디렉토리에 있는 roles 디렉토리를 사용하여 역할을 만들 수 있습니다.

워크스테이션에 로그인하고 지금 이 디렉터리로 이동합니다.

cd ~/chef-repo/roles

이 디렉터리 내에서 조직에서 원하는 역할을 정의하는 다양한 파일을 만들 수 있습니다. 각 역할 파일은 Chef의 Ruby DSL 또는 JSON으로 작성할 수 있습니다.

웹 서버에 대한 역할을 생성해 보겠습니다.

nano web_server.rb

이 파일 내에서 역할에 대한 몇 가지 기본 데이터를 지정하여 시작할 수 있습니다.

name "web_server"
description "A role to configure our front-line web servers"

이것들은 상당히 간단해야 합니다. 우리가 제공하는 이름은 공백을 포함할 수 없으며 일반적으로 이 역할에 대해 선택한 파일 이름에서 확장자를 제외하고 일치해야 합니다. 설명은 역할이 관리해야 하는 대상에 대한 사람이 읽을 수 있는 메시지일 뿐입니다.

다음으로 이 특정 역할에 사용할 run_list를 지정할 수 있습니다. 역할의 run_list에는 쿡북(기본 레시피를 실행함), 쿡북의 레시피(cookbook::recipe 구문을 사용하여 지정됨) 및 기타 역할이 포함될 수 있습니다. run_list는 항상 순차적으로 실행되므로 다른 항목 앞에 종속성 항목을 배치해야 합니다.

run_list가 마지막 가이드에서 구성한 것과 정확히 일치하도록 지정하려면 다음과 같이 표시됩니다.

name "web_server"
description "A role to configure our front-line web servers"
run_list "recipe[apt]", "recipe[nginx]"

또한 환경별 run_lists를 사용하여 서버가 속한 환경에 따라 변수 구성 변경을 지정할 수 있습니다.

예를 들어 노드가 "프로덕션\ 환경에 있는 경우 "nginx\ 쿡북에서 특별한 레시피를 실행하여 해당 서버를 프로덕션 정책 요구 사항에 맞출 수 있습니다. 테스트 서버를 위한 특별한 변경 사항을 구성하기 위한 nginx 요리책의 레시피를 가질 수도 있습니다.

이 두 가지 레시피를 각각 "config_prod\ 및 "config_test\라고 가정하면 다음과 같은 특정 환경 실행 목록을 만들 수 있습니다.

name "web_server"
description "A role to configure our front-line web servers"
run_list "recipe[apt]", "recipe[nginx]"
env_run_lists "production" => ["recipe[nginx::config_prod]"], "testing" => ["recipe[nginx::config_test]"]

위의 예에서 노드가 프로덕션 환경의 일부인 경우 "nginx\ 쿡북 내에서 "config_prod\ 레시피를 실행하도록 지정했습니다. 그러나 노드가 테스트 환경에 있는 경우 "config_test\ 레시피를 실행합니다. 노드가 다른 환경에 있는 경우 기본 run_list가 적용됩니다.

마찬가지로 기본 및 재정의 특성을 지정할 수 있습니다. 이 시점에서 기본 속성에 대해 잘 알고 있어야 합니다. 역할에서 우리는 다른 곳에서 설정된 기본 속성을 재정의할 수 있는 기본 속성을 설정할 수 있습니다.

다른 많은 속성 선언보다 우선 순위가 높은 재정의 속성을 설정할 수도 있습니다. 이를 사용하여 이 역할이 할당된 노드가 특정 방식으로 작동하도록 할 수 있습니다.

파일에서 다음과 같이 추가할 수 있습니다.

name "web_server"
description "A role to configure our front-line web servers"
run_list "recipe[apt]", "recipe[nginx]"
env_run_lists "production" => ["recipe[nginx::config_prod]"], "testing" => ["recipe[nginx::config_test]"]
default_attributes "nginx" => { "log_location" => "/var/log/nginx.log" }
override_attributes "nginx" => { "gzip" => "on" }

여기에서 노드의 모든 서버에 대한 기본 로그 위치를 설정했습니다. 우리는 또한 다른 속성 선언이 다른 위치에서 명시한 것과는 달리 이 역할의 노드는 gzip 속성을 "on\으로 설정해야 한다고 지정했습니다. 이는 몇 군데 더 재정의될 수 있지만 일반적으로 우선 순위가 높습니다. 선언.

JSON을 사용하여 역할 생성

역할을 구성하는 데 사용할 수 있는 다른 형식은 JSON입니다. 실제로 칼을 사용하여 이 형식에서 역할을 자동으로 생성함으로써 이 형식을 탐색할 수 있습니다. 테스트 역할을 생성해 보겠습니다.

knife role create test

템플릿 역할 파일이 미리 로드된 상태로 텍스트 편집기가 열립니다. 다음과 같아야 합니다.

{
  "name": "test",
  "description": "",
  "json_class": "Chef::Role",
  "default_attributes": {
  },
  "override_attributes": {
  },
  "chef_type": "role",
  "run_list": [

  ],
  "env_run_lists": {
  }
}

이것은 기본적으로 Ruby DSL 형식 파일에 입력한 것과 동일한 정보입니다. 유일한 차이점은 형식화와 json_classchef_type이라는 두 개의 새로운 키 추가입니다. 이들은 내부적으로 사용되며 수정해서는 안 됩니다.

그 외에는 다음과 같이 JSON에서 다른 파일을 쉽게 다시 만들 수 있습니다.

{
  "name": "web_server",
  "description": "A role to configure our front-line web servers",
  "json_class": "Chef::Role",
  "default_attributes": {
    "nginx": {
      "log_location": "/var/log/nginx.log"
    }
  },
  "override_attributes": {
    "nginx": {
      "gzip": "on"
    }
  },
  "chef_type": "role",
  "run_list": [
    "recipe[apt]",
    "recipe[nginx]"
  ],
  "env_run_lists": {
    "production": [
      "recipe[nginx::config_prod]"
    ],
    "testing": [
      "recipe[nginx::config_test]"
    ]
  }
}

이것은 위의 Ruby 버전과 거의 동일한 기능을 가져야 합니다.

워크스테이션과 서버 간 역할 이전

knife 명령을 사용하여 생성된 JSON 파일을 저장하면 Chef 서버에 역할이 생성됩니다. 반대로 로컬에서 만든 Ruby 파일은 서버에 업로드되지 않습니다.

다음과 같은 명령을 실행하여 루비 파일을 서버에 업로드할 수 있습니다.

<예비>

이렇게 하면 파일에 지정된 역할 정보가 서버에 업로드됩니다. 이는 Ruby DSL 형식 파일 또는 JSON 파일에서 작동합니다.

비슷한 맥락에서 서버에서 JSON 파일을 가져오려면 knife 명령에 해당 역할 파일을 JSON으로 표시한 다음 다음과 같은 파일로 파이프할 수 있습니다.

<예비>

노드에 역할 할당

이제 우리가 사용한 형식에 관계없이 Chef 서버에서 우리의 역할이 있습니다. 노드에 특정 역할을 어떻게 할당합니까?

노드의 run_list에서 레시피처럼 노드에 역할을 할당합니다.

따라서 역할을 노드에 추가하려면 다음을 실행하여 노드를 찾습니다.

knife node list

그런 다음 다음과 같은 명령을 내립니다.

<예비>

이렇게 하면 노드의 정의 파일이 표시되어 run_list에 역할을 추가할 수 있습니다.

{
  "name": "client1",
  "chef_environment": "_default",
  "normal": {
    "tags": [

    ]
  },
  "run_list": [
    "recipe[nginx]"
  ]
}

예를 들어 레시피를 이 파일의 역할로 바꿀 수 있습니다.

<예비>

]

},

이는 이전 레시피와 동일한 단계를 수행하지만 대신 서버가 가져야 하는 역할에 대해 간단히 설명합니다.

이렇게 하면 검색을 통해 특정 역할의 모든 서버에 액세스할 수 있습니다. 예를 들어 역할과 환경을 검색하여 프로덕션 환경의 모든 데이터베이스 서버를 검색할 수 있습니다.

knife search "role:database_server AND chef_environment:prod" -a name

이렇게 하면 데이터베이스 서버로 구성된 노드 목록이 표시됩니다. 이것을 요리책에서 내부적으로 사용하여 모든 프로덕션 데이터베이스 서버를 풀에 자동으로 추가하여 읽기 요청을 하도록 웹 서버를 구성할 수 있습니다.

환경 사용 방법

환경 만들기

어떤 면에서 환경은 역할과 매우 유사합니다. 또한 서로 다른 서버를 구분하는 데 사용되지만 서버의 기능으로 구분하는 대신 기계가 속한 개발 단계로 환경을 구분합니다.

앞서 역할에 대해 이야기할 때 이 중 일부를 논의했습니다. 실제 제품 수명 주기와 일치하는 환경이 가장 적합합니다. 테스트, 스테이징 및 프로덕션을 통해 코드를 실행하는 경우 일치하는 환경이 있어야 합니다.

역할과 마찬가지로 Ruby DSL 또는 JSON에서 정의 파일을 설정할 수 있습니다.

워크스테이션의 "chef-repo\ 디렉터리에 환경 디렉터리가 있어야 합니다. 여기에 환경 파일을 넣어야 합니다.

cd ~/chef-repo/environments

이 디렉토리 내에서 개발 환경을 정의하려는 경우 다음과 같은 파일을 만들 수 있습니다.

nano development.rb
name "development"
description "The master development branch"
cookbook_versions({
    "nginx" => "<= 1.1.0",
    "apt" => "= 0.0.1"
})
override_attributes ({
    "nginx" => {
        "listen" => [ "80", "443" ]
    },
    "mysql" => {
        "root_pass" => "root"
    }
})

보시다시피 환경을 시스템에 통합할 때의 주요 이점 중 하나는 배포되는 쿡북 및 레시피에 대한 버전 제약 조건을 지정할 수 있다는 것입니다.

JSON 형식을 사용할 수도 있습니다. 나이프 도구는 다음을 입력하여 환경 파일의 템플릿을 생성할 수 있습니다.

knife environment create development

이렇게 하면 이름이 채워진 미리 로드된 환경 파일과 함께 편집기가 열립니다(다시 export EDITOR=nano로 편집기를 설정할 수 있음).

다음을 입력하여 동일한 파일을 만들 수 있습니다.

{
  "name": "development",
  "description": "The master development branch",
  "cookbook_versions": {
    "nginx": "<= 1.1.0",
    "apt": "= 0.0.1"
  },
  "json_class": "Cheff:Environment",
  "chef_type": "environment",
  "default_attributes": {
  },
  "override_attributes": {
    "nginx": {
      "listen": [
        "80",
        "443"
      ]
    },
    "mysql": {
      "root_pass": "root"
    }
  }
}

이 파일은 위에서 설명한 Ruby 파일과 기능적으로 동일해야 합니다. JSON 역할 파일과 마찬가지로 환경 JSON 파일에는 그대로 두어야 하는 두 가지 추가 정보(json_classchef_type)가 있습니다.

서버에서 환경 파일 이동

이 시점에서 Ruby DSL을 사용했다면 파일은 워크스테이션에 있고 JSON을 사용했다면 파일은 서버에만 있습니다. 나이프를 통해 파일을 앞뒤로 쉽게 이동할 수 있습니다.

다음을 입력하여 Ruby 파일을 Chef 서버에 업로드할 수 있습니다.

knife environment from file ~/chef-repo/environments/development.rb

JSON 파일의 경우 다음과 같이 입력하여 서버에서 환경 파일을 가져올 수 있습니다.

knife environment show development -Fjson > ~/chef-repo/environments/development.json

이것은 서버의 JSON 파일을 표시하고 결과를 환경 하위 디렉토리 내의 로컬 파일로 파이프합니다.

노드에서 환경 설정

각 노드는 정확히 하나의 환경에 있을 수 있습니다. 노드 정보를 편집하여 노드가 속한 환경을 지정할 수 있습니다.

예를 들어 client1이라는 노드를 편집하려면 다음과 같이 입력할 수 있습니다.

knife node edit client1

그러면 현재 노드 매개변수가 포함된 JSON 형식 파일이 열립니다.

{
  "name": "client1",
  "chef_environment": "_default",
  "normal": {
    "tags": [

    ]
  },
  "run_list": [
    "role[web_server]"
  ]
}

보시다시피 chef_environment는 원래 _default로 설정되어 있습니다. 해당 값을 수정하여 노드를 새 환경에 배치하기만 하면 됩니다.

완료되면 파일을 저장하고 닫습니다. 노드에서 실행되는 다음 Chef-Client에서는 새로운 속성과 버전 제약 조건을 선택하고 새로운 정책에 맞게 자체적으로 수정합니다.

결론

지금쯤이면 컴퓨터의 상태를 확고히 하기 위해 역할 및 환경과 함께 작업할 수 있는 다양한 방법을 잘 이해하고 있어야 합니다. 이러한 분류 전략을 사용하여 Chef가 다양한 컨텍스트에서 서버를 처리하는 방식을 관리할 수 있습니다.

저스틴 엘링우드