Skip to content

Instantly share code, notes, and snippets.

@GusAntoniassi

GusAntoniassi/README.md

Last active April 9, 2020 20:30
Show Gist options
  • Save GusAntoniassi/98c6e6bf86ab6675ec3ba9fb614f9ba3 to your computer and use it in GitHub Desktop.
Save GusAntoniassi/98c6e6bf86ab6675ec3ba9fb614f9ba3 to your computer and use it in GitHub Desktop.
Download ZIP
AWS APN - Containers on AWS
Raw
README.md

Container on AWS - APN Training

  • Instrutor: André Rosa
  • Curso recomendado antes: Foundational Professional Techincal

Modernização de aplicações

Cloud Native Development

  • Muitos clientes querem rodar container porque é "moda"
  • Tem outros pré-requisitos que devem ser considerados
    • Microserviços
    • DevOps
    • CI/CD
    • Aplicação moderna
  • Cliente pode estar sofrendo com legado/monolito
  • Processo lento
  • Deploy depende muito da comunicação entre dev e ops

Melhores práticas para migração

  • Componentizar apps
    • Microserviços
  • Automação da segurança
    • Testes
    • Varredura de código, análise léxica
  • Simplificar a infra
  • Incentivar a experimentação
    • Times pequenos
  • Atualizações rápidas (CI/CD, Agilidade)
  • Padronizar operações (IaC)
    • Mesmo ambiente para dev, hmg, prod, outros
  • Observabilidade (Monitoramento)
    • Performance, tuning dos componentes

Principais para Containers:

  • Componentizar
  • CI/CD
  • Performance

Componentização de aplicações

Monolito VS Microserviços

  • Monolito

    • Código gigante, todas as funções estão dentro do mesmo serviço
    • Referência cruzada entre o código, acaba virando um vício
    • Ex: Pedidos -> Pagamentos - Inventário
    • Manutenção vira um inferno

  • Microserviços

    • Benefícios
      • Serviço de pedidos, de pagamentos, etc
      • Comunicação é feita entre APIs, só usa o que é exposto
      • Ferramenta certa para o trabalho (Linguagem)
      • Evolução ágil, independência no deploy
      • Código menor para validar segurança, sintaxe, testes, etc
      • Menor custo, escala granular
      • Facilidade de experimentação e inovação
    • Desafios
      • Precisa estabelecer APIs bem determinadas
      • Arquitetura, monitoramento e segurança tem que evoluir
        • Múltiplas máquinas rodando várias aplicações, talvez de ling. diferentes
      • Mudança de mindset do cliente

Automatizar entrega com CI/CD

Quatro fases

  • Código fonte (git)

    • Check-in (commit)
    • Fonte de verdade da aplicação
    • Qualquer mudança na aplicação deve ser feita pelo repositório

  • Build

    • Compilar código, rodar testes, style checks, métricas
    • Testes unitários
    • Criar imagens de container (docker build)

  • Test

    • Integração com outros sistemas
    • Carga, UI, pentest

  • Production

    • Envio pra ambientes de prod
    • Antigamente era na base da comunicação, e nunca dava certo

  • Processos de automação de releases

    • CI: Source e Build
    • Continuous Delivery: Source, Build, Testes. Envio p/ prod manual
      • Alguém valida e dá o OK para o deploy
    • Continuous Deployment: Source, Build, Testes e Prod automático

  • CI/CD em monolito é muito lento

  • Cadência de release em microserviços é mais rápido

Observabilidade

  • Ter respostas rápido

  • Métricas

  • Logs

  • Traces / Rastreabilidade

  • Enxergar o comportamento da aplicação

  • Ambiente totalmente distribuído

  • Monitorar microserviços

    • Logs, formatos que variam entre serviços
    • Coletar, rotear, correlacionar e analisar
    • Métricas e alarmes pra cada componente

  • Arquitetura de microserviços

    • Erros na comunicação entre serviços
      • Saber quem retornou o erro, isolar e corrigir
      • Erros em cascata
    • Tuning

  • Desafios para debugging

    • Teste local, print, breakpoints
    • Se você não sabe qual MS gerou o erro, teria que testar cada um desses

Como orientar os clientes?

Dominar componentização de aplicações

  • Orientar clientes, mostrar desafios e possibilidades de execução
  • Melhores práticas e padrões de arquitetura
    • Componentes serverless

