Seu Primeiro Projeto Prático DevOps COMPLETO: Docker, AWS, Terraform e CI/CD!

Seja muito bem-vindo ao primeiro episódio do laboratório de voz. Você estuda, lê livros, assiste aulas, mas sente que falta algo concreto, né? Que a teoria ela não se conecta com a prática. Eu sei exatamente como é isso e foi justamente pensando nisso que eu criei essa série pra gente colocar a mão na massa de verdade. Eu sou a Maria, engenheira de VOPS e hoje eu vou te guiar por um guia prático de projetos DevOps, pensado para você dar os seus primeiros passos na carreira e melhor ainda, construir um projeto que você pode colocar no seu

portfólio do GitHub. Hoje mesmo a gente vai começar do zero e evoluir até um fluxo totalmente automatizado. E o melhor é que essa série ela vai ser 100% gratuita para que qualquer pessoa possa acompanhar sem gastar nenhum centavo. Nesse vídeo a gente vai construir um projeto do zero em três fases. Primeiro, a gente vai Containerizar e fazer o deploy manual de um site estático na AWS. Depois a gente vai automatizar toda a parte da infraestrutura com o Terraform. E para fechar com chave de ouro, a gente vai implementar uma automação completa com CD utilizando o

GitHub Actions. Vai ser uma jornada do simples até algo mais avançado, mais elaborado, pensada para quem quer aprender de verdade e ganhar a experiência prática. Então já deixa seu like, se inscreve no canal e ativa o Sininho para que você não perca nenhum episódio dessa série. E antes da gente começar, é muito importante que você tenha alguns conhecimentos básicos. Não precisa se preocupar porque você não precisa ser um expert, mas você precisa ter uma base para te ajudar a acompanhar essa aula. É importante que você saiba Linux, os comandos básicos do terminal, que você entenda,

né, sobre Docker, o que que é um contêiner, uma imagem, Docker file, que você tenha Conhecimentos básicos de Git para poder clonar os repositórios e que você saiba o que é a WS, tenha as noções básicas do que que é uma EC2, enfim. E pro seu ambiente de trabalho, certifique-se de ter a AWSCLI instalada e configurada, uma conta na AWS criada e o Docker já instalado na sua máquina. E por fim, um editor de código como VS Code, por exemplo, para que a gente consiga fazer esse laboratório. Se você já tem tudo isso pronto, então

bora pro projeto. Então vamos lá, pessoal. Esse daqui é o nosso repositório, aonde vai estar todas as fases do projeto com a devida documentação. Então vocês podem ler com calma, entender do que que se trata e clicando dentro de cada fase aqui também tem toda uma documentação explicando o passo a passo que eu vou seguir aqui. Então, antes da gente de fato partir pra prática desse projeto, a gente precisa entender o seguinte, a gente precisa entender como que funciona o fluxo de Desenvolvimento de um produto. Igual eu falei no meu vídeo sobre o dia a

dia prático de um engenheiro de VOPS, a gente precisa entender do negócio como um todo, ou seja, nós precisamos ter uma visão ampla do que que a empresa vende, de quais são os objetivos estratégicos dessa empresa para que a gente consiga atender a demanda de uma forma mais eficiente. Então, eu desenhei aqui um fluxo e eu vou explicar para vocês sobre a nossa empresa fictícia. Então, a Partir de agora, você é oficialmente o engenheiro DevOps Júnior e você foi contratado na empresa X. Uma empresa, ela geralmente desenvolve um produto para um determinado cliente. Ela atende

uma demanda e o cliente ele paga por esse produto ou serviço. Esse é o objetivo principal de uma empresa. Então, pensando aqui, o nosso produto vai ser um website estático. Então, a nossa empresa, ela desenvolve sites. Eu pensei aqui numa aplicação bem simples, Então vai ser um site estático, não vai ter conexão com banco de dados, nada disso, mas quem sabe mais pra frente aí a gente não continue este laboratório e, enfim, faça o deploy de aplicações mais complexas que vão se aproximar de fato do dia a dia prático. Mas como eu quis trazer algo

aqui para pessoas iniciantes, vamos começar com o website estático. E aí, como que funciona, né? Uma empresa, ela olha a demanda do mercado e ela começa a desenvolver, a Pensar no escopo do produto, né, que ela vai vender. E este produto, por consequência, ele se torna um projeto. E esse projeto ele vai ser dividido em fases, em etapas. E cada time vai ser responsável por uma etapa. Então aqui no meu desenho, por exemplo, na etapa um, os desenvolvedores, né, frontend, backend, enfim, eles vão construir a aplicação, eles vão construir o site, escrever o código HTML

e CSS, JavaScript. Com esse site, né, já Desenvolvido, o pessoal do time de, por exemplo, vai fazer os testes, as validações. O time de infraestrutura vai subir o ambiente aonde essa aplicação vai rodar. Aqui no meu caso, onde eu trabalho, eu também sou responsável pela infraestrutura. Então eu como devops, eu crio o ambiente essa aplicação ela vai estar funcionando. Aqui eu até dupliquei, isso aqui não precisa. E aí a gente de fato entrega esse projeto, esse produto pro nosso usuário final. E tem o Time de operações que vai manter este site de pé, eh, vai

monitorar, vai resolver incidentes caso dê algum problema em produção. Então, o time de operações fica responsável por manter. O time de desenvolvimento vai desenvolver, vai criar aplicação e o time de operações vai manter essa aplicação. E nós do time devols, nós vamos estar olhando para todo este processo de desenvolvimento do software, pensando numa forma de melhorar, simplificar e Automatizar todo este processo. Aqui eu coloquei para vocês uma imagem do ciclo de vida do desenvolvimento do software, que a fase um consiste no planejamento. Depois a gente tem, né, a análise de requisitos, o design, a codificação

e testagem, a implantação em si, que é a entrega, né, e a manutenção que é feita pelo time de operações. Eu recomendo fortemente que você estude sobre o ciclo de desenvolvimento de software, porque nós como DevOps sempre vamos estar Olhando para essas etapas e pensando numa forma de melhorar todo este processo. E aqui, né, se você nunca viu, este daqui é o símbolo do DevOps, que é o infinito, aonde a gente tem todas essas etapas e o DevOps vai sempre estar olhando para todas essas etapas que eu expliquei. Então, vamos lá. Por que que a

