Automação operacional com o Systems Manager
Operações de dia 2 em escala: alcançar a frota pelo Systems Manager em vez de SSH, manter os nodes com patches em dia e sem desvio de configuração, centralizar a configuração no Parameter Store, e ligar o trabalho de rotina a eventos e cronogramas.
Os tópicos anteriores construíram e entregaram infraestrutura. Este é sobre os servidores que já estão rodando e o trabalho que nunca acaba: alcançar eles, aplicar patches, manter a configuração no lugar e automatizar as partes da semana que se repetem. É também o tópico em que uma única base sustenta tudo, porque nenhuma ferramenta do Systems Manager funciona antes de a instância virar um managed node, e a maior parte das falhas por aqui é essa condição não atendida.
O que este tópico cobre
- As 3 condições que tornam uma instância EC2 um managed node, e a ordem de diagnóstico que encontra a quebrada mais rápido
- Instance profiles contra a Default Host Management Configuration, incluindo a permissão que faz um sobrepor o outro em silêncio
- O Session Manager como substituto de chaves SSH e bastion hosts, e as sessões que o log dele não alcança
- Targeting do Run Command por ID, tag e resource group, com os padrões de concorrência e de erro que decidem como um comando de frota inteira se comporta
- Fleet Manager e Inventory, e o resource data sync que torna o inventário consultável entre contas
- Patch Manager: Scan contra Install, regras de aprovação de baseline e o padrão de 7 dias, como um patch group resolve para um baseline, e os estados de compliance com a opção de reboot por trás deles
- Maintenance windows com duração e cutoff, patch policies para uma organização, e associations do State Manager para configuração que se recoloca no lugar
- Parameter Store: os 3 tipos, hierarquias e a armadilha de path no IAM, tiers, policies, versões e labels, o teto de 40 TPS e as dynamic references do CloudFormation
- S3 Event Notifications, EventBridge Scheduler, e a escolha de onde um cronograma operacional deve morar
- O Change Calendar como a guarda que manda a automação em execução esperar
Por que isso importa
O domínio 3 vale 22% do SOA-C03, e este tópico entrega as questões que parecem chamado de suporte em vez de exercício de arquitetura: uma instância que não aparece no console, um patch lançado ontem que não instalou, um node reportando compliant enquanto um patch crítico está faltando, uma aplicação sofrendo throttling em leituras de configuração no instante em que ela escala. Cada uma tem uma configuração específica por trás.
A pressão no trabalho tem o mesmo formato. A diferença entre um time de operações que escala e um que não escala está em o trabalho de rotina ser descrito uma vez e aplicado por um serviço, ou executado por uma pessoa que precisa lembrar dele.