Criar cultura de ownership e experimentação

  • Times dedicados para cada componente
    • Liberdade e responsabilidade pelos componentes
    • Testes e evolução
  • Entender o ciclo de desenvolvimento do cliente
    • Como que ele usa o pipeline de release da aplicação?
    • O que é manual? Como ele dedica pessoas pra atuarem na pipeline?

Guiar clientes para migração p/ nuvem com automação e DevSecOps

  • Ir pra nuvem sem comprometer o ambiente
  • Design para automação, observabilidade, alerta, recovery (rollback)
  • Padrões e metodologias DevSecOps
  • Desenhar processos para migrar
    • Tem ferramentas, com custo
    • APN tem programas de migração
    • MAP
    • Créditos para rodar a migração, montar uma PoC de containers
    • Existem facilidade de créditos que a APN fornece pra rodar as PoC
    • Conversa com o PDM/PDR pra ver as possibilidades de funding pra facilitar um benefício pra migração do cliente pra AWS
    • Nome do PDM/PDR aparece no painel do APN, provavelmente é a Jhuli
    • Treinamento Developer Essentials: sobre ferramentas de CI/CD
  • Tem que ter em mente no processo de modernização:
    • Fomentar a transformações culturais
    • Facilitador para entregar a estratégia de containers dentro da nuvem
    • Executar migrações, para levar o workload legado para a AWS
  • Participar do processo de desenvolvimento
    • Facilitar o entendimento do cliente
    • Codevelopment, montar uma PoC e participar com o cliente no desenvolvimento dos componentes
    • Mostrar pro cliente que fica mais fácil usar as ferramentas auto-gerenciadas da AWS

Abstração em plataformas de computação

  • Espectro da computação
    • On premises => VMs => Containers => Serverless functions
    • Otimizar abstração e maturidade
  • Considerações de arquitetura
    • Servidores on-premise
      • Maior customização
      • Construído pelo maior uso
    • VMs
      • Sem dependência da máquina física, maior abstração
      • Adoção maior, overhead de virtualização
    • Containers
      • Maior abstração da máquina física
      • Mais leve e enxuto
      • Quantidade grande de containers rodando em uma máquina física
      • Não tem o overhead da máquina virtual
      • Melhor prática: rodar distribuído em um cluster
      • Aumenta a dependência de rede
    • Serverless
      • Menos dependência do servidor e rede
      • Toda a infra é provisionada pelo cloud provider
      • "Infinitamente" escalável
      • Possibilidade de arquitetura baseada em eventos
      • Maior nível de dependência do cloud provider
        • Só roda na linguagem que o provider suporta0
  • Considerações operacionais
    • Servidores on-premise
      • Responsabilidade do cliente
      • Mais "trabalho" pra manter, monitorar, etc
    • VMs
      • Provedor de nuvem que se preocupa com a infra física
      • Gerenciar o que tem de SW instalado na máquina, tempo de boot
      • Outras preocupações que não tinha na máquina física
      • Estratégias p/ provisionar e gerenciar
    • Containers
      • Maior abstração da manutenção
      • Estruturas imutáveis
      • Depois que o container está rodando, não se altera o conteúdo da imagem, se precisar modificar algo tem que gerar outra imagem
    • Serverless
      • Modelo operacional único
      • Monitoramento tradicional é difícil
        • Ferramentas da AWS: CloudWatch, X-Ray
  • Considerações de integração
    • On premises
      • Mercado estabelecido, nem todas as aplicações estão preparadas para virtualização
    • VMs
      • Mais flexibilidade do deployment
      • Parceiros possuem software disponível pra usar na AWS, em AMIs
    • Containers
      • Mais moderno, grande quantidade de parceiros que conseguem rodar dentro de containers

