Deploys sin caída para tu app: qué son y cómo activarlos

Un deploy sin caída construye la versión nueva de tu app junto a la que está en marcha, espera a que responda y solo entonces le pasa el tráfico, de modo que los visitantes nunca se encuentran con la app detenida. En SolumeCore lo activas en Código > Deploy para apps web y APIs desplegadas desde Git, y además te permite volver al instante a versiones recientes.

Cómo funciona un deploy sin caída

Con el modo normal, llamado Reemplazar y reiniciar, el código nuevo se pone encima del actual y la app se reinicia. Es sencillo, pero las peticiones fallan durante unos segundos en cada deploy.

Con Sin caída:

1. El código se descarga en su propia carpeta, un release, mientras la versión actual sigue atendiendo.
2. El release nuevo se construye y se arranca en un puerto interno.
3. Se comprueba que esté sano. Si falla, no cambia nada y la versión actual sigue atendiendo.
4. Cuando responde, el tráfico pasa a él petición a petición.
5. La versión anterior termina las peticiones que estaba atendiendo y después se apaga.

Como los releases se quedan en disco, volver a uno reciente también es rápido: el release arranca sin construirse y toma el tráfico cuando responde.

Requisitos

La tarjeta lista lo que necesita tu app, cada punto marcado como cumplido o no:

• Un repositorio de Git conectado, porque los releases se construyen desde tu repositorio. Mira Desplegar una app desde GitHub o GitLab.
• Un comando de arranque propio, definido en la tarjeta Origen y comandos de Código > Deploy. Cada release arranca desde su propia carpeta, así que el comando tiene que ser relativo, como npm start o node index.js. Pulsa Ponerlo si falta.
• Una app que responde HTTP (no un bot).
• El nodo del servidor está listo, es decir, la máquina de tu app lo admite.
• Ruta de chequeo de salud (opcional). Si configuras un health check web, las versiones nuevas deben responder en esa ruta con un estado 2xx antes de recibir tráfico. Sin él, cualquier respuesta HTTP en / cuenta como sana. Pulsa Configurar para ajustarlo; mira Reiniciar tu app o bot y activar el reinicio automático.

Actívalo

1. Abre tu app en el panel y entra en Código > Deploy.
2. Busca la tarjeta Deploys sin caída y, en Cómo sale cada deploy, elige Sin caída.
3. Lee la confirmación y pulsa Activar.

Dos cosas que debes saber antes de confirmar:

• El primer deploy reinicia la app una vez. Tu app sigue funcionando como siempre, así que el primer deploy sin caída la reinicia para que arranque con el runner de releases. Cada deploy posterior cambia sin ningún corte.
• Tu app arranca desde una carpeta releases/. Los archivos que deben sobrevivir entre deploys, como las subidas de usuarios o una base SQLite, van en DATA_DIR (/home/container/data), no junto al código.

Para volver atrás, elige Reemplazar y reiniciar y confirma con Volver. Los releases que ya están en disco se quedan ahí hasta que los borres.

Releases y vuelta atrás instantánea

La tarjeta lista tus releases recientes con el commit, quién lo hizo y cuándo, y estas columnas:

• Cambio: cuánto tardó desde la petición hasta que el tráfico pasó a ese release, incluyendo su arranque y su chequeo de salud. Un release que no necesitó build se marca como sin build.
• Volver: Al instante si el release sigue en disco, o Reconstruye si se borró y hay que traerlo y construirlo de nuevo.
• Una etiqueta indica cuál release está Atendiendo y cuál es el Anterior.

Para cambiar a un release, pulsa Activar en su fila y confirma. Si sigue en disco, arranca sin construirse y toma el tráfico en cuanto responde. Si no, se vuelve a traer su commit y se construye, y después toma el tráfico sin caída. El Historial de deploys también marca estos deploys como sin caída o al instante.

SolumeCore conserva en disco los últimos releases además del activo y el anterior (3 por defecto). Cuando el tráfico ya pasó, la versión anterior dispone por defecto de hasta 30 segundos para terminar lo que hacía, y una versión nueva dispone por defecto de 120 segundos para superar el chequeo de salud antes de que el deploy se dé por fallido. Son valores por defecto de la plataforma y pueden cambiar.

Cambia variables o conecta una base sin caída

Cuando guardas variables nuevas o conectas una base de datos, tu app solo las ve en su próximo arranque. En modo sin caída, la tarjeta muestra Hay variables que tu app todavía no ve con Aplicar sin caída: el release actual arranca de nuevo junto al que está en marcha y toma el tráfico como en un deploy. Mira Variables de entorno de tu app o bot y Base de datos para tu app.

Por qué los bots no pueden usarlo

Discord permite una sola conexión al gateway por token de bot, así que dos versiones de un bot no pueden funcionar a la vez. Un bot siempre tiene un corte corto mientras se reconecta, y el panel muestra Un bot no puede superponerse. Los bots siguen con el deploy normal.

Solución de problemas

• La opción no está disponible para mi API: revisa la lista de requisitos. Un repositorio conectado y una app HTTP son obligatorios.
• Mi app HTTP se trata como un bot: el panel considera bot a una app que salió de una plantilla de Discord o que tiene una variable llamada DISCORD_TOKEN, BOT_TOKEN o TOKEN_DISCORD. Si tu API usa uno de esos nombres para otra cosa, renombra la variable.
• El deploy falló en el chequeo de salud: la versión nueva no respondió a tiempo. Comprueba que escuche en la variable PORT en 0.0.0.0, que tu ruta de salud devuelva 2xx y lee el log del deploy. La versión actual sigue atendiendo.
• Los datos desaparecieron al cambiar: los guardaste junto al código. A partir de ahora usa DATA_DIR.

Preguntas frecuentes

¿Qué es un deploy sin caída?

Es un deploy en el que la versión nueva se arranca y se comprueba antes de recibir tráfico, así que no hay ningún momento en que tu app esté detenida. Si la versión nueva falla, la anterior sigue atendiendo.

¿Funciona el deploy sin caída con bots de Discord?

No. Un token de bot admite una conexión a la vez, así que un corte corto de reconexión es inevitable. Los bots usan el deploy normal.

¿Puedo volver atrás al instante?

Sí, a los releases que siguen en disco. Pulsa Activar en un release anterior y toma el tráfico en segundos, sin construirse.

¿Qué pasa si la versión nueva falla?

Nada cambia para tus visitantes. El deploy se marca como fallido y la versión actual sigue atendiendo mientras lees el log del deploy y corriges el problema.

Artículos relacionados

• Desplegar una app desde GitHub o GitLab
• Reiniciar tu app o bot y activar el reinicio automático
• Base de datos para tu app: PostgreSQL, Redis y MongoDB
• Variables de entorno de tu app o bot

¿Tienes una web o una API que debe seguir en pie mientras publicas cambios? Mira los planes de apps.