instalações automatizadas vs. imagem de unidade

Quais são os prós e os contras da implantação por meio de instalações automatizadas versus imagem de unidade? Para Windows, eu sei que há problemas em torno da geração de SID ao clonar unidades. Existem problemas semelhantes para implantar o Linux por meio de uma imagem?

Não concordo com algumas das respostas aqui. Se feito corretamente, você pode pegar uma imagem e carregá-la em vários sistemas usando hardware diferente. Pessoalmente, vi imagens que suportam até 30 sistemas diferentes.

Minha resposta para sua pergunta é usar os dois métodos se você for muito anal sobre a criação de uma imagem. Crie a instalação automatizada e, em seguida, organize o resultado. Isso levará a imagens repetidas e auto-documentadas.

Além disso, se você puder gravar na imagem do disco em seu estado salvo, poderá estender o que está na imagem incluindo um script que possa ser executado durante o sysprep. OU você pode fazer backup do seu sistema antes de executar um sysprep, estendê-lo e executar um sysprep depois.

Eu fiz os dois métodos com bons resultados.

Com relação aos problemas do SID, você deve sempre usar o Sysprep para uma nova imagem (embora o NewSID funcione), que resolverá os problemas do SID. No entanto, existem outros aplicativos que gravam GUIDs no registro que precisam ser limpos. Em cima da minha cabeça, Altiris e WSUS são dois que fazem isso.

A imagem é uma proposição perdedora. Uma instalação completa do kickstart do CentOS deve levar menos de 10 minutos. Se sua instalação for significativamente mais lenta, é um problema que vale a pena investigar.

O problema com a criação de imagens é que você deve manter uma cópia "dourada" e atualizá-la à medida que faz alterações na sua compilação. Isso significa que você ainda precisa de um mecanismo para uma instalação autônoma, e cada alteração exige essa instalação, alteração da imagem (requer um mecanismo de personalização automatizada para o seu ambiente) e a cópia em ouro. Se você for fazer alterações diretamente na sua cópia dourada, você acabará rapidamente com uma bagunça depois de anos de correções, atualizações etc.

Se você deve criar uma imagem dos sistemas, deve criar uma imagem da compilação padrão do sistema operacional e fazer com que seu trabalho pós-instalação (personalização local) ocorra separadamente em cada nova máquina. Dessa forma, alterações triviais na compilação não exigirão a reconstrução da cópia dourada.

Se o seu hardware não for todo idêntico, você poderá aproveitar a detecção / configuração automatizada do instalador. Usei uma configuração Kickstart praticamente idêntica entre o RedHat / CentOS 3, 4 e 5 e todos os tipos de hardware.

O pior resultado de imagem que eu já vi foi um sistema de instalação de sistemas Solaris usando uma imagem dourada (e dd com multipacks). O instalador e as correções são tão lentos que isso parecia fazer sentido. Infelizmente, eles não alteram completamente o hardware de um sistema instalado. Cada tipo de hardware tinha sua própria imagem dourada. Uma alteração trivial na construção exigiria uma alteração em dezenas de discos. O segundo pior foi o de máquinas de geração de imagens de grupo do Windows (novamente razoáveis ​​devido a um instalador danificado) em comparação com um grupo Linux usando o Kickstart. O grupo Linux pode implantar uma alteração na configuração do DNS em alguns minutos. (Um minuto para alterar a pós-instalação, depois uma compilação de teste e, em seguida, um envio manual da configuração para as máquinas existentes). O grupo do Windows teve que inicializar cada imagem dourada, fazer a alteração, desfaça a crosta causada pela inicialização da imagem dourada e faça uma compilação de teste. (Eles também tiveram que comprar ferramentas especiais para automatizar alterações na configuração do sistema em várias máquinas, para alterar as máquinas existentes). O grupo Windows também teve a opção de reinstalar a imagem de ouro para fazer as alterações, mas, como se tratava de uma instalação manual do sistema operacional e de dezenas de aplicativos, seria um pouco diferente a cada vez, exigindo semanas de testes e arriscando menos os sistemas de produção. idêntico ao possível.