Fundamentos de containers

  • Código, configuração, dependências, runtime tudo encapsulado no container

  • Container usa o OS do host para chamadas de OS

  • Ambiente de software se torna isolado do ambiente de execução

  • Benefícios dos containers

    • Portabilidade, posso migrar pra qualquer lugar, única dependência é o Docker ou orquestrador
    • Artefato único e imutável
    • Flexibilidade, rodar versões simultâneas, blue/green deployment
    • Velocidade, de desenvolvimento
    • Eficiência, melhor utilização de recursos do sistema

  • Comparação de arquiteturas

    • On prem: Aplicações A,B,C, bibiotecas, OS, hardware
    • VM: Várias VMs no topo de uma mesma máquina física
      • Libs, apps, e guest OS ficam isolados dentro de cada VM
    • Container: Apenas a aplicação e libs que precisa. Mais rápido pra rodar

  • Plataforma de containers

    • Suporte para AWS apenas via Docker

  • Imagens Docker

    • Base layer
      • Imagem "Pai", pode ser de um repo público (Docker Hub) ou algo que eu mesmo construí
      • Read only
    • Intermediate layer
      • Read only, onde vou instalar minha aplicação
    • Top Layer
      • Criada em tempo de execução
      • Read write
      • Quando o container é removido, as layers são também
    • FROM: centos:7 -> Não é o sistema operacional que vai ser instalado, e sim as bibliotecas do CentOS

Sumário

  • Lembrar do modelo de responsabilidade compartilhada
    • Colocar segurança nas aplicações dentro dos containers
  • Defesa em profundidade
    • Criar camadas de proteção pra acessar o orquestrador, security groups pras EC2, camadas pros containers, permissões de execuções nas aplicações, etc
    • Evitar comprometimento invasivo nos containers
  • Investir em automação E2E
    • Desde a criação das imagens até o deploy em produção
    • Automatizar a criação das camadas de segurança também
  • Mantenha segurança nas imagens dos containers
    • Menos é mais seguro
    • Minimizar footprint dos containers
    • Usar imagem com quantidade de componentes pré-configurados
    • Ex: JDK já testado e homologado
    • Instalar o menos possível
  • Limite os ambientes que pode executar os containers
    • Ex: executar um monte de tranqueira no cluster de prd
    • Procurar por vulnerabilidades (CVEs)

Persistent storage

  • S3, EFS, etc

Databases

  • Baixa latência = NoSQL

Service discovery/mesh

  • Quando subir um container, saber onde eles estão residindo
    • Em qual instância, em qual porta
    • Faz um mapa do endereço IP da instância

Secrets management

  • Usuário e senha, ex. banco
    • Gravar no arquivo = péssima ideia
  • Secrets são puxados individualmente por cada container

Escalar um host com múltiplos containers

  • Plataforma de orquestração
    • ECS e EKS

ECR

  • Imagens criptografadas com KMS, mais seguro

ECS

  • Fluxo:

    • Internet -> ELB -> EC2 Instance -> Task -> Container

  • Cada instância tem um Agent ECS

    • Toda comunicação é feita através do agent
    • Ele que recebe as requisições pra subir novos containers
    • Pull, run, etc é tudo feito pelo agent

  • Backplane do ECS

    • Gerencia comunicação com os agents
    • Chamadas de API
    • Engine p/ gerenciamento do cluster
    • Key/value store com informações do cluster

  • Não pede pra subir um container, e sim uma task

    • Task tem um ou mais containers que vão ser criados com ela
    • No TG coloca o nome do serviço pra onde vai redirecionar a chamada
    • No serviço vai estar configuradas as tasks

  • Serviço

    • Mapear requisições
    • Quantas tasks vão executar simultaneamente
    • Gerencia tasks, sobe novas instâncias das tasks, faz deploy

  • Task

    • Melhor prática: Mapeamento 1:1 entre tasks e containers
    • Containers da mesma task vão ser criados na mesma instância
    • Especifica imagem e nome do container
    • Container essencial = compartilha recursos com outros containers que vai subir dentro daquela task
      • Se o container cair, sobe em outro
    • Mountpoints: montagem de volumes
    • Limites de CPU e memória: Só com benchmark

  • Terminologia

    • Cluster = Grupamento lógico de instâncias EC2 onde as tasks rodam

Orquestração com o ECS

Task placement

  • Filtros que o ECS usa:

    • Task requirements: CPU, memória e networking
    • Custom constraint: filtro para localização, tipo de instância, AMI ou outros atributos
    • Placement strategy: Identificar instâncias que satisfazem as estratégias
    • última que esqueci de anotar: escolhe a EC2

  • Constraints and strategies

    • Strategies
      • Binpack: tudo na mesma instância p/ minimizar CPU ou memória. Usar o máximo de memória de uma única EC2
      • Spread: distribui igualmente entre as instâncias
    • Constraints
      • Affinity: Lançar tasks baseada em nomes de grupos com tags. Estilo cluster placement de EC2
      • Distinct instance: Cada task em uma instância diferente
        • Se tiver AutoScaling, ele sobe uma instância daquele tipo se não tiver
        • Se não tiver AutoScaling, fica em HOLD até alguém subir uma instância
