Comentarios deseados: estrategias de implementación sin interrupciones para la producción Lisp webapps

Question

Estoy interesado en escuchar cómo las personas hacen sus implementaciones y actualizaciones de aplicaciones de Lisp (especialmente actualizaciones) en producción.

En Ruby muchos, yo incluido, uso Capistrano para las implementaciones. Proporciona algunos indirectos agradables y la capacidad de ejecutar comandos de forma remota y, lo que es más importante (en mi opinión) la capacidad de retrotraer a una base de código de trabajo.

Sé que la idea de un proceso largo de Lisp conectado a través de Swank a través de un túnel SSH y modificado en su lugar es una idea popular que está afectada, pero no he bebido ese Koolaid, principalmente por el problema de actualizar un proceso con estado (que parece pedir problemas si algo sale mal, como desajustes imprevistos de impedancias entre el estado actual en la memoria y nuevas definiciones de objeto que pronto estarán en la memoria).

Dado que puede crear webapps casi apátridas (o completamente) usando hunchentoot (o insertar su servidor de aplicaciones Lisp favorito aquí), parece que usar algo como Capistrano podría usarse también para actualizaciones no disruptivas del código Lisp si el Los procesos de Lisp se esconden detrás de nginx en su canal ascendente y si se puede coreografiar correctamente eliminando los procesos hunchentoot y hacerlos girar nuevamente después de una actualización del código, por ejemplo, hacer que vuelvan a subir mientras se ejecuta al menos un proceso hunchentoot en el clúster en cualquier momento dado (CGI o mod_lisp podrían usarse, pero no estoy particularmente interesado en ese enfoque, aunque si realmente te gusta ese enfoque, por favor, al menos di algo al respecto, quiero aprender). Por ejemplo, al usar Passenger (que compara naranjas con manzanas porque genera procesos a pedido), toca tmp/restart.txt y el servidor de la aplicación se reinicia con el código recién actualizado, sin interrupciones desde la perspectiva de los usuarios.

Bueno, esto es un poco divagable, y en realidad estoy a punto de probar todo esto, pero me gustaría obtener algunos comentarios de otros sobre estas ideas. Quizás tengas una mejor idea.

Gracias

Answer 1

Usted puede lograr implementaciones no disruptiva (cero tiempo de inactividad) escribiendo guiones Capistrano para un equilibrador de front-end/carga inteligente como HAProxy que tira de los servidores de aplicaciones de rotación, los reinicia con el código recién desplegada y los vuelve a poner en la mezcla

Al aumentar progresivamente los servidores de aplicaciones mientras están fuera de rotación en producción, puede lograr despliegues sin problemas.

Esto no afecta a la persistencia de los bucles del servidor de aplicaciones con un estado específico, eso parece aterrador por exactamente las razones que usted mencionó. Los REPL son geniales para la depuración y el ajuste, pero sus instintos para ejecutar el código en el disco parecen estar bien fundados.