empresa ela contrata um engenheiro de vóps? Ela não contrata porque tá na moda, né? Enfim, ela contrata porque ela tem um objetivo e este objetivo é Resolver problemas. Então, nós fomos contratados aqui na nossa empresa fictícia para resolver um um problema. O que que tá acontecendo hoje? O deploy do site pros nossos clientes, ele é feito totalmente de forma manual, ou seja, o desenvolvedor ele faz a aplicação, né, o site e depois esse site tá pronto, ele envia o código para o GitHub, né, que é onde a gente armazena os códigos. E aí a pessoa

responsável por fazer o deploy dessa aplicação, ela entra de forma Manual no servidor, aonde vai ficar hospedada essa aplicação. Então ela entra manualmente na máquina, ela instala o NJNEX. Então para quem não sabe, o NJNEX ele é um servidor web, né, que ele pode servir conteúdo estático, ou seja, quando a gente acessa a aplicação, tem o JNEX por trás. Então, voltando aqui pro nosso desenho, é, a pessoa que era responsável pelo deploy dessa aplicação, ela instalava o Injnex na mão dentro do servidor. Aí ela Copiava os arquivos, né, que estava na máquina dela, do website

para este servidor e ela iniciava o serviço. Só que o que que acontecia, eh, o que que acontecia, ou melhor, está acontecendo na nossa empresa fictícia de problemas para nós resolvermos. Não existe só este site rodando aqui nessa instância. A gente paga por essa instância, certo? A gente precisa aproveitar todos os recursos que essa instância fornece pra gente, pra gente conseguir rodar as Nossas aplicações. Então, quando você for e trabalhar para uma empresa, é muito raro da gente ter um servidor exclusivo para uma aplicação específica, por exemplo, um site WordPress. É muito raro você ver

isso. Geralmente na mesma instância vai ter um banco de dados, vai ter uma aplicação node, vai ter outros websites, enfim. Então, nesse caso específico aqui da nossa empresa, a gente tem vários aplicações rodando neste servidor, nesta máquina. E aí, Quando a gente faz esse processo de forma manual e sem nenhum tipo de isolamento, geralmente os erros que dão é conflito de dependências, né? Então, às vezes eu vou instalar o Injnex e nessa máquina já poderia estar instalado um servidor Apach e aí a porta 80, que é a porta padrão, já estaria sendo utilizada por outro

serviço e daria conflitos, né, conflitos com outras aplicações que estão presentes nessa máquina. Então, há uma falta de Isolamento muito grande. Isso pode causar diversos problemas. Eh, um problema clássico é você entrar manualmente no servidor, editar algum arquivo de forma errada, apagar algum caminho e aí você acaba prejudicando outras aplicações, outros sites que estão rodando dentro dessa máquina. Outro problema também é a dificuldade da gente conseguir replicar esse ambiente. Então, por exemplo, a gente quer subir uma instância exatamente igual a essa Para o ambiente de homologação. Como que a gente faz isso de forma manual,

com tudo isso rodando? é muito complicado de fazer, muito custoso. Fora aqui pode haver versões diferentes. Então, na máquina do dev, às vezes ele tá rodando uma versão do Engine, que nesta máquina em específica é outra versão e isso dá também dá problemas. E aí quem sofre com tudo isso é o cliente final, é a empresa perdendo dinheiro, porque a gente demora para fazer o deploy dessa aplicação. Às Vezes o cliente não vai conseguir acessar, vai ficar fora porque a gente errou. Tudo isso tá gerando prejuízo para a empresa. Então, a empresa ela contratou a

gente para resolver esses problemas. E nós, como engenheiros de BOPs, nós sempre temos que pensar em como a gente vai reduzir o tempo de entrega do produto, como que a gente vai consumir menos recursos, né, e consequentemente menos dinheiro. Então você como engenheiro de Volop sempre tem que est olhando para isso, olhando para os objetivos do negócio. Então, depois de ter toda essa análise desse cenário, a gente vai começar a estruturar na nossa cabeça como que nós vamos resolver o problema de falta de isolamento que está tendo no nosso servidor, na nossa empresa atual. Chegou

pra gente a demanda, vamos subir uma aplicação, vamos subir um website para o nosso cliente num servidor, só que de uma forma que esse servidor ele Possa ser compartilhado e tenha isolamento entre as aplicações. Então, para isso, o nosso fluxo vai ser praticamente o mesmo. O desenvolvedor, ele vai entregar a app pronta pra gente no GitHub e nós, como DevOps vamos criar uma imagem desta aplicação. Nós vamos criar toda a infraestrutura para este projeto. No nosso caso aqui vai ser o ECR, que é onde nós vamos armazenar as nossas imagens. E nós vamos subir uma

máquina, uma instância E S2, baixar a Imagem que nós armazenamos no SR dentro da nossa S2. Nós vamos rodar este contêiner aqui no servidor e aí o nosso cliente vai conseguir acessar essa aplicação pelo navegador dele. Então vamos lá, bora pra prática. Então vamos lá pessoal, vou criar uma nova pasta aqui paraa gente começar a trabalhar no nosso projeto dentro de uma pasta que eu já tenho chamada projetos e a pasta vai chamar Lab. Eu vou entrar dentro dela e aí eu vou clonar o meu repositório. Então eu vou copiar o RL do repositório aqui

e vou colar aqui, fazer o git clone. Beleza? Com repositório clonado, eu vou abrir o meu VS Code. Com meu Visual Studio Code aberto aqui, a gente já tem a estrutura das pastas e cada pasta, né, cada fase vai ter a referência e o arquivo do código e o readm instruções para você seguir esse laboratório. Pra gente não se confundir aqui, eu vou copiar a pasta website, que É onde de fato está a nossa aplicação, e vou colar aqui fora. Então vamos pensar como que funciona no dia a dia, né? chega pra gente a aplicação,

é o o código dessa aplicação, como é o caso aqui do website, e nós vamos ser responsáveis por fazer o deploy desta aplicação. Qual que é a primeira coisa que a gente faz? Analisa a aplicação, entende o que ela é, para que que ela serve. Então, no nosso caso aqui, é um site estático que está desenvolvido em Código HTML, que possui um JavaScript e também um estilo do CSS. Pra gente conseguir visualizar, né, a nossa aplicação, eu tenho uma extensão chamada Live Server. Então, se você vir aqui em extensões e pesquisar por Live Server, é

esse daqui, tá? Você pode baixar. E aí, clicando com o botão direito no HTML, a gente consegue Open with Live Server. É só você clicar aqui em Open with Live Server que vai aparecer pra gente aqui o site. Então, esse aqui é o nosso site Que a gente vai fazer o deploy, tá? bem basiquinho mesmo. E aí você consegue visualizar. Qual que é a primeira coisa que a gente vai fazer? A gente vai pensar numa forma de empacotar essa aplicação. Ou seja, nós vamos criar uma imagem para essa aplicação, pro nosso site estático. E a

