Bom pessoal, agora que a gente já falou um pouquinho sobre container, já deu uma passada para a gente relembrar quem já tinha esquecido sobre o container ou para quem não conhecia tanto? Ele vai fazer toda essa zona se organizar e a gente conseguir tanto executar os containers quanto gerenciar eles no dia a dia. E você pode fazer isso por uma instância EC2, tá bom? Ou você pode usar uma opção, outra opção serverless da AWS, que é o Fargate. De novo, quando a gente usa serverless, a gente pode gerar algum tipo de lock-in com aquela empresa. Ou seja, Fargate é muito bom para AWS. Aí você tem que ver se a gente for para outro tipo de provedor cloud se você não vai ter nenhum problema por ter usado Fargate. Mas você consegue usar ou Instance C2 ou Fargate. Depende do que você for fazer, ambos os pontos podem ser muito positivos. Tá bom? E aí vamos falar um pouquinho dos containers e como é que eles funcionam imagina que o container ele e as imagens tá como é que ele se se falam aqui container ele é executado a partir de uma imagem como eu tava falando para vocês é e uma imagem elas são os pacotes ali com tudo necessário para executar o código, incluindo o próprio código e todo o resto de dependências, tá bom? E como é que a gente pode fazer isso falando das abstrações que a gente está fazendo, que eu acho que ajuda a gente a tangibilizar a coisa. Imagina que aqui quando a gente está falando de uma imagem, uma imagem nada mais é do que uma receita. Imagina que você tem que entregar um prato, você é o chefe de uma cozinha e você tem que entregar um jantar, tá bom? Você tem que entregar um jantar e dentro desse jantar você tem os pratos a serem servidos. Você tem um monte de gente fazendo pratos ali e você precisa que todos os pratos, por exemplo, de entrada saiam iguais, todos os pratos principais saiam iguais, todas as sobremesas são iguais. Você tem três tipos de prato. Entrada, prato principal e sobremesa. Você precisa que tudo isso saia igual. Então, quando você vai fazer a entrada, você tem ali a sua imagem, que seria a sua receita. O que você espera daquele prato. Imagina que é realmente uma imagem daquele prato. Como que aquele prato tem que sair no final da receita. daquele prato como que aquele prato tem que sair no final da receita e com isso você gera o container que vai ser o prato com tudo que ele precisa ter então você vai ter ali a sua entrada preparada igualmente por todos os que pegarem aquela receita para fazer essa seria a idéia de imagem tá bom quando a gente está falando de uma task é uma task ela ser um pedaço de coisa dentro do task definition. Ou seja, o task definition é uma listona com tudo que pode ter e a task é uma delas. E dentro dessa task você pode ter um container ou mais. No ECS, as configurações de task, como se pelo memória, são definidas na task definition também. E daí, qual é a diferença disso? Quando a gente está falando da task, imagina o nosso case aqui do restaurante que a gente está fazendo. Então, a task vai ser mais ou menos a performance da cozinha, tá bom? Cada container ali, ele é um prato, beleza? Que nem a gente falou na nossa ideia anterior. Então você foi lá e fez a entrada, o prato principal e a sobremesa. Cada container é um desses pratos que está sendo realizado. A task é a organização desses pratos, tá bom? Que cada container ali ele vai ser responsável por fechar para o jantar ficar pronto. Então imagina que essa task definition ela vai ter tudo isso. Quais são... Qual é o tamanho da CPU, memória, espaço e o que vai precisar para aquele container, para que ele coexista e para que ele seja gerado no final do dia. Beleza? E quando você fecha todas as tasks definition, você vai ter uma visão do todo do seu jantar inteiro ali, basicamente. Os services aqui é um servidor mantém o número de instâncias ou de testes definidas na técnica definir executando dentro de um cluster ou seja cada cada vez que um desses caras cai tiver um problema precisa de recuperação escalabilidade ele vai resolver isso então imagina que ali começou a pegar fogo na sua praça ali de cozinha e você precisa de mais gente pra trabalhar e fazer mais pratos principais os services, basicamente os caras que vão manter ali o número de instâncias trabalhando de acordo com o número de pratos, de throughput que você precisa ter de saída, ou até quando alguma das pessoas, sei lá, cortar o dedo, ele vai colocar uma pessoa no lugar. Está ficando boa a minha abstração. Vai com a cozinha. Estou fazendo ela agora de cabeça, então se eu cometer alguma falha aqui, não me julguem. Mas está ficando boa. No fim das contas, o que a gente tem que pensar é que esse services, ele vai ser o cara que vai fazer com que seus containers estejam rodando ali as instâncias elas estejam rodando de acordo com o que foi definido no test definition sem você perder nada e sem deixar nada cair aí e um cluster é o agrupamento ali lógico das instâncias dos recursos que a gente tem lá de infraestrutura EC2 ou de fargate e aonde o ECS vai lançar as tasks beleza então é o espaço onde a gente vai ter para fazer isso. Pessoal, vamos dar uma passada, então, em como que a gente vai usar o ECS aqui com o EC2, tá bom? Primeiro sobre como é o ECS com o EC2, depois a gente dá uma aprofundada no ECS com o Fargate, depois eu faço um paralelo para vocês, entre um e outro, para vocês entenderem qual a diferença, benefícios e assim por diante. Então vamos lá, quando a gente está falando do EC2, você primeiro vai começar criando um cluster ECS, um cluster ECS, tirando o nome bonito, não é nada mais do que um agrupamento de EC2, são algumas instâncias EC2 ali que vão servir como seu host, e como tal, você precisa ali definir quais são as configurações que vão servir para você, e você pode definir ali qual é o tamanho da CPU, memória, qual vai ser a capacidade de rede. Assim como qualquer EC2, você vai definir dentro desse cluster quais são as instâncias EC2 que vão se encaixar melhor para o que você precisa, beleza? Então o primeiro cenário é, você vai decidir ali um número de instâncias EC2 com as suas características ali de CPU, memória e capacidade de rede que vão conseguir seu cluster ECS. Depois de definido, você vai registrar essas instâncias EC2 no ECS e para isso você vai usar um carinha chamado Agente ECS. O Agente ECS não é nada mais do que uma aplicação que conecta uma coisa com a outra, que faz o seu EC2 conectar com o ECS. Acho que é a melhor forma que eu tenho para explicar o agente ECS. Basicamente ele vai fazer isso, transformar o seu EC2 em um cluster. E depois que você registrar isso no cluster ECS, você vai ter já esse cluster determinado. Esse processo aí, normalmente, quando você cria ali na AWS, direto no painel, você já vai ter isso realizado ali, se você usar o padrão da AWS. Você não precisa de muita coisa para fazer isso. O Amina vai fazer um hands-on com vocês, mas vocês vão ver que não é nada demais. Depois do registro das instâncias, a gente tem o Task Definitions aqui, tá bom? O Task Definitions é aquela lista que eu falei onde a gente vai colocar quais são as configurações e assim por diante. Eu expliquei para vocês enquanto eu estava falando ali sobre como funciona os containers. Nada mais é do que isso dentro do ECS. A gente vai colocar ali os requisitos de CPU de memória, variável de ambiente tudo que você precisa para o seu ECS funcionar então você vai ter ali a imagem do container dentro da task definition e para o seu ECS com EC2 funcionar você vai especificar ali todos os parâmetros que vão influenciar dentro da criação dessas instâncias dentro do cluster. Depois você vai ter que pensar em escalabilidade, que é a parte mais legal. A gente está falando de tudo isso simplesmente para pensar em escalabilidade. Então o ECS vai te ajudar nisso. Então aqui quando a gente está chegando no momento de usar o ECS, porque ele foi feito mesmo, que é nada mais do que gerenciar essa escalabilidade e assim por diante, quando você está falando de EC2, você vai ter a flexibilidade ali para escalar essas instâncias, tanto fazer upscale como downscale, com base no que você precisar, tá bom? Você pode usar ali o auto-scale group, que é o ESG, para gerenciar essa parte de escalabilidade das instâncias FC2. E para isso, você vai ter que definir quais são as políticas. Por exemplo, estou ali com a minha aplicação, começou a executar muita coisa, está começando a gastar X% de CPU, está chegando a ficar perigoso, ou sei lá, chegou num nível onde eu acho que a minha aplicação já pode começar a degradar, ou antes disso, nível de segurança lógico, você não vai deixar chegar quase no gargalo para começar a escalar então imagina que você está começando a chegar num momento onde o seu CPU está começando a ficar muito consumido você pode escalar com base nisso você pode escalar com base em memória também você pode falar, putz, em vez de CPU é memória minha aplicação consome muita memória, então quando a memória começar a aumentar a gente faz a escalabilidade por ela. Ou você pode usar os dois também. Você pode colocar parâmetros de CPU e parâmetros de memória para escalar também essa aplicação. Aqui é bem interessante a gente pensar que a definição dessa escalabilidade vai ser importante, mas é importante também vocês pensarem no FinOps disso, ter alertas de FinOps. Porque imagina que você começa a ter, vou dar um exemplo, você começa a ter um cyber ataque, você não se preparou, você não ajeitou lá as suas instâncias e os seus padrões de segurança para lidar com isso, e com isso você começa a aumentar muito muitas instâncias, você vai começar a escalar pra caramba porque está batendo CPU, por exemplo. E nesse momento, você vai estar gastando dinheiro pra caramba, e se você não tiver nenhum tipo de FinOps pra te alertar que algo estranho está acontecendo, você pode capotar também. Lógico que você não precisa estar só com FinOps, você pode ter outros tipos de alerta, mas é legal você ter alguns FinOps aqui pra te avisar quando você tá tendo aumento de gasto, porque você tá escalando muito e assim por diante. Bom, basicamente é isso, você vai ter que começar a ficar de olho em como essas coisas funcionam, mas você vai conseguir escalar aquela história do ônibus, no fim das contas, lembra que eu falei? Aqui não é nada mais do que a história do ônibus onde você está colocando quais são os critérios para você chamar mais ônibus para te ajudar a levar as pessoas para a praia. Os critérios vão vai ser porque o seu ônibus está ficando com pouco espaço para sentar ou porque ele está ficando com pouca gasolina, sei lá. Basicamente seria isso quando a gente está falando de CPU e memória. Quais são os parâmetros que vão definir quando é que eu preciso chamar mais ônibus para me ajudar. Quando a gente está falando de colocação de tasks, a gente tem algumas oportunidades aqui de estratégias que a gente pode usar. Eu vou detalhar com vocês três estratégias que são bem interessantes para a gente utilizar aqui quando a gente está falando de colocação de tasks. A primeira delas é a Spread. Essa estratégia vai fazer o seguinte, ela vai separar de forma equalitária o uso de todas as suas instâncias. Então ela vai jogar as tasks igualmente nas suas instâncias para você não deixar nenhuma instância sobrecarregada. Com isso, o que você vai garantir? Você vai garantir que você vai ter a melhor velocidade, tempo de resposta e assim por diante. Você vai garantir a qualidade daquela aplicação. Então, se você estiver precisando, por exemplo, de uma aplicação que ela tem que estar sempre em alto nível, sempre mandando muito bem, sem poder ter nenhum tipo de mudança em tempo de resposta e assim por diante, pode ser uma boa estratégia. Ela é um pouco mais cara do que as demais, porque ela vai pegar, se você tiver 10 instâncias disponíveis no momento, ela vai usar as 10 e separar igualmente as 10 instâncias ali para você sair utilizando o seu balance de carga em todas essas 10. Então, ela vai otimizar aqui a velocidade no fim das contas e assim por diante. Se você estiver usando, por exemplo, a estratégia de BIMPACK, essa estratégia já é o contrário. Ela vai tentar gastar o máximo daquela instância antes de subir a próxima. E com isso ela diminui o seu custo, porque você tem menos instâncias rodando. Então com essa estratégia você fica mais barato. Com essa estratégia você vai fazer o seguinte, quando quando você tiver no máximo no talo daquela máquina se joga para a próxima instância e de quando ela tiver o máximo se joga para a próxima e assim por diante e vai escalando então você não sai direto usando todas as suas instâncias é com o mínimo possível que é o que você faz no espreite se você parar para pensar que você está separando igualmente no bem pec não é o contrário faz no spread, se você parar para pensar, porque você está separando igualmente. No BIMPACK, não, é o contrário, você vai gastar o máximo aquela instância antes de ir para a próxima. E quando a gente está falando de affinity, esse cara, ele é uma estratégia que, inclusive, eu acho ela bem peculiar, bem interessante para a gente. Ela vai acabar usando uma estratégia ali de agrupar clusters que façam sentido estar próximos. Então, por exemplo, quando você tem algum tipo de estratégia que você tem tasks que precisam estar rodando próximos, ele vai tentar jogar na mesma instância e assim por diante. Ou, ao contrário, tasks que não podem rodar na mesma instância. Você tem que estar com elas em diferentes instâncias. Ele vai separar isso. Então, você consegue trabalhar certamente uma segurança de aplicação aqui também junto com a Affinity, que também