¿Qué soluciones existen para permitir el uso del control de revisión para los archivos de configuración del servidor? [cerrado]

En un entorno con múltiples administradores de sistemas, veo algunas ventajas al agregar los archivos de configuración del servidor en un sistema de control de revisión. Lo más notable es la capacidad de rastrear los cambios, quién los realizó y, por supuesto, poder volver a las configuraciones de trabajo conocidas.

Estoy principalmente interesado en las soluciones de Unix / Linux, pero también me interesarían las implementaciones de Windows.

He probado esto en casa (~ 3 hosts) desde hace un tiempo, probando diferentes scms (RCS, Subversion, git). La configuración que funciona perfectamente para mí en este momento es git con el setgitpermsgancho.

Cosas que debes considerar:

Manejo de permisos de archivos y propiedad

• RCS: hace esto de forma nativa
• Subversion: la última vez que lo intenté, necesitabas un contenedor svnpara hacer esto
• git: el setgitpermsgancho maneja esto de forma transparente ( post-checkoutaunque necesita una versión bastante reciente de git con soporte para ganchos)

Además, si usted no quiere a toda su /etccontrol de versiones bajo, pero sólo los archivos que realmente se haya modificado (como yo), necesitará un SCM que soporte este tipo de uso.

• RCS: funciona solo en archivos individuales de todos modos.
• Subversion: esto me pareció complicado.
• git: no probem, pon " *" en el .gitignorearchivo de nivel superior y agrega solo los archivos que quieras usargit add --force

Por último, hay algunos directorios problemáticos bajo /etcdonde los paquetes pueden caer fragmentos de configuración que luego son leídos por algún programa o demonio ( /etc/cron.d, /etc/modprobe.d, etc.). Algunos de estos programas son lo suficientemente inteligentes como para ignorar los archivos RCS (por ejemplo, cron), algunos no lo son (por ejemplo, modprobe). Lo mismo con los .svn directorios. Una vez más, una gran ventaja para git (solo crea un .git directorio de nivel superior ).

Lo hice informalmente con git, pero también está el proyecto etckeeper , que es una implementación más completa y detallada.

Otra opción es usar una herramienta de configuración de servidor automatizada como Puppet o Cfengine para hacer un script de las configuraciones de su servidor en un lenguaje declarativo.

Es un trabajo adicional en el front-end, pero el uso de una utilidad como Puppet le permite reconstruir y configurar automáticamente un servidor con muy poca intervención humana.

He estado experimentando con etckeeper, que parece funcionar bastante bien. No necesito un servidor centralizado, lo que puede ser importante en algunas situaciones. Puede usar varios backends DVCS diferentes, por lo que puede elegir el que le resulte más familiar. Parece que funciona muy bien para mí, pero aún no he intentado que los otros técnicos donde trabajo empiecen a usarlo.

He estado buscando en Chef últimamente. No solo mantiene las configuraciones de plantilla (.erb) en el control de versiones, sino que le permite realizar acciones (como reiniciar un servicio después de cargar las configuraciones en el nodo). Chef ayuda con la gestión de paquetes para que pueda verificar las dependencias con cualquier nodo con el que interactúe (es decir, debe tener el paquete sudo instalado). Chef parece ser fácilmente extensible en Ruby, por lo que si tiene algún proceso personalizado, puede simplemente escribirlo dentro del marco proporcionado.

Pero aún no lo he probado y tienes que instalar Ruby en el cliente y el servidor con las gemas apropiadas (esto realmente no es tan difícil). En general, parece muy fácil administrar muchos servidores a la vez.

Estoy en el proceso de implementar Puppet en nuestra infraestructura, y es muy propicio para mantener sus datos en el control de versiones.

Prefiero Mercurial ya que es solo una colección de archivos con algunos metadatos almacenados en directorios ocultos (fácil de administrar, fácil de entender, fácil de usar).

Mis archivos de Puppet están en / usr / local / etc / puppet / (FreeBSD 7.1). Todo lo que se necesitó para agregarle Mercurial:

> cd /usr/local/etc/puppet
> hg init

Todos los cambios se confirman con un simple "hg commit". Si un cambio aplica algo, puedo revertir cada servidor a una versión dada del archivo (por ejemplo, sudoers) con un solo comando.

Gran introducción a Mercurial

He estado usando Subversion en los servidores que administro. Funciona bien. También he configurado una instancia de Trac , por lo que tenemos una vista de línea de tiempo, sistema de tickets, navegación, etc.

Utilizando enlaces simbólicos, cron y subversion, también configuré una distribución de configuración automatizada basada en el repositorio de subversion, donde cada servidor Linux actualiza un repositorio utilizando svn updatescripts (por ejemplo, scripts de firewall).

Aquí hay un caso de uso real: Subversion usado para administrar archivos de configuración en 4 servidores diferentes. Recomiendo usar el control de versiones para los archivos de configuración por la misma razón por la que los usarías con código: es una copia de seguridad y un botón de deshacer, todo en uno. Si administrara una cantidad mucho mayor de servidores y estuvieran mucho más cerca en términos de configuración, estaría usando algo como Puppet como se detalla en la respuesta de berberich.

La idea es que puede tener un repositorio en el que pueda retirar carpetas específicas en los servidores (por ejemplo, / var / named /) para que yo tenga un historial y una copia de seguridad de los archivos de configuración (la copia de seguridad es una ventaja si comete el error de utilizar una aplicación de configuración de interfaz gráfica de usuario que se limpia la mano editado adiciones tos administrador del servidor de Mac OS X Server para la tos ). Entonces es fácil probarlo en un servidor de prueba y posteriormente actualizar el servidor de producción con archivos que funcionen sin copiarlos manualmente.

Creé un proyecto hace unos años para hacer exactamente esto: Savon

Utiliza subversion para almacenar archivos y tiene algunas características adicionales, como el seguimiento de la propiedad, los permisos y el contexto de SELinux. También le permite dividir lógicamente los cambios de su sistema de archivos en capas, por lo que puede, por ejemplo, realizar un seguimiento de los cambios que deberían ir a todos sus servidores web por separado.

Subversion es muy fácil de configurar y usar, y hay muchos recursos:

Instrucciones básicas

SVN Book

Resumen de gestión de documentos

La mayoría de nuestros cambios se gestionan con nuestro sistema de mesa de ayuda, incluso para tareas de mantenimiento de rutina. Hemos movido lentamente nuestra documentación a una wiki para nuestro propio uso y lo que publicamos para los usuarios finales. Publicar los cambios de configuración y la discusión detrás de esto, es bueno tener abierto en nuestra intranet.

Durante muchos años usé rcs para archivos que comencé a modificar, pero hace un par de años comencé a poner todo / etc bajo control git. Se requiere un poco de trabajo para registrar los archivos en grandes cantidades (algunas veces recurro a un registro enorme de "varias actualizaciones"), y he escrito algunos scripts para ayudar con esto, pero etckeeper mencionado parece muy interesante, lo intentaré de inmediato.