팀 환경에서 요리사 요리 책 관리

요리사를 배우고 팀과 함께 일할 모든 것을 구성하는 데 문제가 있습니다.

우선, 당신은 당신의 노드를 관리하는 데 사용되는 요리 책을 저장하고 수정할 chef-repo 폴더를 만들어야합니다.

나는 다양한 프로젝트를 수행하고 있으며, 각 프로젝트는 이미 git source control하에 있습니다. 이상적으로는 해당 프로젝트 요리 책과 함께 각 프로젝트마다 하나의 chef-repo 폴더를 유지합니까?

그러나 chef-repo 폴더에서 나이프 구성 및 주요 유효성 검사와 함께 구성 폴더 (.chef)를 추가해야하며 이는 나에게 고유합니다. .chef 폴더를 gitignore 파일에 추가하는 것이 정상입니까?

요리 책이 요리사 서버에 업로드되어 배포되는 것을 알고 있습니다. 다른 팀이 많은 작업을 복제하지 않고 스테이징을 프로덕션 환경과 어떻게 분리합니까? 우리는 프로덕션 브랜치 인 마스터 브랜치, 준비 브랜치 (웹 사이트 요청의 5 % 미만 수신) 인 피브먼트 브랜치 및 기능 브랜치를 보유하고 있습니다. 대부분의 경우 안정된 dev 분기는 마스터 분기에 병합됩니다. 요리 책을 따로 업로드하여 두 가지 환경을 별도의 방법으로 가질 수있는 방법은 무엇입니까?

도와 주셔서 감사합니다!

여러 프로젝트로 작업하므로 cjc의 솔루션이 작동하지 않습니다. 일반적인 구성과 사용자 정의 구성의 문제도 있습니다 (주소 등은 회사에 공통적이며 구성에는 약간의 마술이 있습니다). 마지막으로 정한 계획은 약간의 해킹이지만 사용하기 편리합니다.

global 대신 ~/.chefchef-repo 내에서 '.chef'하위 디렉토리를 사용합니다.이 디렉토리는 git에 저장되지 않습니다 (에 추가됨 .gitignore). config/knife.rbGit에 체크인되어 공유 구성이 포함 된 파일 도 있습니다. 이 스 니펫으로 시작합니다.

root_dir = File.join(File.dirname(__FILE__), '..')
%w(knife-secrets.rb knife-local.rb).each do |conf_name|
  conf = File.join(root_dir, ".chef", conf_name)
  Kernel::load(conf) if File.exists? conf
end

이것은 .chef/knife-local.rb사용자 정의 구성을 포함하는 파일 (기본 버전에서는 OPSCODE_USER='username'나중에 사용되는 상수이지만 나이프 구성을 포함 할 수 있음)과 .chef/knife-secrets.rb공유 비밀 (AWS 키 등)을 포함 하는 파일 을 로드합니다 .

그 아래에는 이러한 파일에 정의 된 상수를 사용하는 일반 나이프 구성이 있습니다. 예 :

client_key               "#{root_dir}/.chef/#{OPSCODE_USER}.pem"

이렇게하면 회사 전체에서 나이프 구성의 표준화를 달성 할 수 있습니다. 이는 위키에서 공유되는 모든 코드 스 니펫 또는 나이프 호출이 모든 사람에게 효과적이라는 것을 의미합니다. 나이프 자체에는 혼란과 마법이 충분합니다. 구성이 다르면 상황이 더 나빠질뿐입니다. 또한 모든 사람이 사용자의 로그인 정보를 구성 하기 위해이 작은 스 니펫 을 knife ssh이용할 수 있습니다.~/.ssh/config

셰어 서버의 유효성 검사 키,에 저장된 AWS 키 knife-secrets.rb, EC2의 SSH 개인 키, 암호화 된 데이터 백 키 등 의 공유 비밀 문제도 있습니다 . 우리는 그것들이 저장소에 저장되는 것을 원하지 않으며, 실제로 안전하게 암호화되지 않은 어느 곳에서나 저장되기를 원하지 않습니다. 따라서 이러한 파일을 파일로 배포합니다.이 파일 .tar.gz은 회사의 모든 사람에게 GPG로 암호화되어 Dropbox를 통해 공유됩니다.

