Actualizaciones

Canales de lanzamiento

El paquete de OPanel se distribuye desde un repositorio APT firmado, con tres canales:

Canal	Para
stable	Servidores de producción. Recibe los lanzamientos después de haber pasado por beta.
beta	Servidores que quieren el próximo lanzamiento antes que nadie.
nightly	Solo servidores de prueba — builds de desarrollo.

Fijá el canal al instalar (opanel install --channel beta) o después (opanel install --channel beta de nuevo, y luego apt-get install opanel). Todos los servidores de un clúster deberían seguir el mismo canal — un despliegue instala una única versión en todos lados.

Actualizaciones de seguridad desatendidas

Las actualizaciones de seguridad de Debian y las de PHP se instalan solas, todos los días, sin intervención. Después de una actualización de PHP, el proceso maestro de PHP-FPM de cada sitio pasa al nuevo binario en la siguiente verificación de deriva del nodo — sin ningún paso manual. El paquete de OPanel en sí nunca se actualiza de forma desatendida; eso es un despliegue deliberado, disparado por el operador (ver abajo), así que tú controlás exactamente cuándo un clúster pasa a una versión nueva.

Desplegar una actualización de OPanel

Iniciá un despliegue desde la consola o la API:

curl -X POST https://panel.example.com/api/v1/platform/updates/rollouts \
  -H "Authorization: Bearer $TOKEN" -d '{"version":"1.3.0"}'

Omití version para desplegar el último lanzamiento que ofrece tu canal. El controlador actualiza primero los servidores de control, después los edges, y por último el resto, uno a la vez. En cada servidor:

1. Debe estar en línea, sincronizado, y sin un movimiento de sitio en curso.
2. El agente actualiza las listas de paquetes e instala la versión nueva; el edge y la puerta de enlace SSH recargan sin cortar ninguna conexión, el controlador y el agente se reinician.
3. El servidor debe pasar entonces una verificación de salud — en línea, sincronizado, corriendo la versión objetivo, cada componente que corría antes sigue corriendo, sin problemas nuevos y (para servidores web) una muestra de sus sitios respondiendo a través del edge — sostenida durante 30 segundos antes de que el despliegue siga adelante.

Un servidor que falla su actualización o su verificación de salud detiene el despliegue ahí mismo, dejando el resto del clúster en la versión anterior, con el motivo visible en la consola.

Tarea	Solicitud
Seguir un despliegue	GET /api/v1/platform/updates/rollouts/{id}
Pausar (el servidor actual termina, ningún otro arranca)	POST /api/v1/platform/updates/rollouts/{id}/pause
Reanudar un despliegue pausado o detenido	POST /api/v1/platform/updates/rollouts/{id}/resume
Abortar (ningún otro servidor se actualiza)	POST /api/v1/platform/updates/rollouts/{id}/abort

Desplegá las versiones de a una versión menor por vez — un lanzamiento solo funciona junto a la versión menor anterior durante un despliegue con versiones mezcladas, y retroceder más de una versión menor no está soportado por las migraciones de base de datos.

Reinicios

Nada se reinicia solo. Cuando una actualización requiere un reinicio (típicamente un kernel nuevo), opanel doctor avisa y nombra los paquetes, y GET /api/v1/platform/updates lista el servidor bajo rebootRequired. En un clúster, drená primero el servidor para que sus sitios se muevan de forma prolija, reiniciá, verifica con opanel doctor, y después sacalo de cuarentena:

# en un controlador, o vía la API
POST /api/v1/nodes/{id}/drain
# en el propio servidor
reboot
# una vez que volvió
opanel doctor
POST /api/v1/nodes/{id}/uncordon

Verificar la versión de un servidor

apt-cache policy opanel                  # versión instalada y lo que ofrece el canal
apt-get install opanel=1.2.3             # volver a una versión específica
apt-mark hold opanel                     # mantener un servidor en su versión; los despliegues lo saltean

opanel doctor verifica que el repositorio y su clave de firma estén correctamente configurados y que las actualizaciones desatendidas estén habilitadas.