Gomex: TDD para código de infraestrutura? Acho que não…

Após iniciar um texto sobre a importância de testes automatizados para código de definição de infraestrutura, refleti sobre o uso de TDD nesses casos e cheguei a uma conclusão um pouco polêmica.

Queria deixar claro que esse texto é propositivo e aberto a mudança de opiniões com base nas interações. Meu objetivo é iniciar esse debate, apresentado as minhas conclusões sobre esse assunto e assim  possamos juntos concluir algo coletivamente sobre isso.

Antes de pular para conclusão, vamos primeira contextualizar o que é TDD. De acordo com o nosso “nerd alfa” Martin Fowler:

“Test-Driven Development (TDD) é uma técnica para construção de software que o processo de desenvolvimento através da escrita de testes.”

De acordo com esse artigo, é uma prática que força o desenvolvedor a pensar sobre seu código antes de ele escrever ele e que TDD é muito mais sobre design do que teste. (Dica do Luis, no comentário).

Em essência você segue dois simples passos repetidamente:

• Escreva um teste para validar a funcionalidade que precisa adicionar
  • Exemplo: Quero uma função para somar dois números, eu escrevo um teste que a soma de 2 + 2 o resultado seja sempre 4. Qualquer resultado diferente desse indica que a função está errada
• Escreva de forma imperativa o código até ele passe nos testes
  • Exemplo: Você escreve o código que recebe dois número como parâmetros e soma.

Seguindo essa lógica é fácil pensar que seria ideal isso acontecer também para infraestrutura, certo? Não necessariamente.

Código de infra geralmente é descritivo e não imperativo

Nos exemplos demonstrados acima, temos, a partir de um único teste, uma grande gama de possibilidade de implementação da função a ser testada, ou seja, para um teste de soma de dois números, o código resultante para satisfazer essa validação pode variar bastante.

Desenvolvimento de software normalmente utiliza o modelo imperativo de construção, ou seja, você precisa dizer detalhadamente de que forma ,o que você deseja, seja feito. O código de infraestrutura regularmente segue uma outra linha, que é a descritiva. Você apenas precisa dizer o que deseja e não precisa implementar como isso será executado.

Comparação entre código imperativo e descritivo

Porque não TDD

Levando em consideração que um dos motivadores do TDD seja o auxilio na construção da lógica por trás da solução do teste em questão e no modelo descritivo a lógica é algo raro, fazer um teste para cada definição de infraestrutura me parece um trabalho desnecessário, já que o código de teste seria bem parecido com o usado para atender o teste.

Exemplo:

Quero criar o usuário elmo e o teste seria criado da seguinte maneira com o serverspec

describe user('elmo') do
 it { should exist }
end

O código de infraestrutura para atende o teste acima seria:

user { 'elmo':
    ensure => present,
}

Você há de concordar que esse teste nunca falharia, uma vez que não precisei de nenhuma lógica aqui. Sem falar que eles são bem parecidos na sua escrita, ou seja, no final de contas seria um grande desperdício de tempo.

E se meu código tiver lógica, faz sentido TDD?

Tecnicamente falando, sim, mas na prática nem toda definição terá lógica e ter isso como metodologia de desenvolvimento talvez atrapalhe mais do que gere algum valor para seu processo de desenvolvimento.

Isso quer dizer que não devo ter teste no meu código?

Claro que não! Testes automatizados são bem importantes para a confiança do seu código. Não vou me aprofundar nas razões de ser fazer teste, pois isso foi bem explicado aqui.

Atualização pós comentários

Depois de uma boa interação nos comentários, vale a pena deixar claro algumas coisas que talvez tenham ficado meio solta no artigo e adicionar outras que faltaram no texto ou estavam de forma incorreta.

TDD somente com teste unitário?

A ideia que é TDD seja orientado a teste unitário não foi proposital, mas no caso de teste de infraestrutura esqueci de comentar que testes de integração e outros mais complexos demandam interação com uma infraestrutura provisionada, ou seja, o feedback é bem lento, o que inviabiliza (em minha opinião) o trabalho orientado a teste.

É importante que você crie seu ambiente “do zero” a cada teste, para que você garanta que não tem dado de outro teste ou alguma modificação fora da definição no ambiente. Com isso em mente, é comum encontrar situações que podem demorar até 30 minutos para reconstruir o ambiente, aplicar as definições e então executar os testes.

