Tema: provisioning
-
Arquivos de resposta do Windows (unattend.xml): fases de configuração e onde o Setup os procura
Um arquivo de resposta unattend.xml fornece configurações a fases específicas do Windows Setup; windowsPE, generalize, specialize e oobeSystem são as mais usadas em provisionamento. O Setup localiza o arquivo por uma ordem de busca implícita fixa e o guarda em cache em %WINDIR%\Panther; o Windows System Image Manager cria esses arquivos e pode ocultar neles, mas não criptografar, senhas de contas locais.
-
Comandos ad-hoc do Ansible e modo de verificação para uma primeira execução segura em uma frota de hosts
Um comando `ansible` ad-hoc executa um módulo em um ou mais hosts sem precisar de playbook; combinado com `--check --diff` e um `--limit` restrito, permite que um agente veja o que uma mudança faria na frota antes de aplicá-la.
-
Generalizar uma imagem do Windows com o Sysprep: /generalize, /oobe, /shutdown e o limite de rearm
O Sysprep /generalize remove de uma instalação do Windows as informações específicas do computador, como o SID e os dispositivos configurados, para que a imagem possa ser implantada em outros computadores. No Windows 8.1/Server 2012 e posteriores, o Sysprep pode ser executado até 1001 vezes por imagem (3 vezes no Windows 7/Server 2008 R2), e as falhas de generalização deixam rastros nos logs do Panther em System32\Sysprep.
-
Regenerar as chaves de host SSH e o machine ID em um host Linux clonado
Um host Linux recém-clonado precisa das próprias chaves de host SSH e do próprio machine ID antes de entrar em uma frota. O ssh-keygen -A e o systemd-machine-id-setup podem criá-los, mas, em um clone que já inicializou, um machine ID duplicado exige gravar um valor novo e reiniciar. Verificar duplicidades em toda a frota é a única confirmação real de que a clonagem não copiou os mesmos identificadores para todos os hosts.
-
Preparar uma golden image do Linux para clonagem: chaves de host, machine-id, logs e regras de rede
Uma imagem Linux destinada a ser clonada muitas vezes não pode conter um /etc/machine-id preenchido (nem um /var/lib/dbus/machine-id desatualizado), chaves de host SSH existentes, configuração de rede fixada a um MAC nem estado do cloud-init. Caso contrário, cada clone inicia com os mesmos identificadores dos demais, e remover as chaves de host sem um caminho de regeneração no primeiro boot deixa os clones sem SSH.
-
Desativar um servidor com segurança: removê-lo de todos os sistemas que ainda confiam nele
Desativar um servidor não é apenas desligá-lo: DNS, monitoramento, jobs de backup, o registro de inventário e qualquer objeto de computador no diretório continuam a confiar no servidor ou a esperá-lo, a menos que alguém o remova explicitamente. Além disso, o armazenamento precisa de um método de sanitização realmente adequado ao tipo de mídia antes de ser reutilizado ou descartado.
-
Criação de imagens de máquina com Packer: builders, provisioners, validate e build
O HashiCorp Packer separa os builders de um template (que plataforma produz a imagem) dos provisioners (o que configura a máquina antes de ela ser capturada). O `packer init` instala os plugins necessários, o `packer validate` verifica a sintaxe e a configuração do template antes de o `packer build` o executar, e marcar variáveis como sensíveis mantém credenciais fora dos templates e dos logs.
-
Debian preseed e Ubuntu autoinstall: dois formatos de instalação automatizada que não são intercambiáveis
O instalador do Debian é automatizado por um arquivo preseed que responde às perguntas do debconf, enquanto o Ubuntu Server (20.04+) e o Desktop (23.04+) usam o formato YAML autoinstall do Subiquity, entregue como user-data do cloud-init ou como autoinstall.yaml na mídia de instalação. Os dois formatos não são portáveis entre as distribuições e ambos devem ser validados antes de uso em uma instalação sem supervisão.
-
Agentes de provisionamento do primeiro boot no Windows na nuvem: EC2Launch v2, Azure VM Agent e cloudbase-init
A AWS, a Azure e a maioria das outras nuvens executam, dentro da imagem do Windows, um pequeno agente que processa user data ou custom data no primeiro boot; os agentes mais comuns são o EC2Launch v2, os agentes de provisionamento e Windows VM Agent do Azure (que gravam o custom data em CustomData.bin, mas não o executam) e o cloudbase-init, de código aberto. Cada um registra logs em um local diferente, que vale conferir quando o provisionamento parece ter falhado em silêncio.
-
Checklist de verificação pós-provisionamento antes de entregar um servidor
Um servidor que inicializa não é o mesmo que um servidor pronto para cargas de produção. Este checklist dá ao agente uma ordem fixa de verificações (hora, resolução de nomes, nível de patches, monitoramento, inclusão no backup, acesso e varredura de linha de base) a executar antes de marcar um host recém-provisionado como concluído.
-
Gerenciamento de configuração versus image baking: onde idempotência e drift decidem
Ferramentas de gerenciamento de configuração fazem um sistema em execução convergir para um estado declarado a cada execução, enquanto o baking de uma imagem de máquina fixa esse estado uma única vez, no momento do build; a idempotência torna a primeira abordagem segura para repetir, e escolher entre baking e configuração no boot é, na prática, escolher onde o drift pode acontecer.
-
Nomear, etiquetar e registrar um novo servidor: metodologia para hostnames e inventário
Um servidor que foi provisionado, mas não recebeu um nome consistente, etiquetas de responsável e finalidade, nem registro em um inventário, passa a ser infraestrutura sem documentação assim que quem o montou segue para outra função. Esta metodologia define o hostname no Linux e no Windows e descreve o que um registro mínimo de inventário deve conter.
-
Controlar o cloud-init em uma instância Debian ou Ubuntu recém-criada: user-data, status --wait e reexecuções seguras
O cloud-init aplica o user-data uma única vez, no primeiro boot; `cloud-init status --wait` bloqueia até essa execução terminar, para que um script de provisionamento não dispute com ela, `cloud-init schema --system` detecta um arquivo user-data inválido antes do próximo boot, e `cloud-init clean` é a forma documentada de forçar uma reexecução completa para testes.
Legível por máquina: JSON