espejos git sincronizados en todo momento

Question

Tengo varios sitios que utilizan Drupal, tengo varios servidores, en vivo, dev1, dev2 ...

repo código base de Drupal es grande (112MB), así que estoy interesado para aprovechar al máximo las capacidades de enlace cruzado de git, de modo que cada vez que agregue un sitio no se duplique esto.

Así que, digamos, el servidor vivo que tiene un acuerdo de recompra maestro desnuda, y todos mis sitios son clones de este, cada uno usando una rama diferente. Esto es genial en un servidor, se usan enlaces duros, es rápido y eficiente.

Pero en mis servidores dev, por lo general todo el clon de la cesión temporal maestro al descubierto, lo que significa dos sitios en la misma máquina no pueden utilizar los enlaces duros para ahorrar espacio.

Lo que me gustaría hacer es configurar un espejo de la cesión temporal al descubierto en cada uno de mis servidores dev, y después clon de eso.

dev1$ git clone --mirror live:master-bare-repo dev1-mirror-repo 
dev1$ git clone -b site1 dev1-mirror-repo site1 
dev1$ git clone -b site2 dev1-mirror-repo site2 

Todo bien hasta ahora. Pero quiero que los espejos estén sincronizados todo el tiempo. Entonces usé post-receive hook en el espejo de dev1 para hacer git push --mirror origin. Ahora si site1 en dev1 empuja commits, son empujados mágicamente al master-bare-repo.

Pero lo que si hago un cambio en el servidor vivo, y empuje que? No puedo preparar un gancho post-receive para empujar al otro (s) porque eso sería presumiblemente desencadenar sus post-receive ganchos que terminarían en la recursividad?

¿Hay alguna forma inteligente de evitar esto?

Answer 1

En primer lugar, que no va a terminar en una recursión, ya que el post-recibir gancho no se ejecuta cuando "Todo está al día" (como se señala en this other question), que será el resultado del empuja desde los servidores espejos al servidor activo.

Por otro lado, eso no es todo un diseño escalable (cada vez que agrega un nuevo espejo, tendrá que cambiar el enlace de su servidor en vivo para agregar un sitio para enviar). Probablemente te resulte más elegante utilizar una estrategia de sincronización "floja" en tus réplicas: cuando reciben un empujón, no solo presionan al maestro, sino que antes lo capturan/extraen del maestro. De esta manera, no es necesario configurar un gancho en el maestro y la estrategia de sincronización será completamente administrada por espejos. La desventaja de esta estrategia es que, con el tiempo, es posible que desee realizar un cambio en el servidor directo que desea propagar a los servidores réplica antes de que deban realizar algún cambio. Por lo tanto, debe reflexionar sobre si los cambios en sus maestros serán tan importantes para compensar el compromiso de escalabilidad. Por supuesto, un parche para hacer que este diseño "escalable" también sea "sincronizable" es mediante el uso de una tarea cron externa para verificar periódicamente los cambios en el maestro, como se sugiere en los comentarios.