Gerenciar livros de receitas do chef em um ambiente de equipe

Estou aprendendo chef e tendo problemas para estruturar tudo para trabalhar com minha equipe.

Para iniciantes, parece que você deve criar uma pasta chef-repo, onde armazenará e modificará os livros de receitas usados ​​para gerenciar seus nós.

Eu trabalho em vários projetos, e cada um deles já está sob o controle da fonte git. Idealmente, eu manteria uma pasta de repo chef em cada um dos meus projetos com os livros de receitas dos projetos, certo?

No entanto, na pasta chef-repo, tenho que adicionar uma pasta de configuração (.chef) com minha configuração de faca e minhas validações-chave, e estas são específicas para mim. É normal adicionar a pasta .chef ao arquivo gitignore?

Entendo que os livros de receitas são carregados no servidor do chef para serem implantados. Como as outras equipes separam a preparação dos ambientes de produção sem duplicar muito trabalho? Temos um ramo principal que é nosso ramo de produção, um ramo de desenvolvimento que é nosso ramo intermediário (recebe menos de 5% das solicitações do site) e ramos de recursos. Na maioria das vezes, o ramo dev, quando estável, é mesclado ao ramo mestre. Como podemos fazer upload dos livros de culinária separadamente para podermos ter dois ambientes de maneira separada?

Obrigado pela ajuda!

Como trabalho com vários projetos, a solução da cjc não funciona para mim. Há também um problema de configuração comum versus personalizada (endereços etc são comuns à empresa, também há um pouco de mágica nas configurações). O esquema em que finalmente decidi é um pouco complicado, mas é conveniente de usar.

Em vez de global ~/.chef, eu uso o subdiretório '.chef' no chef-repo, que não é armazenado no git (é adicionado a .gitignore). Eu também tenho um config/knife.rbarquivo que é verificado no Git e contém configuração compartilhada. Começa com este trecho:

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

Isso carrega arquivos .chef/knife-local.rbcontendo configuração personalizada (na versão básica, é apenas OPSCODE_USER='username'constante que é usada posteriormente, mas pode conter qualquer configuração de faca) e .chef/knife-secrets.rbque contém segredos compartilhados (chaves da AWS, etc.).

Abaixo disso, há uma configuração regular de faca que usa constantes definidas nesses arquivos, por exemplo:

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

Dessa maneira, eu alcanço a padronização da configuração da faca em toda a empresa, o que significa que qualquer trecho de código ou chamada de faca compartilhada em um wiki funcionará para todos. Existe bastante confusão e mágica na própria faca - configurações diferentes apenas piorariam. Além disso, todo mundo se beneficia de pequenos trechos mágicos, como este, para knife sshusar o login configurado no usuário~/.ssh/config

Há também a questão dos segredos compartilhados: chave de validação do servidor chef, chaves da AWS armazenadas knife-secrets.rb, chave privada SSH do EC2, chaves criptografadas do saco de dados e assim por diante. Definitivamente, não queremos que eles sejam armazenados no repositório - ou, na verdade, em qualquer lugar onde não sejam criptografados com segurança. Por isso, distribuímos esses arquivos como um .tar.gzarquivo, criptografado em GPG para todos na empresa e compartilhado no Dropbox.

A configuração de tudo isso está ficando complicada, e quero que as pessoas da equipe usem realmente a coisa, então há o elemento final: rake inittarefa que cria .chefdiretório, links simbólicos config/knife.rb, descriptografa e descompacta o chef-secrets.tgzarquivo, garante que a chave privada Opscode Platform do usuário esteja lá e .chef/knife-local.rbesteja adequadamente configurado, vincula os plug-ins de faca e define as permissões apropriadas no diretório e nos arquivos. Esta tarefa é configurada para que seja seguro executá-la várias vezes no repositório já inicializado (por exemplo, para atualizar segredos ou plug-ins de faca).

Há também uma tarefa auxiliar que repete todos os segredos, criptografa o tarball para todos e copia-o no dropbox, para facilitar a adição de novos funcionários ou a alteração de segredos.

Em relação a vários ambientes: o Chef possui um recurso chamado ambientes . Ainda não o usei, mas deve fazer o que você precisa. Você também pode separar estritamente o ambiente de produção (para evitar que os desenvolvedores tenham chaves relacionadas de alguma forma ao ambiente de produção), tendo duas organizações Hosted Chef ou servidores Chef separados. Este trecho do knife.rb mostra como configurar o faca de uma maneira diferente, com base na ramificação atualmente registrada - você pode usá-lo para definir o ambiente e o URL do servidor do chef. Há também um plugin de faca chamado fluxo de faca , fornecendo um fluxo de trabalho mais completo e com duas organizações.

Você precisa configurar dois servidores Chef, um para produção e outro para desenvolvimento. O motivo é que nenhum servidor Chef pode suportar desenvolvimento ramificado; mesmo com ambientes.

Ou você pode abandonar o conceito de servidor Chef e usar chef-solo. Você pode manter seus livros de receitas no Git. Você pode ramificar e mesclar. Você pode ignorar os problemas com credenciais de faca porque não os usará mais.

Você não poderá usar a pesquisa por faca ou os sacos de dados **. Mas algumas pessoas não precisam desses recursos de qualquer maneira.

** Bem, você pode: http://wiki.opscode.com/display/chef/Data+Bags#DataBags-UsingDataBagswithChefSolo

Tenho dois diretórios em minha casa, .chef e chef-repo. O chef-repo está no git. O .chef é um diretório privado que é o padrão para o knife. Você não precisa colocar seus segredos de .chef em git; faca procurará ~ / .chef.

Seu diretório ~ / .chef não deve estar no repositório git.

Eu tenho um diretório ~ / projects / no qual mantenho meu repo de chef. Aqui estão as configurações dos meus servidores.

Meu último trabalho foi como engenheiro de sistemas na loja Ruby-on-Rails. Nossas configurações de nginx, verniz e rails (entre outras) vão para o repositório de chefs, mas os próprios aplicativos Rails foram mantidos em repositórios git separados e foram implementados separadamente.

Nosso ambiente de armazenamento temporário era um único servidor que executava todo o ambiente de armazenamento temporário. Isso não era ideal porque não se parecia com a Produção, onde o Rails e o DB estavam em caixas separadas. O que eu recomendaria é usar os ambientes do chef para separar a preparação e a produção. (Foi assim que cheguei lá e simplesmente não tenho tempo para consertar isso antes de sair.)