Esta é a versão em texto da performance 2018-04-25 no Saint-Petersburg Linux User Group . Exemplo de código aqui: https://github.com/ultral/ansible-role-testing

Eu acredito que você está usando gerenciamento de configuração, não bash . I.e. sua configuração é código. Se dissermos que infraestrutura é código, a mesma filosofia deve ser aplicada à sua criação e ao desenvolvimento de software. Você já pensou sobre isso? Como você faz isso? E outros?

Pré-requisitos

No caso descrito, havia muitos casos introdutórios:

• Muitos papéis ansíveis.
• Hyper-V como o hypervisor principal.
• Nuvem privada com recursos limitados para criar máquinas virtuais em tempo real.
• Proxy para acesso à Internet.
• A incapacidade de executar o teste de funções ansible na janela de encaixe, porque a função é a configuração de toda a VM, incluindo configurações de rede, por exemplo.
• Desejo usar a política do assistente verde para um repositório com funções possíveis.

Antes de fazermos o que fazemos, comparamos as soluções existentes.

Decidimos não reinventar a roda e adotar uma solução chave na mão. Nossa equipe de infraestrutura conhece o ruby, por isso a Test Kitchen & inspec foi escolhida

Kitchen-ci

A ideia é feia e simples. Criamos uma nova máquina virtual, usamos a função, executamos testes de fumaça.

Política de construção verde

Mas decidimos seguir em frente. Use o ala github flow, ou seja, papéis em brunches individuais e após a revisão de merjim no mestre. Se os testes estiverem corretos, rolamos as funções para a infraestrutura.

Virtualização aninhada

Como você se lembra, tínhamos restrições à criação de máquinas virtuais, portanto tivemos que tomar uma decisão desagradável na forma de virtualização aninhada.

Inicialmente, tentamos o Virtualbox x32 para não incluir suporte aninhado. Isso acabou não sendo muito idéias, devido à estabilidade do pânico do kernel. O segundo fator importante é que estamos sentados no x86_64, então a pesquisa continuou (oi libvirt), mas se instalou no virtualbox como mais comum no SO suportado.

Dificuldades

Durante o lançamento, tudo foi bom e teve várias dificuldades.

Ignorar configurações de proxy do host para o convidado

Em alguns cenários de teste, configurações de proxy foram usadas, enquanto no host com testkitchen um proxy transparente foi usado e o bônus ansible não aceitou variáveis ​​extras com valores vazios.

Solução: brega - crie um modelo de ERB.

<%= ENV['http_proxy'].to_s.empty? ? 'http://proxy.example.com:3128' : ENV['http_proxy'] %> 

Gerenciamento de configurações de rede através do ansible

Em algumas funções, a rede foi configurada; em testes, ficou assim:

• Configuramos a rede copiando o arquivo.
• Aplique as configurações de rede.
• Tudo está ruim.

Solução: adicione uma interface à máquina virtual

Se o conjunto de testes contiver "_", tudo cai

O Virtualbox não pode usar "_" no nome da máquina virtual. E a máquina virtual usou o nome do script.

Solução: renomeie os conjuntos de testes "vm_" => "vm-"

Testar casos com a instalação do Oracle sem "." no final do nome da máquina virtual cair

O papel foi usado em vendas condicionadas quando eles decidiram cobri-lo com testes. Quando você o enrola em uma VM preparada, ele cumpre a função e passa pelo teste da cozinha.

Pequena dica

 [root@vm-oracle vagrant]# getent ahosts vm-oracle 127.0.0.1 STREAM vm-oracle 127.0.0.1 DGRAM 127.0.0.1 RAW [root@vm-oracle vagrant]# getent ahosts vm-oracle. fe80::a00:27ff:febd:bd6a STREAM vm-oracle fe80::a00:27ff:febd:bd6a DGRAM fe80::a00:27ff:febd:bd6a RAW 10.0.2.15 STREAM 10.0.2.15 DGRAM 10.0.2.15 RAW [root@oracle vagrant]# getent ahosts oracle.example.com. 192.168.128.182 STREAM oracle.example.local 192.168.128.182 DGRAM 192.168.128.182 RAW 

Alguma idéia do que está acontecendo?

Foi um cenário divertido:

1. Ativamos a ligação IPv4 apenas nas configurações do ouvinte do oracle.
2. O oracle usa o FQDN.
3. O linux contém uma base especial "myhostname" para resolver nomes de domínio, foi usada após os servidores / etc / hosts & dns.
4. O Vagrant cria VM e atualizações /etc/hosts .

Vou explicar um pouco:
O que acontece no caso de vm-oracle ?

1. O vagrant cria uma máquina virtual.
2. atualizações vagrantes /etc/hosts ( vm-oracle x2)
3. o ouvinte da oracle ouve o IPv4.
4. os ouvintes da oracle resolvem o nome de domínio vm-oracle. e obtém o IPv6.
5. FALHOU

O que acontece no caso de vm-oracle. ?

1. O vagrant cria uma máquina virtual.
2. atualizações vagrantes / etc / hosts ( vm-oracle e vm-oracle. ).
3. o ouvinte da oracle ouve o IPv4.
4. os ouvintes da oracle resolvem o nome de domínio vm-oracle. e obtém IPv4
5. Ok

OOM vem nos visitar

OOM matou aleatoriamente máquinas virtuais. Ao mesmo tempo, Testkitchen transmitia todo tipo de mensagens estranhas em seus registros.

Solução: Aumente a quantidade de memória.

Construções lentas

Todo esse esquema funcionou devagar, por dezenas de minutos, às vezes mais de uma hora.

Soluções:

• Packer . Pré-montar imagens de máquinas virtuais.
• Execute vários casos de teste em paralelo

Conclusão

Se dissermos que infraestrutura é código, a mesma filosofia deve ser aplicada à sua criação e ao desenvolvimento de software. Por um lado, temos uma solução funcional, mas há alguns momentos desagradáveis:

• Não é amigável, tudo parece.
• Uma mistura de rubi e python.
• Não há verificações e funções de função.
• Funciona devagar.
• Difícil ....

Na saída, a molécula com docker parece interessante e mais nativa. Nós estamos pensando sobre isso.

Referências

• Versão em inglês
• Slides de desempenho
• Exemplo de código
• http://kitchen.ci/
• https://github.com/chef/kitchen-inspec
• https://docs.chef.io/config_yml_kitchen.html
• https://docs.chef.io/ctl_kitchen.html
• https://github.com/neillturner/kitchen-ansible/blob/master/provisioner_options.md