nossa imagem, ela vai se basear no enginex. Então, a gente sempre analisa o problema, o cenário, e aí paraa gente desenvolver uma solução, a gente precisa entender o que era feito Antes e como que a gente pode adaptar esse processo para poder fazer de uma forma mais eficaz. Então, no processo antigo, o desenvolvedor, a pessoa, ela entrava manualmente na máquina até ir, OK? e ela instalava o JNEX na mão. Só que ao invés da gente instalar as coisas na mão, a gente vai utilizar o arquivo que a gente chama Docker File para poder criar a

nossa imagem. E aí a gente vai se basear no Njx. Maria, não tô entendendo nada, sem problema, vamos com Calma. Então aqui eu vou criar um novo arquivo chamado Docker File. Então né, ao invés da gente entrar na máquina e instalar tudo manualmente, nós vamos criar o que nós chamamos de Docker File. Mas o que que é um Docker File? Um Docker File é como se fosse uma receita de bolo pra sua aplicação. Nele vai conter todas as informações e instruções para você montar o ambiente aonde a sua aplicação ela vai rodar. Então primeiro a

gente precisa pensar, nós vamos se Basear no quê? No Engine Next. Então, a gente inicia sempre o Docker file com from e eu vou digitar enginear a versão do Alpine. O que que é isso? O Alpine é uma distribuição Linux minimalista e ela é perfeita para contêiners porque ela ocupa muito pouco espaço e ela é bem segura. E da onde que eu tô tirando isso daqui, né? A gente tem o que a gente chama de Docker Hub, que é onde ficam armazenadas todas as imagens do Docker, certo? Então, é um Repositório comunitário onde as pessoas

elas sobem as imagens aqui e a gente tem imagens oficiais, como por exemplo a imagem do NJ Next. Tem várias versões do NJ Next aqui e eu escolhi a versão Alpine, tá vendo? Se eu clicar aqui, ele mostra para mim todo o Docker File do Engine Next na versão Alpine. E aí a gente tem a imagem do Enginex. É que ele até mostra, né? Ele dá pra gente aqui toda a documentação falando como que eu posso criar uma imagem baseada no Enginex. Então aqui é o from Engine, dois pontos eu passo a tag. A tag

é o Alpine no caso. E aí aqui a gente tem o nosso segundo comando, que é copy static HTML directory para este caminho aqui. Isso nada mais é do que o que o desenvolvedor, a pessoa quando ela fazia de forma manual, ela fazia na máquina. Então ela copiava os arquivos do site. Quando eu falo arquivos do site, eu tô falando do HTML, do CSS e do JavaScript. Ela copiava esse conjunto de arquivos Para dentro deste pés, né, para dentro deste caminho barrausr share html, que é o caminho padrão, o caminho root do servidor em JNEX.

Só que ao invés da gente copiar isso diretamente dentro lá da instância da máquina S2, a gente vai fazer isso no nosso arquivo Docker File, porque a gente vai copiar os arquivos que está dentro de website, né, dentro da nossa pasta para dentro do contêiner neste PEF. Então, eu não sei se você tá reparando, mas a gente tá Meio que melhorando o processo que já acontecia. A gente tá fazendo, entre aspas a mesma coisa, só que de uma forma bem melhor, bem mais escalável, bem mais rápida. Então aqui eu posso até copiar essa parte aqui

da documentação do COP e vou colar no nosso arquivo Docker File. E como que funciona o comando copia? A primeira parte do comando é a pasta, o arquivo que a gente quer copiar, né? É onde a gente vai fazer o contrl C. E a segunda parte depois do espaço é o Caminho dentro do contêiner que a gente vai colar, né, que a gente vai mover esses arquivos. O que que eu vou copiar aqui? No meu caso, eu vou copiar a pasta website. O arquivo Docker File, ele tá no mesmo lugar que o website. Então, se

eu abrir o terminal aqui e eu der um LS nessa pasta lab, se você reparar, o Docker File está na mesma pasta que a pasta website. Então aqui eu vou passar apenas o nome da pasta. Então ele vai copiar tudo que tá dentro de website. O Que que tá dentro de website? O código CSS, JavaScript e o index html. E eu vou colar, né? Eu vou mover esses arquivos para dentro deste lugar aqui no meu contêiner. Feito isso, a gente precisa expor a porta desse contêiner para que ele receba as requisições, né? Para que ele

consiga receber as requisições externas. A porta padrão para conexões, né, HTTP é a porta 80. Então é literalmente o comando expose, qual porta? 80. E por fim a gente precisa Rodar um comando que vai iniciar o NJ Next e manter, né, o NJNX rodando. Então, pensando no nosso cenário antigo, a pessoa que era responsável pelo deploy, ela rodava ali um CCTL Start Enginex, então ela iniciava o serviço do Engineex. Como que a gente faz isso aqui no nosso Docker file, dentro do nosso contêiner? a gente roda um comando e para isso a gente utiliza o

cmd. E aqui eu vou até dar o tab que ele tá completando aqui para mim. Caso você Esteja com dúvida, eu até perguntei pro copilot aqui qual que é o significado específico de cada parte desse comando aqui para que você entenda. Então o cmd é a instrução do docker file que vai definir o comando que eu vou executar é quando o meu contêiner iniciar. Cada elemento desse array é um argumento separado. Então eu vou rodar em J Next, que é o executável principal do servidor. Então menos G é a flag que eu tô passando, certo?

Que ela é global. E Aí aqui é o que que eu quero, né, de configuração, neste caso, Demonf, que vai instruir o NJNEX a rodar em primeiro plano. Aqui até tá falando por, né, que que isso é importante. É porque o contêiner precisa manter o processo principal rodando e se o NJ Next rodasse em background, o contêiner iria encerrar imediatamente. Quando a gente tá trabalhando com Docker, o contêiner ele só vive, ele só fica funcionando quando há um processo ativo. Se o processo ele Por algum motivo para, né, ou inicia e termina, o contêiner termina

quando não há nenhum processo ativo. Bom, o nosso Dockerfile já está completo, então toda aquela parte que a pessoa ela faria manualmente dentro do servidor, a gente passou para cá, né? Então, a gente, entre aspas, instalou o Enjinnex já utilizando uma imagem base do INJNX na versão Alpine. A gente copiou todos esses arquivos para dentro do PEF padrão do NJNX. A gente expôs a porta 80 e a Gente rodou o comando para manter esse contêiner funcionando. Só que eu só criei o arquivo, né? Isso não tá rodando em nenhum lugar, não tá funcionando. O que

