Automatizar la implementación del servidor

Creo que constantemente configuro servidores y VPS casi idénticos para varios de mis clientes y puede llevar mucho tiempo. A menudo, lo único que cambia entre cada implementación es el sitio web diferente que se va a servir. ¿Hay una manera fácil de automatizar todo esto y tomar la aburrida monotonía de configurar 56 servidores idénticos?

Los servidores que he implementado hasta ahora solo han sido Ubuntu, pero es posible que comience a usar otros sistemas operativos Linux o incluso Windows. Hasta ahora he mirado a Capistrano, pero parece estar enfocado en escribir pequeños programas de rubíes para hacer el trabajo, y no tengo ningún conocimiento

Puppet suena perfecto para lo que estás tratando de hacer, con la advertencia de que, en este momento, no hay soporte para Windows.

En su caso, definiría un nodo Servidor en términos de todos los paquetes que son idénticos en todas las máquinas. Luego, define los hosts individuales como nodos que heredan del servidor y configura las cosas únicas específicas para él.

Puppet es declarativo: le permite describir sus cajas en términos de los recursos que debe tener cada caja. Entonces, si lo desea ssh, escriba una clase para ese recurso, y dentro de la clase puede incluir una lógica sobre cómo ssh se llama ligeramente diferente en FreeBSD vs Ubuntu. También sabe usar yumdentro de Redhat y apt-getdentro de distribuciones basadas en Debian, y portsen los BSD. Ahora en su nodo Servidor, solo tendrá una línea como include ssh, y Puppet hará lo correcto y pondrá SSH en la máquina sin tener que recordar si eso es Ubuntu o Redhat o FreeBSD.

Lo bueno es que todas las cosas del Servidor viven en un solo lugar, y si en algún momento agrega a la definición del nodo Servidor, TODAS las máquinas actualizarían su configuración en consecuencia.

En este momento, solo estoy administrando tres cajas con Puppet, pero ya está pagado. Después de pasar una semana configurando una caja que usaremos para la presentación de estímulo en un experimento, resultó que el controlador de la tarjeta gráfica era demasiado antiguo en la versión de Ubuntu que le puse (8.04). Tuve que instalar el último Ubuntu (9.04), pero después de eso solo tuve que usar apt-get y ejecutar puppet, y todo lo que había pasado una semana configurando fue restaurado.

Puppet tiene una pequeña curva de aprendizaje, pero he evitado con éxito aprender Ruby, sé que lo estoy usando, ya que eso es lo que Puppet está escrito, pero hasta ahora he tenido éxito en modificar los ejemplos en la documentación y las recetas en el wiki . Otro inconveniente es que la marioneta tarda un poco más en hacer las cosas la primera vez. Lo bueno es que todo lo que cambia en todas sus máquinas se almacena en un solo lugar: es una práctica estándar mantener su configuración de marionetas en un sistema de control de versiones, para que siempre pueda mirar hacia atrás y ver cómo ha configurado servidores en el pasado - o revierta algunos cambios fallidos.

Finalmente, aquí hay un video rápido que hace una demostración de títeres simple que me ayudó a comenzar rápidamente.

Nosotros usamos zapatero y de marionetas para la acumulación y la automatización de la configuración de ambas máquinas reales y virtuales.

Cobbler une DHCP, arranque PXE y Kickstart para que la implementación no sea más que agregar un perfil de máquina y presionar el botón de encendido. Para las máquinas virtuales, el koan comando hace la magia Xen (en nuestro caso) para comenzar la instalación; en el dom0solo escribo:

koan --system vps.fqdn --server cobbler --no-gfx

luego virsh consolemirar un edificio VPS sin ninguna interacción.

Usamos RHEL y tenemos un montón de perfiles configurados para particionar discos, configurar redes e instalar paquetes base para diferentes clases de servidores. Cobbler admite las razas Debian y Ubuntu, pero nunca lo he probado. Un comentario aparte: otros usos interesantes para Cobbler incluyen ejecutar ISO de memtest y actualizaciones de firmware de HP .

Una vez que nuestros sistemas están construidos con Cobbler, Puppet se hace cargo de configurar las aplicaciones, los demonios del sistema, registrar la caja con RHN, etc. Puppet se ejecuta como un demonio que verifica periódicamente que la configuración del sistema coincida con los manifiestos definidos. a todos los servidores. También es una excelente manera de asegurarse de que una caja que se ha apagado por mantenimiento tiene la configuración correcta antes de devolverla al servicio en vivo.

