chef-solo 대신 chef-server를 실행하면 어떤 이점이 있습니까?


33

팀을위한 자동화 된 배포 솔루션을보고 있으며 지난 며칠 동안 Chef와 협력 해 왔습니다. chef-solo를 사용하여 기본 Red Hat VM에서 간단한 웹 응용 프로그램을 실행할 수있었습니다.

최종 목표는 Chef (또는 다른 시스템)를 사용하여 빌드를 실행할 때 애플리케이션 토폴로지를 클라우드에 자동으로 배포하는 것입니다. 우리의 프로세스는 기본적으로 다음과 같이 실행됩니다 :

  1. 우리의 웹 앱 코드, 의존성 및 요리사 요리 책은 SCM에 저장됩니다
  2. 빌드가 실행되고 이미지를 수집하고 테스트 할 단일 패키지가 생성됩니다.
  3. 그런 다음 빌드 엔진은 Chef 클라이언트를 실행하여 패키지를 설치하는 새로운 클라우드 이미지를 배포합니다.
  4. 이미지는 SCM 또는 Chef 서버에서 요리 책을 가져 와서 모든 것을 설치하고 실행합니다.

Chef 서버를 실행할 때의 이점 및 / 또는 사용 사례는 무엇입니까?

Chef Server가 Chef-Solo를 사용하고 SCM에서 Cookbook을 가져 오는 스크립트를 사용하는 것과 비교하여 SCM에서 Cookbook을 보유하고 확보하는 데 큰 이점이 있습니까?

답변:


67

나는이 질문에 대해 "chef-solo의 장점은 무엇인가"인 것처럼이 답변의 방향을 정할 것입니다. 그것이 접근 방식의 차이점을 다루는 가장 좋은 방법이기 때문입니다.

필자의 요약 권장 사항은 다른 사람들과 일치합니다. 노드를 자주 추가하고 제거 할 동적 가상화 환경을 관리해야하는 경우 요리사 서버를 사용하십시오. 필요한 경우 요리사 서버도 훌륭한 CMDB 입니다. 노드가 너무 자주 바뀌지 않지만 역할과 레시피가 바뀌는 역동적 인 환경이 아닌 경우 chef-solo를 사용하십시오. 환경의 규모와 복잡성은 어느 정도 관련이 없습니다. 두 가지 접근법 모두 매우 잘 확장됩니다.

chef-solo를 배치하는 경우 rsync, 'git pull'또는 다른 dem 등원 파일 전송 메커니즘과 함께 cronjob을 사용하여 각 노드에서 chef 저장소의 전체 사본을 유지하십시오. cronjob은 (a) 전혀 실행하지 않고 (b) 실행하지만 로컬 저장소를 동기화하지 않고 쉽게 구성 할 수 있어야합니다. Chef 리포지토리에 각 노드의 json 파일과 함께 nodes / 디렉토리를 추가하십시오. 올바른 노드 파일을 식별하는 관점에서 cronjob을 원하는대로 정교하게 만들 수 있습니다 (단순하게 $ (hostname -s) .json을 권장하지만, opscode 계정을 만들고 호스팅 된 요리사가있는 클라이언트를 구성 할 수도 있습니다) 칼을 사용하여 커뮤니티 요리 책을 다운로드하고 골격을 만드는 것 외에 다른 이유는 없습니다.

명백한 "서버를 관리 할 필요가없는 것"외에,이 방법에는 몇 가지 장점이 있습니다. 소스 제어는 모든 구성 변경의 최종 중재자가되고 저장소에는 모든 노드와 런리스트가 포함되며 각 서버는 완전히 독립적이므로 편리한 테스트 시나리오를 용이하게합니다.

