Cómo implementar una aplicación ASP.NET con cero tiempo de inactividad

Para implementar una nueva versión de nuestro sitio web, hacemos lo siguiente:

1. Comprime el nuevo código y súbelo al servidor.
2. En el servidor en vivo, elimine todo el código en vivo del directorio del sitio web de IIS.
3. Extraiga el nuevo archivo zip de código en el directorio IIS ahora vacío

Este proceso está totalmente programado y ocurre con bastante rapidez, pero aún puede haber un tiempo de inactividad de 10-20 segundos cuando se eliminan los archivos antiguos y se implementan los archivos nuevos.

¿Alguna sugerencia sobre un método de tiempo de inactividad de 0 segundos?

Necesita 2 servidores y un equilibrador de carga. Aquí hay pasos:

1. Convierta todo el tráfico en el Servidor 2
2. Implementar en el servidor 1
3. Servidor de prueba 1
4. Convierta todo el tráfico en el Servidor 1
5. Implementar en el servidor 2
6. Servidor de prueba 2
7. Gire el tráfico en ambos servidores

La cosa es que, incluso en este caso, aún tendrá reinicios de la aplicación y pérdida de sesiones si está utilizando "sesiones fijas". Si tiene sesiones de base de datos o un servidor de estado, entonces todo debería estar bien.

La herramienta de implementación web de Microsoft admite esto hasta cierto punto:

Habilita la compatibilidad con el Sistema de archivos transaccionales de Windows (TxF). Cuando el soporte TxF está habilitado, las operaciones de archivo son atómicas; es decir, tienen éxito o fracasan por completo. Esto garantiza la integridad de los datos y evita que los datos o archivos existan en un estado "a mitad de camino" o dañado. En MS Deploy, TxF está deshabilitado de forma predeterminada.

Parece que la transacción es para toda la sincronización. Además, TxF es una característica de Windows Server 2008, por lo que esta característica de transacción no funcionará con versiones anteriores.

Creo que es posible modificar su script para el tiempo de inactividad 0 utilizando carpetas como versiones y la metabase de IIS:

• para una ruta / url existente:
  • ruta : \ web \ app \ v2.0 \
  • url : http: // aplicación
• Copie el sitio web nuevo (o modificado) al servidor en
  • \ web \ app \ v2.1 \
• Modificar la metabase de IIS para cambiar la ruta del sitio web
  • desde \ web \ app \ 2.0 \
  • a \ web \ app \ v2.1 \

Este método ofrece los siguientes beneficios:

• En caso de que la nueva versión tenga un problema, puede retroceder fácilmente a v2.0
• Para implementar en múltiples servidores físicos o virtuales, puede usar su script para la implementación de archivos. Una vez que todos los servidores tengan la nueva versión, puede cambiar simultáneamente todas las metabases de los servidores con la Herramienta de implementación web de Microsoft.

Puede lograr una implementación de tiempo de inactividad cero en un solo servidor utilizando el Enrutamiento de solicitud de aplicaciones en IIS como un equilibrador de carga de software entre dos sitios IIS locales en puertos diferentes. Esto se conoce como una estrategia de implementación verde azulada en la que solo uno de los dos sitios está disponible en el equilibrador de carga en un momento dado. Implemente en el sitio que está "inactivo", caliéntelo y llévelo al equilibrador de carga (generalmente pasando una verificación de estado de Enrutamiento de solicitud de aplicación), luego saque el sitio original que estaba activo, fuera del "grupo" (nuevamente haciendo que su comprobación de estado falle).

Un tutorial completo se puede encontrar aquí.

Revisé esto recientemente y la solución que se me ocurrió fue tener dos sitios configurados en IIS y cambiar entre ellos.

Para mi configuración, tenía un directorio web para cada sitio A y B como este: c: \ Intranet \ Live A \ Interface c: \ Intranet \ Live B \ Interface

En IIS, tengo dos sitios idénticos (mismos puertos, autenticación, etc.), cada uno con su propio grupo de aplicaciones. Uno de los sitios se está ejecutando (A) y el otro se detiene (B). el live también tiene el encabezado de host en vivo.

Cuando se trata de implementar para vivir, simplemente publico en la ubicación del sitio DETENIDO. Como puedo acceder al sitio B usando su puerto, puedo precalentar el sitio para que el primer usuario no provoque el inicio de una aplicación. Luego, usando un archivo por lotes, copio el encabezado del host en vivo en B, detengo A e inicio B.

