Chef Server vs Chef Solo [duplicado]

Question

Estou montando uma estrutura para executar um aplicativo Rails. O aplicativo em si é executado em Heroku. No entanto, ele faz solicitações para um cluster, que executa a chamada por meio de um programa em C.

Para poder recuperar de falhas mais rapidamente, quero criar uma rotina usando o Chef. Eu consegui escrever um "livro de receitas" que instala tudo que você precisa, e funciona perfeitamente quando eu uso uma máquina virtual Vagrant.

No entanto, quando eu solicito um servidor real, ele falha. Além disso, estou usando o Chef Solo e preciso instalar manualmente algumas coisas na máquina antes de executar o script, o que não é muito prático.

Eu não sei se devo levar o Chef Server neste caso. Receio que seja uma "excelente" ferramenta para uma "pequena" necessidade.

Este cluster é composto de apenas três máquinas, isso não deve aumentar muito. No entanto, o aplicativo também faz solicitações para outro cluster um pouco maior (6 máquinas), que, apesar de serem muito rápidas de instalar, também podem fazer uso do Chef Server.

Deve ir com o Chef ou o Chef Solo Server? Existe algum guia didático sobre isso? A documentação do desenvolvedor é muito confusa.

    

Answer 1

Essa pergunta parece subjetiva, mas tentarei abordar essa resposta objetivamente.

O Chef Server fornece um sistema de publicação e um índice de pesquisa com uma API RESTful.

Isso significa que você pode:

1. Distribua livros de receitas para nós por meio de um único local que tenha uma API, e primitivos para criar restrições de versão, recuperação, todas as coisas que você provavelmente esperaria de um sistema de publicação.

2. Armazene dados (atributos) sobre os nós que você está gerenciando. Quer seja um ou mil, você pode obter informações sobre os nós diretamente por meio da API. Você também pode usá-lo para dizer aos nós que executem receitas diferentes.

3. Armazene informações arbitrárias sobre sua infraestrutura no que o Opscode chama de "bolsas de dados". Essa é qualquer informação de que você goste, como informações do usuário, informações do aplicativo ou qualquer outra coisa que você possa imaginar sobre sua infraestrutura.

4. Consulte o servidor para obter informações sobre nós, "quais são os servidores Web em produção?"

Como isso difere do Chef Solo? Que bom que você perguntou!

Com o Chef Solo, você precisa obter os livros de culinária, os atributos do nó, os sacos de dados, etc, para os nós. Isso significa publicá-los em algum lugar que vários nós possam obtê-los ou rsync / scp em um repositório para cada nó gerenciado. Não há armazenamento centralizado dos dados do nó e nenhum índice de pesquisa para nenhum deles.

No começo, tudo é muito pequeno e fácil de distribuir. Entre 1, 3 ou até 5 nós isso geralmente não é um problema. Mas a maioria das pessoas se encontra com alguns problemas.

• "Com certeza seria bom ter uma maneira de enviar os livros de receitas para os nós com mais facilidade"
• "Cara, toda vez que atualizamos um livro de receitas, a produção cai porque não queríamos que a mudança fosse feita lá"
• "Como podemos reunir todos os dados do nó em um lugar e consultá-los?"

A lista continua. O que acontece é que muitas pessoas não querem "administrar um servidor de chef", então eles criam seus próprios repositórios, servidores http e similares.

O caso de uso do qual você está falando (aproximadamente 5 nós) é o alvo do plano "5 node free" do Opscode Hosted Chef, então você não precisa gerenciar um sistema especial para ser seu Chef Server, pelo menos para veja se é algo que funcionará para sua infraestrutura. Você pode continuar a crescer em planos pagos maiores ou mover seus dados (facilmente através da API) para o seu próprio Chef Server no futuro.