O cloud-init é o padrão de facto para inicializar instâncias na nuvem durante o primeiro arranque. Quando lança uma instância e lhe passa um script de user-data, é o cloud-init que o interpreta e executa: cria utilizadores, escreve ficheiros, instala pacotes, monta discos ou arranca serviços.
A combinação ideal é clara: a golden AMI contém o que não muda —sistema operativo, runtime, hardening— e o user-data traz o que varia por ambiente ou por instância: configuração, segredos injetados, papel. Assim reutiliza uma única imagem em muitos contextos.
Duas formas de escrever user-data
O user-data admite vários formatos; os dois mais comuns são o script de shell e o cloud-config.
- Script de shell: começa por
#!/bin/bash. Simples e direto para tarefas rápidas. - cloud-config: começa por
#cloud-confige usa YAML declarativo. Mais limpo, legível e idempotente para configurar utilizadores, pacotes, ficheiros e comandos.
Exemplo de cloud-config
Um #cloud-config típico declara secções como packages: (pacotes a instalar),
write_files: (ficheiros de configuração), runcmd: (comandos finais) e users:
(contas e chaves). Sendo declarativo, é mais fácil de rever e manter do que um script
longo.
Boas práticas
- Mantenha o user-data pequeno: se crescer demasiado, provavelmente isso devia estar cozido na AMI.
- Idempotência: desenhe os comandos para que reexecutá-los não parta nada.
- Nunca ponha segredos em claro no user-data: é legível a partir dos metadados da instância. Injete-os do Secrets Manager, Parameter Store ou Vault em tempo de execução.
- Proteja o acesso aos metadados: use IMDSv2 para mitigar o roubo de credenciais via SSRF.
- Registe e depure: os logs do cloud-init (
/var/log/cloud-init-output.log) são o seu melhor amigo quando algo falha.
Baking ou booting: onde pôr cada coisa
| Vai na AMI (baking) | Vai no user-data (booting) |
|---|---|
| Sistema operativo e patches | Configuração específica do ambiente |
| Runtime, agentes e hardening | Variáveis e parâmetros por instância |
| Software estável e pesado | Registo no cluster e descoberta |
| Tudo o que demora a instalar | Injeção de segredos em runtime |
Regra de ouro: o estável e lento coze-se; o variável e leve vai no arranque.
Erros comuns que custam horas
- Meter no user-data o que devia estar na imagem, com arranques lentos e frágeis como resultado.
- Expor segredos em texto simples nos metadados.
- Supor que o user-data se reexecuta em cada arranque: por omissão só corre no primeiro.
- Não rever os logs do cloud-init quando a instância «não faz o que devia».
Perguntas frequentes
O user-data executa-se em cada reinício?
Por omissão, só no primeiro arranque. É possível configurar o cloud-init para executar certas partes em cada arranque, mas convém fazê-lo de forma consciente e idempotente.
É seguro passar palavras-passe no user-data?
Não. O user-data é legível a partir dos metadados da instância. Use um gestor de segredos e injete-os em tempo de execução, e proteja os metadados com IMDSv2.
O cloud-init só funciona na AWS?
Não. O cloud-init é multiplataforma e funciona na AWS, Azure, GCP e outras, o que o torna ideal para automatizar o arranque de forma portável.
Na imaxe.cloud desenhamos imagens pensadas para se combinarem com o cloud-init, de modo que uma só AMI lhe sirva em muitos cenários.
