Infraestrutura como código e TDD


11

A infraestrutura como código nos diz para usar ferramentas que automatizam suas construções. Ótimo. Ferramentas como ansible , chef , fantoche , pilha de sal e outras nos levam a escrever como é a infraestrutura, enquanto resolve as diferenças.

No Salt Stack, esses bits são chamados estados . Se o estado não corresponder à realidade, a ferramenta resolverá isso para nós. Em outras palavras - estamos escrevendo um teste para nossa infraestrutura e, se o teste falhar, a ferramenta irá corrigi-lo por conta própria. Pelo menos essa é a ideia.

O XP nos ensina a usar TDD e a questão é se é aplicável à infraestrutura? As ferramentas sugerem que é.

Eu posso imaginar alguns tipos de testes que podem ser muito úteis.

Escrevemos testes de fumaça fornecidos com o serviço implantado para garantir que o serviço implantado de ponta a ponta funcione e seja executado conforme o esperado. Seria uma chamada à API ou / e verificação systemctl para garantir que o que acabamos de implantar funciona. Muitas dessas funcionalidades podem ser abordadas nos mesmos estados, pois ferramentas como ansible têm estados para garantir que um serviço esteja sendo executado.

Existe o projeto Molecule que permite executar funções individuais (como a ansible chama seus estados) no docker ou em outro mecanismo de virtualização temporário. Isso força a dissociação de funções e permite executá-las isoladamente do manual enquanto trabalha nelas. Os testes permitem principalmente zombar das variáveis ​​com as quais a função deve trabalhar. Outros exemplos parecem uma duplicação do mecanismo ansible (afirme que um arquivo pertence a um usuário ...).

ThoughtWorks radar tecnologia agora elogia ferramentas como Inspec , serverspec ou Goss para validar se o servidor atende a especificação. Mas estamos escrevendo uma especificação, não estamos?

Portanto, existe um ponto em mais infraestrutura de teste se estivermos descrevendo infraestrutura em estados / funções? Eu poderia suspeitar que isso se torna mais necessário em organizações maiores, onde uma equipe fornece as especificações e outras a seguir, ou se houver um grande conjunto de funções, talvez você queira executar um subconjunto dessas e obter um benefício rápido com os testes? Estou lutando para ver por que você escreveria um teste se pudesse ter um papel / estado para a mesma pergunta em mente.

Respostas:


6

Em resumo, vejo duas categorias de testes para sua infraestrutura: 1) ele possui tudo o que você precisa para executar seu aplicativo e 2) não possui nenhum material supérfluo?

Em primeiro lugar, você pode tratar o conjunto de testes do seu software real como uma espécie de "meta-teste" para sua infraestrutura. Desde que você crie a infraestrutura do zero para cada execução de teste e o conjunto de testes seja executado completamente nessa infraestrutura (ou seja, não use serviços externos), o fato de todo o conjunto ser ecológico significa que sua infraestrutura codificada também é suficiente .

Segundo, especialmente da perspectiva de segurança, você pode escrever testes em sua infraestrutura. Ou seja, se uma parte de sua infraestrutura for uma VM executando Linux, você poderá escrever um teste que faça uma varredura de porta nessa VM, para garantir que não haja portas não intencionais abertas, que podem ter sido instaladas por um apt-get installefeito colateral não intencional . Ou você pode escrever testes para verificar se algum arquivo inesperado foi alterado após a conclusão do seu conjunto de testes apropriado. Ou você pode verificar as pssaídas de seus contêineres de VMs ou Docker quanto a processos inesperados e criar listas brancas, etc.

Esse segundo tipo de teste é, de certa forma, semelhante ao que você faria em uma configuração de operações clássica de qualquer maneira, ou seja, fortalece seus servidores e verifica se há invasões, evitando recursos completos e outras coisas.


Então, depois de algum tempo, essa é exatamente a posição que tomei. As partes executadas pelo ansible não são testadas por si só, mas os efeitos colaterais dessas ações são testados usando goss. Por exemplo, por exemplo, o RPM é instalado (ansible) e testado se o arquivo padrão esperado for colocado no lugar ou se o serviço estiver sendo executado e escutando uma porta específica. Não quero corrigir esse problema automaticamente, mas ser notificado e interromper o progresso. Claro Ansible pode testar o sistema para você também, você só precisa ser explícito sobre isso, mas no nosso caso, utilizamos gosspara testar o comportamento de serviço dentro de um recipiente
JackLeo

1

IMHO é bastante redundante escrever testes TDD para itens totalmente cobertos pela especificação de estado IaaC. Fazer isso implica que a eficácia do IaaC é questionável - por que você o usaria?

Analisá-lo a partir de um IaaC prospectivo diferente (se / quando feito corretamente) incorpora recursos já testados e considerados funcionando de maneira confiável. Qual é o que o torna atraente e o que torna redundante a escrita dos testes de correspondência TDD.

Por exemplo, uma configuração IaaC que especifica um sistema com o SSH sendo instalado já incorpora uma verificação confiável para a instalação correta do SSH e, se não, mecanismos para instalá-lo corretamente. O que faz um teste TDD para verificar se o SSH está instalado redundante. Se a sua configuração IaaC também especificar que o sshd seja iniciado e escutando em uma porta específica, os testes TDD para execução do sshd e escuta a porta respectiva também serão redundantes.