Chef-server는 "나이프 업로드"를 사용하여 요리 책을 업데이트하는 구멍을 소개하며,이 구멍을 직접 패치 (포스트 커밋 후크 등)하거나 "나이프 업로드"사람이 사이트 변경 사항을 자동으로 덮어 쓸 위험이 있습니다. 랩톱의 오래된 로컬 저장소에서 사용되지 않는 레시피입니다. 모든 변경 사항이 마스터 리포지토리에서 서버로 직접 동기화되므로 chef-solo에서 발생할 가능성이 적습니다. 여기서 문제는 징계와 공동 작업자 수입니다. 단독 개발자이거나 소규모 팀인 경우 API를 통해 요리 책을 업로드하는 것은 그리 위험하지 않습니다. 규모가 큰 팀에서는 적절한 통제력을 갖추지 않을 수 있습니다.

또한 chef-solo를 사용하면 모든 노드의 역할, 사용자 정의 속성 및 실행 목록을 기본 chef 저장소에 node.json 파일로 저장할 수 있습니다. chef-server를 사용하면 API를 사용하여 역할 및 실행 목록을 즉석에서 수정할 수 있습니다. chef-solo를 사용하면이 정보를 개정 관리에서 추적 할 수 있습니다. 정적 환경과 동적 환경 사이의 충돌을 명확하게 볼 수있는 곳입니다. 노드 목록 (길이에 관계없이)이 자주 변경되지 않는 경우이 데이터를 개정 관리에 포함시키는 것이 매우 유용합니다. 반면, 새 노드를 자주 생성하고 이전 노드를 다시 파기하는 경우 (호스트 이름이나 fqdn을 다시 보지 않음) 개정 제어에서 모든 노드를 유지하는 것은 불필요한 번거 로움이며 변경을위한 API를 갖는 것이 매우 편리합니다. Chef-server에는 노드를 식별하는 기본 방법으로 fqdn을 대체 할 수있는 "knife bootstrap"의 이름 옵션과 같이 동적 클라우드 환경 관리를위한 모든 기능이 있습니다. 그러나 정적 환경에서는 이러한 기능의 가치가 제한적입니다. 특히 다른 모든 기능을 사용하여 개정 제어에서 역할 및 실행 목록을 갖는 것과 비교할 수 있습니다.

마지막으로, 추가 작업없이 레시피 테스트 환경을 즉석에서 설정할 수 있습니다. 서버에서 실행중인 cronjob을 비활성화하고 로컬 저장소를 직접 변경할 수 있습니다. chef-solo를 실행하여 변경 사항을 테스트 할 수 있으며 프로덕션 환경에서 서버가 어떻게 구성되는지 정확히 확인할 수 있습니다. 모든 것이 테스트되면 변경 사항을 체크인하고 로컬 크론 작업을 다시 활성화 할 수 있습니다. 레시피를 작성할 때 "검색"API를 사용할 수 없습니다. 즉, 동적 레시피 (예 :로드 밸런서)를 작성하려면이 제한을 해킹하여 json 파일에서 데이터를 수집해야합니다. 노드 / 디렉토리는 덜 편리하고 전체 CMDB에서 사용 가능한 일부 데이터가 부족합니다. 다시 한 번 더 역동적 인 환경은 데이터베이스 중심 접근 방식을 선호합니다. 덜 동적 환경은 로컬 디스크의 json 파일을 사용하면 좋습니다. Chef Run이 중앙 데이터베이스에 대한 API 호출을 수행해야하는 서버 환경에서는 해당 데이터베이스 내의 모든 테스트 환경 관리에 의존하게됩니다.

마지막은 응급 상황에서도 사용할 수 있습니다. 프로덕션 서버에서 중요한 문제를 해결하고 구성 변경으로 문제를 해결하는 경우 서버의 저장소에서 즉시 변경 한 다음 마스터로 업스트림으로 푸시 할 수 있습니다.

이것들은 chef-solo의 주요 장점입니다. 서버를 관리하거나 호스트 셰프를 지불 할 필요가없는 것과 같은 다른 것들이 있지만, 이들은 비교적 사소한 문제입니다.

