Erlang/Elixir en Docker y Hot Code Swap

Question

Una de las características de Erlang (y, por definición, Elixir) es que puedes intercambiar código caliente. Sin embargo, esto parece estar en desacuerdo con Docker, donde tendría que detener sus instancias y reiniciar las nuevas con nuevas imágenes que contengan el nuevo código. Esto esencialmente parece ser lo que todos hacen.

Dicho esto, también sé que es posible usar un nodo oculto para distribuir actualizaciones a todos los otros nodos a través de la red. Por supuesto, al igual que suena como pedir problemas, pero ...

Mi pregunta sería la siguiente: ¿alguien ha intentado y logrado con éxito razonable establecer una infraestructura basada en Docker para Erlang / Elixir que permitiera el intercambio de códigos de acceso rápido? Si es así, ¿qué hacer, qué no hacer y advertencias?

Answer 1

La historia

Imagine un sistema para manejar llamadas de teléfonos móviles o acceso a datos móviles (para eso fue creado Erlang). Hay servidores de puerta de enlace que mantienen la sesión de usuario durante la duración de la llamada, o la sesión de acceso a datos (la llamaré la sesión en adelante). Esos servidores tienen una representación en memoria de la sesión mientras la sesión esté activa (el usuario está conectado).

Ahora hay otro sistema que calcula cuánto cobrar al usuario por la llamada o los datos transferidos (llámelo PDF - Función de decisión de política ). Ambos sistemas están conectados de tal manera que el servidor de puerta de enlace crea un puñado de conexiones TCP a PDF y descarta las sesiones de los usuarios si esas conexiones TCP se desactivan. La puerta de enlace puede manejar unos pocos cientos de miles de clientes a la vez. Siempre que haya un evento por el que se deba cobrar al usuario (próxima transferencia de datos, otro minuto de la llamada), la puerta de enlace notificará al PDF el hecho y el PDF restará una cantidad específica de dinero de la cuenta del usuario. Cuando la cuenta de usuario está vacía, PDF notifica a la puerta de enlace que desconecte la llamada (se ha agotado el dinero, necesita recargar).

Tu pregunta

Finalmente, hablemos de su pregunta en este contexto. Queremos actualizar un nodo PDF y el nodo se está ejecutando en Docker. Creamos una nueva instancia de Docker con la nueva versión del software, pero no podemos cerrar la versión anterior (hay cientos de miles de clientes en el medio de su llamada, no podemos desconectarlos). Pero tenemos que mover a los clientes de algún modo del antiguo PDF a la nueva versión. Entonces le decimos al nodo de puerta de enlace que cree cualquier conexión nueva con el nodo actualizado en lugar del PDF anterior. Los clientes pueden ser habladores y también algunos de ellos pueden tener conexiones de datos de larga duración (descargando Windows 10 iso) por lo que toda la operación tarda de 2 a 3 días en completarse. Ese es el tiempo que puede tomar actualizar una versión del software a otra en caso de un error crítico. Y puede haber docenas de servidores como este, cada uno manejando cientos de miles de clientes.

Pero, ¿y si usáramos el controlador de versiones de Erlang? Creamos el archivo Relup con la nueva versión del software. Lo probamos correctamente y lo implementamos en nodos PDF. Cada nodo se actualiza in situ: el estado interno de la aplicación se convierte, el nodo ejecuta la nueva versión del software. Pero lo más importante, la conexión TCP con el servidor de puerta de enlace no se ha eliminado. Entonces, los clientes continúan felizmente con sus llamadas o están descargando la última ISO de Windows mientras estamos actualizando el sistema. Todo se hace en 10 segundos en lugar de 2-3 días.

La respuesta

Este es un ejemplo de un sistema específico con requisitos específicos. El manejo de versiones de Docker y Erlang son tecnologías ortogonales. Puedes usar cualquiera o ambos, todo se reduce a lo siguiente:

• Requisitos
• Costo

¿Tendrá los recursos suficientes para probar ambos enfoques de forma predecible y la paciencia suficiente para enseñar a su equipo de operaciones para que puedan implementar el sistema con cualquiera de los métodos? ¿Qué pasa si la instalación de prueba cuesta millones de libras (debido al hardware requerido) y puede usar solo uno de esos dos métodos a la vez (porque el ciclo de prueba lleva días)?

El enfoque pragmático podría ser desplegar los nodos inicialmente usando Docker y luego actualizarlos con el controlador de versiones de Erlang (si necesita usar Docker en primer lugar). O bien, si su sistema no necesita estar disponible durante la actualización (como lo hace el sistema PDF de ejemplo), puede optar por implementar siempre nuevas versiones con Docker y olvidarse del manejo del lanzamiento. O bien, puede seguir con el controlador de liberación y olvidarse de Docker si necesita actualizaciones rápidas y confiables sobre la marcha y Docker solo se usaría para la implementación inicial. Espero que eso ayude.