Melhor estratégia para manter as versões dos livros de receitas do chef sob controle

Estou procurando idéias sobre gerenciamento de versões de livros de receitas do chef. Eu sei que você fixa versões específicas no ambiente, mas não sei ao certo como fazê-lo.

Usamos o bibliotecário-chef, que instala livros comunitários de terceiros na pasta de livros de receitas. Nunca tocamos nesses livros e apenas atualizamos para versões mais recentes de tempos em tempos.

Também temos nossos livros de receitas personalizados específicos do site, de onde incluímos os da comunidade ( include_recipe).

Teoricamente, poderíamos especificar versões específicas dos livros da comunidade dos quais dependem os livros personalizados e, em seguida, definir as versões do livro de receitas na configuração do ambiente, mas o problema é que esses livros da comunidade podem confiar em outros livros sem versões especificadas. E essa profunda dependência aninhada poderia continuar.

Portanto, não há garantia de que, quando você fizer o upload de um livro de receitas no servidor do chef, ele não funcionará, pois os livros de receitas dependentes também podem mudar.

A única solução que posso ver no momento é especificar todas as versões de livros de receitas que usamos na configuração do ambiente, incluindo as comunitárias e as personalizadas. Mas então eu tenho que percorrer cada livro de receitas e descobrir essas versões.

Também fazemos atualizações bibliotecárias-chefes de vez em quando e imagino que pode ser difícil rastrear versões que mudaram e não esquecer de atualizar a versão no ambiente quando chegar a hora.

Compartilhe sua experiência e melhores práticas. Tenho certeza que será super útil para outras pessoas.

Não demorou muito tempo depois que eu comecei a usar o Chef a sério, eu estava enfrentando esses mesmos problemas. Eu só tive um senso de sanidade quando comecei a fazer quatro coisas operacionalmente. Observe que algumas podem não ser consideradas "práticas recomendadas" por alguns membros da comunidade Chef. No entanto, foi assim que trouxe sanidade, repetibilidade e ordem ao meu mundo.

1. Crie suas próprias receitas. Parei de usar os livros de receitas da comunidade e simplesmente criei minhas próprias receitas, de acordo com minhas especificações. Dessa forma, gerencio e controlo minhas próprias dependências. Muitos argumentariam contra isso, mas honestamente - se eu tivesse lido primeiro algumas das receitas da Opscode e da comunidade, provavelmente não teria escolhido o Chef como minha solução para começar. Eu mantenho minhas receitas simples e alinhadas com minha maneira de trabalhar. Eu tenho exatamente zero livros de receitas da comunidade no meu repositório.
2. Seja disciplinado sobre atualizações. Se eu atualizar uma receita, garanto que ela funcione em todos os lugares e passei pelo trabalho extra de implantá-la em qualquer lugar, mesmo que isso atrapalhe o meu fluxo de trabalho e adicione atrito. A longo prazo, essa é a chave para a sanidade do chef. Em casos extremos, se eu precisar de variações para alguns hosts, como um ambiente de teste versus produção, codificarei-os no livro de receitas. Mas minha filosofia é que a versão mais recente de todo livro de receitas possa ser aplicada com segurança em todos os lugares que forem necessários.
3. Use o Chef Solo para tudo. A cada poucos meses, de alguma forma, entendo que devo tentar usar o Chef Server novamente. A edição da comunidade está melhorando, mas o paradigma inteiro nunca parece se encaixar no meu mundo. E toda vez que eu tento, eu enfrento e me chuto. O paradigma Chef Server é adequado para um mundo com servidores de longa duração que precisam de mudanças frequentes nos sistemas. Eu faço alterações nos sistemas tão raramente que fazer com que meus servidores façam check-in constantemente em um servidor chef para atualizações é apenas uma tolice. E eu tenho ferramentas muito melhores para garantir que meus hosts estejam saudáveis. Meu trabalho está em um mundo de máquinas virtuais descartáveis, onde elas podem sobreviver apenas a uma ou duas alterações na configuração. Agora uso exclusivamente o Chef Solo e envio alterações aos meus hosts, além de enviar exatamente os mesmos livros de receitas a todos os hosts que precisam deles.
4. Evite compilar software durante as execuções do Chef. O caso mais extremo (ou seja, estúpido) para mim envolveu a compilação do ruby-1.9.3 a partir da fonte toda vez que eu inicializava uma nova caixa. Mas a criação de pacotes personalizados geralmente pode ser um problema. Depois que descobri o excelente fpm da ferramenta , tornou-se trivial empacotar meus próprios rpms, debs e gemas e tornou minha vida muito mais eficiente e fácil.

Espero que isso ajude alguém!

- ATUALIZAÇÃO -

Quase três anos depois, esses princípios continuaram sendo úteis para mim. Mas vou acrescentar mais um conselho, e é realmente pelas mesmas razões que preferi chef-solo do que chef.

5. USE ANSIBLE EM VEZ

Existem 2 problemas:

1. gerenciar versões de livros de receitas em diferentes objetos do ambiente
2. gerenciar a versão da receita no nó run_list.

O artigo Fundamentos das versões do livro de receitasé a melhor referência para versões de livros de receitas. De acordo com o nº 1, você está certo porque é um trabalho difícil gerenciar versões diferentes de livros de culinária para atender a diferentes conjuntos de configurações, especialmente misturado com dependências de livros de receitas, onde a maioria do livro de receitas do site de livros de culinária não faz esse trabalho bem. Portanto, a configuração pode quebrar. e se você não gerenciou as versões testando o comportamento em tempo de execução de qualquer componente, ele apenas quebra. Portanto, é uma má idéia fazer upload do livro de receitas sem especificar o número da versão no seu objeto de ambiente. Portanto, gerencie as versões do livro de receitas no objeto de ambiente e teste cuidadosamente ao promover a versão de qualquer novo livro de receitas. Normalmente, eu gerencio o objeto de ambiente no SCM e não carreguei no servidor chef por meio de trabalho automatizado até que o livro de receitas alterado possa funcionar bem com o restante de outro componente existente.

De acordo com o item 2, é um tópico complicado porque é aqui que a dependência real da receita funciona em cada nó. Em poucas palavras, para nós críticos, é melhor controlar a dependência de receitas especificando a versão da receita na lista de execução de nó / função. Eu dificilmente faço isso porque é bom controle de grão e custa mais em teste / promoção. No entanto, para função / nó crítico, isso não é uma má idéia, mas fornece seguro para alterações na configuração.