Infraestrutura como código e TDD

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.

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.

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.

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

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!