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

Question

Estou procurando ideias sobre o gerenciamento de versões de livros de receitas de chef. Eu sei que você fixa versões específicas no ambiente, mas não sei como fazer isso.

Nós usamos o bibliotecário-chefe, que instala livros da comunidade de terceiros na pasta de livros de receitas. Nós 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 nossos livros personalizados dependem e, em seguida, definir as versões do livro de receitas na configuração do ambiente, mas o problema é que esses livros da comunidade poderiam contar com outros livros sem versões especificadas. E essa dependência profunda aninhada poderia continuar.

Portanto, não há garantia de que, quando você envia um livro de receitas para o servidor do chef, ele não vai quebrar o incentivo, pois os livros de culinária dependentes também podem mudar.

A única solução que posso ver no momento é especificar cada versão do livro de receitas que usamos na configuração do ambiente, incluindo a comunidade e as personalizadas. Mas então eu tenho que passar por cada livro de receitas e descobrir essas versões.

Também fazemos atualização de bibliotecário-chefe 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.

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

    

Answer 1

Não demorou muito para que eu começasse a usar o Chef com sinceridade para enfrentar esses mesmos problemas. Eu só cheguei a algum senso de sanidade quando comecei a fazer quatro coisas operacionalmente. Note que estes podem não ser considerados "melhores práticas" por alguns na comunidade Chef. No entanto, foi assim que trouxe a sanidade, a repetibilidade e a ordem para o meu mundo.

1. Crie suas próprias receitas. Parei de usar os livros de culinária da comunidade e simplesmente criei minhas próprias receitas, de acordo com minhas especificações. Desta forma eu gerencio e controlo minhas próprias dependências. Muitos argumentariam contra isso, mas honestamente - se eu tivesse lido primeiro algumas receitas do Opscode e da comunidade, eu provavelmente não teria escolhido o Chef como minha solução para começar. Eu mantenho minhas receitas simples, e de acordo com o meu jeito de trabalhar. Eu tenho precisamente zero livros de receitas comunitárias no meu repositório.
2. Seja disciplinado sobre atualizações. Se eu atualizar uma receita, asseguro que ela funcione em todos os lugares e passei pelo incômodo extra de implantá-la em todos os lugares, mesmo que isso atrapalhe o fluxo de trabalho e adicione atrito. A longo prazo, esta é 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, então eu os codifico no livro de receitas. Mas minha filosofia é que a versão mais recente de todos os livros de culinária deve ser aplicada com segurança em todos os lugares em que são necessários.
3. Use o Chef Solo para tudo. A cada poucos meses, de alguma forma eu coloco em minha cabeça que eu deveria tentar usar o Chef Server novamente. A edição da comunidade está melhorando, mas todo o paradigma parece nunca se encaixar no meu mundo. E toda vez que eu tento, eu facepalm e me chuto. O paradigma do Chef Server é adequado para um mundo com servidores de longa duração que precisam de mudanças freqüentes nos sistemas. Eu faço alterações de sistemas tão raramente que ter meus servidores constantemente check-in para um servidor de chef para atualizações é apenas bobo. E eu tenho ferramentas muito melhores para garantir que meus hosts sejam 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 de configuração. Eu agora uso exclusivamente o Solo do Chef e empurro as alterações para os meus hosts, além de empurrar exatamente os mesmos livros de receitas para todos os hosts que precisam deles.
4. Evite compilar o software durante a execução do Chef. O caso mais extremo (isto é, estúpido) para mim envolveu a compilação do ruby-1.9.3 a partir da fonte toda vez que inicializei uma nova caixa. Mas a criação de pacotes personalizados pode ser uma dor na bunda. Uma vez que eu descobri a excelente ferramenta fpm , tornou-se trivial empacotar meus próprios rpms, debs e gems e tornei minha vida muito mais eficiente e fácil.

Espero que isso ajude alguém!

- ATUALIZAÇÃO -

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

5. USE ANSEÍVEL EM VEZ

Answer 2

Existem 2 problemas:

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

O artigo Essenciais das versões do livro de receitas é o melhor referência para versões de livro de receitas. De acordo com o número 1, você está certo, porque é difícil gerenciar versões diferentes de livros de receitas para servir a diferentes configurações, especialmente se misturadas a dependências de livros de culinária onde a maioria dos livros de culinária do site não o faz bem. Então a configuração pode quebrar. e se você não gerenciasse as versões testando o comportamento do tempo de execução de qualquer componente, ele simplesmente quebra. Portanto, é uma má ideia enviar o 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. Eu geralmente gerencio o objeto do ambiente no SCM e não fiz o upload para o servidor do chef por meio de um trabalho automatizado até que o livro de receitas modificado funcione bem com outros componentes existentes.

De acordo com o item 2, trata-se de um assunto complicado, porque é onde a dependência real da receita funciona em cada nó. Em suma, 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ós / funções. Eu dificilmente faço isso porque é bom controle de granulação e custa mais em testes / promoção. No entanto, para o papel / nó crítico, isso não é uma má ideia, mas fornece seguro em alterações de configuração.