Bom pessoal, agora nós vamos voltar ao arquivo YAML que nós criamos com a definição do nosso workflow e nós iremos fazer aqueles ajustes necessários para que a gente consiga então executar esse workflow. E o primeiro deles é desfazer a alteração que eu fiz na aula anterior, então eu acabei removendo de forma precipitada todo esse step, todo o setup Terraform. Na verdade eu deveria ter removido simplesmente essa linha aqui, se é a Lie Config Credentials Token, que é a parte relativa à configuração do Terraform Cloud, que é o que nós não precisamos, mas nós precisamos do setup do Terraform. Nós precisamos de instalar aqui o Terraform na nossa VM, que está rodando aqui o nosso workflow. Então, eu voltei esse setup Terraform e agora vou remover essa linha aqui. E eu vou adicionar uma nova linha, porque nós precisamos especificar a versão do Terraform. Para a gente garantir que caso haja alguma atualização, nós não sejamos impactados. Então, nós precisamos manter a mesma versão do Terraform que nós estamos utilizando atualmente no nosso projeto. Então, coloquei aqui Terraform Version, que é um dos parâmetros aceitos por essa action aqui, e a versão que nós estamos utilizando é 1.9.2. Então, beleza, já temos aqui o setup do Terraform. Agora nós precisamos também configurar as nossas credenciais, porque nós tínhamos aqui do nosso lado, rodando localmente, o profile da AWS que nós configuramos, e tínhamos a utilização do Azure CLI, onde nós rodávamos sempre o AZ login para nós obtermos uma sessão válida e beleza, nós conseguimos fazer o deploy sem nenhum problema. Agora nós estamos aqui rodando dentro do GitHub Actions e nós não vamos ter essa mesma configuração. Então nós precisamos pensar em alternativas, nós precisamos pensar em como nós vamos nos autenticar de forma segura aqui no GitHub Actions. Voltando na documentação, nós temos aqui a parte de AWS e nós temos aqui a parte de Environment Variables. Existem várias formas de nós nos autenticarmos, como eu já expliquei em sessões anteriores. E uma delas é através de variáveis de ambiente, que inclusive é a forma como nós estamos utilizando, que nós estamos nos autenticando. Porém, a única variável de ambiente que nós setamos para utilização local é o AWS Profile. Por quê? Nós temos ali o AWS CLI na nossa máquina, nós temos o Profile configurado, então basta nós setarmos ali o nome do nosso Profile, que automaticamente nós podemos obter as credenciais a partir desse Profile. Mas que automaticamente nós podemos obter as credenciais a partir desse profile. Mas nós podemos também, ao invés de especificar profile, especificar diretamente a access key, secret access key e a nossa region. Então nós não precisamos de instalar o AWS CLI, criar um profile e assim por diante. Não, basta nós termos essas variáveis de ambiente aqui com o access key,, o Secret Axis Key e o Region já setados e beleza, nós vamos conseguir nos autenticar, tá? Então nós vamos aqui precisar dessas variáveis de ambiente, vamos criá-las no nosso email e nós precisamos também nos autenticar no Azure e faremos algo de forma semelhante, tá? Temos várias formas aqui de nos autenticar, porém a forma que nós utilizaremos para o nosso exemplo é utilizando o Service Principal e o Client Secret então clicando aqui nós temos todos os detalhes de como nós podemos criar o Service Principal, como nós conseguimos obter os nossos Client Credentials os nossos Client Secrets e nós vamos fazer passo a passo desse tutorial aqui porém na próxima aula. Agora nós vamos entender que no final, aqui após nós executarmos todos esses passos, nós vamos entender aqui que nós precisamos simplesmente dessas quatro variáveis de ambiente. Então nós precisamos criar um usuário, um service principal, e obter aqui os client credentials desse service principal, então setar essas variáveis de ambiente. Pega essas variáveis de ambiente, nós vamos conseguir também nos autenticar no Azure através do GitHub Actions, beleza? Então vamos lá. A primeira coisa que nós faremos aqui, então, é nós definirmos as nossas variáveis de ambiente. Porém, essas variáveis de ambiente, elas vão apontar para secrets que nós iremos utilizar. É claro que nós não podemos colocar aqui no nosso arquivo em email diretamente os nossos valores, diretamente os nossos secrets. Essas informações são sensíveis. Qualquer pessoa com esses secrets em mãos conseguiria acessar as nossas contas e fazer o que quisesse. Então, nós precisamos utilizar secrets, nós vamos considerar que esses secrets já tenham sido criados, nós faremos isso na próxima aula, aqui nós vamos simplesmente referenciar esses secrets da seguinte forma, na verdade existem duas formas. Bom, sabendo que nós vamos utilizar aqui no Apply, basta nós especificarmos aqui Envy,, colocar o nome das variáveis de ambiente. Por exemplo, nós vamos aqui utilizar o AWS Access Key ID e nós vamos referenciar o nosso Secret com o nome AWS Access Key ID, que é exatamente o mesmo nome. Imediatamente nós já temos acesso aqui, ou nós já temos o nosso escopo, no escopo desse step, essa variável de ambiente. Porém, nós podemos fazer de uma forma diferente e acertar aqui globalmente. Então, nós podemos ter essas variáveis de ambiente para todos os steps e é isso que eu vou fazer. Então, eu vou copiar aqui todas as variáveis de ambiente que nós precisamos e eu vou colocar aqui abaixo de permissions. Beleza, agora nós temos as variáveis para todos os steps. Nós temos aqui access key ID, secret key, secret access key, melhor dizendo, e region. E agora nós temos a parte aqui de Azure, ARM client ID, client secret, tenant ID e subscription ID. E observe que todos os secrets possuem exatamente o mesmo nome, o mesmo nome da variável de ambiente. Beleza? Temos aqui então essa parte de credenciais ajustada. É claro que se nós salvarmos aqui e rodarmos não vai funcionar porque esses secrets ainda não foram criados, mas como eu já adiantei nós faremos isso na próxima aula. Uma outra coisa que nós precisamos fazer aqui é o seguinte. Se nós observarmos aqui os nossos comandos nós estamos considerando que nós vamos rodar os comandos Terraform no diretório raiz do repositório, só que esse não é o caso, tá? Principalmente aqui no meu caso, onde eu tenho, se nós observarmos aqui, deixa eu verificar se eu consigo navegar até o código, só para nós darmos uma olhada, eu tenho aqui, na verdade, outros diretórios na raiz do projeto, tá? E aqui os arquivos de configuração eu estou utilizando dentro de AWS nesse momento, tá? AWS nem seria o nome correto, porque nós temos também recursos do Azure aqui, mas atualmente está dentro de AWS e nós temos aqui Dev, Modules e Prod, mas nós estamos trabalhando aqui dentro dessa branch, que é a branch Section 7 CICG, e aqui nós já ajustamos, nós criamos aqui o diretor environments com dev e prod. Então, nós precisamos rodar os comandos dentro desses environments. Para este exemplo, eu vou rodar dentro do environment dev, mas é claro que você criaria aí provavelmente um workflow para dev, um outro workflow para produção, ou então somente para produção, enfim. Vai depender aí da sua abordagem, no caso aqui para o nosso exemplo, nós vamos criar somente para o contexto de desenvolvimento, beleza? Então nós vamos voltar aqui, para que a gente consiga fazer isso, para que a gente rode em um determinado contexto, nós precisamos utilizar um parâmetro adicional aqui nos comandos do Terraform. E esse parâmetro aqui é o parâmetro childdir, o diretório filho. Então, basta nós colocarmos esse carinha aqui, childdir, e colocar qual é o diretório que nós queremos que seja executado esse comando, beleza? E nós precisamos fazer isso aqui para todos. Na verdade que seja executado esse comando, beleza? E nós precisamos fazer isso aqui para todos, na verdade quase todos, tá? Eu vou pular por enquanto esse formato, aqui no plan eu vou colocar, beleza? E eu vou colocar aqui também no apply. E por que eu pulei aqui essa parte de formatação? Primeiro porque nós ainda não vimos, tá? Eu vou falar aqui brevemente sobre isso. E segundo, que nós precisamos formatar o nosso projeto todo, não somente esse diretório específico. Bom, vamos entender como funciona esse comando, esse terraformformat, tá? Ele é simplesmente uma ferramenta que vai nos auxiliar com a parte de lente. Deixa eu só redimensionar aqui o meu Visual Studio Code pra gente dar uma olhada, tá? Beleza. Então, esse carinha aqui, ele faz a checagem da formatação, caso a gente especifique o parâmetro check, ou então ele mesmo formata automaticamente, tá? Deixa eu abrir um novo terminal, create terminal, estou aqui na raiz do projeto, se eu executar terraform fmt check, ele não vai mostrar nada, tá? Por quê? Porque nesse diretório eu não tenho nenhum arquivo de configuração. Então, quando nós rodamos esse comando aqui, ele vai checar simplesmente os arquivos de configuração dentro do próprio diretório. Porém, se eu coloco recursive, ele vai checar todos os nossos diretórios, tá? E dessa forma ele encontra aqui estes arquivos. Ele está apontando estes arquivos por quê? Porque nós temos problema de formatação nestes arquivos. Então, vamos verificar se nós encontramos aqui este problema. Aparentemente, aqui não dá para nós visualizarmos. Talvez isso é herdeira, né? Bom, mas precisamos entrar arquivo por arquivo e corrigir? Não, basta nós executarmos o terraforme porém agora é a forma de formato é porém agora sem esse cheque agora nós queremos de fato fazer a formatação então quando nós executamos nós podemos ver aqui que os arquivos foram alterados e formatados automaticamente está é muito importante nós executarmos esse cheque lá na nossa parte lá em porque tiver alguma tiver algum arquivo como informação formatação incorreta melhor dizendo, nós seremos notificados e esse ajuste precisará ser realizado para que a gente consiga fazer de fato o nosso apply, é importante para garantir a padronização dos nossos repositórios se nós observarmos aqui os arquivos alterados nós veremos aqui todos os ajustes de formatação que foram realizados e agora está tudo certinho, nós podemos inclusive depois fazer o commit. Então eu faço o commit aí, eu farei o commit depois, mas já entendemos como o format funciona e é por isso que nós além desse check aqui, nós iremos também, deixa eu voltar aqui, beleza? Nós iremos também deixa eu voltar aqui beleza, nós iremos também adicionar recursive perfeito, agora nós estamos checando toda a formatação de todo o nosso projeto e não precisamos desse childdir justamente por causa desse recursive porque nós queremos ali todo o projeto é isso, eu acho que nós já passamos aqui por praticamente todos os steps, fazendo as alterações. Uma outra alteração importante que nós iremos fazer aqui é a remoção dessa condição. Então esse step aqui, ele executa somente se nós estivermos aqui na branch main, se a alteração aconteceu na branch main. E se o evento que fez com que esse workflow rodasse foi um evento de push, tá? Então, essa daqui é uma validação bem interessante e bem importante. Então, nos garante que o apply vai acontecer somente na branch main e também somente com eventos de push, mas no nosso caso nós vamos remover, tá? Porque nós estamos trabalhando aqui em outra branch, é simplesmente para nós testarmos, mas realmente considere utilizar essa condição aí nos seus projetos reais. Vamos verificar aqui. Bom, tem um step, algo que nós estamos aqui, que precisa ser adicionado, que nós ainda não adicionamos, que é a parte de testes, porém nós falaremos sobre os testes com mais detalhes nas próximas aulas. E por enquanto é isso, nós já temos aqui praticamente a nossa pipeline pronta. Ela só não vai funcionar. Porque nós não criamos os nossos secrets. Mas nós falaremos com mais detalhes sobre isso na próxima aula. Eu espero que você tenha gostado. Vejo você lá.