Con la clase ServerManager de Microsoft.Web.Administration puede desarrollar su propio agente de implementación.

El truco consiste en cambiar la ruta física del directorio virtual, lo que da como resultado un cambio atómico en línea entre las aplicaciones web antiguas y las nuevas.

¡Tenga en cuenta que esto puede resultar en que los AppDomains antiguos y nuevos se ejecuten en paralelo!

El problema es cómo sincronizar los cambios en las bases de datos, etc.

Al sondear la existencia de AppDomains con PhysicalPaths antiguos o nuevos, es posible detectar cuándo los antiguos AppDomain (s) han finalizado y si los nuevos AppDomain (s) se han iniciado.

Para forzar el inicio de un dominio de aplicación, debe realizar una solicitud HTTP (IIS 7.5 admite la función de inicio automático)

Ahora necesita una forma de bloquear solicitudes para el nuevo AppDomain. Utilizo un mutex con nombre, que es creado y propiedad del agente de implementación, atendido por Application_Start de la nueva aplicación web y luego liberado por el agente de implementación una vez que se han realizado las actualizaciones de la base de datos.

(Uso un archivo de marcador en la aplicación web para habilitar el comportamiento de espera de mutex) Una vez que se ejecuta la nueva aplicación web, elimino el archivo de marcador.

Está bien, ya que todos están votando la respuesta que escribí en 2008 * ...

Le diré cómo lo hacemos ahora en 2014. Ya no usamos sitios web porque estamos usando ASP.NET MVC ahora.

Ciertamente no necesitamos un equilibrador de carga y dos servidores para hacerlo, está bien si tiene 3 servidores para cada sitio web que mantiene, pero es una exageración total para la mayoría de los sitios web.

Además, no confiamos en el último asistente de Microsoft: demasiado lento, demasiada magia oculta y demasiado propenso a cambiar su nombre.

Así es como lo hacemos:

1. Tenemos un paso posterior a la compilación que copia las DLL generadas en una carpeta 'bin-pub'.

2. Utilizamos Beyond Compare (que es excelente **) para verificar y sincronizar archivos modificados (a través de FTP porque eso es ampliamente compatible) hasta el servidor de producción

3. Tenemos una URL segura en el sitio web que contiene un botón que copia todo en 'bin-pub' a 'bin' (tomar una copia de seguridad primero para permitir una reversión rápida). En este punto, la aplicación se reinicia sola. Luego, nuestro ORM verifica si hay tablas o columnas que deben agregarse y las crea.

Eso es solo un tiempo de inactividad de milisegundos. El reinicio de la aplicación puede tomar uno o dos segundos, pero durante el reinicio, las solicitudes se almacenan temporalmente, por lo que efectivamente no hay tiempo de inactividad.

Todo el proceso de implementación demora entre 5 segundos y 30 minutos, dependiendo de cuántos archivos se cambien y cuántos cambios se revisen.

De esta manera, no tiene que copiar un sitio web completo a un directorio diferente, sino solo la carpeta bin. También tiene control completo sobre el proceso y sabe exactamente qué está cambiando.

** Siempre hacemos un vistazo rápido de los cambios que estamos implementando, como una verificación doble de último minuto, para saber qué probar y si algo se rompe, estamos listos. Usamos Beyond Compare porque te permite diferenciar fácilmente archivos a través de FTP. Nunca haría esto sin BC, no tienes idea de lo que estás sobrescribiendo.

