Então, continuando com o nosso assunto sobre testes de integração, nós iremos criar um novo diretório aqui dentro de cluster, que será o diretório teste. Sempre que nós precisarmos criar algum módulo específico para os nossos testes, seja para setup ou para alguma validação, alguma verificação, nós colocamos dentro dessa pasta teste. Então, isso aqui é uma convenção que é bastante utilizada. Então nós vamos aqui adicionar um outro diretório dentro de teste, que será HTTP, porque aqui nós temos um módulo para fazer essa validação HTTP. Nós utilizaremos o provider HTTP. Se nós observarmos a documentação, eu já estou aqui na verdade com o site do Terraform aberto na documentação do provider HTTP, nós temos a informação de como utilizar este provider e a única coisa que nós temos dentro deste provider é o DataSource HTTP, que nos possibilita fazer chamadas HTTP por padrão, utilizando aqui o método GET, mas esse método também pode ser alterado. Aqui nós temos vários exemplos, nós vamos ter aqui todos os nossos argumentos que nós podemos informar, o único obrigatório é o RL, mas nós podemos, como eu disse, colocar aqui o método, um request body, colocar headers e assim por diante, inclusive retry, tá? Que será muito importante para o nosso exemplo. E nós temos aqui, como propriedade read-only, o response body, então nós podemos verificar qual foi o retorno da nossa chamada, podemos ver aqui o response em 64, os headers do nosso response e também o status code, que é a propriedade ou o argumento mais importante que nós temos dentro desse data source, que é aquele que nós vamos utilizar, tá bom? Nós temos aqui também algumas informações relacionadas ao retry. Então, a ideia deste módulo é que a gente utilize esse data source HTTP para fazer essa chamada ao nosso load balancer e verificar o status 200. Nós vamos aqui, então, criar um diretório variables, na verdade, não um diretório, tá? Mas um arquivo, variables.tf, naquele mesmo padrão, tá? Então, imagina estes módulos exclusivos para teste, como qualquer outro módulo Terraform. Nós teremos aqui variables, e a única coisa que nós vamos esperar é o ARN do nosso load balancer. Inclusive, por isso que nós exportamos ele, nós colocamos ele lá no nosso output na aula anterior, porque nós vamos precisar dele aqui. Variables será a nossa única variável, tá? E nós vamos ter aqui main.tf, também seguindo aí os mesmos padrões. Primeiro, nós vamos colocar o nosso required provider, tá? Então, aqui nós estamos utilizando o HTTP e eu vou utilizar a versão 3.4.3, beleza? Nós agora teremos aqui um data source, nós vamos chamar aqui esse cara de AWS LBLB e nós estamos setando aqui o ARN deste cara, e o interessante desse data source aqui é que somente com o ARN nós conseguimos obter todas as informações do nosso load balancer estão utilizando esse aí nós vamos ter acesso ao dns do load balancer especificamente você pode perguntar bom então nós poderíamos exportar aqui simplesmente o dns nem diretamente e utilizá-lo aqui tá a gente poderia mesmo né isso funcionaria, mas eu gostaria de mostrar aqui um exemplo onde nós utilizamos mais de um Data Source. Até porque quando nós estamos dentro dos arquivos de teste especificamente, melhor dizendo, quando nós trabalhamos com cheques, que nós veremos na próxima aula, nós podemos utilizar um único Data Source por arquivo. Então, às vezes ter aqui um módulo auxiliar pode nos ajudar porque nós podemos colocar quantos data sources nós quisermos beleza então vou colocar aqui esse data source e eu vou colocar agora a definição do nosso http então nós temos aqui um data source o tipo do data source http e o nome vai ser lb tá então inclusive nós estamos colocando o mesmo nome aqui, também para mostrar que é possível colocar o mesmo nome. Geralmente, a gente não vai colocar, a gente vai colocar nomes diferentes, mas é possível porque o identificador, na verdade, é a combinação do tipo do recurso com o identificador que nós colocamos. E aqui nós colocamos a nossa URL, então nós estamos aqui referenciando o nosso Data Source e utilizando o argumento, ou melhor dizendo, a propriedade DNS Name, e estamos concatenando aqui com o protocolo HTTP, já que nós estamos expondo na porta 80 e não configuramos certificado nem nada do tipo. Aqui nós temos um timeout de 5 segundos e nós configuramos 5 tentativas, ou 5 tentativas de retry isso significa que nós iremos chamar o nosso load balancer até 6 vezes, por que? ele chama uma vez, se não der certo ele passa para os retries e a quantidade de retries é 5, nós temos aqui um delay mínimo de 1 segundo um delay máximo de 10 segundos entre cada tentativa de retry e é importante nós termos esses retries, porque após o provisionamento, após o apply, o nosso load balancer ainda não está pronto para receber requisições, tá? Então ele tem ali uma etapa de health check, uma etapa de, vamos dizer assim, de setup, né? Onde tudo está se configurando, o nosso auto-scanning está se ajust ajustando, nosso grupo está registrando os targets e assim por diante, que pode demorar um pouquinho, tá? Então, não é imediatamente após o Apply que nós conseguimos fazer uma chamada HTTP. Nós precisamos esperar um pouco. Então, ter esses retries garante que nós iremos, eventualmente, conseguir fazer a nossa chamada com sucesso, beleza? E é isso. Nós já temos aqui o nosso módulo auxiliar que nós vamos precisar referenciar no nosso arquivo de teste de integração. Então vamos navegar aqui novamente até integration.tftestes, e aqui nós vamos ter um outro bloco run, que será o nosso bloco verify http, beleza? Novamente utilizando o comando apply, e aqui como você já deve ter imaginado, nós vamos referenciar o módulo que nós acabamos de criar. Então nós colocamos aqui source como sendo .barra teste em barra http. Então ele vai executar este módulo que nós acabamos de criar, e agora nós precisamos passar as variáveis que este módulo espera, assim como nós passamos as variáveis aqui para o nosso cluster e também para o nosso network. E a única coisa que nós precisamos passar é a ARN no nosso load balancer que nós obtemos aqui a partir do nosso bloco run.cluster. E agora eu acho que ficou um pouquinho mais claro por que nós tivemos que adicionar lá no output o ARN do nosso load balancer. Por quê? Quando nós rodarmos esse run aqui, o Terraform estará no contexto deste módulo test em ponto HTTP. Então, ele não conhece o contexto do módulo cluster que nós acabamos de rodar. Ele não conhece o contexto desse bloco run.cluster. Então nós não conseguimos acessar diretamente os recursos deste módulo, do módulo de cluster. Nós precisamos expor aquilo que nós queremos acessar externamente. E é dessa forma que nós fazemos. Então a única coisa que nós conseguimos acessar do nosso cluster é a RM do nosso load balance, que é a única coisa que nós expomos. Beleza? Então já temos aqui tudo configurado e agora nós podemos fazer as nossas validações. Como nós estamos aqui no contexto de teste em HTTP, nós conseguimos facilmente acessar o nosso data source, e nós conseguimos então validar o nosso status code, e é isso que nós faremos dentro do bloco assert. Beleza? A nossa condição é data.http.lb.statusCode igual a 200 se não for, nós veremos que o nosso web app não está disponível e assim nós finalizamos as nossas validações nós finalizamos os nossos testes de integração, mas é claro que agora nós precisamos rodar aqui os nossos testes e verificar se tudo está configurado se tudo está funcionando perfeitamente. Deixa eu abrir aqui o nosso terminal. Novamente eu vou fazer o export. Na verdade, deixa eu utilizar aqui o nosso outro terminal que já tinha o export. Agora eu preciso navegar até, na verdade, cluster. Beleza. Aqui nós vamos rodar o Terraform init, já que nós temos novos módulos aqui vamos verificar se tudo vai ser inicializado com sucesso precisamos aguardar aqui um pouquinho e beleza tudo foi inicializado e agora nós rodamos o terraform teste e nós vamos aguardar aqui temos a execução dos testes de integração Já identificou dentro da pasta testes. Ele identificou aqui que nós temos um arquivo de testes. E no nosso caso, todos os testes necessitam do comando apply. Agora, é importante, enquanto nós temos os testes sendo executados, nós verificarmos que aqui, se nós navegarmos até network, até VPC, na verdade, vamos aqui em VPC, nós o vpc ela foi criada a nossa vez de teste então ele precisa temos aqui teste de pc porque teste porque a nossa variável prefixo a variável pfix na verdade ela contém o valor de teste vamos equivalente a gente é por isso que nós temos aqui teste de pc e que você ela contém o valor de teste. Vamos aqui validar teste. É por isso que nós temos aqui teste VPC. E aqui você pode observar que todos os recursos estão de fato sendo criados, sendo provisionados. E esse é um ponto de atenção, uma vez que nós teremos custos, nós teremos gastos com o provisionamento desses recursos. E é claro que os testes demorarão muito mais tempo para passar. Por isso, eu recomendo que sempre faça aquilo que for possível, utilizando testes unitários, então todas as validações de nome, por exemplo, de lógica, como utilização do count, utilização de certos argumentos específicos, você pode utilizar os testes unitários para isso. Agora, para aquilo que é conhecido somente após o Apply, ou para uma validação mais complexa, como a que nós fizemos aqui, aí sim vale a pena utilizar os testes de integração. É importante lembrar sempre da pirâmide de testes. Na base, os testes unitários, depois os testes de integração, e por fim, em menor quantidade, os testes end-to-end. Vamos verificar aqui o status da execução dos nossos testes. Temos aqui só o provisionamento da nossa network, que já foi concluída. Essa parte de cluster aqui com certeza vai demorar um pouquinho, tá? E é por isso que eu vou pausar a gravação da aula e quando finalizar, nós voltamos. E aqui está. Todos os nossos testes passaram. Nós temos aqui os nossos trêses passaram, nós temos aqui os nossos três blocos run networks, cluster, verificar, http eles passaram e é interessante observar aqui também que o nosso tearing down aconteceu, o que é esse tearing down? É quando os recursos estão destruídos, então o terraform ele automaticamente provisiona e automaticamente ele destrói todos os recursos que foram provisionados durante os testes, inclusive para validar nós podemos navegar aqui até a nossa VPC. Essa VPC foi criada, teste VPC. Ao dar um refresh aqui, nós temos somente uma VPC agora. E dessa forma, nós concluímos o nosso assunto sobre teste de integração. Espero que você tenha aprendido, espero que você tenha gostado. Nós nos vemos na nossa próxima aula.