AWS – pegadinha na cópia de AMIs entre regiões

dilbert_09012013_big_data_cloud

Esta semana me deparei com uma “pegadinha” em um projeto que me custou pelo menos umas 2 horas e algum stress: a cópia de AMIs entre regiões.

Quando criamos uma instância a partir de uma AMI padrão (ex: versão mais recente do Amazon Linux), normalmente deixamos ela obter um ID de kernel default. Podemos depois ver na página de detalhes da instância qual foi o ID obtido, conforme abaixo. Neste caso, o ID obtido foi aki-fc37bacc.

detalhes_instancia

Após a cópia (que demora bastante), provavelmente vamos criar uma nova instância a partir da AMI copiada. Para subir com sucesso a instância na nova região, precisamos criá-la com um ID de kernel compatível com o da instância original. Basta escolher o mesmo, certo? Errado! Os IDs de kernel variam de uma região para a outra, e você dificilmente encontrará o mesmo ID de kernel da região original. No meu caso, ao criar a instância com o kernel default, eu me deparava com um erro no 2o status check da instância (Instance Reachability), que ficava preso no status “Initializing” e a instância não terminava nunca sua inicialização. A instância deve chegar em poucos segundos à situação abaixo, caso contrário provavelmente ocorreu algum problema sério no boot.

status_checks

O que fazer então? No meu caso, a instância original havia sido criada com o Ubuntu Server 12.04 LTS. Criei uma nova instância do zero na região de destino com a AMI do Ubuntu Server 12.04 e deixei no Kernel ID default. Após a criação, chequei qual foi o kernel ID gerado para a nova instância. Tentei novamente subir uma instância com a AMI migrada de região, desta vez escolhendo explicitamente o kernel ID que acabei de anotar. Pronto, subiu 100% tranquilo e sem problemas, e foi um baita alívio. Espero que isto ajude a outras pessoas que se deparem com a mesma situação 🙂 Até a próxima!

Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.