* Desplácese hacia abajo para verlo: (Por cierto, ya no recomendaría sitios web porque son más lentos de construir y pueden fallar con archivos temporales a medio compilar. Los usamos en el pasado porque permitieron un archivo más ágil por archivo despliegue. Muy rápido para solucionar un problema menor y puedes ver exactamente lo que estás implementando (si usas Beyond Compare, por supuesto, de lo contrario olvídalo).

Los únicos métodos de tiempo de inactividad cero en los que puedo pensar incluyen el alojamiento en al menos 2 servidores.

Refinaría un poco la respuesta de George, como sigue, para un solo servidor:

1. Use un proyecto de implementación web para precompilar el sitio en una sola DLL
2. Comprime el nuevo sitio y súbelo al servidor
3. Descomprímalo en una nueva carpeta ubicada en una carpeta con los permisos correctos para el sitio, de modo que los archivos descomprimidos hereden los permisos correctamente (tal vez e: \ web, con subcarpetas v20090901, v20090916, etc.)
4. Use el Administrador IIS para cambiar el nombre de la carpeta que contiene el sitio
5. Mantenga la carpeta antigua por un tiempo, para que pueda recurrir a ella en caso de problemas.

El paso 4 hará que el proceso de trabajo de IIS se recicle.

Esto es solo cero tiempo de inactividad si no está utilizando sesiones InProc; use el modo SQL en su lugar si puede (aún mejor, evite el estado de sesión por completo).

Por supuesto, es un poco más complicado cuando hay múltiples servidores y / o cambios en la base de datos ...

Para ampliar la respuesta de sklivvz, que dependía de tener algún tipo de equilibrador de carga (o simplemente una copia en espera en el mismo servidor)

1. Dirija todo el tráfico al Sitio / Servidor 2
2. Opcionalmente, espere un poco para asegurarse de que el menor número posible de usuarios tenga flujos de trabajo pendientes en la versión implementada
3. Implemente en el sitio / servidor 1 y caliéntelo tanto como sea posible
4. Ejecute migraciones de bases de datos transaccionalmente (esfuércese por hacer esto posible)
5. Dirija inmediatamente todo el tráfico al Sitio / Servidor 1
6. Implementar en el sitio / servidor 2
7. Tráfico directo a ambos sitios / servidores

Es posible introducir un poco de prueba de humo, creando una instantánea / copia de la base de datos, pero eso no siempre es factible.

Si es posible y necesario, use "diferencias de enrutamiento", como diferentes URL de inquilino: s (customerX.myapp.net) o diferentes usuarios, para implementar primero en un grupo desconocido de conejillos de indias. Si nada falla, liberar a todos.

Dado que las migraciones de bases de datos están involucradas, volver a una versión anterior a menudo es imposible.

Hay formas de hacer que las aplicaciones funcionen mejor en estos escenarios, como el uso de colas de eventos y mecanismos de reproducción, pero como estamos hablando de implementar cambios en algo que está en uso, realmente no hay una manera infalible.

Así es como lo hago:

Requisitos mínimos absolutos del sistema:
1 servidor con

• 1 equilibrador de carga / proxy inverso (por ejemplo, nginx) ejecutándose en el puerto 80
• 2 ASP.NET-Core / mono reverse-proxy / fastcgi chroot-jails o docker-container que escuchan en 2 puertos TCP diferentes
  (o incluso solo dos aplicaciones de proxy inverso en 2 puertos TCP diferentes sin ninguna caja de arena)

Flujo de trabajo:

iniciar transacción myupdate

try
    Web-Service: Tell all applications on all web-servers to go into primary read-only mode 
    Application switch to primary read-only mode, and responds 
    Web sockets begin notifying all clients 
    Wait for all applications to respond

    wait (custom short interval)

    Web-Service: Tell all applications on all web-servers to go into secondary read-only mode 
    Application switch to secondary read-only mode (data-entry fuse)
    Updatedb - secondary read-only mode (switches database to read-only)

    Web-Service: Create backup of database 
    Web-Service: Restore backup to new database
    Web-Service: Update new database with new schema 

    Deploy new application to apt-repository 
    (for windows, you will have to write your own custom deployment web-service)
    ssh into every machine in array_of_new_webapps
    run apt-get update
    then either 
    apt-get dist-upgrade
    OR
    apt-get install <packagename>
    OR 
    apt-get install --only-upgrade <packagename>
    depending on what you need
    -- This deploys the new application to all new chroots (or servers/VMs)

    Test: Test new application under test.domain.xxx
    -- everything that fails should throw an exception here
    commit myupdate;

    Web-Service: Tell all applications to send web-socket request to reload the pages to all clients at time x (+/- random number)
    @client: notify of reload and that this causes loss of unsafed data, with option to abort 

    @ time x:  Switch load balancer from array_of_old_webapps to array_of_new_webapps 
    Decomission/Recycle array_of_old_webapps, etc.

catch
        rollback myupdate 
        switch to read-write mode
        Web-Service: Tell all applications to send web-socket request to unblock read-only mode
end try 

Sugeriría mantener los archivos antiguos allí y simplemente sobrescribirlos. De esta forma, el tiempo de inactividad se limita a los tiempos de sobrescritura de un solo archivo y solo falta un archivo a la vez.

Sin embargo, no estoy seguro de que esto ayude en una "aplicación web" (creo que estás diciendo que eso es lo que estás usando), por lo que siempre usamos "sitios web". Además, la implementación de "sitios web" no reinicia su sitio y elimina todas las sesiones de usuario.