Provisionamento de Juju e Openstack

4

Sou novo no Juju e no Openstack e atualmente estou implementando o ambiente de teste openstack de dois e três nós usando o provedor manual Juju. Na minha primeira tentativa, tentei implantar serviços em meus hosts usando --to-key para implementar o juju.

Eu percebi que algo está errado quando o Juju não conseguiu criar uma relação entre o Keystone e o MySQL implementado no mesmo host. Para implantar serviços, usei a seguinte sintaxe:

juju deploy keystone --to 1   
juju deploy mysql --to 1

Alguns googling me deram esta pergunta no askubuntu e este guia .

Então, pelo que entendi, a maneira correta de implantar serviços em ambiente manual é usar contêineres lxc para serviços que estão sendo implantados no mesmo host (se esses serviços puderem funcionar em contêineres, é claro).

Embora eu veja essas vantagens do lxc como independência e isolamento de serviços, ainda não entendo porque os serviços implementados pelo Juju DEVEM ser isolados em contêineres. É uma falha no design do Juju ou uma solução temporária?

Existe alguma maneira de implantar alguns serviços no mesmo host sem lxc?

Eu acho que isso pode ser feito especificando o arquivo de configuração para cada serviço que está sendo implantado, mas isso eliminaria quase toda a "mágica" e simplicidade do Juju ...

    
por J'' 04.08.2014 / 13:05

1 resposta

4

O próprio Juju não se importa. Cabe aos feitiços que você implanta lidar com a situação ou não. Então isso não é realmente tratado como um problema; é apenas uma diferença entre o que o Juju suporta, o que o charme normalmente suporta e a melhor prática aceita.

Eu não acho que essa resposta seja específica para o provedor do manual. Aplica-se a todos os fornecedores.

A maioria dos charms assume que eles "possuem" a máquina (ou container) para a qual eles são implantados e, no passado, essa era a única maneira de implementá-los.

Esse isolamento facilita o desenvolvimento e o teste de charms. Elimina a necessidade de os desenvolvedores de charme se preocuparem com o compartilhamento de recursos com outros encantos. Uma implantação modular facilita o gerenciamento da complexidade. Ao limitar as interações entre os encantos e as relações de Juju, elas podem permanecer limpas e bem compreendidas. Os autores de charms não precisam se preocupar em fazer alterações de nível de "sistema" que possam afetar adversamente outros charms; cabe à contêiner para lidar com isso corretamente. Isso elimina toda uma classe de bugs de charme, onde um feitiço afeta negativamente o outro.

Assim, na prática, os charms devem ser implantados em seus próprios contêineres, no mínimo, a menos que sejam especificamente projetados para funcionar em conjunto. Conflitos que surgem quando dois charms são implantados na mesma máquina sem colocá-los em contêineres geralmente não serão tratados como bugs.

Isso não deve afetar muito. LXC é leve.

Nada disso impede que você escreva seus próprios charms ou modifique os charms existentes para permitir que eles sejam implantados na mesma máquina ou container. Juju vai permitir, mas cabe então aos encantos garantir que eles não entrem em conflito.

  

É uma falha no design do Juju ou uma solução temporária?

Não - não é realmente uma coisa do Juju; Essa é a melhor prática escolhida entre os autores de charme e está relacionada às decisões tomadas sobre quais configurações de implantação os charms devem ou não devem suportar.

Existem alguns casos em que é útil e não é difícil de suportar (por exemplo, a GUI Juju em execução no nó de inicialização), portanto, o Juju permite isso. Eu acredito que não há planos para o apoio de Juju mudar.

    
por Robie Basak 06.08.2014 / 18:05