que eu tenho que fazer agora? A gente precisa empacotar, a gente precisa criar a imagem do nosso site. Então, o que que eu tenho que fazer agora? Eu preciso fazer o build desta imagem. Se eu digitar o comando docker images, ele vai listar para mim todas as imagens que eu tenho aqui na minha máquina. No caso, Eu não tenho nenhuma. Para buildar essa imagem, eu vou rodar o comando docker build. E aí eu vou passar a flag men- T, que eu vou dar um nome para essa imagem. O nome, no caso, vai ser, ã, por

exemplo, meu site. Eu aperto dois pontos e eu preciso passar a tag dessa imagem, ou seja, qual a versão dessa imagem. No meu caso, vai ser a versão 1.0. E aí, depois desse comando, eu preciso passar aonde está, né, o caminho do meu Docker file. No meu caso, eu vou digitar o Ponto. Por quê? Porque o Docker File está na mesma pasta que o comando onde eu estou rodando. Então, ele está na pasta lab. E aí eu digito o ponto e já vai funcionar. Aqui eu digitei errado, é Docker build. E beleza, ele já tá

buildando, já buildou a minha imagem aqui. Se eu der um Docker images novamente, ele já vai aparecer aí o meu site. Aqui tá aparecendo há 15 minutos atrás porque eu já havia criado a imagem e não fiz nenhuma modificação. Então Aqui ele me dá o nome da imagem, a tag, um ID único para esta imagem, o tamanho e o tempo de criação, né? Desde quando essa imagem está criada, tá? Eu já criei imagem, Maria. E agora como que eu acesso a aplicação? Imagem é diferente de contêiner, tá? O contêiner ele se baseia numa imagem para

rodar, mas eu posso ter, por exemplo, vários contêiners que utilizam a mesma imagem. Então a imagem ela serve para isso. Você empacota a aplicação nela e aí você pode Rodar vários contêiners com a mesma imagem. E aí para poder rodar essa imagem, certo? Eu vou rodar o comando docker run. Eu vou passar a flag - D pro nosso terminal não travar. Eh, porque se eu não passar essa flag aqui, vai ficar aparecendo os logs e eu não vou conseguir sair do terminal depois. O parâmetro - P, que é a porta que eu vou acessar esse

contêiner. Então, vou digitar a porta 8080, que vai redirecionar paraa porta 80 do meu Contêiner. Essa parte aqui eu sempre ficava em dúvida quando eu tava aprendendo sobre Docker. A primeira parte é a porta aonde eu vou acessar no meu computador, na minha máquina. E a segunda parte é a porta do contêiner que está exposta. No nosso caso aqui, a gente expôs a porta 80. Então aqui é a porta 80 que eu quero acessar. A primeira parte aqui pode ser qualquer porta. Então aqui, por exemplo, eu poderia digitar a porta 3.000, porta 50, Enfim, vai

depender muito da ocasião do caso. É, poderia inclusive digitar a porta 80 mesmo para ficar os dois iguais e tanto faz, tá? E aí eu preciso passar qual que é a imagem que este contêiner utilizar. No nosso caso aqui é a imagem que a gente acabou de criar chamada meu site. Então vai ser meu site. E qual a tag, qual que é a versão dessa imagem? É a versão 1.0. Pronto, apareceu o hash aqui. Significa que o nosso contêiner está rodando. Como que eu sei se esse Contêiner tá rodando? Eu digito o comando dockerps. Aqui

a gente consegue ver que já tem o processo rodando aqui do nosso contêiner. Então ele vai ter um ID, ele vai ter a imagem, foi criado há 10 segundos atrás. Então aqui a porta 8080 está redirecionando para a porta 80. E esse name aqui apareceu um nome aleatório porque eu não passei a flag name, mas se eu quisesse eu poderia rodar um contêiner aqui, por exemplo, e passar menos name e o nome que eu Quisesse. Por exemplo, site dois. E aí eu vou só trocar a porta aqui na porta, na porta 3.000. Aqui eu tô

rodando outro contêiner com a mesma imagem. E aí, se eu der um Dockerps, a gente tem dois contêiners usando a mesma imagem. E aqui aparece o nome dela, tá vendo, ó? Site dois. E como que eu entro, né? Como que eu vejo? É só digitar no meu navegador, local host dois pontos, a porta que eu quero acessar, no caso 8080. E aí a gente já tem o nosso site. Se eu digitar Também a porta 3.000, que é do segundo contêiner, a gente também vai ter o mesmo site, né? Porque no caso é a mesma imagem.

Então beleza, a gente já validou, já testou localmente aqui, já viu que o nosso contêiner tá funcionando, é só a gente parar o contêiner. Para isso, a gente digita o comando docker stop e eu copio aqui o ID desse contêiner que eu quero parar. Beleza, já parou. Docker PS de novo. Eu vou parar esse aqui também. Então, Docker stop. E agora se eu der um Docker PS, a gente não tem mais nenhum contêiner rodando. Se eu der um Docker PS-A, eu vou ver todos os contêiners que foram criados aqui por mim e que eles estão

inativos, certo? Eu recomendo que você exclua esses contêiners. Para excluir é só você dar um docker RM e passar o ID do contêiner. Por exemplo, eu quero remover o site do aqui, Docker RM. E pronto. Se eu der um Docker PS - A, apareceu os dois. E aí faça isso, Remova os contêiners aí. E beleza, então do nosso escopo aqui, a gente já conseguiu criar e empacotar a imagem da nossa aplicação. E o que a gente vai fazer agora vai ser a infraestrutura, ou seja, nós vamos provisionar todos os recursos na AWS. Então, a nuvem

escolhida aqui é a WS. E a gente vai criar um ECR, né, um elastic container registry, que nada mais é do que um repositório de imagens da AWS. É como se fosse um Docker Hub. E nós vamos Provisionar um servidor na nuvem. No nosso caso aqui, esse servidor se chama EC2, que são instâncias na AWS. Então, com o meu console da WS aqui, eu vou clicar em elastic containeristry. Se ele não tiver aparecendo aqui para você, é só você pesquisar, digitar esse R aqui. Aí já aparece aqui Elátic container registry. E aqui eu vou clicar

