¿Cómo puedo actualizar mi sitio sin obligar a los usuarios a esperar?

El tiempo de inactividad es inconveniente para los usuarios y actualmente tienen que esperar cada vez que se actualiza el motor de un sitio. Además, cuando se utilizan scripts estándar, existe el riesgo de que un cambio de configuración no funcione tan bien como se esperaba (incluso si se han probado en un sitio de preparación).

¿Cómo puedo mantener varias versiones de un sitio en un servidor y cambiar entre ellas sin causar ningún tiempo de inactividad (por ejemplo, con un archivo htaccess)?

¿Estás en una máquina Linux / BSD? Si es así, puede usar fácilmente enlaces simbólicos para lograr este objetivo.

Cree la Versión 1 del sitio aquí:

/var/www/www.example.org.v1

Cree un enlace simbólico que apunte a este directorio

cd /var/www
ln -s www.example.com.v1 www.example.com

Esto debería darle una lista de directorio ( ls -la) que se parece a esto:

lrwxr-xr-x   1 userid  users    18 Aug  3 03:35 www.example.com -> www.example.com.v1
drwxr-xr-x   2 userid  users   512 Aug  3 03:35 www.example.com.v1

Configure su servidor web para usarlo /var/www/www.example.comcomo raíz del documento. Nunca tendrás que cambiar esto; Todos los cambios de orientación se realizarán a nivel del sistema de archivos.

Ahora, cuando desee intercambiar en la Versión 2 del sitio, todo lo que tiene que hacer es colocar la nueva versión en:

/var/www/www.example.org.v2

Y actualice el enlace simbólico para apuntar a esta versión:

ln -sfh www.example.com.v2 www.example.com

Lo que dejará la salida de su directorio con el siguiente aspecto:

lrwxr-xr-x   1 userid  users    18 Aug  3 03:43 www.example.com -> www.example.com.v2
drwxr-xr-x   2 userid  users   512 Aug  3 03:42 www.example.com.v1
drwxr-xr-x   2 userid  users   512 Aug  3 03:41 www.example.com.v2

Como puede ver, el enlace simbólico www.example.com ahora apunta a la Versión 2 de su sitio. Esta es una operación atómica y no debe causar ningún tiempo de inactividad relacionado con la falta de disponibilidad de archivos.

Por supuesto, todavía se requiere una complejidad considerable para garantizar que las estructuras de la base de datos se actualicen, que los recursos estáticos estén disponibles (y estén vinculados a la versión correcta), etc., pero al menos esto se asegura de que todos los recursos correctos para el El nuevo sitio está disponible al instante.

Windows Vista y Server 2008 también admiten enlaces simbólicos con el mklinkcomando, aunque no tengo experiencia directa con ellos.

Puede usar hosts virtuales en apache para tener 2 versiones del código en 2 URL diferentes. Un ejemplo de uso común es:

test.example.com -> /var/www/version1.2

www.example.com -> /var/www/version1.1

ambos están en el mismo servidor, pero quizás solo uno sea accesible al mundo. Una vez que esté satisfecho de que test.example.com está funcionando, puede cambiar el lugar al que apuntan en su configuración de apache y ... presto. Nuevo sitio, nuevo código. Suponiendo que no hubo cambios en el esquema de la base de datos, esto debería funcionar. Entonces, después de hacer el cambio, será:

test.example.com -> / var / www / newtestversion

www.example.com -> /var/www/version1.2

Aquí hay un ejemplo de directiva de configuración de apache para un host virtual:

<VirtualHost *:80>

     ServerAdmin gabe@localhost

     DocumentRoot "/var/www/version1.1"

     ServerName test.example.com

</VirtualHost>

Para obtener más información sobre cómo hacer esto, consulte la documentación del host virtual apache

No estoy seguro de cómo hacer esto en IIS, pero imagino que también hay una manera.

Si algo sale mal, cambie el host virtual de nuevo al original, y su sitio anterior está de vuelta ... sin problemas. Debe reiniciar Apache para que estos cambios surtan efecto, pero eso generalmente es algo muy rápido.

En IIS puede configurar un segundo directorio virtual con sus actualizaciones.

Luego, redirige todas las solicitudes o vuelve a asignar los enlaces del segundo sitio al nombre de host deseado

Redirección HTTP en IIS 7: http://technet.microsoft.com/en-us/library/cc732930(WS.10).aspx

Lo que sugeriría:

• Pruebe localmente en un servidor de desarrollo antes de cargar cualquier cambio. No realice los cambios en un servidor en vivo hasta que esté razonablemente seguro de que funciona en el servidor de prueba.
• Realice el mantenimiento en el menor tiempo de tráfico pesado. Para la mayoría de los sitios web, esto será en las primeras horas de la mañana los fines de semana. Si los fines de semana no son una opción, hágalo durante el tiempo de menor tráfico durante la semana.
• Advierta a sus usuarios del mantenimiento programado con anticipación.