David, os nós não existem antes do bootstrap ser executado. A Orchestra configura o cobbler para instalar os nós a partir do zero e, em seguida, iniciar o juju. Isso é feito para que os encantos de juju implantados possam começar com um sistema básico e limpo. Tem sido discutido que podemos querer facilitar o controle de uma máquina existente com juju, mas agora não é assim que funciona.
bootstrap juju basicamente faz isso com a orquestra:
- Fala com o cobbler através da API XML-RPC, encontra um sistema marcado para boot PXE que está na 'available-mgmt-class', injeta dados para instalar o juju na primeira inicialização e o move para o 'mgmt adquirido' -classe'. Em seguida, usa a infra-estrutura de energia, se definida, para ligar a máquina. Esta máquina será o "nó de bootstrap" que executa o zookeeper e o agente de provisionamento. Incluído nos dados iniciais da "primeira inicialização" está a chave pública SSH do usuário para instalar no usuário 'ubuntu' para que os clientes juju possam falar com o nó de inicialização através de um túnel ssh.
- Armazena um objeto no armazenamento de arquivos (geralmente um serviço ssl webdav no orchestra-provisioning-server) que informa futuros clientes juju que o ambiente é autoinicializado e como entrar em contato com o nó de autoinicialização.
Observe que você pode substituir o caminho das chaves autorizadas do ssh a ser usado. Ele normalmente usa ~ / .ssh / id_rsa.pub ou ~ / .ssh / id_dsa.pub. Você também pode configurá-lo com 'authorized-keys-path' em environments.yaml. Você também pode inserir chaves reais para substituir tudo isso com 'chaves autorizadas'.