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.