em create. Repara, pessoal, que eu tô trabalhando na região de Ohio, né, US2. Eh, eu recomendo que você verifique a Região que você está e que você crie os recursos, todos os recursos na mesma região. Para quê? Para você evitar se perder, porque são várias regiões e aí você acaba esquecendo algum recurso ligado. Então, sempre que você for fazer um laboratório, escolha uma região e crie tudo na mesma região para você não se perder. Dito isso, aqui, a gente vai dar um nome pro nosso repositório, aonde a gente vai armazenar a nossa imagem. No meu

caso aqui, eu vou colocar site prod E eu não vou mudar nada, eu vou deixar as configurações padrão e eu vou clicar em create. Beleza, ele já criou aqui o meu repositório e ele já me dá a URL deste repositório. Esses primeiros números é o número da minha conta e aqui a região. Então essa é uma URL padrão. Todas as URLs do ECR, elas possuem essa nomenclatura, este padrão. E o barra, tudo que vier depois do barra é o nome do nosso repositório privado. E como o nome já diz, é um repositório privado, Ou seja,

como que eu vou enviar a minha imagem que eu acabei de criar para dentro do ECR. Para isso, a gente precisa se autenticar. Não é qualquer pessoa que vai conseguir baixar essa imagem ou enviar alguma imagem para esse repositório, porque ele é um repositório privado. Diferente do Docker Hub, aonde a gente consegue, por exemplo, baixar a imagem do NEX, que foi o que a gente fez para poder buildar essa imagem nossa, aqui a gente não vai conseguir fazer Isso. Então, grande parte das empresas, eu diria maioria, utiliza repositórios privados porque eles não querem que qualquer

pessoa acesse as suas imagens. Então, para se autenticar dentro do SR, a gente precisa de um login e de uma senha. Como que eu consigo esse login e essa senha? Se eu clicar aqui no canto em Security Credentials, aqui ele vai me dar as informações da minha conta. E aqui tem a parte de access keys, que é onde eu gero um login e uma senha pro Meu usuário, no caso, o usuário varia laser. Aqui já tem uma access key criada, mas se você não tiver, é só clicar aqui em create access key, é command line

interface, por exemplo, e aí você segue todas as etapas, ele vai te dar o seu login e a sua senha. E aonde que você insere este login e essa senha? Voltando aqui pro meu VS Code, se eu digitar a WS configure, eu consigo já fazer as configurações da WS e colocar o meu usuário e a minha senha. Então, no Access Key, eu vou passar o Access Key. No meu caso, eu já configurei. Se eu apertar enter, aparece o secret access key, né, que seria entre aspas a senha. E aí você coloca o secret, a região

default, no meu caso, tá? O S e X2. Aí você coloca a região que você está trabalhando e o output você pode deixar Jon mesmo. E pronto, as configurações, né, as credenciais já foram setadas, já foram configuradas e aí a gente vai conseguir fazer o login do SR Tranquilamente. Para fazer o login na WS, a gente vai utilizar este comando, que ele é um pouco grande, tá? Eu já colei aqui que basicamente essa primeira parte aqui antes do pipe é aonde eu vou gerar uma senha temporária que ela dura aproximadamente 12 horas para me autenticar

no ECR, né, no repositório privado da WS. Esse Docker login com username AWS é um comando padrão pra gente fazer login utilizando essa credencial que foi gerada nesse primeiro Comando. Então aqui eu vou só substituir pelas informações. A minha região aqui é o S2. Aqui eu vou colocar a minha conta da WS. É só clicar aqui no account ID e copiar. E aqui eu vou passar a região que eu estou trabalhando que é a US IS2. Ah, Maria, por que que você não coloca aqui o barra site, né, que é o nome do nosso repositório?

Porque aqui eu tô fazendo login no ECR, né, no serviço da WS elastic container register e não no repositório privado em si. Então é só a Gente apertar enter aqui que ele vai fazer o login. Aqui deu erro pessoal porque eu digitei errado. É o S East 2. E beleza, ele já fez o login. Com o login feito, a gente precisa enviar a imagem que a gente gerou para o ECR. Então se eu digitar Docker images, eu tenho a imagem que foi gerada aqui do meu site. Como que eu pego essa imagem que eu gerei

na minha máquina e armazeno ela, envio ela para o SR? Eu preciso dar uma tag para essa imagem. Então eu Preciso gerar uma tag que vai dizer que esta imagem ela vai ser enviada para o então para isso eu vou escrever docker tag. Eu vou passar qual imagem eu quero colocar uma nova tag. Então no caso é a imagem chamada meu site na versão 1.0. E aí eu digito qual a nova tag que essa imagem vai passar a ter. A nova tag é aí sim de fato essa URL aqui. Então vou clicar e copiar ela.

Vou colar aqui dois pontos e eu coloco uma tag específica, uma versão específica para essa imagem. Eu vou manter a mesma 1.0. Se eu der um docker images agora, vai aparecer a minha imagem aqui. Se você reparar tem o mesmo ID, porque é a mesma imagem. A gente só adicionou uma nova tag a essa imagem. E agora para fazer o envio dela pra CR é bem simples. É só a gente digitar docker push. Qual imagem que eu quero enviar, né? Esta imagem aqui e qual versão? Na versão 1.0. Se eu der enter agora, ele vai

começar a fazer o push lá pro repositório. Então, entrando Dentro aqui do repositório privado, a gente já consegue ver a nossa tagada. Então, aqui do nosso projeto, a parte do ECR já foi feita. Agora o que falta é a gente provisionar uma instância S2 na AWS. Pra isso, aqui na AWS, a gente vai vir no serviço EC2 e clicando em instâncias, a gente clica em launch instan para poder criar uma nova instância. Aqui eu vou dar o nome, por exemplo, de website server. Aqui você pode escolher qual sistema operacional Vai ter esse servidor. No meu

caso, eu vou deixar Amazon Linux mesmo. E aqui nessa AMI que é free tier. Descendo um pouco na parte de tipo da instância, a gente tem diversos tipos de instância aqui para cada ocasião. Essa instância aqui, por exemplo, tem 8 CPU, 32 GB de memória. Eh, mas no nosso caso, pode deixar a T2 micro mesmo, que ela é bem pequenininha, tem um VCPU e 1 GB de memória. E ela é frer, ou seja, a gente não vai ser cobrado pela WS. Tome Bastante cuidado na hora de selecionar a instância, porque existem instâncias muito caras aqui,