aws ecs run-task --cluster ecs-demo --task-definition myapp --count 5 --placement-constraints type="memberOf",expression="(attribute:ecs.instance-type == t2.small or attribute:ecs.instance-type == t2.medium) and attribute:ecs.availability-zone != us-east-1d"

  • Task Scheduler

    • Workload on-demand
    • Rodar 1x
    • Batch jobs
    • Não vai rodar o container se o serviço morrer

  • Service Scheduler

    • Long-running apps
    • Gerenciamento de saúde
    • Scale in/out entre AZs
    • Múltiplas tasks

  • Integração com o ECS

    • Service Discovery
    • Endereçamento DNS ou descoberta de API
    • Quando manda subir um grupo de tasks no ECS
      • ECS registra no AWS CloudMap
      • Atualiza um grupo de entradas DNS do Route53
      • Cliente faz a chamada pro CloudMap pra descobrir a API ou o DNS

  • Fargate

    • Lança os containers em um parque de máquina por baixo dos panos, você não gerencia e não tem visibilidade
    • Parâmetro do Fargate fica na Task Definition
    • Launch Type = FARGATE
    • family
    • Fargate = até 10 containers na mesma task
    • Define limite CPU e memória dentro da task definition
      • E depois define dentro dos containers também
    • Platform: Versões do Docker, do OS Kernel, etc
    • IAM:
      • Restrições de execuções do cluster ou da task
      • Colocar algumas restrições do IAM
      • Permissões do cluster = quem pode lançar, parar e descrever operações no cluster
      • Application permissions = Quais serviços que essa aplicação vai se comunicar, ex S3
        • Parecida com uma role da EC2
      • Task housekeeping = Tarefas de manutenção no cluster Fargate
        • ECS service linked role:
          • Gerenciar ENI
          • Registrar e deregistrar no ELB
        • Task Execution IAM role
          • ECR pull
          • CloudWatch logs push
      • Resource pode ser a família da task def
    • EBS
      • Armazenamento efêmero usando EBS
      • 10GB por task
      • Volume para scratch space (compartilhado entre containers)
        • 4GB por task
        • Mount points especificados na task definition
        • Pode compartilhar entre containers

EKS

  • Kubernetes

    • Projeto Open Source CNCF
    • Orquestrador de containers open source

  • EKS = Kubernetes Gerenciado

  • etcd é gerenciado pelo EKS

  • Master nodes

    • Controller Manager (fornece comunicação via kubectl)
    • Cloud controller: interage com a plataforma de nuvem
    • Scheduler: Recebe as requisições pra lançar containers
    • Abstraídos no API Server

  • ETCD: Banco chave-valor que armazena valores do estado do cluster

  • Worker nodes: nós provisionados, gerenciados pelo cliente

    • pods
    • kube-proxy
    • Qualquer runtime de containers
      • EKS suporta Docker
    • Kubelet: recebe requisições do API Server pra lançar um container
      • Equivalente ao ECS agent

  • Deployment => ReplicaSet => Pods

  • Service => Apenas direcionamento das chamadas

    • Port = 80
    • TargetPort = 13721

  • Gestão de rotação de senhas pelo Parameter Store e Secrets Manager

O que usar

Depende do caso de uso do cliente, conhecimento, como ele quer trabalhar, etc.

  • Fargate é mais fácil, bom ponto de partida
    • EKS também suporta Fargate :O
  • ECS é melhor se o cliente manja mais de orquestração
    • Se o cliente rodava containers de forma manual, mas nunca trabalhou com orquestração de containers
  • EKS é melhor se o cliente já roda K8S ou prefere software open source

Como rodar containers na AWS

  • Well Architected Framework

    • Mecanismo para a jornada na AWS
    • Questões pra identificar o alinhamento com as boas práticas
    • Princípios de design
    • Pilares

  • Excelência operacional

  • Segurança

  • Confiabilidade, resiliência

  • Tirar melhor performance do ambiente

  • Otimização de custo

  • Runbook: pdf com perguntas

  • Well architected tool

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment