Bom pessoal, então para nós finalizarmos a nossa pipeline, o nosso workflow, quando nós estamos falando em GitHub Actions, nós devemos nessa aula criar as nossas Secrets. Para fazer isso, nós vamos acessar aqui os settings do nosso repositório, deixa eu abrir aqui uma nova aba,? São a AWS Access Key ID, a AWS Region e a AWS Secret Access Key, que são exatamente as três secrets que nós precisamos para o deploy na AWS, tá? Eu já criei esses secrets porque nós já aprendemos como trabalhar com os usuários, como criar um usuário para acesso programático lá na AWS, como obter as credenciais, o Access Key ID e o Secret Access Key desde o usuário e como configurar o nosso profile. Nós podemos utilizar aquelas mesmas informações que nós obtemos do nosso usuário para nós criarmos esses secrets. Então, caso você não se lembre, você pode voltar aqui a algumas aulas. Na verdade, logo no início, quando nós falamos sobre integração do Terraform com a AWS, como fazer provisionamento de recursos na AWS com o Terraform, logo no começo, eu mostrei para vocês como nós conseguimos criar esses usuários e obter essas credenciais, tá? Uma outra coisa que você pode fazer, ao invés de criar um novo usuário, é acessar aí o seu diretório, o diretório do seu usuário. Então, se eu acessar o diretório do meu usuário, o meu diretório home, eu tenho aqui o diretório .aws, esse diretório oculto, e aqui eu tenho as credenciais para cada profile que eu tenho configurado. Então, eu posso abrir esse arquivo de credenciais e obter essas informações a partir deste arquivo credenciais e simplesmente criar aqui os nossos repositórios secret, tá? Então isso é bem simples. Region nem precisava ser um secret, poderia ser um valor até hardcode lá no nosso workflow, poderia ser uma variável ao invés de um secret, mas nós vamos manter aqui como um secret para manter aqui o mesmo padrão e nós não dificultarmos muito, beleza? Então já temos aqui a parte de AWS. Eu recomendo que você crie aí os segredos aí do seu lado. Agora nós precisamos também criar os Secrets para o Azure, tá? E que é um pouquinho mais complicado, porque nós não vimos ainda a parte de autenticação no Azure. A ideia também não é entrar em detalhes sobre isso. Eu vou simplesmente passar aqui o passo a passo, que é bem simples, na verdade. Nós precisamos logar, então eu vou dar um AZ Login aqui, beleza? Vou escolher aqui a minha conta, perfeito, já estou logado. E aqui ele vai pedir para eu selecionar a Subscription. Eu vou selecionar aqui a única Subscription que eu tenho, por isso eu vou colocar aqui o número 1, beleza? Já estou aqui com a Subscription selecionada. E essa daqui já é uma informação que nós precisamos, né? Que é a nossa subscription ID. Então, eu vou pegar essa subscription aqui e eu já vou criar esse secret, tá? Deixa eu primeiro pegar aqui o nome do nosso secret, beleza? Vou criar aqui o new repository secret. Perfeito, deixa eu voltar aqui que eu acabei perdendo aqui o meu ID, e agora o meu Secret está definido aqui, então vou adicionar esse Secret aqui dentro, perfeito, e agora nós vamos precisar fazer o seguinte, deixa eu pegar aqui o nosso próximo comando, que na verdade já é o comando de criação mesmo do nosso service principal. Não vou entrar em detalhes aqui do que é um service principal, mas você pode imaginar como se fosse esse usuário que nós temos ali na AWS, que nós criamos para acesso programático, seria mais ou menos equivalente ao nosso service principal. A diferença é que no Azure, a identidade do usuário ou de uma aplicação é tratada de uma forma diferente, ela é tratada como um Service Principle e esse Service Principle está associado ao usuário ou a uma aplicação. E ele pode ser replicado em vários tenentes diferentes. Esse Service Principle carrega as credenciais e a identidade de um usuário ou aplicação. O que importa aqui para nós é que este Principle está associado às nossas credenciais. Então, nós podemos obter aqui uma Password e um Client ID a partir desse Service Principle. Beleza? Então, vamos lá. Para nós criarmos esse Service Principle, nós temos um comando aqui bem simples do Azure CLI, tá? Se fosse no portal, nós teríamos que criar um App Registration primeiro, mas utilizando o CLI é um pouquinho mais tranquilo de nós fazermos. E o comando é esse, tá? azad, sp, Service Principle, create for our back, então, nós vamos associar aqui a uma row, utilizando o row-based access control do Azure, e a row que nós vamos utilizar é a contributor, dessa forma nós teremos acesso para fazer o provisionamento. Nós estamos aqui selecionando o scope, e qual que é o scope? O scope da nossa subscription, então você precisa colocar aqui barra, subscriptions, barra e o id da subscription, que nós acabamos de obter aqui. Então, bem simples, nós criamos este usuário e a partir da criação deste usuário, ou melhor dizendo, não deste usuário, deste Service Principle, a partir da criação deste Service Principle, nós teremos acesso às informações que nós precisamos. Nós temos aqui primeiro o nosso App ID aí então se nós voltarmos aqui nós precisamos do cliente adi e o cliente aí dia justamente aquele é verdade então vou criar aqui um novo repositório secret beleza vou voltar aqui é o meu ao celular beleza e aqui eu estou colocando é que a dita vou adicionar esse secret. Agora, o outro secret que nós precisamos é o tenant ID. Então, vamos chegar a esse tenant ID aqui. Deixa eu já criar o secret com esse nome, ARM tenant ID, beleza? Que é justamente esse cara, ó. Temos aqui o tenant já pronto para nós. Beleza? Add secret. E, por fim, temos aqui o nosso client secret. Então, vamos adicionar também esse cara, client secret, que é a última informação que nós precisamos adicionar, que é justamente a nossa password. Bom, eu estou mostrando aqui todas as credenciais para esses usuários que eu criei, mas evidentemente após a finalização dessa aula, eu irei excluir esse service principal. Então, é por isso que eu estou mostrando aqui, mas, evidentemente, essa informação deve ser protegida, você nunca deve compartilhar essas informações com ninguém, beleza? Então, adicionando aqui o nosso ARM Client Secret, e agora nós temos todos os segredos que nós precisamos. Então, foi relativamente simples, talvez mais complicado seja entender o conceito, como esses diferentes Cloud Providers trabalham com a parte de segurança, com a parte de autorização, que é um pouco mais complicado e cada um tem suas particularidades. Beleza? Agora nós vamos voltar aqui, supostamente se nós criarmos o nosso workflow, nós já vamos conseguir executar ele eu só gostaria de adicionar o nosso último step que é o step de testes que acabou com nós eu não adicionei antes né então vou copiar aqui e vou colar para nós darmos uma olhada tá vai ser logo após o formato antes do plano beleza e nós temos aqui o terraform testes ele é um pouquinho mais complicado que os outros comandos, porque nós temos aqui, por exemplo, no formato, nós temos o recursive, que eu acabei removendo aqui sem querer, deixou de sonar de novo. Nós temos esse recursive, que vai procurar em todos os subdiretórios, e eu vou dar esse comando de formatação para todos os subdiretórios. Para testes, nós não temos isso. E nós temos ali testes nos nossos módulos compartilhados E temos também testes nos nossos módulos raízes Então nós precisamos de alguma forma de rodar aqui os testes em todos esses diretórios Colocar isso de forma hardcode não é muito legal Então eu criei aqui um bash script para que a gente conseguisse fazer isso de forma automatizada. Então, se nós adicionarmos novos módulos, nós garantimos que os testes serão executados também nesses novos módulos. A ideia aqui mesmo é um for each em cada um dos diretórios do nosso repositório. Então, ele executa o terraform init, que é obrigatório, e executa também o Terraform teste, e assim nós garantimos que os testes serão executados corretamente, tá? E é isso. Uma coisa que eu fiz na aula anterior foi remover aqueles comentários que nós tínhamos aqui na pipeline, então eu deixei ela um pouco mais clean aqui, e agora nós vamos fazer o commit. Eu vou fazer o commit no diretório main mesmo. Se eu não me engano, eu já tenho um arquivo terraform. Deixa eu verificar aqui se vai dar algum conflito. Sim, eu já tenho um arquivo terraform.eml então eu vou colocar aqui terraform dev, tá? Terraform dev, vou fazer o comit dessas alterações, beleza? Comit. Bom, a próxima coisa que eu preciso fazer aqui, deixa eu verificar, é que nós, eu estou trabalhando em uma outra branch, eu vou fazer um merge dessas alterações na minha branch específica, então eu vou colocar essa pipeline para executar. Na verdade, quando eu fizer o merge, eu já vou fazer aqui o push, então a nossa pipeline, o nosso workflow, será executado de forma automática. Eu vou pausar a aula para eu fazer esse pequeno ajuste, caso você esteja trabalhando dessa mesma forma, você pode fazer isso aí do seu lado. E depois nós vamos verificar aqui se o nosso workflow rodou com sucesso, beleza? E aqui nós temos a execução do workflow que foi a que nos deu um resultado de erro. O nosso workflow não foi executado com sucesso. Nós podemos verificar aqui o que aconteceu. O nosso workflow não foi executado com sucesso. Nós podemos verificar aqui o que aconteceu. E o nosso erro está no Terraform init e está relacionado a uma falha ao obter o charge config profile. Mas nós não deveríamos ter esse problema. Por quê? Porque nós não estamos mais utilizando o profile e sim as variáveis de ambiente com as credenciais. Isso aconteceu porque eu não removi aqui os nossos profiles. Se nós pesquisarmos aqui no nosso repositório por default, que é justamente o nome do meu profile, eu tenho aqui, por exemplo, um arquivo providers.pf, tanto o profile associado ao nosso backend, quanto o profile associado também ao nosso provider AWS. E isso acontece tanto no environment de dev, quanto no environment de prod. Então, nós precisamos remover este cara, beleza? Eu farei essas alterações aqui do meu lado, sugiro que você faça o mesmo, depois eu vou subir de novo para o nosso repositório e nós vamos verificar se agora o nosso workflow roda. Bom, pessoal, fiz a remoção dos profiles lá dos nossos arquivos de configuração e agora eu tenho outro problema aqui que é na parte de formatação. Então nós temos aqui o arquivo providers que não está configurado corretamente, acabou que eu não alterei e não mexi na parte de formatação. Eu estou mostrando todos esses problemas que eu estou tendo aqui porque com certeza aí no seu dia a dia você vai ter esses mesmos problemas e para mostrar aqui que nem sempre as coisas funcionam de primeira, tá? Geralmente quase sempre elas não funcionam de primeira. Então eu vou também ajustar aqui a formatação, simplesmente rodando terraform format, inclusive nós podemos fazer isso juntos, né? Deixa eu já aqui na pasta AWS, vou dar terraform fmt de format e aqui nós podemos utilizar o Recursive para garantir que todos os arquivos serão ajustados. Foi justamente os dois arquivos que eu alterei, então acabou que eles não ficaram formatados corretamente. Beleza, agora nós podemos fazer o commit das nossas alterações, então eu vou colocar aqui um fixformat como mensagem do nosso commit e agora nós podemos sincronizar aqui as nossas alterações, então eu vou colocar aqui um fixformat como mensagem do nosso commit, e agora nós podemos sincronizar aqui as nossas alterações, nós podemos voltar aqui aos nossos workflows, e nós teremos a execução aqui de um novo workflow. Vamos aguardar aqui alguns instantes para que ele identifique a alteração, beleza? Fixformat, e agora sim, bom, nós já vimos que pelo menos o init não deu erro mais, nós tivemos um init no próximo step, agora nós vamos verificar os próximos steps, depois do formato. E agora sim, o nosso workflow foi executado com sucesso, e nós podemos revisar aqui cada um dos steps que foram executados, como por exemplo a parte de form format, nós inclusive já vimos aqui, antes de eu passar a gravação da aula, mas deu tudo certo, nós podemos verificar aqui os logs, nós temos a parte dos testes, então nós precisamos verificar aqui se aquele script que foi criado está rodando, está executando conforme nós esperamos, e nós temos aqui primeiro ele executando os testes no módulo de cluster, beleza, Aqui, primeiro ele faz o init, ok? E aqui nós temos a execução dos testes de integração, ele rodou os testes de network, cluster e verificar HTTP, beleza? Todos eles passaram com sucesso, os três passaram. Agora, ele passa aqui para a parte de network, ele faz a inicialização, perfeito. Então, ele executa os testes, né? Validate VPC e validSubnets, os dois blocos do RAM passaram também com sucesso, então dois testes, e é isso, eram os testes que nós tínhamos, os testes de integração e os testes unitários, perfeito, temos a execução do Terraforming Plan, também sem nenhum problema, né, nós temos aqui o output de tudo aquilo que será ou que foi já provisionado, temos o perfil Terraform Apply, onde nós aqui executamos com o auto-approve, não podemos nos esquecer desse auto-approve, beleza, temos aqui de novo o plan, perfeito, e ao descer um pouquinho nós temos todos os blogs que foi criado e nós temos aqui inclusive a o nosso cheque né nós podemos verificar aqui que ele tem a leitura do nosso de irá só se apontando que para o nosso de balançar a esse carinho aqui e beleza completa que após, que foi o período que levou para que o nosso load balancer ficasse disponível. E beleza, temos agora aqui então os nossos recursos provisionados através do Terraform, utilizando GitHub Actions, utilizando esse workflow que nós criamos. E agora você precisa se lembrar que os recursos estão lá rodando na AWS e rodando também no Azure. Nós podemos verificar aqui que foi criado o nosso Storage Account. Beleza? Creation Complete aqui do nosso Storage Account. Então, não se esqueça, muito importante, não se esqueça de executar o Terraform Destroy para que você não seja apanhado de surpresa por um gasto exorbitante no seu cartão de crédito por causa desses recursos provisionados. Eu espero que você tenha gostado. Com certeza você utilizará isso daqui no seu dia a dia. É muito comum. Todas as empresas costumam adotar a infraestrutura como código e também em conjunto com técnicas de CI e CD, eles fazem o provisionamento desses recursos através de uma pipeline, através de um workflow. Beleza? Vejo você na