tá? como, por exemplo, essa daqui que custa cerca de $.000 por hora. Então, cuidado. Aqui na parte da Kir é onde a gente vai gerar uma chave SSH para poder se conectar na nossa instância. Então eu posso selecionar uma existente, mas no nosso caso aqui eu vou criar uma nova chave. Eu vou dar o nome, por exemplo, de chave site prod. E aí eu vou deixar no tipo RSA e no formato Ponpen. Se você estiver usando Windows, eh, vai ser essa outra versão. Eu não vou entrar em detalhes aqui porque não é o foco do

nosso projeto, mas é bem simples. Você pode pesquisar aí no YouTube como que você faz para poder se conectar na instância via SSH com o sistema operacional Windows. E aí é só clicar em create pair que ele vai gerar um arquivo pra gente baixar. Beleza? Já baixei a chave aqui. Aqui é as configurações de network, certo? de Rede. No caso, a gente vai criar uma Security Group. E o que que é uma Security Group? Nada mais é do que um fire. É na Security Group que vai conter as regras de entrada. Então aqui já tem

algumas que você pode selecionar. No meu caso, vou permitir o acesso SSH do meu IP apenas. Também vou permitir o acesso https e o acesso HTTP para que a internet, né, os todos os IPs do mundo possam acessar a minha máquina na porta 80, né, na porta default e na porta 443, Que é a porta https. Aqui de resto, eu vou deixar tudo padrão e é só clicar em launch instance. E pronto, a WS já vai começar a provisionar uma instância S2 para mim. Se eu voltar aqui em instâncias, ele já começa a subir. O

status está pendente aqui embaixo. Eu consigo também ver as informações desse servidor. Eu vou clicar aqui no endereço público e colar aqui para vocês verem que não vai aparecer nada, porque não tem nada nessa máquina ainda. Mas a Ideia é que quando a gente digitar o nosso IP aqui na porta correta, ele abra o nosso site. Voltando aqui pro nosso desenho, a parte de criar a instância C2 já foi feita. Agora o que falta é a gente entrar dentro dessa instância EC2, dentro desse servidor e baixar a imagem que a gente armazenou no ECR e

rodar, né, o contêiner, assim como a gente fez a nossa máquina local, a gente vai fazer dentro do servidor, que nada mais é do que uma máquina que está na nuvem. Então Vamos lá, pessoal. Como que a gente se conecta em um servidor, em uma máquina que está lá na WS, lá em Ohio, né? A gente faz isso através da conexão SSH. A conexão SSH, ela é um protocolo de rede aonde a gente consegue se conectar remotamente a diversos servidores aí que estão espalhados pelo mundo. Para a gente fazer isso, a gente precisa do usuário

daquela máquina e do IP da máquina, além da chave privada para poder se conectar a essa instância, a Essa máquina. Se eu der um LS aqui, a gente vê a chave aqui que eu acabei de baixar. Tá? Eu baixei a chave privada, aquela Keep Per dentro da minha pasta lab para poder ficar mais fácil aqui para vocês. Então o comando SSH, ele é bem simples, então você vai digitar SSH- i e aí você vai passar qual que é o arquivo da chave privada. No nosso caso é essa chaveitep.pen. Aí eu vou passar o usuário da

máquina e o IP da máquina que eu quero me Conectar. Como que eu sei essas informações? Voltando aqui pra WS, se eu clicar na instância em connect, aqui embaixo em username, aparece o usuário padrão dessa máquina. No caso chama S2 user. Se fosse uma máquina Ubuntu, por exemplo, o usuário seria Ubuntuo. Aqui, então cada sistema operacional vai ter um usuário ali diferente. Então, username é esse é do user e o IP dessa máquina é aqui, ó. Public IPv4. Eu já vou copiar. Voltando pro meu terminal, Eu vou digitar o usuário, que é esse 2user @ipdamina.

Aqui vai dar erro, tá? Se eu tentar apertar enter, e deu erro. Não se assuste com esse erro. O que que isso significa, né? Tá falando aqui chave privada desprotegida. Por quê? Se eu der um LS - LH aqui, a gente consegue ver que as permissões dessa chave aqui estão muito abertas, então as pessoas conseguem editar esse arquivo. E como ela é uma chave privada, ela não deve ser editada, né? Porque senão, se eu for Lá e mudar a chave, eu não vou conseguir acessar a instância, né? Porque a chave ela tem que ser imutável.

Para resolver esse problema de permissão, a gente roda o comando chamado CH mod. E aqui a gente vai passar o número 400. E qual o arquivo a gente quer alterar? No caso é esse arquivo aqui. Então aqui por que que a gente tá colocando o 400, certo? Porque a gente só quer que o dono desse arquivo consiga ler e ninguém mais consiga fazer nada com esse arquivo. Ou Seja, a gente vai tornar esse arquivo inalterável. Se eu digitar enter aqui e dá um ls- lh agora, como você pode reparar nas permissões desse arquivo aqui, só

a gente tem a leitura e todos os outros usuários não vão ter leitura disso. Se eu rodar o comando SSH novamente, ele vai se conectar na máquina. Beleza, agora eu já estou dentro da minha máquina lá em Ohio, nos Estados Unidos. Se eu tentar rodar o comando Docker aqui, ele não vai Encontrar nada. Por quê? Porque a gente não instalou o Docker nessa nessa máquina ainda aqui. Como a gente tá utilizando o Amazon Linux, eu vou rodar o comando um update- Y para poder atualizar o sistema. Tem que ser sudo update - y e aí

para baixar o Docker aqui vai ser sudo install Docker - Y. Pronto, ele já tá baixando o Docker. Com o Docker baixado pra gente ver se funcionou é só a gente dar um Docker menos version. E aí já aparece a versão Do Docker aqui. Só que a gente precisa rodar alguns outros comandos para poder habilitar o Docker e ele funcionar corretamente na nossa máquina. Eu vou copiar aqui para ficar mais rápido. O primeiro aqui é pra gente startar o Docker. A gente vai habilitar ele. Se eu tentar rodar um Docker PS, por exemplo, ele vai

falar que eu tô com permissão negada, porque somente o usuário root é que consegue rodar esse comando se a gente não ajustar. Então, se eu, por Exemplo, usar aqui o sudo sudo dockerps, por exemplo, ele vai aparecer o comando. Pra gente resolver esse problema, a gente precisa rodar esse comando aqui, que a gente vai adicionar o usuário S2 ao grupo do Docker para que ele consiga executar o comando. Eu já adicionei, só que para isso funcionar, eu vou precisar sair da máquina e entrar de novo, porque se eu der um docker PS aqui, ele não

