Olá pessoal, sejam muito bem-vindos a mais uma aula. E bom, até agora nós vimos como nós podemos declarar a nossa infraestrutura, declarar os nossos recursos nos arquivos de configuração. Nós vimos que o Terraform gera um arquivo TF State, que é uma representação de fato do nosso ambiente, da nossa infraestrutura real. Porém, até agora nós vimos uma relação de um para um. Então, nós temos um único projeto em Terraform, nós temos um único arquivo TF State e nós temos um único ambiente. A questão é que no dia a dia, na vida real, principalmente nas empresas de maior porte, nós teremos ali a necessidade de replicar o nosso ambiente. Então agora nós não vamos trabalhar com um único ambiente. Nós teremos um ambiente de desenvolvimento, talvez um ambiente de homologação e testes, para que o time de IKEA possa realizar os seus testes, e nós teremos, evidentemente, o nosso ambiente de produção. Então, essa é uma necessidade bastante comum, e existem diferentes abordagens para solucionar esse problema, existem diferentes formas como nós podemos replicar o nosso ambiente, e eu vou trazer aqui duas das abordagens que eu acho mais interessantes. A primeira delas é trabalhar com múltiplos diretórios, e depois, na próxima aula, nós veremos também como trabalhar com Workfaces. Para essa primeira abordagem, nós não precisamos conhecer nenhum recurso extra aqui do Terraform. Com o conhecimento que nós temos até agora, nós conseguimos criar essa divisão de ambientes, criar essa réplica de ambientes. Baseado somente no título da aula, trabalhando com múltiplos diretórios, eu desafio você, eu sugiro que você tente solucionar esse problema, que você tente criar múltiplos diretórios e criar ambientes diferentes para a sua infraestrutura. Tente criar um ambiente de desenvolvimento e um ambiente de produção e depois volte para você entender qual é a abordagem que eu vou seguir aqui. Não significa que será a correta, a melhor, mas é simplesmente uma sugestão de como você pode trabalhar com múltiplos ambientes. Beleza? Então vamos lá. Considerando que você já tenha testado, que você já tenha tentado a sua própria abordagem, vou mostrar aqui uma forma que eu considero interessante. Nós vamos aqui criar, então, neste exemplo, um ambiente de desenvolvimento e um de produção, somente estes dois ambientes. Teremos aqui um diretório de dev e teremos, então, um diretório de prod. E aqui nós vamos mover estes arquivos, nós vamos mover todos os arquivos, tá? Nós vamos mover os arquivos, todos os arquivos tf, inclusive este terraformlock.htl para dentro da pasta de produção. E agora eu vou mover estes arquivos, na verdade copiar os arquivos de configuração também para dentro da pasta dev, tá? Aqui agora nós precisamos de no nosso arquivo main.tf, tanto de dev quanto de produção, atualizar o nosso source. Então, vou referenciar aqui o source corretamente, precisamos voltar no diretório, né? Em main, nós precisamos também atualizar, na verdade, main.tf do diretório de desenvolvimento, precisamos dessa atualização e beleza. Então, nós já temos aqui já os nossos arquivos definidos e é basicamente isso. Então, quando nós queremos dividir o nosso ambiente múltiplos ou dividir a nossa infraestrutura em múltiplos ambientes, nós criamos diretórios para cada um desses ambientes. E aí, para cada um desses diretórios, nós teremos um TF Stage diferente e nós conseguimos definir variáveis diferentes para cada um desses diretórios. Então, eu poderia aqui em Dev, navegar até o nosso Terraform TF Vars e mudar o nosso prefixo. Agora eu posso colocar Dev-FullCycle. E como nós utilizamos esse prefixo em basicamente todos os recursos que nós criamos, agora nós teremos um nome diferente para esses recursos quando eles forem referentes a desenvolvimento. E não só isso, mas eu poderia também mudar aqui o bloco do nosso VPC, o CIDR bloco do nosso VPC, utilizando, por exemplo, aqui um range de classe B. Então, nós podemos aqui referenciar este carinha, mudar somente para desenvolvimento, então tudo que nós aplicarmos aqui será para desenvolvimento. tudo que nós aplicarmos aqui será para desenvolvimento. Aqui esse InstanceCount não está sendo utilizado, eu acabei deixando aqui, mas foi utilizado somente alguns exemplos, depois nós não referenciamos ele mais. Então eu vou acabar removendo esse cara daqui, deixa eu remover esse InstanceCount daqui. Em módulos nós também precisamos fazer esse ajuste, então eu vou até Variables e vou remover instance count. E a mesma coisa aqui em produção. Vou remover instance count daqui e instance count também do nosso arquivo de variáveis e também do nosso tf.vars. Eu acho que eu não removi de variables aqui dentro de desenvolvimento. Tá perfeito. Já fizemos essas alterações, então aqui nós acabamos de mudar o CIDER block da nossa VPC somente para desenvolvimento, nós poderíamos também especificar aqui no nosso arquivo main.tf que nós agora queremos uma única instância em desenvolvimento e o maxSize será 2, então nós vamos trabalhar com no máximo duas instâncias em desenvolvimento, já que nós não temos a necessidade de fazer um scale out maior do que isso, nós não precisamos ter mais de duas instâncias. E é basicamente isso, nós temos aqui a referência aos nossos módulos acontecendo para a dev e acontecendo para a produção. Bom, você pode achar aqui, mas eu tenho duplicidade de código, eu tenho que manter dois diretórios, eu tenho que manter N arquivos de configurações para cada ambiente. E de fato, esse seria um dos contras de nós utilizarmos essa abordagem de múltiplos diretórios. Mas a ideia é que você crie módulos que não tenham tantas variáveis, que eles não tenham tantos inputs. Então, os seus módulos devem ser já imaginados para esse cenário. Aqui no nosso exemplo, nós temos várias customizações, então eu criei várias variáveis aqui para nós testarmos ou para nós exemplificarmos alguns módulos mais genéricos. Pensando que esses módulos seriam utilizados em diferentes projetos com diferentes necessidades. Mas, quando você trabalha em um projeto que você tem que criar diferentes ambientes, você vai criar módulos, geralmente com valores padrões, com valores default, com variáveis já definidas e você vai passar aqui como argumento simplesmente aquilo que é específico de cada ambiente. Então, acaba que você vai ter arquivos de configurações bem pequenininhos, onde você simplesmente referencia o módulo e seta aqueles valores que são específicos de cada ambiente. Beleza? É uma abordagem muito simples. E aqui, isso permite que a gente, por exemplo, suba o nosso ambiente de desenvolvimento em uma conta diferente, de uma forma muito simples. porque aqui eu tenho o nosso arquivo de providers, então eu posso criar aqui, referenciar um outro S3 bucket, eu posso referenciar uma outra conta, utilizando outro profile, de uma forma muito simples, é muito fácil de nós dividirmos o nosso ambiente dessa forma. Inclusive é isso que nós precisamos alterar aqui no nosso back-end de desenvolvimento, nós poderíamos colocar aqui, por exemplo, dev, então eu posso colocar aqui dev, porque agora eu preciso de um outro tfstate, eu não posso utilizar o mesmo arquivo para armazenar o state dos nossos dois ambientes, então eu vou colocar aqui um dev tfstage, para nós termos essa diferença. Aqui eu vou manter a mesma conta, já que nós temos o nosso tfvars aqui com outros prefixos. Então, agora nós conseguimos identificar os recursos na mesma conta, porém eles terão um prefixo diferente. Nós podemos vir aqui em dev, vamos abrir aqui o nosso terminal, nós podemos dar um terraform init aqui dentro de desenvolvimento beleza, ele está instalando aqui os nossos providers perfeito, e nós podemos fazer a mesma coisa agora dentro de Prod, para nós inicializarmos o nosso ambiente também, então vamos aqui dar no cd prod e vamos rodar terraform plan, na verdade não terraform plan né terraform init e o nosso backend será inicializado e agora nós teremos dois TFs feitos. Depois da inicialização aqui do nosso projeto, eu vou rodar o Terraform Apply para os dois ambientes e depois que finalizar o deploy, eu volto aqui com a gravação da aula para que a gente veja qual é o resultado, beleza? Beleza pessoal, deploy concluído, então nós podemos verificar aqui que 20 recursos foram adicionados, esse deploy que aconteceu para a nossa conta de, ou melhor dizendo, para o nosso ambiente de desenvolvimento, tá? É possível verificar aqui que eu rodei para desenvolvimento, vamos subir aqui um pouquinho, beleza, CDDev, então está acontecendo tudo aqui na pasta de Dev, e anteriormente eu também adicionei os 20 recursos no nosso diretório de produção, ou seja, nós temos ali recursos adicionados com prefixo diferente. Se nós navegarmos até a nossa conta, nós verificaremos isso. Nós podemos então navegar até VPC e nós teremos duas VPCs diferentes, além da nossa VPC default, a VPC padrão, que já vem criada na nossa conta para essa região específica. Então em VPC nós temos aqui DevFullCycleVPC com o nosso CiderBlock, um CiderBlock diferente agora de classe B, e temos aqui o FullCycleVPC para produção com um CiderBlock de classe A. Se nós verificarmos aqui, nós teremos também as subnetas específicas para cada uma dessas VPCs. Nós temos aqui todos esses recursos criados novamente com o prefixo dev full cycle podemos verificar também aqui na verdade nós vamos navegar até esse 2 que é o serviço de Cloud Compute da AWS, nós temos 3 instâncias rodando, duas dessas instâncias são de produção, já que nós colocamos o desired count igual a 2 e um desses nós é o nosso nó de desenvolvimento, já que o nosso desired count é igual a 1, nós teremos aqui então, agora dois load balancers específicos, um para produção e um para desenvolvimento e a mesma coisa para target groups e também os nossos auto-scaling groups então foi bem simples nós criarmos este outro ambiente a chave aqui é nós modularizarmos então todos os recursos eles devem ser definidos em módulos. E aqui nos nossos arquivos específicos, para cada ambiente, nós devemos simplesmente referenciar esses módulos e preferencialmente definir as variáveis que são específicas para cada um desses módulos. E como eu já expliquei anteriormente, é também possível nós alterarmos aqui em providers o nosso backend, referenciando outro bucket, referenciando aqui um outro state, isso aqui é obrigatório, na verdade, então nós precisamos referenciar um state diferente para cada um dos ambientes. A tabela em DynamoDB para os nossos locks pode ser a mesma tabela, mas caso você queira também mudar, criar uma outra tabela sem nenhum problema. E a mesma coisa aqui com o nosso provider, nós podemos utilizar um outro profile caso a gente queira fazer o deploy em uma outra conta. Beleza? Então, essa daqui é a primeira abordagem, a mais simples delas. Na próxima aula nós falaremos sobre workspaces. Eu espero que você esteja gostando, vejo você na nossa próxima aula