Bom pessoal, agora que nós já aprendemos como escrever testes unitários, nós passaremos para a próxima etapa, que são os testes de integração. Quando nós rodamos os testes de integração, primeiramente o Terraform provisiona todos os nossos recursos. Então, tudo aquilo que nós estamos testando, de fato, será criado, será provisionado lá na nossa infraestrutura. Isso é interessante porque nós podemos fazer algumas validações um pouco mais complexas. Nós temos aqui, por exemplo, o módulo de cluster, onde nós criamos ali, como o próprio nome sugere, um cluster de máquinas virtuais através de um auto-scaling group, e nós criamos, para nós acessarmos essas máquinas virtuais, um application load balancer. Então, dessa forma, nós temos ali o nosso tráfego distribuído entre todas as nossas máquinas virtuais. Uma forma de nós validarmos que isso está funcionando é após o provisionamento nós fazermos uma chamada HTTP utilizando o DNS gerado para esse load balancer e nós verificarmos, na verdade, se nós vamos receber um status code 200. Então, utilizando testes de integração nós podemos fazer isso. Com testes unitários, isso não é possível, porque o Terraform não provisiona os recursos. Ele simplesmente rola o Terraform Plane e faz as validações de acordo com o estado planejado. Beleza? Então, eu já até adiantei aqui o que nós faremos. Nós vamos testar aqui o cluster, mas para isso, nós temos aqui algumas etapas um pouco mais complexas do que o que nós temos nos testes unitários, porque nós temos algumas dependências. Para que a gente consiga provisionar um cluster, nós precisamos primeiro criar uma network, porque nós temos ali alguns parâmetros dentro de cluster, nós podemos inclusive revisar aqui em variables, que são, por exemplo, o ID da nossa VPC e os IDs das nossas subnets e também security groups. Então, essas informações estão vindo lá do nosso módulo de network e é por isso que nós temos que ter aqui uma etapa de setup. Isso é bastante comum quando nós falamos em teste de integração. Geralmente, nós temos um setup e nós temos também uma etapa de loading, de verificação, onde nós temos que utilizar data sources para nós buscarmos alguma informação que foi provisionada lá na nossa infraestrutura, então verificarmos se está funcionando. Provavelmente está um pouco abstrato, está um pouco complexo, mas à medida que nós formos desenvolvendo aqui ficará muito mais claro. Então vamos lá. Uma coisa que eu gostaria de alterar aqui antes de nós, de fato, começarmos com cluster é na nossa parte aqui de testes do network, tá? Do cluster, ou melhor dizendo, do módulo de network. Nós criamos aqui o nosso arquivo unit.tftest.hcl e tudo funcionou perfeitamente, tá? Porém, uma convenção muito comum é nós colocarmos os arquivos de teste dentro de uma pasta de testes, especificamente dentro de cada módulo, tá? Então, nós vamos aqui mover e unir teste aqui para dentro, beleza? E não muda nada, tá? Não muda nada no sentido do fluxo aqui de execução dos nossos testes, porque basta nós navegarmos aqui até o nosso módulo de cluster, tá? Eu vou fazer o export da minha variável de ambiente, beleza? Igual a default. E eu vou executar terraform teste. O que vai acontecer aqui é que o terraform vai identificar os arquivos de teste no próprio diretório, mas também dentro do diretório testes. Então, ele faz isso aí automaticamente, a gente não precisa especificar, tá? Então, os nossos testes, então ele faz isso aí, automaticamente a gente não precisa especificar, tá? Então os nossos testes estão passando, agora eu vou aqui no módulo de cluster, eu vou criar uma nova pasta, que será também a pasta de testes, e nós teremos aqui todos os nossos testes, beleza? Deixa eu só fechar aqui, perfeito, e aqui nós teremos o arquivo que será o arquivo integration, então seguindo até a mesma lógica que nós seguimos, tá, pftest hcl, beleza, temos esse carinha aqui dentro, agora nós precisamos fazer algumas configurações, primeiro a configuração do nosso provider, né, então nós vamos dizer aqui que nós vamos rodar a nossa infraestrutura no AWS US West 2, a nossa infraestrutura no AWS US West 2, assim como nós fizemos para os testes do nosso módulo de network. E além disso, nós vamos criar as variáveis. Porém, aqui nesse cenário, eu vou criar simplesmente uma variável global que será a variável prefix. Somente essa daqui. Por quê? Primeiro, como eu já expliquei, nós precisamos de uma etapa de setup, nós precisamos de uma networkapa de setup, nós precisamos ali de uma network válida para nós criarmos o nosso cluster. Para isso, eu vou criar aqui um bloco run para justamente configurar essa network e eu vou utilizar o próprio módulo de network que nós já criamos. Nós não precisamos criar um outro módulo especificamente para criar uma rede para os nossos testes. Claro que nós poderíamos fazer isso em alguns cenários, nós vamos fazer isso, mas aqui nós não temos essa necessidade. Então, nós teremos aqui o seguinte, nós teremos um bloco run, network, o nosso comando será o comando apply, já que nós estamos falando em testes de integração, e é isso que diferencia um teste unitário de um teste de integração. Para testes unitários nós temos o plain, aqui nós temos o apply, que na verdade é a opção default. Então nós poderíamos até inclusive remover este comando daqui. Agora, para nós referenciarmos o nosso módulo de cluster, nós precisamos utilizar aqui o bloco module. Então eu vou colocar aqui module e vou referenciar sorte como sendo a pasta anterior e network beleza então dessa forma aqui nós estamos dizendo para o terra forma que ele precisa provisionar este módulo específico e aqui vai considerar as variáveis que nós temos definidas neste arquivo com por exemplo prefix mas nós sabemos que nós temos outras variáveis que nós precisamos definir as específicas do nosso módulo de network, que é a parte de CIDER Blocks. Então, nós vamos definir essas variáveis aqui no contexto do bloco run. Por quê? Nós não precisamos expor essas variáveis aqui do lado de fora porque não são todos os blocos que utilizaram essas variáveis. Essas variáveis são específicas do módulo de network, são específicas aqui da nossa parte de setup. Vou colocar aqui como sendo o nosso setup. E beleza, com isso aqui nós já temos o nosso setup pronto, os nossos pré-requisitos já estão todos ok, que é a parte da criação de network. Mas beleza, tendo aqui o nosso módulo de network, a nossa rede, nós podemos também executar verificações, tá? Então, aproveitando que nós já configuramos o nosso network, por que não realizar uma verificação desse módulo e verificar se tudo está correto, tá? Nós, então, teremos um assert aqui, onde nós vamos verificar se de fato foram criadas duas subnets, tá? Então, nós estamos simplesmente fazendo o setup, mas já também testando o módulo de network de forma executar esses blocos na ordem em que eles aparecem no arquivo. Então, é importante que ele seja o primeiro. Beleza. Agora, nós temos o seguinte. Nós precisamos de provisionar o nosso cluster de fato. Então, bem simples, na verdade. Nós teremos um bloco run, onde nós teremos todas as nossas variáveis de acordo com o que o nosso módulo de cluster espera temos aqui o apply novamente e agora eu vou copiar e colar as variáveis porque nós já conhecemos na verdade essas variáveis nós já temos ali nos nossos módulos de desenvolvimento e de produção então eu vou simplesmente colar essas variáveis aqui nós temos o seguinte, nós temos as nossas subnets, que eu estou referenciando a partir de run network subnet IDs. Então, nós temos a possibilidade de referenciar valores expostos por outros blocos run. Então, para você entender, aqui nós temos o provisionamento do módulo de network. E este módulo, ele expõe subnet IDs. Para nós se lembrarmos, nós podemos navegar aqui até network nós temos aqui os nossos outputs e o primeiro output é subnetid e nós estamos referenciando esse cara aqui dentro então estou referenciando run.network foi o identificador que eu coloquei aqui e .subnetid que é o output do módulo que está sendo executado aqui neste bloco run. A mesma coisa para security group IDs e a mesma coisa para vpcid. Então, acho que agora ficou clara a necessidade de nós termos esse setup, esse run de setup. Agora, nós temos o nosso user data e esse user data aqui é bem simples. Nós não estamos criando aquela lógica aqui para mostrar o IP quando o usuário acessar essa máquina, nós estamos simplesmente instalando o Nginx, e quando nós instalamos o Nginx, nós já temos ali por default um arquivo index.html que vai exigir uma mensagem de boas-vindas, mas de fato quando nós fizermos uma chamada HTTP, a nossa conexão será estabelecida, se tudo estiver ok, e nós iremos receber um status code 200 com esse HTML, mas nós não vamos nos importar muito com esse HTML, nós vamos nos importar com status code 200. Além disso, eu coloquei aqui o desired capacity para 1, min size e max size igual a 1, eu não preciso mais de uma máquina virtual aqui, eu vou colocar aqui então essas duas propriedades como sendo 1. Scale in, scale out, eu coloquei as opções que nós deixamos ali, se eu não me engano, na parte de desenvolvimento, tá? Mas poderia ser qualquer valor, desde que sejam valores válidos. E beleza, temos aqui o nosso cluster. E agora nós podemos validar qualquer propriedade dos recursos que nós provisionamos. Eu gostaria de validar somente uma propriedade, que é a propriedade DNSName, onde eu verifico se o DNSName é diferente de nulo. Caso seja igual a nulo, nós vamos exibir invalid DNSName. Eu coloquei essa propriedade especificamente porque ela tem uma particularidade. O DNS de Load Balancer é conhecido simplesmente após nós rodarmos o comando terraform apply. Então, quando nós rodamos o plan, se nós observarmos ali o plano, nós verificaremos uma mensagem dizendo, olha, esse valor será conhecido simplesmente após o apply. E é por isso que nós conseguimos fazer essa validação com testes de integração, porém não é possível fazer essa mesma validação com testes unitários, tá bom? Então, espero que isso tenha ficado claro. Só é possível porque nós só damos o terraform apply antes a utilizar comand igual apply. E essa daqui é a única verificação que nós faremos neste bloco run especificamente. Agora nós passaremos para a parte mais complexa, que é a chamada HTTP nesse DNS. Então, nós vamos fazer uma chamada HTTP e verificar se nós receberemos um retorno de 200. E para esse tipo de validação, onde nós temos que utilizar o Data Provider, nós temos uma lógica um pouquinho mais complexa, geralmente nós criamos um outro módulo aqui mesmo dentro de cluster, mas dentro de uma pasta chamada testing, onde nós vamos ter as lógicas ali para fazer as validações necessárias. Porém, nós faremos isso na próxima aula. Para que isso seja possível, para que a gente crie este módulo, primeiro que nós precisamos de ter um output aqui no nosso módulo de cluster, porque nós não vamos conseguir acessar o DNS em outro módulo. Esse DNS aqui, nós só conseguimos acessar porque nós estamos dentro deste bloco run, e este bloco run aqui está no escopo do módulo de cluster. Porém, em outro módulo, nós não teríamos acesso a esse DNS, porque nós não estamos expondo nada aqui no output do nosso módulo de cluster. Não existe nada aqui dentro, nós não conseguimos acessar nada, para que a gente consiga acessar nós precisamos de expor o nosso DNS, mas na verdade não é o DNS name que nós vamos precisar aqui, nós vamos precisar nós poderíamos até colocar o DNS name aqui, mas eu gostaria de colocar o ARN, porque nós podemos utilizar depois um data source que obtém esse ARN então verifica qual que é o DNS, vai ficar mais claro daqui a pouco, tá? Mas por enquanto nós teremos aqui simplesmente o export, simplesmente o output do ARN do nosso load balancer, tá? Então agora o nosso cluster aqui, ele exporta LBARN, inclusive nós poderíamos verificar aqui este carinha, né? Então, vamos colocar aqui, se não me engano, output, né? Vamos colocar aqui output. E nós vamos colocar o nome do nosso output. Deixa eu voltar aqui para o output do nosso cluster, LBARN. E deve ser também diferente de nulo e que eu vou colocar invalid lbarn só para validar mesmo se o nosso output ele é diferente de nulo agora na próxima aula nós vamos trabalhar nesses módulos auxiliares que vão nos permitir fazer essa validação mais complexa eu espero que até aqui você tenha gostado e vejo você na nossa próxima aula.