vai funcionar. Para sair da máquina é só dar um exit e aí eu vou me conectar Novamente. E agora sim, se eu tentar dar um Docker PS já está funcionando. Então a gente já tá com o Docker aqui instalado na nossa máquina. Agora, qual que é o próximo passo? É a gente baixar a imagem neste servidor e rodar a aplicação inicial contêiner. Para isso, a gente vai baixar a imagem que está no ECR. Maria, como que eu baixo a imagem que eu subi pro ECR, certo? Como que eu vou baixar a tag aqui versão 1.0

lá na minha máquina? Assim como a gente fez o Docker Push para poder enviar pro SR, a gente vai fazer o Docker Pool para poder baixar essa imagem do EC. Então, basicamente, a gente roda o comando docker pool e aí eu passo qual imagem, né, que eu quero baixar. No nosso caso aqui, eu vou copiar o RL do site Prod, vou colar aqui e aí dois pontos eu coloco a tag, né, qual que é a versão dessa imagem. No caso aqui vai ser a versão 1.0. E se você for inteligente, você vai imaginar o que

vai acontecer Agora. Se você reparar, tá aparecendo no basic out credentials. O que que isso significa? Que falta as credenciais. Você lembra que eu falei para você que o repositório ele é um repositório privado? Ou seja, não é qualquer pessoa que consegue acessar esse repositório. Ah, Maria, mas tá o SR tá na mesma região, tá na mesma conta WS e que a instância C2. Eles estão no mesmo, entre aspas, no mesmo lugar. E por que que a instância, né, a EC2, ela não consegue Acessar o SR, porque tudo na WS você precisa concedermissão. A AWS

ela é extremamente segura neste quesito. Então se você não declarar, né, explicitamente que tal recurso tem permissão para acessar outro recurso, isso não vai acontecer. Então a gente precisa fazer essa configuração, essa autenticação. E aí você deve est pensando que, ah, Maria, é só a gente rodar um AWS configure e aí passar aqui, né, Marias, o Access Key, o Secret Key e A região, enfim, e logar. Só que não é ideal a gente fazer isso. Por quê? Porque aquele Access Key Secret Key, ele é do meu usuário, né? O meu usuário pessoal, Maria Lázara. E

aqui no meu caso, quem tá tentando baixar é a instância C2. Então se você for ver o desenho aqui, que eu acho que fica mais fácil de entender, a instância C2 é que vai baixar a imagem que está nesse CCR. Então pra isso, a gente precisa configurar uma permissão. Só que Diferente das credenciais de usuário que é o Access Key Security Key, quando a gente fala de um serviço da WS, né, um recurso, acessar outro recurso da WS, a gente utiliza o que a gente chama de roles. Então aqui a gente vai precisar de uma

RLE, não precisa se assustar com o nome, que eu vou tentar explicar da forma mais simples aqui para você o que que significa isso. Uma rolly, ela nada mais é do que um crachá. Então, pensa na sua cabeça como crashar em português. Rolley, eh, na WS, se você for ver está como funções. Então, se você pensar num crashar com uma função específica, se eu for entrar em uma determinada empresa, eu ganho o meu crachá, certo? No meu crachá vai ter a minha função, o que que eu sou ali, o que que eu posso fazer naquela

empresa e o que que eu não posso fazer. E pensa naqueles crachás que você encosta assim, você vai abrindo as portas, sabe? Então tem determinados lugares que você pode entrar porque você Tem permissão e esse crashat te dá essa permissão, certo? E tem alguns outros lugares que você não pode acessar porque a sua função não é essa. Então a RL ela é como se fosse o crashar que a instância vai usar para poder acessar o Sr. Então pra gente fazer isso, a gente vai usar o serviço chamado Iim da AWS, que é o Identity Access

Management. Aqui na tela do IM você pode ver que a gente tem grupos, usuários, roles e políticas. Essa role ela vai ter o que a gente Chama de policy ou em português política. O que que é uma política? Uma política nada mais é do que um conjunto de regras, ou seja, o que eu posso fazer e o que eu não posso fazer. Então, a police, por exemplo, vai est escrito: "Você pode fazer isso, você não pode fazer aquilo". E aí você atrela essa política a uma role, a um crachá. E aí a gente atrela a

Rolly no serviço. Eu tinha bastante dificuldade de entender como que funciona isso daqui. Eh, então, Se você não entendeu, não se cobra, não precisa ficar com medo, porque com o tempo, é, praticando, você vai pegando o jeito, você vai entendendo como que as peças elas se encaixam neste quebra-cabeça. Aqui no meu painel do IM, eu vou clicar em rolls e eu vou criar uma nova role, um novo crashar. Aí ele me pergunta aqui, né, para quem que você quer criar essa role? No meu caso, eu vou criar para um serviço da WS, que é a

EC2. A EC2, ela é um serviço da AWS. Até Aparece aqui, ó, permite os serviços da WS, como o EC2 ou outros a fazerem ações nessa compra. Então, vai ser um serviço da WS. E aqui eu posso colocar qual serviço, no caso uma EC2. É só clicar em next. E aí aqui a gente adiciona as póliices, que são as permissões. A gente tem as póliices que são criadas pela própria WS, que aparece aqui como AWS Managed. E a gente tem as políticas, né, as póliices que a gente pode criar por conta própria. Então a gente

escreve lá E cria uma pollice personalizada. Mas no nosso caso, a gente vai utilizar uma política padrão. Então, se você olhar aqui, a gente tem a policy de administrator access, que nada mais é do que uma pollice que vai permitir acessar qualquer recurso e fazer qualquer ação. A gente tem, por exemplo, aqui PI Gateway Administrator, que é também um um acesso aí que você consegue fazer tudo, mas só com o recurso API Gate aí da WS. Então aqui pro nosso caso, a Gente vai adicionar uma pollice que permita a leitura do ECR e somente isso.

Então se eu pesquisar por registry aqui, a gente vai ter algumas políticas relacionadas ao ECR. Então no nosso caso, a gente vai escolher a Amazon Container Registry Read Only. E aqui tem a descrição, né, que fala que permite acesso apenas ao ECR. Então é só clicar em next. Aqui ele vai pedir para você revisar e para você dar um nome para essa RLE. No meu caso, eu vou colocar Aqui e2 RLE. Para poder identificar essa RLE, é só clicar em create role. Pronto, a gente criou o nosso crashar. Ah, Maria, mas por que que você

