Como o Juju “coexiste” com o Chef, levando o processo de automação “um passo adiante”?

Question

Está claro de este post que Juju senta em uma camada diferente do que o Chef Server. Juju está na camada de orquestração ou serviço , enquanto o Chef se senta mais no servidor individual ou na camada configuração .

Em uma das principais páginas de Juju da Canonical , afirma-se que Juju foi projetado para "coexistir" com ferramentas como Chef e Puppet, levando o processo "um passo adiante". Eu vasculhei a internet nas últimas semanas sobre este assunto e não consigo encontrar uma boa explicação de como , no entanto, uma ferramenta como o Chef irá coexistir com o Juju.

Então, para dividir a questão abrangente no título: (interesse particular em Juju trabalhando em conjunto com um Chef Server)

• Qual é o exemplo de um encanto "escrito em Chef"? É simplesmente um charme escrito no bash que chama o comando chef-solo ? Se sim, um charme pode chamar o comando chef-client para trabalhar em conjunto com um Chef Server?
• Onde está a sobreposição entre Juju e Chef? Por exemplo, o charme apache2 tem seu config-changed hook, onde faz alterações de configuração que, no mundo do Chef, ocorreriam em uma receita aplicando um arquivo de modelo. Se um charme de Juju funcionasse junto com um livro de receitas do Chef na implantação de um serviço apache2 (cluster), quase pareceria que um charme "apache2-chef" teria que ser escrito para que você pudesse separar as tarefas. Nesse caso, o charme do apache2 na Charm Store não seria nada útil.
• Se você tiver funções Chef aplicadas a nós (unidades de serviço) implantadas / gerenciadas pelo Juju e seu sysadmin decidir alterar as regras de firewall para uma função de servidor específica e fizer isso na função de Chef, a Juju nunca irá sobrescrever essas mudanças?
• Mais simplesmente, o Juju pode ser um wrapper do Chef Server, como o Ironfan ?

Eu vejo o Chef Server como o como enquanto o Juju pode fazer o como , mas também traz o que para a tabela. Isso significa que o estado atual real de serviços e máquinas pode ser consultado e resolvido. Você não pode fazer isso no Chef Server. Meu objetivo é trazer a consciência de Juju e a capacidade de orquestração de serviços para uma infra-estrutura gerenciada pelo Chef Server.

Parece quase que um conjunto inteiro de charms teria que ser escrito onde todas as tarefas / informações de configuração gerenciadas pelo Chef são deixadas de fora.

Eu adoraria ouvir pesagens de alguém da Canonical (como o Jorge Castro) e da Opscode (como A. Jacob ou J. Timberman).

    

Answer 1

perguntas incríveis!

o tl; dr

Eu gostaria de quebrar sua (s) pergunta (s) em alguns comentários ... primeiro, aqui está um par de abordagens gerais para integrar chef e juju:

• os ganchos de encantos podem usar receitas de chef existentes que executam o estilo de solo em serviço unidades (recomendado)

• unidades de serviço juju registram-se em um chef-servidor existente usando um subordinado chef-node serviço

Estas ideias ainda não foram implementadas / testadas para o chef, mas o fantoche equivalentes existem.

a ... uma resposta não tão curta

Aqui está um pouco mais de um desdobramento de duas abordagens para integrar o chef e o juju:

Juju como o melhor cão

Aqui juju comanda o show. O maior valor que o juju oferece é a coordenação de eventos durante o gerenciamento de configuração distribuída ... daí o "serviço orquestração "moniker. Juju encantos consistem em ganchos que são chamados por juju no "momento certo" ao coordenar o gerenciamento de serviços. A implementação desses ganchos é praticamente aberto. Eles são scripts de shell, código-fonte, fantoche manifesta, ou ... receitas de chef.

O Juju divide os bits de qualquer configuração de serviço em:

• "instalação" .. os bits que são específicos para instalar um determinado serviço em um nó

• "relation" .. os bits de configuração que são necessários para relacionar esse serviço a alguns outro serviço

A chave para usar receitas de chef como implementações de gancho é exatamente isso ... você tem que se certificar de que as receitas que você está usando respeitam esta separação de preocupações. Caso contrário, não há nada que impeça o uso off-the-shelf livros de culinária. Você pode aproveitar as receitas existentes que você gastou tempo / dinheiro para desenvolver ... Você só precisa se certificar de que você pode chamar o material específico da relação separadamente o material específico da instalação.

Precisamos de alguns exemplos disso, mas acho que vai ser popular b / c chef tem um ótimo dsl, uma ótima ferramenta de templates, e é muito mais agradável de usar do que o bash ao escrever configuração complexa. Para configuração simples, as receitas do chef são um pouco overkill imo, então este método de integração é praticamente o melhor de ambos mundos ... e tem pernas sérias daqui para frente.

Chef como top-dog

A ideia aqui é integrar os serviços de juju em um servidor de chef existente infra-estrutura gerenciada. Para fazer isso, você precisa escrever um nó chef encanto subordinado. Este serviço subordinado seria anexado ao juju principal serviços e registrar efetivamente esses serviços como nós (em particular funções) com o servidor do chef. Subs pode ser anexado durante a inicialização do serviço juju, ou mais tarde, ao longo do ciclo de vida de cada serviço.

Estou pensando que isso seria bem parecido com o sub-nó dos fantoches. Tudo necessário chaves, papéis, etc seriam especificados via config para o subordinado chef-node charme. Eu começaria lá. Uma abordagem mais sofisticada seria para o sub nó chef-in para interrogar tanto o serviço principal é anexado ao e sua chef-servidor para determinar dinamicamente os papéis, mas isso seria um pouco mais difícil que apenas especificando-os em config para o sub.

Opiniões

Eu definitivamente recomendaria o método 1 acima, se possível. Ter a camada de coordenação no topo das ferramentas de configuração provavelmente funcionará bem a longo prazo. Escusado será dizer que infra-estruturas do mundo real podem ser uma combinação ou variação de ambas as abordagens por um período de tempo ... especialmente durante a migração. A coexistência planejada usando o método 2 provavelmente só funcionaria se os componentes gerenciados por ambas as ferramentas fossem um pouco ortogonais entre si. Não sei exatamente como isso seria. Talvez juju e chef administrem serviços separados e relativamente separados? Eu suspeito que pode funcionar bem para deixar o juju gerenciar serviços primários e ter o chef gerenciando mais aspectos de infraestrutura. Não sei. Isso é um pouco mais de discussão:)

Nota lateral ... você também pode usar o juju para gerenciar o próprio chef-servidor ... mesmo grande complexas instalações chef-server multi-tier. Eu não olhei para o charme chef-servidor ultimamente, mas se ele não lida atualmente com camadas e separação de serviços, então certamente pode ser feito para.

Adoraria ver mais exemplos dos dois tipos de integração de chef mencionados acima ... tem estado na minha lista de desejos por um tempo, mas ainda tem que borbulhar alto o suficiente em prioridade para ser feito ... por favor ajude se você estiver interessado!

ok, esse é um pedaço decente de divagações:) ... vamos começar por aí, então podemos entrar em mais detalhes nos próximos blocos de comentários.