Imagens de máquina e de contêineres
Como transformar a configuração de um servidor em um artefato versionado: AMIs douradas construídas por pipelines do EC2 Image Builder e imagens de contêiner guardadas, escaneadas e distribuídas pelo Amazon ECR.
Toda instância que sobe em uma frota precisa do mesmo sistema operacional com patch, dos mesmos agentes e do mesmo runtime. Fazer esse trabalho no momento do launch custa minutos em cada scale-out e ainda produz máquinas ligeiramente diferentes entre si. Este tópico troca esse modelo por outro: faça o trabalho uma vez, guarde o resultado como imagem e suba instâncias a partir dela.
São duas lições, uma para cada unidade de empacotamento que o SOA-C03 espera que você administre. A primeira trata da máquina inteira; a segunda, da aplicação sozinha.
O que este tópico cobre
- O que uma AMI realmente contém, por que ela é regional e por que o custo dela mora nos snapshots
- A decisão entre assar na imagem e bootstrapar no launch, e a regra que separa as duas
- Os cinco recursos do EC2 Image Builder e o que acontece em cada estágio de uma execução de pipeline
- Agendamento por atualização de dependência, distribuição entre Regiões e compartilhamento de AMIs criptografadas
- A diferença entre deprecate, disable e deregister, com as consequências de custo de cada um
- Layers, manifest, tags e digests, e por que fazer deploy por digest resolve o problema do
latest - Autenticação no ECR, as três camadas de permissão e a inversão que a replicação entre contas exige
- Escaneamento básico contra enhanced, lifecycle policies, replicação de registry e pull through cache
Por que isso importa
As questões desta área quase nunca perguntam o que é uma AMI. Elas descrevem um Auto Scaling group que continua subindo uma imagem reprovada, um pipeline que nunca entregou a AMI na Região de DR ou um cache que parou de atualizar depois de alguém ligar um ajuste de segurança, e pedem a causa. Responder exige saber o comportamento exato de cada ação, não a definição dela.
No trabalho, a diferença aparece no tempo de resposta. Uma frota que sobe a partir de uma imagem testada escala em segundos e é auditável por um único ID. Uma que se monta no boot escala na velocidade do repositório de pacotes mais lento.