não coloca um de administrador mesmo, né, que aí fica mais fácil. A gente não faz isso porque a gente tem que aplicar uma boa prática de segurança, que é aplicar o princípio do privilégio mínimo. Isso entra um pouco na parte de deve secs, que é a parte que cuida da da segurança das Nossas aplicações, que basicamente é você conceder permissão apenas ao que aquela pessoa ou aquele serviço pode fazer. Porque, por exemplo, se essa role, né, essa credencial, ela vazar por algum motivo, os danos vão ser bem menores. Porque imagina se eu tivesse concedido o

acesso de administrador para essa role e aí alguém, porventura consegue ter o acesso, a pessoa poderia fazer qualquer coisa na minha conta, desde deletar os recursos até criar Novos recursos. E ela poderia fazer qualquer coisa na minha conta e isso é um problema grave de segurança, tá? Eu já criei o crachá, mas eu preciso falar pra WS que a minha instância S2 ela tem esse crachá. Então eu preciso conceder isso. Eu preciso conceder essa RLE à minha instância S2. E como que eu faço isso? Voltando aqui pro meu painel da EC2 em instâncias, eu vou

clicar na minha instância que eu quero atribuir a role. Eu venho aqui em actions, Security, modificar a role do IM. Tá vendo aí? Aqui é só eu escolher a RLE que eu criei. Eu vou dar o update agora. E pronto, a gente já concedeu essa role a essa S2. Aqui nas informações tem essa parte aqui, I am roll, tá vendo? E aí ele aparece, é o RLE que a gente acabou de criar. Voltando pro meu terminal, eu vou rodar o comando do login pra gente fazer o login nesse R. Vou trocar aqui a região e

eu vou colocar qual que é a URL. Vou copiar a URL aqui. E beleza, Ele fez o login e agora eu vou dar um docker pull. E aí eu vou baixar a imagem do meu então eu vou colar aqui a RL do meu se é o site Prod. Qual versão? Qual tag? A versão 1.0. Se eu der enter, ele já tá baixando a imagem. Agora, se eu der um docker images, ele vai aparecer aqui que eu tenho a minha imagem baixada. E agora, basicamente, a gente vai repetir o mesmo processo que a gente fez na

nossa máquina local. Só que agora dentro da nossa instância C2. Então a Gente vai dar um docker run. Eu vou dar o nome aqui de site container. O men d para poder não travar o nosso terminal. O men p para poder passar a porta de acesso. Aí aqui eu vou colocar a porta 80 para a porta 80. Então a hora que eu abrir o meu navegador digital o IP da máquina, ele já cai na porta 80 padrão. Eu vou passar qual imagem que eu quero rodar esse contêiner. No caso é essa imagem aqui. Qual tag

imagem? a versão 1.0. E pronto. Se eu der um docker PS, a Gente já vê que a nossa imagem está rodando aqui na porta 80. Como que eu confirmo isso? Eu vou abrir o meu navegador, eu vou copiar aqui na parte da instância, eu vou copiar o IP público dessa máquina e vou colar o IP aqui. E pronto, a gente acabou de subir o site na AWS. Então aqui a gente já completou todo o nosso fluxo. Importante que a gente exclua tudo que a gente criou aqui na WS para evitar qualquer cobrança indevida. Então eu

vou vir aqui na minha Instância S2 instance state, a gente dá um terminate nessa instância pode clicar em delete. Beleza, já está deletando aqui a instância. Eu vou vir no meu aqui no meu eu vou clicar dentro e apagar todas as imagens dentro do SR. Digitar delete. Beleza? Já deletei todas as imagens. Eu vou vir agora em repositórios, vou selecionar o repositório e também vou deletar o repositório. Agora, vindo aqui no Eam, a gente vai selecionar o RLE que a gente Criou e vai clicar em delete também. Eu vou deletar essa role. Beleza, a gente

já deletou todos os recursos que foram criados na AWS. É importante também que além, né, da instância você venha na Security Group aqui no canto, selecione a Security Group que foi criada. No meu caso, ela chama launch wizard 5. Se é a primeira que você tá criando, vai est um, provavelmente. Aí você seleciona e deleta também. Então, delete security group e beleza, tá tudo deletado para Evitar aí qualquer cobrança indevida. Parabéns, você acabou de concluir o seu primeiro laboratório prático de devops. Nesse vídeo você aprendeu a usar o Docker, entendeu por e quando utilizá-lo, quais

os problemas que ele resolve. Além disso, você fez o seu primeiro deploy de uma aplicação na AWS utilizando uma instância S2 e o Amazon Sr. Isso já é um grande passo para quem tá começando na área de devps. Você já tem um projeto prático e funcional para Poder adicionar no seu portfólio. Agora imagina que seu chefe chega para você e fala: "Precisamos fazer o deploy desse site para 15 clientes, cada um com a sua própria infraestrutura. Imagina ter que provisionar 15 estruturas como essa manualmente em um dia só. Fica praticamente impossível e totalmente inviável. É

exatamente por isso que na próxima aula nós vamos aprender a resolver esse problema com o Terraform, uma ferramenta incrível de Infraestrutura como código, que com ele a gente pode descrever a nossa infraestrutura em código e provisionar ambientes inteiros com apenas alguns comandos de forma totalmente escalável. E para você não perder nada dessa jornada e ainda, né, conseguir tirar suas dúvidas diretamente comigo e com a nossa comunidade, eu criei um grupo exclusivo no Discord. Lá eu vou separar por módulos, compartilhar materiais extras e a gente pode trocar muita ideia Sobre o mundo de devotos. Se você

se interessar, o link tá na descrição. Entra lá que vai ser um ótimo lugar para você construir um networking, se conectar com pessoas da área, tirar suas dúvidas, enfim. Se você gostou desse vídeo, não se esquece de deixar o seu like e se inscrever no canal para não perder as próximas fases desse projeto e compartilha com aquele amigo ou amiga que também quer entrar na área de devolves. A sua ajuda, ela é fundamental Para que esse conteúdo chegue a mais pessoas. E eu quero aproveitar para agradecer que a gente bateu a marca de 2.000 inscritos

e isso é incrível. Muito obrigada pelo apoio de vocês e me conta aqui nos comentários o que que você achou dessa primeira fase do projeto e qual que é a sua maior dificuldade no mundo de deves. A sua opinião, ela é muito importante para mim, porque assim eu consigo direcionar o meu conteúdo para te ajudar ainda mais nessa jornada. Ah, e o link pro repositório com todo o código que a gente usou nesse vídeo vai estar na descrição para você conseguir clonar e praticar. Um grande abraço e até a próxima.