Cero tiempo de inactividad cargas / Rollback en IIS

No estoy seguro de si esta es la forma correcta de hacer esta pregunta, pero esto es básicamente lo que me gustaría hacer:

1.) Empuje un conjunto de cambios a un sitio en IIS.
2.) No interrumpas a los usuarios.
3.) Ser capaz de retroceder sin esfuerzo.

Entonces, hay algunas cosas que sé que tienen que suceder:

1.) Fuera de sesión de proceso - manejado
2.) Fuera de caché de proceso - manejado

Entonces, las preguntas que quedan son:
1.) ¿Cómo evito interrumpir a los usuarios? Si solo subo los archivos a bin, la aplicación se recicla y tarda más de 10 segundos en volver a estar en línea
2.) ¿Cómo retrocedo sin esfuerzo?

Estaba pensando que una posible solución sería tener dos sitios configurados en IIS, uno público y otro privado. Las cargas van a privado y se calientan. Después del calentamiento, los sitios se intercambian. Una reversión solo implica cambiar a privado sin una carga.

Esto parece sólido en teoría, pero no estoy seguro de la mecánica. ¿Algunas ideas?

Así es como abordaría este problema: tenga en cuenta que no he hecho esto antes, son solo conceptos que probé un poco en mi entorno de desarrollo. Debería poder configurar un marco bastante robusto utilizando esto y algunas secuencias de comandos en el idioma que elija. Básicamente, vamos a configurar un entorno de equilibrio de carga de ghetto y usarlo para cambiar entre el sitio nuevo y el sitio antiguo.

Para configurarlo, necesitará:

• Módulo de enrutamiento de solicitud de aplicación IIS (ARR)
• Herramienta de implementación web de IIS (msdeploy)
• 3 sitios web de IIS diferentes (con 3 direcciones IP diferentes; solo usar puertos o encabezados de host podría no funcionar aquí)

Instale ARR para comenzar.

Configure los 3 sitios web en IIS:

• El sitio web 1 será el sitio al que sus usuarios realmente se conectan, digamos http://192.168.1.1/. Este es también el sitio ARR. Simplemente configure un directorio vacío para que apunte y póngalo en su propio grupo de aplicaciones. Configure el grupo de aplicaciones para que no expire según estas instrucciones .
• Los sitios web 2 y 3 serán los sitios que realmente alojan su contenido. Estos deben estar en sus propias IP y debido a cómo funciona ARR, en un puerto diferente al sitio web 1. Digamos que están http://192.168.1.2:8080y http://192.168.1.3:8080. También deben estar en sus propios grupos de aplicaciones y apuntar a diferentes directorios en el sistema de archivos (pero ambos directorios tienen el mismo contenido típicamente)

Después de instalar ARR, habrá una nueva categoría en el Administrador de IIS llamada "Granjas de servidores": haga clic con el botón derecho y cree una nueva granja.

• dale un nombre que sea significativo para ti
• agregue Webserver 2 y Webserver 3 como servidores: asegúrese de hacer clic en el botón "configuración avanzada", abra la categoría "applicationRequestRouting" y cambie el httpPort a 8080 para cada servidor
• Finalice el asistente: se le preguntará si desea crear reglas de reescritura de URL: haga clic en Sí
• Ahora tiene una granja de servidores: para finalizar la configuración, vaya a la granja y haga clic en el botón Configuración de proxy: active "reescribir host en encabezados de respuesta" y aplique los cambios
• En el Administrador de IIS, vaya a la categoría de servidor de nivel raíz y haga clic en el botón Reescribir URL, habrá una regla que se creó para su granja
  • haga doble clic en la regla para acceder a la configuración
  • abra el cuadro Condiciones
  • agregar una nueva condición para {SERVER_PORT}que no coincida con 8080
  • aplicar los cambios

En este punto, tiene los conceptos básicos de lo que necesitamos para cumplir con su solicitud. Si vas ahttp://192.168.1.1/ , obtendrá su sitio web desde el sitio web 1 o el sitio web 2, pero será completamente transparente que haya otros sitios.

Ahora, lo que puede hacer cuando desea implementar una nueva versión de su aplicación es:

• drainstop 1 de los servidores de su granja (en las herramientas de la granja de servidores, vaya a "Supervisión y administración", elija un servidor y elija "Hacer que el servidor no esté disponible correctamente")
• implemente su nueva versión del sitio en el sistema que está fuera de línea
• Calentar el sitio que está fuera de línea utilizando su IP / puerto alternativo
• hacer que el sitio vuelva a estar disponible para la granja
• repita el proceso para el otro servidor

La herramienta de implementación web entra en juego cuando hablas de querer escribir todo esto. Hace que sea muy fácil crear un paquete para su aplicación e implementarlo desde la línea de comandos. También puede revertir ese paquete fácilmente si hay problemas. ARR también es programable usando los Microsoft.Web.Administrationdlls.

Otra cosa: si realmente está en Windows 2008 R2 (que es IIS 7.5), eche un vistazo al módulo de Calentamiento de la aplicación , también debería facilitarle la parte de calentamiento de esto.

MattB lo golpeó fuera del agua. +1 responderé con más detalles, pero no estoy buscando tomar sus puntos. Agregaré a lo que dijo.

Tengo una configuración similar a la que describió, y funciona muy bien. ARR es el camino a seguir, incluso en un solo servidor.

Sin embargo, agregaría un par de cosas.

Crea los 2 sitios, como Matt recomendó. Llámalos algo así como yoursite.com01 y yoursite.com02.

Crear 2 reglas de reescritura de URL. Uno para www.yourdomain.com y otro más staging.yourdomain.com. Para la producción, use {HTTP_HOST} con un valor de (^ www.yourdomain.com $) | (yourIP). (o cualquier enlace que prefiera) Para la preparación, use {HTTP_HOST} con un valor de (^ staging.yourdomain.com $). Llame a las reglas yoursite.com y staging.yoursite.com.

Vincular Rule = yoursite.com a site = yoursite.com01 y rule = staging.yoursite.com a site = yoursite.com02.

Configurar FTP en staging.yoursite.com.

El tráfico de producción ahora va a Rule = staging.yoursite.com y Site = yoursite.com01. Despedidas a lo contrario.

Puede implementar la puesta en escena en cualquier momento, probar, pre-spinup, hacer que otras personas prueben, etc. Hágalo durante el día, no importa. Implemente en la misma cuenta FTP cada vez. Funciona muy bien con servidores de compilación.

Luego, cuando esté listo para comenzar, solo realice 3 cambios: - mueva el enlace FTP de yoursite.com02 a yoursite.com01 - cambie la regla de reescritura de URL yoursite.com para que apunte a yoursite.com02 - cambie la puesta en escena de la regla de reescritura de URL. yoursite.com para apuntar a yoursite.com01

¡Ahora tiene cero tiempo de inactividad, conmutación instantánea, con funcionalidad de reversión inmediata!

Lo único que debes considerar es tu estado de sesión fuera de proceso. Asegúrese de que su servidor de estado acepte ambos identificadores de sitio para que no pierda el estado de la sesión durante el intercambio.

También tenga en cuenta que esto es solo web y no base de datos.

Para las secuencias de comandos, use el Editor de configuración. Realice los cambios que desee y luego haga clic en "Generar secuencia de comandos". Le dará el código C #, appcmd o AHAdmin.

Lo he implementado durante algunos meses con un front-end de página web para intercambiar instancias y nunca estoy mirando hacia atrás. Hace que las implementaciones sean tan refrescantes en comparación con las implementaciones tradicionales.