Introdução
Sua equipe quer que cada novo servidor de relatórios inicie com a mensagem correta da aplicação. Você escreverá um script Bash de User Data, fornecerá esse script ao lançar uma instância EC2 e inspecionará a aplicação e o log de inicialização resultantes.
Você já deve saber lançar uma instância EC2 e conectar-se por SSH. Este novo ambiente fornece sua própria imagem, rede e par de chaves; você criará o servidor e sua configuração de inicialização.
Relação com a certificação
Este laboratório pratica a configuração programática de recursos e a automação da inicialização, relacionadas à tarefa 3.1 dos objetivos do domínio 3 do AWS Certified Cloud Practitioner CLF-C02.
Configurar a aplicação no lançamento
Nesta etapa, você escreverá um script de inicialização, lançará uma instância com ele e verificará a resposta da aplicação.
User Data são informações fornecidas a uma instância no lançamento. Um script de inicialização Linux pode usá-las para configurar software automaticamente. Por padrão, esses scripts são executados como root na primeira inicialização, portanto seus comandos não precisam de sudo. O guia oficial de EC2 User Data descreve esse comportamento e a localização do log.
Comece no seu diretório de trabalho:
cd /home/labex/project
A imagem preparada contém a aplicação de relatórios. Carregue os IDs da imagem e da rede no seu shell atual:
source launch.env
Crie user-data.sh com um here-document. Os marcadores externos SCRIPT delimitam o script inteiro; os internos JSON delimitam a configuração da aplicação. Marcadores entre aspas preservam o texto literalmente. A primeira linha, #!/bin/bash, seleciona Bash, enquanto set -euo pipefail interrompe o script quando um comando falha ou uma variável não definida é usada. O último echo escreve uma entrada útil no log de inicialização.
cat > user-data.sh <<'SCRIPT'
#!/bin/bash
set -euo pipefail
cat > /etc/report-app/config.json <<'JSON'
{
"message": "Started with User Data"
}
JSON
echo 'Report application configuration applied.'
SCRIPT
Isso cria um arquivo local; nenhuma instância é alterada ainda. Forneça o arquivo a run-instances usando --user-data file://user-data.sh. A AWS CLI lê e codifica o arquivo para a API, portanto você não precisa codificá-lo manualmente. Nomeie este servidor como bootstrap-server:
aws ec2 \
run-instances \
--image-id "$AMI_ID" \
--instance-type t3.micro \
--subnet-id "$SUBNET_ID" \
--security-group-ids "$SECURITY_GROUP_ID" \
--key-name report-key \
--count 1 \
--user-data file://user-data.sh \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=bootstrap-server}]'
Salve o ID da nova instância. O filtro seleciona sua tag de nome, e $(...) captura o resultado em texto simples:
INSTANCE_ID=$(aws ec2 \
describe-instances \
--filters Name=tag:Name,Values=bootstrap-server \
--query 'Reservations[0].Instances[0].InstanceId' \
--output text)
Inspecione o estado e o endereço público:
aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name,PublicIPv4:PublicIpAddress}'
Confirme running. Se ainda estiver pending, aguarde um pouco e repita a consulta. O estado em execução, por si só, não prova que a configuração de inicialização funcionou; agora você verificará a aplicação.
Abra AWS View, clique em Refresh resources e selecione bootstrap-server em Application requests. Clique em Check application. Confirme HTTP 200 e a mensagem Started with User Data. Você configurou o servidor por meio do script de inicialização, sem editá-lo depois do lançamento.
Este exemplo mostra a resposta esperada. Os IDs da sua instância e rede serão diferentes.
Obtenha o endereço público para conectar-se por SSH:
PUBLIC_IP=$(aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[0].Instances[0].PublicIpAddress' \
--output text)
A configuração SSH fornecida seleciona a chave privada e a rota de acesso do laboratório:
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
Agora você está dentro da instância da aplicação. Leia o log de saída da inicialização com privilégios de administrador:
sudo cat /var/log/cloud-init-output.log
Procure Report application configuration applied. Essa é a saída do script fornecido. Ao diagnosticar uma falha de inicialização, procure erros de comandos nesse log e depois teste a aplicação, em vez de depender apenas do estado da instância.
Volte ao terminal do LabEx:
exit
Você também pode obter o User Data armazenado na instância. Esta consulta seleciona seu valor Base64, e o pipe o envia a base64 --decode para exibir o script original:
aws ec2 \
describe-instance-attribute \
--instance-id "$INSTANCE_ID" \
--attribute userData \
--query 'UserData.Value' \
--output text | base64 --decode
Confirme que o script Bash e a mensagem correspondam ao seu arquivo. User Data normalmente é executado apenas na primeira inicialização; parar e iniciar uma instância não repete automaticamente essa configuração. Use a automação da inicialização para uma configuração inicial reproduzível e não inclua credenciais no script.
Terminar o servidor inicializado
Nesta etapa, você removerá a instância criada e verificará seu estado final.
Termine somente a instância identificada pela variável salva:
aws ec2 \
terminate-instances \
--instance-ids "$INSTANCE_ID"
Espere a instância atingir terminated. O waiter consulta o estado periodicamente e retorna sem saída quando tem sucesso:
aws ec2 \
wait instance-terminated \
--instance-ids "$INSTANCE_ID"
Confirme o estado final:
aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name}'
O resultado deve mostrar terminated. Atualize o AWS View e confirme que bootstrap-server não é mais um destino de aplicação em execução. Mantenha a rede e o par de chaves preparados.
Resumo
Você escreveu um script Bash de User Data e o forneceu ao EC2 no lançamento. Verificou a configuração automática da aplicação no AWS View, inspecionou o log de saída da inicialização e obteve o script armazenado. Por fim, terminou o servidor e confirmou seu estado final.
