EC2 Windows pronta para escalar: sysprep e AMI antes do Auto Scaling

Escalar instância Windows na AWS é simples. O difícil é preparar a instância antes de gerar a AMI: se você a imageia do jeito comum, a instância nova sobe sem senha recuperável e você perde o acesso. Aqui está o erro acontecendo, o ajuste que evita o problema e o caminho até o Auto Scaling group.

O problema: AMI de Windows sem preparo

Um caso típico é a aplicação legada que não roda em Linux ou que depende de alguma particularidade do Windows. Você coloca seus recursos numa EC2 Windows e, para ter mais máquinas iguais atendendo à demanda, gera uma imagem (AMI) e liga essa imagem a um Auto Scaling.

Você quer a imagem congelada, mas com a possibilidade de voltar nela para atualizar o aplicativo ou instalar um software mais complexo de atualizar por user data. Para isso, a máquina que nasce da imagem precisa continuar acessível.

A senha do administrador do Windows é gerada quando a instância é lançada. Se você para a máquina e gera a imagem sem preparar nada, essa senha vai junto, "congelada". Na instância nova, o console não entrega uma senha que você consiga recuperar com a chave.

1Lançar duas instâncias para comparar

Lancei duas instâncias iguais, para ver o contraste:

• Windows Server 2019 Base, tipo t3a.micro, duas instâncias, com IP público.
• Disco de 30 GB e a tag Name para distinguir uma da outra.
• Security group com entrada RDP liberada só para o meu IP.
• Um par de chaves novo, baixado na máquina.

Conectei nas duas por RDP, recuperando a senha pelo console com a chave. Em cada uma criei uma pasta no disco C: com um arquivo de texto dentro. É o meu "aplicativo de exemplo": o que a instância precisa ter toda vez que subir.

2O caminho que dá errado

Na primeira instância fiz o que muita gente faz: parei a máquina e criei a imagem pelo console (Image and templates, Create image). Como a instância já estava parada, não precisei me preocupar com o reboot.

Lancei uma instância nova a partir dessa AMI e fui buscar a senha com Get password. O console avisa que a senha não está disponível e pede para esperar pelo menos 4 minutos depois do lançamento.

Esperei os 4 minutos e tentei de novo. A senha não aparece: a imagem não foi preparada para isso. Sem a senha, não dá para entrar, e uma imagem inacessível não serve para escalar.

Existem saídas fora do caminho padrão, como pegar o snapshot, criar um volume e anexar a outra instância. O caminho natural é preparar antes de gerar a imagem.

3Preparar com o Ec2 Launch Settings

Na segunda instância, antes de parar e gerar a imagem, abri o Ec2LaunchSettings pelo menu Iniciar do Windows (a janela se chama Ec2 Launch Settings). Fiz duas coisas:

1. Em Administrator Password, deixei marcada a opção Random (Retrieve from console). Com a senha aleatória, você volta a recuperá-la pelo console.
2. Cliquei em Shutdown with Sysprep, confirmei e apliquei.

O sysprep faz a limpeza: remove a senha gerada no lançamento original. Quando uma instância é lançada a partir da imagem, ele gera uma senha nova. É o "grande segredo" do processo. O Windows demora um pouco e, ao terminar, desliga a instância sozinho.

4Gerar a AMI e lançar a instância

Com a instância desligada pelo sysprep, o fluxo é o normal: Create image, nome para a AMI e espera até ficar disponível. Depois lance uma instância dessa imagem, com o mesmo tipo, o mesmo security group de RDP e a mesma chave.

O Windows tem uma particularidade: numa instância Linux eu conectaria em 30 ou 40 segundos, e no Windows preciso esperar a janela dos 4 minutos. Às vezes libera antes. Na minha, o Get password liberou depois de alguns minutos, e a senha era outra, diferente da usada na instância original.

Conectei por RDP e a pasta e o arquivo do disco C: estavam lá: a instância ficou acessível e com o meu "aplicativo".

Para evoluir a imagem, o ciclo é o mesmo: conecte na instância, faça a melhoria (eu criei uma segunda versão do arquivo), rode Shutdown with Sysprep de novo e gere a AMI nova. Como a senha aleatória já ficou marcada, é só aplicar e confirmar.

5Launch Template e Auto Scaling group

Com a AMI pronta, o caminho até a escala é este:

1. Crie um Launch Template (ou um Launch Configuration) apontando para a AMI e com a rotina que a instância deve executar.
2. Crie o Auto Scaling group e ligue o modelo a ele.
3. Defina as regras de escala no grupo.

O Launch Template é o modelo mais flexível; o Launch Configuration foi a primeira versão. Para o passo a passo de criar o modelo e o grupo, veja Auto Scaling Group com Launch Template.

As regras de escala mais convencionais são CPU e latência. No cliente em que passei por essa dor, nenhuma das duas serviu: o que funcionou foi a fila. O cliente faz um pedido num software dele, o pedido vira mensagem numa fila SQS, e o Auto Scaling olha a quantidade de mensagens na fila para lançar as instâncias Windows.

Se der para sair do Windows, saia

Todo esse processo existe só porque é Windows. Com instância Linux você não tem essa preocupação ao gerar a imagem. Se a sua carga puder mudar para Linux, boa parte desse trabalho some. Trabalhei com Windows por muitos anos, parei em 2018 e recomendo fugir dele quando der.

6Limpar o laboratório

Ao final, terminei as duas instâncias e cancelei o registro das AMIs que gerei (deregister). Limpando tudo, o custo do laboratório fica praticamente zero.

Checklist

• Instale na instância Windows tudo o que a imagem precisa ter, antes de gerar a AMI.
• Abra o Ec2LaunchSettings e confira se a senha do administrador está em Random.
• Clique em Shutdown with Sysprep e deixe a instância desligar sozinha.
• Gere a AMI só depois disso, sem parar e imagear a máquina "crua".
• Lance uma instância de teste da AMI e confirme que recupera a senha e que o app está lá.
• Aponte um Launch Template para a AMI e ligue-o a um Auto Scaling group.
• Escolha a regra de escala que combina com a sua carga: CPU, latência ou fila.
• Termine as instâncias de teste e cancele o registro das AMIs.

Escalar Windows na AWS dá certo quando o preparo da imagem vem antes. Se você precisa levar uma aplicação legada para a nuvem e escalar sem perder o acesso às máquinas, é esse ajuste que evita a dor.