Iniciando com Docker na AWS

Notas do Editor

• #3: So we are going to briefly recap, why containers and the challenges you may face in production, and some of the use patterns We will then talk about cluster management and how Amazon ECS fits into all of this Then we will close with a demo from my colleague _____
• #6: Containers se assemelham a virtualização de hardware (como EC2), no entanto, ao invés de particionar a máquina, containers isolam os processos que rodam em um único sistema operacional Ou seja você pode utilizar o kernel do OS para criar múltiplos processos no user space isolados e que podem ter restrições de CPU e memória. The Docker CLI makes using containers easy, with commands like docker run. Imagens Docker facilitam a definição do que roda em um container e as versões do APP Esses conceitos permitem facilmente a doção de automação – você pode definir sua aplicação, fazer o build e compartilahar a imagem, e fazer o deploy desta imagem.
• #7: Você pode estar pensando– ”isso parece interessante, mas pq eu utilizaria containers? Texistem pelo menos 4 vantagens principais para adoção de containers. 1.) Containers são portáveis. A imagem é consistente e imutável – não importa onde eu a rode ou quando eu a inicialize, será sempre igual. Isso facilitia o ciclo de vida de projetos principalemten para os devs – uma imagem funciona da mesma maneira no computador do dev e em prod, independente da escala da minha aplicação. Toda a aplicação é independente– A imagem é a versão, o que facilita o deploy e a escalabilidade pois as dependências já estão inclusas na imagem. Pequena, geralmente algumas dezenas de MB, facilmente compartilhável 2.) Containers são flexíveis. Você pode criar ambientes reproduzíveis e modulares. Ambientes bem clean. Evita conflitos de bibliotecas. Enquanto no passado, processos múltiplos estariam no mesmo OS (ex: frameword, cache, captura de logs), agora os Containers facilitam a decomposição de um app em pedaços menores, como microserviços, reduzindo a complexidade e deixando os times se moverem mais rapidamente enquanto rodam o processo no mesmo host. Simplidica até o genrenciamento de infra e deploy de código. 3.) Dockers inicializam mais rapidamente Pois o sistema operacional já está rodando, Cada container pode ser um thread único; diminui as interdependencias Also ops benefits - Example: IT updates the base image, I just do a new docker build – I can just focus on my app, meaning it’s faster for me to build & release. 4.) Você pode alocar os recursos exatamente como que quer– CPU, rede, memória específica Já que containers comparilham os mesmo kernel e bibliotecas do SO, eles usam menos recursos que rodar o mesmo processo em diferentes máquinas virutais (jeito difenrente de isolamento)
• #8: Monolith – Unidade única, extremamente acoplado, difícil de alterar, lento Microservice – unidade atônica, faz uma coisa muito bem. Iteração rápida, fácil de alterar.
• #9: Facilita a modelagem da aplicação; A aplicação e todas as suas dependências são empacotadas em uma imagem usando o Dockerfile. Suporta basicamente qualquer aplicação e linguagem A imagem nada mais é que uma artefato versionado na sua base de repositório como se fosse um código fonte – facilita o deploy Servidores stateless são naturais com Docker. Cada deploy é um novo set de containers. Rollback é simplicado
• #10: -Rodar alguns containers pode ser fácil. Mas centenas ou milhares podem ser complicados
• #11: Você não tem somente vários containers, você tem também várias máquinas Geralmente isso implica em gerenciar clusters, e se tem algo chato de gerenciar é cluster. Yvocê provvelmente não escreveu sua prórpia so;ução de gerenciament de clusgter, não é um problema trivial de resolver e há outras melhores maneiras de gastar seu tempo de eng.. Você precisa de uma maneira inteligente de colocar seus containers em instâncias que possuam recursos suficnentes, isso siginifica que você precisa saber o estado de tudodo seu sistema. Você precisa monitorar e agregar todos os individuais recursos de todas as máquinas do cluster e torna-las aptas a receberem os jobs. Algumas infos que você precisa ter: A máquina X está rodando ou não? A maquina tem recursos suficientes para rodar o job? O job ainda está rodando? Ele falhou? Fica claro que é necessária uma ferramenta especilista nisso.
• #24: So how it works is that Each scheduler periodically queries the current cluster state to check the resource availability
• #25: To schedule a task, the scheduler makes a claim for any available resources The scheduler then updates the cluster state with the newly claimed resources in an atomic transaction. 
• #26: If a resource is already claimed, ECS will reject the transaction because it maintains concurrency control
• #27: So what ECS enables is called “shared state optimistic scheduling” where all schedulers can see the current state of the cluster at all times.
• #29: Shared state optimistic scheduling Neste modelo, todos os schedulers podem ver o estado atual do cluster a todo o momento. Cada scheduler periodicamente verifica o estado do cluster, and makes a reividica algum recurso disponível. O scheduler então atualiza o estado do cluster com o novo recurso reividicado através de uma transação atomica. Caso ocorra um evento de conflito (ex dois schedulers reinvidicam o mesmo recurso) somente uma transação terá exito. Porque todos os schedulers veem todos os recursos a todo tempo, este modelo é considerado otimista, pois os recursos nunca são bloqueados enquanto estão sendo oferecidos para o scheduler.
• #30: The target group typically represents a service in a customer’s architecture.
• #35: IMPORTANT: Walk through the parts of the TASK Definition