Observe que minha resposta não está direcionada ao TDD ou a qualquer outro tipo de teste que verifique se a sua configuração IaaC como um todo se encaixa em um determinado objetivo. Isso permanece válido e pode ser usado em TDD, CI ou verificações semelhantes durante o desenvolvimento dessa especificação IaaC - acredito que a resposta do @ AnoE seja aplicável nesse caso.


Você aplica o mesmo raciocínio para garantir que o SSH (ou qualquer outra coisa) esteja ativado em uma porta personalizada específica, analisada a partir de um arquivo de configuração externo? Isso não está nas unidades testadas, é uma lógica nova.
precisa

1
Ele deve fazer parte do IaaC, se for compatível. Caso contrário, essa discussão não se aplica realmente. Sim, isso pode indicar quanto material pode ser coberto pelo IaaC, mas essa é uma discussão diferente.
Dan Cornilescu

1
Também estou assumindo que não estamos em um contexto em que verificações redundantes são necessárias - em alguns casos, verificações redundantes seguindo caminhos de código completamente diferentes ou até infraestrutura pode ser necessária.
Dan Cornilescu

1

Parece que todos aqui assumem que uma ferramenta IAC sempre é executada conforme o esperado, mas posso dizer (por experiência própria) que esse nem sempre é o caso, caso contrário, o teste de unidade seria realmente inútil.

Lembro-me de uma imagem que dizia: "Ansible playbook correu, está tudo bem" com um prédio queimando ao fundo ...

Executar um estado declarativo e ter o servidor nesse estado declarado real são duas coisas diferentes do meu ponto de vista e experiência, pelo menos.

Um ambiente amplo e heterogêneo, espalhado por vários controladores de domínio, alcançável por rede pública, etc ... Há várias razões pelas quais um estado não pode ser aplicado, total ou parcialmente.

Por todos esses motivos, há espaço para o teste de unidade, permitindo obter uma captura instantânea do estado real do servidor, que, novamente, pode diferir do estado pretendido.

Então, eu diria que sim, os testes de unidade são úteis mesmo em um ambiente gerenciado pelo IAC.

EDITAR

E o lado da não regressão da ramificação dev da base de código IaC? então você faria alterações no seu código no ramo dev e o mesclaria no ramo prod esperando não quebrar tudo? teste de unidade são tão valiosos e geralmente simples de implementar, não vejo por que alguém codificaria sem esse recurso.

Referência (em francês, desculpe por isso): https://fr.slideshare.net/logilab/testinfra-pyconfr-2017


1
Seria pelo menos educado adicionar algum comentário com uma votação antecipada, você não acha que votou? Especialmente neste tipo de pergunta em que o debate pode ser muito informativo ou mesmo construtivo.
Pier

Suponho que o tom da sua resposta, que é bastante agressivo para todos que interagiram com essa pergunta, seja adicionado ao fato de que você não está dando nenhuma referência a seu exemplo, nem descrevendo qualquer mau funcionamento observado, foi a razão do desautor. Você finalmente está dizendo a mesma coisa que outras respostas dizem, faça testes de fumaça em seu sistema de provisionamento para garantir que o sistema esteja bom, o que a maioria dos sistemas falha ao não conseguir convergir o sistema no estado desejado. No que diz respeito a sua edição, geralmente a fusão é feita após a implantação para estadiamento e garantindo os testes de fumo passar ...
Tensibai

Definitivamente não pretendia ser agressivo, não estou usando minha linguagem nativa aqui (isso é óbvio, eu acho :)).
Pier

Podemos discuti-lo no DevOps Chat, se desejar, acho que vi essa apresentação ou algo parecido em um evento do devoxx alguns anos atrás. Eu discordo um pouco de chamar esse teste de unidade, são testes mais funcionais.
Tensibai 22/03

Alguém da minha equipe de desenvolvimento me disse o mesmo que este não era um teste de unidade, eu não sou desenvolvedor, por isso posso estar errado em chamar esse teste de unidade, definitivamente #
222 Pier Pier

1

Na minha experiência, uma das principais diferenças entre Dev e Ops são "dependências de tempo de execução pesado". A instalação de pacotes depende muito de repositórios, redes ou chaves válidas, ou seja, instanciando um novo servidor em nuvem - depende dos recursos do seu provedor.

Em termos de provisionamento de servidor, mesmo que você não tenha alterado seu código de provisionamento, sua imagem será válida na maioria das vezes, mas às vezes não. Então eu acho que o teste é realmente essencial para fornecer imagens de trabalho.

Se você for além de servidores únicos, as coisas pioram ainda mais ... como você testará a acessibilidade em configurações de rede inteiras? Incluindo resolução DNS, roteamento e firewall? Mesmo que sua API de provedores de IaaC funcione conforme o esperado (vi problemas com fio nessa área), eu realmente gosto de TDD nesse caso.

Como não encontrei nenhuma ferramenta de teste nessa área, escrevemos uma em nosso tempo livre: https://github.com/DomainDrivenArchitecture/dda-serverspec-crate

Então, acho que o TDD é realmente importante no mundo do DevOps!

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.