Observe que, nos dois casos, as configurações do Windows e Solaris usando uma imagem dourada não foram tratadas da melhor maneira possível e algumas das escolhas feitas pelos administradores envolvidos menosprezavam a falta de competência. Mas começar com um design que não era razoável não ajudou.

O Kickstart funciona tão bem que não há motivo para considerar fazer o contrário (tenho muitas queixas sobre isso, mas seria mil vezes pior se fosse feito por máquinas de imagem). Se o seu programa de instalação é algo além do Anaconda e suas instalações automatizadas são menos úteis que o kickstart, você deve considerar se essa distribuição foi realmente destinada ao uso corporativo.

A geração de imagens da unidade é mais rápida, mas o seu hardware precisa ser muito semelhante para funcionar. Também é mais difícil personalizar a imagem, você precisará de uma imagem base para um servidor Web, servidor de email etc. Com instalações automatizadas, você pode instalar todas as máquinas no mesmo local de rede, mas usar scripts diferentes, dependendo do tipo de servidor você deseja, em vez de precisar armazenar e criar várias imagens.

Eu realmente não posso comentar sobre o lado Linux, mas com o Windows eu diria que não há muitos profissionais para usar um processo automatizado sobre uma imagem.

Há muitas orientações disponíveis na Microsoft, aqui .

A prova está no pudim. A Microsoft agora usa implantações baseadas em imagem para Vista, Windows 2008 e Windows 7. Usando as novas ferramentas e processos descritos no link acima, você pode implantar o Windows em qualquer tipo de HAL (incluindo XP), com suporte total ao driver e sem muito esforço .

A implantação do Windows via imagens é totalmente suportada pela Microsoft usando o Sysprep para "selar de fábrica" ​​a imagem antes de implantá-la. O Sysprep redefine o SID e essencialmente prepara a imagem para uma nova máquina.

No entanto, é altamente recomendável (a menos que você seja uma empresa pequena) também ter uma instalação totalmente com script, por um motivo simples. Sempre que você precisar atualizar sua imagem, você tem duas opções:

1) Modifique continuamente a imagem existente e re-sysprep toda vez. Isso acabará resultando em problemas, à medida que você continua corrigindo, modificando e sysprepping a mesma imagem repetidamente.

2) Recrie a imagem do zero, o que é bastante preferível. No entanto, se você não tiver uma compilação com script, corre o alto risco de obter muitas inconsistências entre compilações.

Então, em resumo:

• Use uma construção com script para criar uma imagem
• Use a imagem para implantação

Uma desvantagem adicional disso tudo é que o Windows Vista, 2008 e 7 usam uma instalação baseada em imagem; portanto, os ganhos do uso da instalação baseada em imagem versus com script desapareceram de qualquer maneira.

depende de quais aplicativos você instalará e por quanto tempo manterá a imagem não atualizada.

existem muitas atualizações todos os meses, portanto, mesmo após restaurar a caixa da imagem, você precisará atualizá-la.

em relação ao SID - até onde eu sei, é suficiente se você gerar chaves privadas exclusivas [para ssh, https, tls, por exemplo, para servidores smtp / pop3 etc.] isso deve funcionar bem. também seria interessante gerar um nome de host exclusivo. isso pode variar dependendo da distribuição, eu estou usando principalmente o debian e não tive nenhum problema ao clonar máquinas virtuais com esse sistema operacional.

Confira esta pergunta que é muito semelhante:

/programming/398410/windows-disk-cloning-vs-automatic-installation-of-servers

(Eu perguntei no stackoverflow.com há um tempo atrás, quando serverfault.com não estava por perto).

Especialmente se você tiver um hardware diferente, sugiro automatizar. Para janelas, olhe autônoma.

http://unattended.sourceforge.net/