Usando o Juju com implementação de nuvem Openstack privada?

Question

Estou vendo vários problemas ao tentar usar o Juju com nossa nuvem Openstack implantada internamente. A maior parte disso parece estar centrada na resolução do host DNS, bem como na necessidade de lidar com os proxies HTTP internos de nossa empresa.

Nossa implantação do Openstack depende de um bloco de endereços 172.16.0.0/12 não-passível de alocação de VLAN para cada projeto (inquilino) hospedado em nossa nuvem interna. O usuário tem a opção de atribuir um ou mais endereços flutuantes a instâncias alocadas a partir de um bloco de endereços roteáveis na LAN de empresas internas.

Atualmente, o Openstack não registra nomes de instâncias com algo diferente do serviço DNSMASQ em execução no controlador de nuvem. Como tal, não há como resolver esse endereço através de nossa hierarquia de DNS interna (esse problema já foi reportado como Bug # 945505). Dessa forma, mesmo que eu possa inicializar meu nó do servidor Juju, não consigo me conectar a ele com o cliente Juju, já que ele não pode resolver o nome da rede local (privada). Eu sou capaz de ssh para o nó, uma vez que eu tenha atribuído um endereço internamente roteável (ou seja, flutuante). O que leva ao próximo problema.

Em seguida, para instalar o software em uma instância em execução em nossa nuvem, ele deve ter nosso endereço de proxy interno definido - no arquivo apt.conf ou nas variáveis de ambiente. Infelizmente, ao inicializar o nó do servidor, não há nenhuma provisão para passar essa informação para uma instância através do arquivo juJu environment.yaml (se essa for a melhor maneira de lidar com esse problema). Como resultado, o nó de bootstrap não pode instalar os pacotes necessários.

Eu estou supondo (perigoso, eu sei) que a maneira que eu implantei o Openstack em nosso ambiente interno provavelmente não é única. Alguém mais encontrou esses problemas? E o mais importante, o trabalho está disponível?

    

Answer 1

Após a implantação / bootstrapping, o Juju tentará se conectar ao ambiente através do endereço público das instâncias. AFAIK, obtém este endereço diretamente da chamada describe_instance (s) da API do EC2. Em seu ambiente, novas instâncias são geradas com um endereço interno / privado e nenhum IP público (flutuante) associado. O resultado é um endereço privado nos campos de endereço privado e público de describe_instances. Depois de associar um IP flutuante à instância, o campo de endereço público deve agora mostrar o novo endereço associado.

Uma vez associado, o Juju deve se conectar bem via SSH (assim como você pode). Então, você deve ser capaz de 'juju bootstrap', associar IP ao nó de bootstrap, 'juju status'. Você também precisa associar IPs flutuantes a todas as outras máquinas implantadas. Uma opção é adicionar o '--auto_assign_floating_ip' ao nova.conf, para que a associação de IP flutuante ocorra automaticamente no spawn da ocorrência.

Quanto ao problema proxy-to-apt, seria ótimo se o Juju permitisse que os usuários personalizassem o cloud-config que é passado para novos nós para inicializar os agentes Juju. Se fosse possível, você poderia configurar seus proxies apt junto com o cloud-config específico do juju. Como isso não é suportado atualmente, uma opção seria publicar uma imagem de nuvem personalizada no Glance que contenha um apt.conf para o seu ambiente e defina default-image-id em environments.yaml para esse ID de AMI.