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.
.chefpasta para usar variáveis de ambiente ou algo assim?