이 모든 것을 구성하는 것은 복잡해지고 팀의 사람들이 실제로 그 일을 사용하기를 원하므로 최종 요소가 있습니다 : 디렉토리 rake init를 만드는 작업 .chef, config/knife.rb거기에서 심볼릭 링크 , chef-secrets.tgz파일의 암호 해독 및 untars , 사용자의 개인 Opscode 플랫폼 키가 있고 .chef/knife-local.rb올바르게 있는지 확인하십시오 구성, symlinks 나이프 플러그인, 디렉토리 및 내부 파일에 대한 적절한 권한을 설정합니다. 이 작업은 이미 초기화 된 저장소에서 여러 번 실행하는 것이 안전하도록 설정되어 있습니다 (예 : 비밀 또는 나이프 플러그인 업데이트).

또한 모든 비밀을 재 포장하고 타르볼을 모든 사람에게 암호화 한 다음 보관함에 복사하여 새로운 직원을 추가하거나 비밀을 변경하는 도우미 작업도 있습니다.

여러 환경 관련 : Chef에는 environment 라는 기능이 있습니다 . 아직 사용하지는 않았지만 필요한 작업을 수행해야합니다. 또한 별도의 Hosted Chef 조직이나 Chef 서버를 두어 프로덕션 환경과 엄격하게 분리 할 수 ​​있습니다 (개발자가 프로덕션 환경과 관련된 키를 갖는 개발자를 피하기 위해). 이 knife.rb 스 니펫 은 현재 체크 아웃 된 분기를 기반으로 다른 방식으로 나이프를 구성하는 방법을 보여줍니다.이를 사용하여 요리사 서버의 URL과 환경을 설정할 수 있습니다. 보다 완벽한 2 개 구성 워크 플로우를 제공하는 knife 플러그인이라는 knife 플러그인 도 있습니다 .

프로덕션 서버와 개발 서버를 각각 하나씩 두 개의 Chef 서버를 설정해야합니다. 그 이유는 단일 Chef 서버가 분기 개발을 지원할 수 없기 때문입니다. 심지어 환경에서도.

또는 Chef 서버 개념을 버리고 chef-solo를 사용할 수 있습니다. Git에서 요리 책을 관리 할 수 ​​있습니다. 분기 및 병합 할 수 있습니다. 나이프 자격 증명과 관련된 문제는 더 이상 사용하지 않으므로 무시해도됩니다.

나이프 검색 또는 데이터 백 **을 사용할 수 없습니다. 그러나 어떤 사람들은 어쨌든 그러한 기능이 필요하지 않습니다.

** 잘 정렬 할 수 있습니다 : http://wiki.opscode.com/display/chef/Data+Bags#DataBags-UsingDataBagswithChefSolo

내 집에는 .chef와 chef-repo라는 두 개의 디렉토리가 있습니다. 요리사-레포는 자식입니다. .chef는 knife의 기본값 인 개인 디렉토리입니다. .chef의 비밀을 git에 넣을 필요는 없습니다. 나이프는 ~ / .chef를 찾습니다.

~ / .chef 디렉토리는 git repo에 없어야합니다.

~ / projects / 디렉토리에 요리사 저장소가 있습니다. 여기에서 내 서버의 구성이 진행됩니다.

나의 마지막 직업은 Ruby-on-Rails 상점의 시스템 엔지니어였습니다. 우리의 nginx, varnish 및 rails 구성 (다른 것들 중에서도)은 chef repo에 있지만 Rails 앱 자체는 별도의 git repos에 보관되어 별도로 배포되었습니다.

우리의 스테이징 환경은 전체 스테이징 환경을 실행하는 단일 서버였습니다. Rails가 얇고 DB가 별도의 상자에있는 프로덕션과 유사하지 않기 때문에 이것은 이상적이지 않았습니다. 내가 권장하는 것은 Chef 's Environments를 사용하여 준비 및 프로덕션을 분리하는 것입니다. (그것이 내가 도착했을 때의 상황이며, 나는 떠나기 전에 그것을 고칠 시간이 없었습니다.)