La marioneta es realmente asombrosa. No es necesario tener todos los aspectos de su configuración bajo su control; comience por hacer que administre algo simple que necesita configurar en cada cuadro ( sudoerses el ejemplo canónico) y tomarlo desde allí. Asegúrese de que sus manifiestos de Puppet también estén versionados; nada es mejor que poder volver fácilmente a una configuración conocida sin tener que recordar qué ajustar.

Donde estoy trabajando en este momento, tenemos que administrar la parte de Linux de nuestra granja de servidores, que es un poco más de 300 servidores de Linux. Esto incluye principalmente HP Proliants, seguido de IBM 3850s, algunos blades de IBM, VMware ESX y algunos KVM para nuestros servidores de administración internos.

zapatero

Miramos el zapatero pero el problema era que el zapatero es muy específico de RHEL / Red Hat. Necesitamos admitir RHEL y SLES al menos, y Ubuntu es el siguiente.

marioneta

Consideramos la marioneta, sin embargo, más tarde decidimos no hacerlo, ya que depende de Ruby, lo que significa que una actualización de Ruby podría potencialmente romper nuestro sistema de gestión.

alambre caliente

Hotwire es lo que usamos (desarrollado internamente, pero es de código abierto), y lo hemos hecho durante los últimos años. En primer lugar, realiza un inventario de los sistemas que se van a construir, lo que significa inventariar el centro de datos, el bastidor, el hardware, el sistema operativo, la red, etc. Una vez que se construye el sistema, el inventario automático de hotwire mantiene el inventario sincronizado, mientras que cfengine los mantiene. Hotwire conoce el hardware del servidor al comunicarse con los datos SMBIOS / DMI en la BIOS a través de python-dmidecode .

Los puntos de bonificación son que combina el inventario y el proceso de construcción en uno, por lo que hay menos para administrar, y la función de inventario en vivo es excelente, ya que sabemos si algo no está del todo bien.

Las desventajas son que la interfaz de usuario todavía necesita pulirse, y hay errores aquí y allá, pero el desarrollo aún está activo y los errores reportados se corrigen relativamente rápido.

cfengine

Usamos cfengine porque aparte de eso, y títere, no hay nada más. En realidad, es una buena herramienta, pero "buena" solo en función de cuán buenas son sus políticas: si establece políticas peligrosas, un pequeño error puede causar mucho daño. Por ejemplo, por política, no "modificamos" archivos, los reemplazamos o no. Además, todos los archivos reemplazados tienen un encabezado que hace que cualquier persona que lo edite sepa que será reemplazado la próxima vez que se ejecute (se ejecuta a través de cron cada hora).

La configuración y todos los archivos enviados por cfengine a los servidores también se guardan en un SCM, y utilizando ganchos posteriores a la confirmación, cuando es posible, verificamos la sintaxis y, si eso falla, la confirmación se rechaza. Esto es fácil para aplicaciones agradables como Apache, pero no es tan fácil para la mayoría de las aplicaciones empresariales.

He tenido éxito con Puppet . Chef es uno nuevo para surgir. Para obtener una lista más larga de opciones y un cuadro comparativo, consulte el artículo de Wikipedia, Comparación de software de gestión de configuración de código abierto .

Para automatizar la instalación según el sistema de destino:

• Debian / Ubuntu: FAI o di preseeding
• RedHat / Fedora: Kickstart
• Novell / openSuSE: AutoYaST
• Solaris: Jumpstart
• Windows: unattended.sourceforge.net

Para la gestión de la configuración, sugeriría usar puppet.

Estoy teniendo mucho éxito con Puppet , pero tienes que escribir mucha configuración.

Otro voto para Puppet aquí. Lo usamos ampliamente para llevar a cabo toda la instalación y la administración de la configuración y el servidor. Más de 200 nodos y contando. El soporte de Windows aparentemente está en desarrollo, aunque en qué estado no estoy seguro.

Todavía estamos investigando el aspecto inicial de arranque de OS, pero como se mencionó anteriormente, Cobbler parece interesante. Actualmente estamos usando una combinación de arranque PXE con Debian / Ubuntu preseeding, pero no es lo óptimo.