Se você for utilizar testes de integração ou outros mais complexos pra guiar seu processo de desenvolvimento, ter esse tempo de espera a cada interação “Red-Green-Refactor” seria complicado para o processo de escrita de código.

Mundo Docker: Docker 1.13 – O que vem por ai

Eai gente!

Você que é leitor do blog já está acostumado a ver por aqui as principais novidades sobre o Docker e tecnologia associadas, e hoje não será diferente. Queremos trazer uma preview sobre as novas features que serão lançadas na versão 1.13 do Docker, como todos os sabem, o ciclo de desenvolvimento dentro do Docker é algo fora da curva, e a cada nova versão alguma novidade aparece, é possível acompanhar esse ritmo pelo próprio github deles.

Mas se você não quiser esperar a versão estável para brincar com as novidades, pode utilizar a versão experimental do Docker, que obviamente não é recomendado para se colocar em produção, mas que pode ser usada para lab sem problema. Para isso, basta você instalar o Docker com o seguinte comando: curl -sS https://experimental.docker.com | sh, com isso você terá acesso a engine com as modificações mais atuais mas em fase de desenvolvimento ainda.

Bom, chega de papo, vamos a uma pequenas lista das novidades do Docker 1.13:

Docker stack

Para quem usa docker-compose ou docker service sabe das diferenças entre essas duas “ferramentas”, e como de certa foram eles deveriam se complementar, não é mesmo? E Essa é uma situação que vinha sendo trabalhada pelos engenheiros do Docker a algum tempo, essa função intermediária vinha sendo testada através do comando docker stack que possibilita criar um serviço dentro do swarm baseado em uma estrutura do docker-compose, ou seja, você conseguirá portar para o cluster de swarm um serviço baseado no docker-compose, isso facilita em muito a administração de seu serviço e claro no deploy do mesmo, pois garante que o serviço esteja rodando independente do nó onde ele está.

Nas versões de teste você tinha que gerar um arquivo .dab (distributed application bundle ou pacote de aplicação distribuída) baseado em seu docker-compose.yml e depois sim você conseguiria fazer deploy dessa stack utilizando o docker. Agora no docker 1.13 isso não é mais necessário, basta você chamar o arquivo docker-compose.yml diretamente no deploy da stack, algo como isso:

# docker stack deploy --compose-file ./docker-compose.yml minhastack

Muito mais simples e rápido não?

Gerenciamento de senha

Ou gerenciamento de segredos, essa é uma função básica dentro de qualquer orquestrator, o Kubernetes já possuía esse conceito e aplicação á algum tempo já, e agora o docker também implementa essa funcionalidade.
Mas afinal, onde vou usar isso? Sua aplicação usa senha não usa? Seja para banco, API, etc, qualquer aplicação usa senha de acesso a algum serviço em algum momento, e com você faz hoje com Docker? Provavelmente via variável de ambiente ou compartilhando um arquivo com o container, existem outras formas, como ferramentas as a service de gerenciamento de identidade.

Agora no docker 1.13 você pode definir uma secret que pode ser utilizada pelo seu serviço dentro do swarm, exatamente da mesma forma que o Kubernetes usa. Para isso foram adicionados quatro comandos novos, são eles:

• docker secret create
• docker secret inspect
• docker secret ls
• docker secret rm

Veja um exemplo de como criar uma secret para ser utilizada dentro de seu serviço

# echo "123456" | docker secret create senha-banco

Agora um exemplo de como utilizar essa secret em seu serviço:

# docker service create --name app --secret senha-banco ubuntu

Dentro do container será criado um arquivo em /run/secrets/senha-banco com a informação da senha, isso é claro apenas dentro do container, sem precisar mapear nada do host para o container.

# docker exec -it app cat /run/secrets/senha-banco
123456

Um detalhe muito importante é: As secrets podem ser utilizadas apenas dentro de serviços, se você criar um container com o docker run, vão não poderá utilizar essa funcionalidade.

Novo parâmetro de rede no Swarm

Essa talvez seja uma das melhorias mais importante no core do docker, pois permite que você adicione uma rede do Swarm mesmo se o container for criado fora de um serviço, ou seja, criado da forma tradicional com o docker run.... Mas afinal, por que isso é importante? É importante porque agora é possível adicionar um container a mesma rede do serviço criado no Swarm, isso é muito útil para debugs ou até mesmo testes de ambiente.

