Estoy buscando la mejor manera (para mis propósitos y situación) de versionar los archivos de configuración del sistema y administrar la implementación (propiedad y modo) entre solo dos máquinas (en vivo y de respaldo, ambas deben considerarse como "producción"). Me gustaría poder utilizar este sistema para duplicar y administrar automáticamente (pero selectivamente) la configuración relevante y especificada en la máquina de respaldo (una instancia EC2).
Actualmente, esas máquinas son principalmente servidores web y SMTP (no almacenamos buzones de correo de usuarios), pero nuestro proyecto está creciendo y quién sabe cuáles pueden ser los requisitos futuros. Por ejemplo, existe la posibilidad de que implementemos radio y chat basado en web en algún momento en el futuro.
Prefiero administrar el servidor de manera convencional (es decir, ingresar y realizar cambios en el servidor activo según sea necesario) y luego almacenar esos cambios (una vez establecidos) en el sistema de administración. (Está bien, si soy honesto, debería decirorgánicamente: No quiero perder la flexibilidad de hacer cosas según lo exijan las necesidades y situaciones). Considero que este enfoque, en lugar de implementar una configuración que se modificó y probó en otros lugares, es más predecible y con el potencial de generar menos sorpresas (fuera del posibilidad de estropear la configuración en un sistema en vivo, claro está!)
Me doy cuenta de que, filosóficamente hablando, esto es al revés y probablemente lo haría al revés si tuviera los recursos (infraestructura de prueba y, lo que es más importante, mano de obra). Tal como están las cosas, tengo que conformarme con lo que tengo. Me gusta bastante la estructura, pero la infraestructura excesiva cobra vida propia y en algún momento se pierde su valor.
Hice algunos deberes y revisé un par de opciones, pero ninguna de ellas parece hacer realmente lo que quiero, por lo que actualmente estoy tentado a implementar mi propia solución. El propósito de esta pregunta es ver en qué no he pensado y comprobar mi cordura antes de ladrar al árbol equivocado.
Opciones
Sistemas de metaconfiguración declarativa como Puppet,Entre otros, son probablemente buenas opciones cuando intervienen muchos servidores con poca o ninguna diferenciación entre ellos, y especialmente cuando está claro de antemano cómo debería ser la configuración. No creo que sea prudente emplear una herramienta de este tipo sin una infraestructura de preparación.
También es un poco pesado y demasiado complicado. Soy el único administrador, hago esto en mi tiempo libre y, si me pasa algo, lo que deje atrás debe ser razonablemente sensato para el afortunado que intervenga después de mí.
etckeeper podría funcionar, pero hasta donde he visto, en realidad no se presta para administrar nada más que /etc. es decir, no sería adecuado para almacenar scripts personalizados que, por tradición, viven en /usr/local/bin. Además, etckeeper presumiblemente gestionatodode /etc, donde creo que preferiría versionar sólo cosas específicas (por ejemplo, postfix, apache, fail2ban, ssh y posiblemente munin).
Un simple repositorio git o svn ciertamente no funcionaría, ya que si bien git rastrea los permisos, no rastrea la propiedad y svn tampoco.
svn mantiene un
.svnsubdirectorio en cada directorio rastreado, mientras que.gitsólo existe en el directorio raíz de la copia de trabajo. En ambos casos existen ventajas y desventajas. La presencia de un.svndirectorio en una ubicación determinada puede estar bien en algunos lugares (por ejemplo, /etc/apache2/sites-enabled) pero alterar scripts/herramientas con muerte cerebral en otros lugares. (Estoy seguro de que leí algo hace un tiempo: ¿era que cron estaba bien con un.svndirectorio en /etc/cron.d, pero depmod no estaba con /lib/modules?)Por otro lado, con un
.gitin /, git consideratodoun candidato para el seguimiento, ¡incluso (presumiblemente) otros repositorios de git!
Solución personalizada
Esto es lo que propongo hacer: un repositorio de Subversion almacenado en la máquina principal (digamos /usr/local/sc-repo) y un script de administración escrito enPysvnque implementa lo siguiente:
add (pero, de forma predeterminada, no recursivamente), que almacena el modo y el propietario del archivo como propiedades personalizadas. Además, me gustan
$Id$las etiquetas en mis archivos de configuración, por lo que esto garantizarásvn:keywordsque estén configuradas correctamente.comprometerse
actualización, que aplica la propiedad y el modo después de escribir el archivo
revertir, lo mismo
permanentes, como diff, pero para propiedad y modo, con indicador de corrección para corregir si es necesario.
La máquina de respaldo accederá al repositorio a través de ssh y realizará una operación de actualización todas las noches. (También hará otras cosas, como restaurar el SQL del sitio y los sistemas de archivos de aplicaciones desde el repositorio de respaldo de la máquina principal (S3), y probablemente tendré que escribir algo de piratería que busque nuevos paquetes agregados en la máquina principal y los agregue en el máquina de respaldo, pero todo eso está fuera del alcance de esta pregunta).
¿Por qué subversión?
Lo sé, me gusta y soymuchomás familiarizado con svn que con git. Sí, probablemente soy un dinosaurio.
Pysvn es fácil y lo he usado antes.
svn admite propiedades personalizadas versionadas, donde git no parece
Esto no es desarrollo distribuido: los repositorios distribuidos complican las cosas sin beneficio. La disponibilidad del repositorio remoto es irrelevante, porque las confirmaciones desde la máquina remota serán raras.
Estaría agradecido por sus comentarios. He pensado en esto todo lo que pude, pero seguramente se me ha escapado algo.
Respuesta1
No reinventes la rueda. Las herramientas existen para hacer lo que necesita. Quizás quieras mirarbcfg2, especialmente porque parece estar particularmente concentrado en los archivos de configuración. Piense también en los servicios. ¿Dónde debe estar el repositorio central en relación con el servidor de producción?
Tal vez una opción intermedia podría ser una modificación cuidadosa de la salida delPlanoherramienta. Utilizo Blueprint para realizar ingeniería inversa en sistemas existentes. El resultado de una ejecución de Blueprint puede crear un script de shell, un módulo Puppet o un libro de cocina Chef... Una vez que tenga una configuración verificada en el servidor de producción, puede usar esta herramienta para capturar el estado del sistema, luego etiquetar y versionar el resultado. Leera través de los ejemplose informe si esto parece que se ajusta a su caso de uso.
Respuesta2
Los sistemas de metaconfiguración declarativa como Puppet, entre otros, son probablemente buenas opciones cuando intervienen muchos servidores con poca o ninguna diferenciación entre ellos, y especialmente cuando está claro de antemano cómo debería ser la configuración. No creo que sea prudente emplear una herramienta de este tipo sin una infraestructura de preparación.
Utilizo Puppet (pero sí, existen Chef, Ansible, Salt y demás) incluso para configuraciones de una sola máquina. Todavía no he tenido una situación en la que alguien haya tenido claro de antemano cómo debería verse la configuración de la máquina (podría decirse que muchos no han tenido claro después cómo debería verse la configuración, pero ese es un problema completamente diferente)
En cuanto a la "infraestructura de preparación", eso esVagabundoyVirtualBox(o alguna otra tecnología de virtualización de respaldo): ejecútela en su máquina de desarrollo sin gastar nada. No hago ningún desarrollo de manifiesto de Puppet sin él. También pruebas automatizadas conTravis CI
También es un poco pesado y demasiado complicado. Soy el único administrador, hago esto en mi tiempo libre y, si me pasa algo, lo que deje atrás debe ser razonablemente sensato para el afortunado que intervenga después de mí.
Parece incoherente decir esto y luego describir cómo se está planificando una solución propia en lugar de soluciones existentes con abundante documentación, ejemplos, "bibliotecas" existentes y desarrollo activo.