¿Cuáles son los pros y los contras de la implementación a través de instalaciones automáticas frente a imágenes de disco? Para Windows, sé que hay problemas en torno a la generación de SID al clonar unidades. ¿Existen problemas similares para implementar Linux a través de una imagen?
Respuestas:
No estoy de acuerdo con algunas de las respuestas aquí. Si se hace correctamente, puede tomar una imagen y cargarla en varios sistemas utilizando hardware diferente. Personalmente, he visto imágenes que admiten hasta 30 sistemas diferentes.
Mi respuesta a tu pregunta es usar ambos métodos si eres muy anal sobre la creación de una imagen. Cree la instalación automatizada y luego sysprep el resultado. Esto conducirá a imágenes repetibles y autodocumentadas.
Además, si puede escribir en la imagen del disco en su estado guardado, puede ampliar lo que está en la imagen al incluir un script que se puede ejecutar durante sysprep. O bien, puede hacer una copia de seguridad de su sistema antes de tomar un sysprep y luego extenderlo y tomar un sysprep después.
He hecho ambos métodos con buenos resultados.
Con respecto a los problemas de SID, siempre debe usar Sysprep para una nueva imagen (aunque NewSID funcionará), lo que resolverá cualquier problema de SID. Sin embargo, hay otras aplicaciones que escriben GUID en el registro que deberían limpiarse. Fuera de mi cabeza Altiris y WSUS son dos que hacen esto.
La imagen es una propuesta perdedora. Una instalación completa de arranque de CentOS debería llevar menos de 10 minutos. Si su instalación es significativamente más lenta, ese es el problema que vale la pena investigar.
El problema con la creación de imágenes es que debe conservar una copia "dorada" y actualizarla a medida que realiza cambios en su compilación. Esto significa que aún necesita un mecanismo para una instalación desatendida, y cada cambio requiere realizar dicha instalación, cambiar la imagen (requiere un mecanismo de personalización automatizada para su entorno) y hacer que esta copia sea la copia de oro. Si va a hacer cambios directamente en su copia dorada, rápidamente terminará con un desastre después de años de parches, actualizaciones, etc.
Si debe crear una imagen de los sistemas, debe crear una imagen de la compilación predeterminada del sistema operativo y hacer que su trabajo posterior a la instalación (personalización local) se realice por separado en cada nueva máquina. De esta manera, los cambios triviales en la compilación no requerirán reconstruir la copia dorada.
Si su hardware no es todo idéntico, puede aprovechar la detección / configuración automatizada del instalador. He utilizado una configuración Kickstart prácticamente idéntica entre RedHat / CentOS 3, 4 y 5, y todo tipo de hardware.
El peor resultado de las imágenes que he visto fue un sistema de instalación de sistemas Solaris usando una imagen dorada (y dd con paquetes múltiples). Su instalador y parcheo es tan lento que parece tener sentido. Desafortunadamente, hacen que cambiar completamente el hardware de un sistema instalado no sea trivial. Cada tipo de hardware tenía su propia imagen dorada. Un cambio de compilación trivial requeriría hacer un cambio en docenas de discos. El segundo peor fue un grupo de máquinas de imágenes de Windows (nuevamente razonable debido a un instalador paralizado) en comparación con un grupo de Linux que usa Kickstart. El grupo de Linux podría implementar un cambio en, digamos, la configuración de DNS en unos minutos. (Un minuto para cambiar el postinstall, luego una compilación de prueba y luego un envío manual de la configuración a las máquinas existentes). El grupo de Windows tuvo que arrancar cada imagen dorada, hacer el cambio, deshaga la muesca causada por el arranque de la imagen dorada, luego haga una prueba de construcción (También tuvieron que comprar herramientas especiales para automatizar los cambios en la configuración del sistema en varias máquinas, para cambiar las máquinas existentes). El grupo de Windows también tenía la opción de reinstalar la imagen dorada para hacer su cambio, pero como era una instalación manual del sistema operativo y docenas de aplicaciones, sería ligeramente diferente cada vez que requeriría semanas de pruebas y el riesgo de que los sistemas de producción fueran menos idéntico de lo contrario posible.
Tenga en cuenta que en ambos casos, las configuraciones de Windows y Solaris que utilizan una imagen dorada no se manejaron de la mejor manera posible y algunas de las elecciones realizadas por los administradores involucrados ocultaron una falta de competencia. Pero comenzar con un diseño que no fuera razonable no ayudó.
Kickstart funciona tan bien que no hay razón para considerar hacer lo contrario (tengo muchas quejas al respecto, pero sería mil veces peor si lo hicieran las máquinas de imágenes). Si su programa de instalación es algo más que Anaconda, y sus instalaciones automatizadas son menos útiles que kickstart, debe considerar si esa distribución realmente fue destinada para uso empresarial.
La imagen de la unidad es más rápida, pero su hardware tiene que ser muy similar para que funcione. También es más difícil personalizar la imagen, necesitaría una imagen base para un servidor web, un servidor de correo electrónico, etc. Con las instalaciones automáticas, puede hacer que todas las máquinas se instalen desde la misma ubicación de red, pero use diferentes scripts según el tipo de servidor desea en lugar de necesitar almacenar y crear múltiples imágenes.
Realmente no puedo comentar sobre el lado de Linux, pero con Windows diría que no hay demasiados profesionales para usar un proceso automatizado sobre una imagen.
Hay mucha orientación disponible de Microsoft, aquí .
La prueba está en el pudín. Microsoft ahora usa implementaciones basadas en imágenes para Vista, Windows 2008 y Windows 7. Usando las nuevas herramientas y procesos descritos en el enlace anterior, puede implementar Windows en cualquier tipo de HAL (incluido XP), con soporte completo de controladores y sin una gran cantidad de esfuerzo .
Microsoft implementa totalmente Windows mediante imágenes mediante Sysprep para "sellar de fábrica" la imagen antes de implementarla. Sysprep restablece el SID y esencialmente prepara la imagen para una nueva máquina.
Sin embargo, se recomienda encarecidamente (a menos que sea una empresa pequeña) tener también una instalación totalmente programada, por una simple razón. Cada vez que necesite actualizar su imagen, tiene dos opciones:
1) Modifique continuamente la imagen existente y vuelva a prepararla cada vez. Esto eventualmente resultará en problemas a medida que continúes parcheando, modificando y preparando la misma imagen una y otra vez.
2) Recree la imagen desde cero, lo cual es ampliamente preferible. Sin embargo, si no tiene una compilación programada, corre el riesgo de obtener muchas inconsistencias entre las compilaciones.
Entonces, en resumen:
Una desventaja adicional en todo esto es que Windows Vista, 2008 y 7 usan una instalación basada en imágenes, por lo que las ganancias de usar la instalación basada en imágenes frente a la secuencia de comandos han desaparecido de todos modos.
depende de qué aplicaciones instalará y cuánto tiempo mantendrá la imagen sin actualizar.
hay muchas actualizaciones cada mes, por lo que incluso después de restaurar el cuadro de la imagen, deberá actualizarlo.
con respecto a SID: hasta donde sé, es suficiente si genera claves privadas únicas [para ssh, https, tls, por ejemplo, para servidores smtp / pop3, etc.], esto debería funcionar bien. También sería agradable generar un nombre de host único. esto puede diferir según la distribución, principalmente estoy usando Debian y no tuve ningún problema para clonar máquinas virtuales con ese sistema operativo.
Mira esta pregunta que es muy similar:
/programming/398410/windows-disk-cloning-vs-automatic-installation-of-servers
(Lo pregunté en stackoverflow.com hace un tiempo, cuando serverfault.com no estaba cerca).
Especialmente si tienes un hardware diferente, te sugiero automatizado. Para ventanas mira desatendido.