E como fica agora então? Simples, veja:

# docker network create --driver overlay --attachable rede-plugavel

Com o comando acima nós criamos uma rede overlay do Swarm, e a diferença agora é o parâmetro –attachable, que permite que essa rede seja plugada em qualquer container criado, e no comando abaixo nós plugamos um container a essa rede:

# docker run --rm -it --net rede-plugavel centos ping google.com

Plugins

Finalmente alguns plugins que estavam sendo testados e aprimorados foram disponibilizados como estáveis dentro da engine do Docker. Dentre ele podemos destacar o Flocker e o Weave, que agora tem integração total com docker.

Docker Daemon –experimental

Até então para você poder utilizar comandos e opções em desenvolvimento/teste do docker, você teria que instalar a versão experimental ou test da engine, mas agora basta você iniciar o daemon do docker com a opção –experimental, com isso será habilitado em momento de execução as opções da versão experimental, veja:

Melhorias no docker service

Essas, na verdade, são algumas das melhorias que a comunidade pediu ao longo do meses, uma delas tem relação com o update da imagem no update do serviço, para quem não notou, quando um serviço é atualizado (até então) você precisava executar um update com alguns parâmetros a mais para poder atualizar o serviço com uma nova imagem, na nova versão esse processo pode ser feito passando o parâmetro –force junto, o docker service update já verificará se há uma versão mais recente da imagem e atualizará o serviço baseado nisso.

Novo parâmetro no docker service

Além das melhorias no docker service, foi acrescentado também um novo parâmetro. Hoje nós acessamos um serviço através da porta exposta do mesmo, que você pode definir com o parâmetro –publish, no docker 1.13 será possível você definir de forma mais detalhada essa regra, isso deve-se ao novo parâmetro –port, que, da mesma forma que o –mout, tem sintaxe parecida com csv, onde você define item=valor,item=valor… Veja um exemplo:

# docker service create --name servico_web --port mode=ingress,target=80,published=8080,protocol=tcp

Dessa forma você tem, de forma mais clara, as definições de porta do serviço.

Outras novidades

Dentre outras novidades do docker 1.13 podemos destacar ainda algumas que tem bastante relevância para quem o utiliza, como por exemplo:

• Cache de Layer para o Build: Para que gera muitas imagens, sabe que esse era um problema a ser resolvido, exemplo: geramos um imagem agora com o docker build, caso tenha que modificar essa imagem todas as layers anteriores a alteração não eram buildadas novamente, o docker build usava o cache para elas. Agora digamos que mandamos essa imagem para outro host e queremos fazer outra modificação nela, o que ocorre? Exatamente, todas as layers são buildadas novamente, isso pelo fato do docker não ter naquele host o cache de build dessa imagem. Parece ser trivial, mas quando se quer ganhar tempo, não é. No docker 1.13 você pode especificar na hora do build de onde o docker poderá buscar o cache de build, como por exemplo:

  docker pull imagem:v1.0
  docker build --cache-from imagem:v1.0 -t imagem2:v1.1 .
  

  Dessa forma o build da nova imagem utilizará o cache da imagem original, compilando assim apenas as layers diferentes.

• A instrução MAINTAINER  foi removida do Dockerfile, agora essa informação deve ser utilizada através de label;
• Foi adicionado um novo comando, ainda experimental, que é o docker service logs para visualizar os logs do serviço e não do container em si.
• Outra adição do docker service foi o parâmetro –rollback que tem por objetivo realizar o update do serviço através de uma versão anterior a atual;
• Remoção de container velhos através do docker system (ainda não há mais informações sobre como esse comando funcionará para remoção de containers antigos, então ficamos ligados no lançamento)

Ok Cristiano, e quando será lançada? Não há uma data 100% definida, o que se sabe é que será lançada até inicio de Janeiro de 2017, então pode ser que seja lançada hoje mesmo . Pode haver mais modificações? Claro, sempre há e com certeza as novidades que trouxemos hoje serão melhor explicadas após o lançamento oficial, então o jeito é ficar ligado aqui no blog e claro no site do ofiical do docker.

Grande abraço!