요약 : 동적이고 고도로 가상화 된 경우 chef-server는 여러 가지 훌륭한 기능을 제공하며 (다른 곳에서 다루어 짐) 대부분의 chef-solo 장점은 눈에 띄지 않습니다. 그러나 특히 전통적인 환경에서는 셰프 솔로에게 분명하고 언급되지 않은 장점이 있습니다. 클라우드에 배포되었다고해서 반드시 동적 환경이있는 것은 아닙니다. 예를 들어, 소프트웨어의 새 버전을 공개하지 않고 시스템에 노드를 더 추가 할 수 없다면 동적이지 않을 수 있습니다. 마지막으로, CMDB는 높은 수준의 관점에서 팀 간 계정 및 정보 공유와 같은 시스템 관리 및 구성과 접하는 것과 관련된 모든 항목에 유용 할 수 있습니다. chef-server를 사용하면 해당 기능만으로도 가치가 있습니다.


chef-solo와 함께 중요한 데이터 (예 : 개인 키 / 암호)를 어떻게 저장 / 배포 하시겠습니까? 일반 텍스트로 저장하지 않고 수정본 제어로 추적하려면 어떻게합니까?
Limbo Peng

@LimboPeng Chef 저장소에 암호화 된 데이터 백을 저장할 수 있습니다. 그래도 암호화 키를 외부에 저장해야합니다.
Willie Wheeler

27

공개 : Opscode에서 일합니다.

솔로에 비해 Chef Server의 주요 이점은 인프라에서 검색을 사용할 수 있다는 것입니다. 전형적인 예는 웹 서버가있는로드 밸런서입니다. 웹 서버가 인프라에 추가 및 제거 되기만하면로드 밸런서는 구성을 자동으로 업데이트하여 검색 할 수 있습니다. 솔로 (Solo)는 단일 머신이지만 Chef Server는 "4 기가 넘는 RAM을 가진 모든 머신"또는 "데이터베이스 마스터"와 같은 것을 쿼리 할 수있는 기능을 제공합니다.

Chef Server는 또한 tarball을 복사하지 않고 인프라를 관리하고, 관리 콘솔을 사용하여 인프라를 시각화하고, 환경이있는 어떤 버전의 요리 책을 실행중인 기계를 관리 할 수있는 기능을 제공합니다. 다른 이점이 있지만, 이것이 내 머리 꼭대기에있는 것입니다. Chef Server를 설치하지 않고 시험해보고 싶다면 Opscode Hosted Chef 계정에 가입하면 처음 5 개의 노드는 무료입니다.


1
고마워요, 그 정보는 TON에 도움이됩니다. Chef 서버를 사용할 때 DevOps 철학을 어떻게 수용 할 수 있는지 알고 있습니까? 이것이 의미하는 것은 모든 요리 책이 SCM에 살고 있다는 것입니다. 새로운 코드를 제공 할 때 Chef 서버가 요리 책을 업데이트 할 수있는 쉬운 방법이 있습니까?
linusthe3rd

2
@ strife25 당신은해야 확실히 버전 제어 시스템에 요리 책이있다. 관심이 없다면 Opscode는 분산 된 팀을 위해 가지와 암석을 다루기 쉽기 때문에 Git을 권장합니다. Cookbook을 Chef 서버에 업로드하는 커밋 후 후크를 작성할 수 있습니다. API를 통해 업로드하기 때문에 Chef 서버에서 요리 책을 복제하는 것이 아니라 의도적으로 의도 된 것입니다.
jtimberman

1

chef-server는 노드의 요리 책 및 구성 데이터를 관리합니다.

나이프 도구를 사용하여 요리사 서버에 요리 책을 추가 한 다음 각 노드에 요리법 목록을 제공하여 요리사가 클라이언트를 사용하여 노드를 설정할 때 필요한 요리 책을 가져옵니다. 요리사 클라이언트는 백그라운드에서 실행되므로 요리사 서버에 업데이트 된 요리 책이 있는지 노드가 정기적으로 점검합니다.

chef-server는 구성 데이터 및 변수도 보유하므로 노드의 설정을 자동으로 픽업하도록 변경할 수 있습니다. 레시피에서 하드 코딩해서는 안되는 하드 다이내믹 설정에 좋습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.