Eu trabalho com vários projetos, então a solução da cjc não funciona para mim. Há também uma questão de configuração comum vs personalizada (endereços etc são comuns para a empresa, há também um pouco de mágica nas configurações). O esquema que eu finalmente decidi é um pouco complicado, mas é conveniente.
Em vez do global ~/.chef , eu uso o subdiretório '.chef' dentro do chef-repo, que não é armazenado no git (ele é adicionado ao .gitignore ). Eu também tenho arquivo config/knife.rb arquivo 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.rb contendo configuração personalizada (na versão básica é apenas OPSCODE_USER='username' constante que é usada mais tarde, mas pode conter qualquer configuração de faca) e .chef/knife-secrets.rb que contém segredos compartilhados (chaves AWS etc) .
Abaixo disso, há uma configuração de faca regular que usa constantes definidas nesses arquivos, por exemplo:
client_key "#{root_dir}/.chef/#{OPSCODE_USER}.pem"
Dessa forma, eu obtenho a padronização da configuração de faca em toda a empresa, o que, por sua vez, significa que qualquer fragmento de código ou chamada de faca compartilhada em um wiki funcionará para todos. Há bastante confusão e magia na própria faca - configurações diferentes só tornariam isso pior. Além disso, todos se beneficiam de pequenos snippets mágicos, como este para fazer com que knife ssh use login configurado no usuário ~/.ssh/config
Há também problemas de segredos compartilhados: a chave de validação do servidor do chef, as chaves da AWS armazenadas em knife-secrets.rb , a chave privada do EC2 do SSH, as chaves de pacote de dados criptografadas e assim por diante. Nós definitivamente não queremos que eles sejam armazenados no repositório - ou, na verdade, em qualquer lugar onde eles não sejam criptografados com segurança. Portanto, distribuímos esses arquivos como um arquivo .tar.gz , que é criptografado por GPG para todos na empresa e compartilhados pelo Dropbox.
Configurar tudo isso está ficando complicado, e eu quero que pessoas em equipe realmente usem a coisa, então há o elemento final: rake init task que cria .chef directory, symlinks config/knife.rb there, descriptografa e untars chef-secrets.tgz file, certifica-se de que a chave privada do Opscode Platform do usuário está lá e .chef/knife-local.rb está configurada corretamente, com plug-ins de faca symlinks e define as permissões adequadas no diretório e nos arquivos internos. Essa 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 repaga todos os segredos, criptografa o tarball para todos e o copia para a caixa de depósito, para facilitar a adição de novos funcionários ou a alteração de segredos.
Em relação a vários ambientes: o Chef tem um recurso chamado ambientes . Eu não usei ainda, mas deve fazer o que você precisa. Você também pode separar estritamente o ambiente de produção (para evitar que os desenvolvedores tenham quaisquer chaves que se relacionem de alguma forma ao env de produção) tendo duas organizações Hosted Chef separadas ou servidores Chef. Este snippet knife.rb mostra como configurar a faca de maneira diferente com base em atualmente check-out branch - você pode usar isso para definir o ambiente, bem como url do servidor chef. Há também o plugin de faca chamado fluxo de facas , fornecendo um fluxo de trabalho de duas organizações mais completo.