Bom pessoal, agora que nós já criamos o nosso primeiro exemplo em Terraform, chegou a hora de nós falarmos sobre os providers. Tudo que nós fazemos em Terraform, tudo que nós criamos utilizando Terraform, gira em torno desses providers, porque são os providers que nos fornecem os recursos que nós podemos criar na nossa infraestrutura, seja na cloud, seja local. E aqui no nosso exemplo, nós utilizamos um provider chamado local. E esse provider aqui, ele nos permite, por exemplo, criar um arquivo como nós criamos, nos permite ler arquivos quando nós utilizamos data sources, sobre os quais ainda a gente não falou, mas nós falaremos um pouco mais adiante, e nos fornece algumas outras funcionalidades. No momento em que nós rodamos o Terraform init, o Terraform vai procurar por todos os arquivos com a extensão .tf naquele diretório, ele vai ler todos esses arquivos e vai identificar quais são os providers utilizados. E os providers são identificados por essa primeira parte aqui da nossa label nos nossos resources. Ele então, uma vez que ele tem identificado todos esses providers, ele vai fazer o download da versão mais atual desse provider. Em seguida, ele fará a criação, ele vai criar esse arquivo terraform.log.hcl, informando a origem do provider, a versão e os sashes para verificar a integridade do arquivo. Então é muito importante, como eu já citei também na aula anterior, que a gente versone esse arquivo. Então é muito importante, como eu já citei também na aula anterior, que a gente versone este arquivo. Por quê? Quando nós versionamos e quando nós executamos o Terraform em uma outra máquina, em um outro ambiente, damos um Terraform init, por exemplo, ele vai utilizar este arquivo lock.hcl, caso este arquivo exista. Então ele vai identificar aqui, opa, eu já tenho um arquivo lock.hcl, então eu vou baixar este provider aqui nessa versão específica, então ele não vai tentar fazer o download da versão mais atual, ele vai baixar essa versão específica. Dessa forma, nós podemos fazer o deploy da nossa aplicação, dos nossos recursos em desenvolvimento, em produção, seja lá no ambiente que for, sem nos preocupar com incompatibilidades, com versões diferentes por todos esses ambientes. Nós garantimos que a versão dos providers serão sempre as mesmas. Quando nós falamos em provider também, uma dúvida que nós podemos ter é como nós vamos identificar quais são as versões que nós temos disponíveis para um provider, quais são os argumentos, quais são as funcionalidades que aquele provider nos oferece. Isso é muito simples, nós podemos acessar a documentação do próprio Terraform. Então, eu já estou aqui com a página principal do Terraform aberta, terraform.io, e nós podemos acessar Registry. Quando nós acessamos Registry, nós temos a opção de navegar pelos providers, pelos módulos, pelas políticas dessas bibliotecas e assim por diante. Nós vamos acessar aqui o navegador de providers. E aqui nós já temos uma informação muito importante, que são as tiers, que são as categorias desses providers. Nós temos primeiro os providers oficiais, que são os providers mantidos pela própria HashCorp, então eles têm esse selo específico aqui. Temos uma segunda categoria de providers, que são os providers mantidos por parceiros, empresas de tecnologia que têm uma parceria com a HashCorp, e temos também os providers mantidos pela comunidade. E aqui do lado direito nós temos acesso aos principais providers. Primeiro temos os providers oficiais, temos os providers mais utilizados, AWS, Azure, GCP e assim por diante. Temos uma série de outros providers aqui. Sabemos que eles são oficiais por causa do selo. Temos também os providers de parceiros, que também aqui tem esse selo azulzinho. E depois, à medida que nós navegamos aqui, nós podemos chegar até os providers da comunidade. Então, nessa página nós temos acesso a todos os providers. Agora vamos procurar aqui pelo provider local, que foi o provider que nós utilizamos. Já temos aqui acesso a ele, provider local. Temos aqui a versão atual, 2.5.1, podemos escolher uma versão específica, então podemos ir até a versão, por exemplo, 2.4.0 e aqui nós temos a documentação para essa versão específica. Então, deixa eu voltar aqui para a versão mais atual e nós podemos verificar aqui uma breve descrição do provider, temos as funções que esse provider nos fornece, ainda não falamos sobre funções temos aqui os recursos né os recursos primeiro temos local file foi o recurso que nós já utilizamos o nosso projeto e aqui nós temos como utilizar temos esquema então nós temos aqui acesso a quais são os argumentos obrigatórios required temos que file name é o único argumento obrigatório e temos aqui todos os argumentos opcionais, sendo que content foi o único argumento que nós utilizamos opcional. Beleza? Além disso, nós temos aqui também os data sources, sobre os quais a gente ainda também não falou, mas são muito interessantes, vamos falar sobre eles mais adiante. E do lado direito, temos esse use provider, Quando nós clicamos aqui, nós temos algumas informações sobre como nós utilizarmos esse Provider. E o interessante aqui, que eu gostaria que você observasse, é que nós temos um bloco Terraform. Nós temos aqui o Required Provider e nós temos a versão sendo especificada. Então, nós podemos também especificar qual versão nós queremos utilizar no nosso projeto sem nenhum problema. Nós faremos isso agora como exemplo. Então, eu vou copiar aqui este bloco Terraform, vou copiar todo o bloco, vou voltar até o nosso projeto e vou colar este bloco. Então, sempre que nós queremos especificar os providers, nós vamos colocar dentro do bloco Terraform e dentro desse bloco nós teremos um outro bloco que será o required providers e aqui nós vamos especificar esses providers. Primeiro nós utilizamos uma chave, um identificador, pode ser qualquer identificador, mas é recomendado que você utilize o nome que está sendo utilizado também no source. Então nós vamos utilizar local aqui para manter o padrão. Nós indicamos a source, então, de onde está vindo esse provider e aqui nós podemos especificar a versão. Aqui no nosso caso, estamos utilizando a versão mais atual. Mas, e se eu quiser utilizar uma versão que não seja a versão mais atual? Então, vamos supor que eu estou criando o projeto agora e eu sei que essa versão aqui está com algum problema, não é essa versão que eu quero utilizar, e eu quero utilizar a versão 2.4.1. Bom, se você especificar dessa forma e você ainda não tiver rodado o comando terraform init, ou seja, você ainda não tiver este arquivo terraform.log.hcl, basta você executar terraform init, ou seja, você ainda não tiver este arquivo terraform.log.hcl, basta você executar terraform init, que essa será a versão que vai ser baixada, tá? Agora, se você já tiver aqui o terraform.log.hcl e você quer mudar a versão desse provider, você especifica dessa forma e você vai rodar o comando terraform init e vai dar um upgrade mesmo que você não esteja fazendo um upgrade aqui no caso nós estamos fazendo um downgrade, mas o comando será exatamente o mesmo e aí nós podemos observar que o arquivo terraform.loc já foi modificado e quando nós clicamos aqui nós temos que a versão é 2.4.1, nós temos a restrição 2.4.1 e temos aqui os novos hashes. Então, é dessa forma que nós conseguimos trabalhar com as versões em Terraform. Nós conseguimos especificar exatamente a versão com a qual nós queremos trabalhar. Porém, não só isso, nós conseguimos também especificar constraints, nós conseguimos especificar restrições. Se nós observarmos aqui a documentação, eu estou aqui com essa página aberta, version constraints aqui do próprio Terraform, nós podemos utilizar essa sintaxe, onde nós dizemos que nós queremos uma versão maior ou igual, por exemplo, a versão 1.2.0, mas que seja menor do que a versão 2.0.0. Então, nós temos essa flexibilidade no momento de especificar as versões. E a versão a ser escolhida será definida no momento que você rodar o Terraform Init ou o Terraform Init-Upgrade, beleza? ou terraform init traço upgrade, beleza? Não só isso, eu gostaria de mostrar também uma forma de especificar essas constraints, essas restrições, de uma forma muito interessante, que é essa forma aqui, onde nós temos esse til e esse símbolo de maior. Se nós lembrarmos, se nós relembrarmos os conceitos de versionamento, e eu estou aqui com a página Semantic Version em aberta, e nós temos que, sempre que nós temos um versionamento aqui, onde nós temos um número separado por outro, separado por outro, através de pontos, nós temos o seguinte. Começando pelo lado direito aqui, pela parte direita, nós temos o patch. O patch é a versão que corresponde à correção de bugs ou algum ajuste, alguma melhoria de segurança, que não adiciona nenhuma funcionalidade nova e que não quebra a compatibilidade. Quando nós temos uma alteração minor, que nós alteramos a versão aqui nessa parte minor, significa que novas funcionalidades foram adicionadas, porém a compatibilidade permanece. Nós não precisamos atualizar o código fonte da nossa aplicação, por exemplo, ou o código fonte do nosso projeto. Nós podemos manter exatamente da mesma forma porque tudo vai continuar funcionando, mas agora nós temos mais recursos que nós podemos utilizar. Porém, quando nós temos uma atualização major, significa que houve uma quebra de compatibilidade. Então, algumas coisas que antes estavam funcionando, agora podem não funcionar daquela forma mais. Então, o seu código vai precisar ser alterado. E aqui, quando nós falamos em version constraints, nós podemos fazer o seguinte, se nós especificarmos essa sintaxe aqui, por exemplo, que nós queremos maior que 1.0.4, vai permitir que o Terraform instale 1.0.5, então ele permitiu aqui uma atualização de versão, uma atualização patch, vai permitir também que instale 1.0.10 sem nenhum problema, porque é uma atualização de patch, porém não vai permitir instalar 1.1.0. O que está acontecendo aqui? Essa restrição impõe que a versão minor deve permanecer. A versão minor é 1.0. Porém as atualizações de patch podem ser baixadas, podem ser utilizadas desde que elas sejam maiores do que o patch 4, do que a versão 4, certo? Mas além disso, nós conseguimos especificar aqui uma restrição mais abrangente, onde nós especificamos simplesmente até o minor, nós especificamos o patch, tá? Isso nos permite instalar, por exemplo, a versão 1.2, 1.10, mas não nos permite instalar uma outra versão major, não nos permite instalar uma versão 2.0. Dessa forma a gente consegue brincar aqui com esse tipo de atualização, com esse tipo de restrições de versões. Então vamos para um exemplo, vamos dar uma olhada aqui nas versões que nós temos disponíveis para este recurso. E nós podemos, como exemplo, utilizar o seguinte, a versão 2.5.0. Então, se nós fizermos dessa forma, especificando 2.5.0, e nós rodarmos aqui perform init upgrade, nós vamos ter aqui que a versão utilizada será a versão 2.5.0. Então, nós temos aqui 2.5.0, que é uma versão acima de 2.5.1, desculpa, né? Essa foi a versão utilizada. A nossa restrição é 2.5.0. Beleza? Porque houve uma atualização de patch e as atualizações de patch são bem-vindas. Agora nós podemos especificar também, por exemplo, 2.1 somente. E se nós dermos aqui um terra form, se nós rodarmos de novo o nosso comando, vamos verificar aqui se vai ser feita alguma atualização. Não foi feita nenhuma atualização. Por quê? Porque nós identificamos que a versão 2.5.1 já é a versão mais atual. Agora, se nós especificarmos, por exemplo, 2.4.1 e rodarmos novamente, na verdade não 2.4.1, vou especificar 2.4.0, dermos um upgrade, nós vamos instalar a versão 2.4.1. Por quê? Porque nós temos que manter a mesma versão minor. Nós podemos atualizar simplesmente o patch quando nós especificamos uma versão de patch aqui dentro. Beleza? Então, dessa forma aqui, nós já entendemos sobre as restrições. Eu vou manter fixo, eu vou manter aqui a versão exata para que a gente não tenha nenhum problema. E dessa forma, nós já entendemos como funcionam os providers, como nós podemos acessar a documentação e como nós podemos gerenciar as versões desses providers. Eu espero que você tenha gostado. Vejo você na nossa próxima aula.