Despliegue

Elimina un entorno desplegado de su servidor.

Sintaxis

$ vela destroy deployment
$ vela destroy deployment -t staging
$ vela destroy deployment -t preview:feature/maps

Esto detiene y elimina los servicios systemd de la aplicación, borra sus releases y retira su configuración de Caddy, con lo que el sitio deja de servirse. Otras aplicaciones y otros objetivos en el mismo servidor quedan intactos. Un objetivo del que el servidor no tiene nada se comunica como tal y el comando sale con 0 — no se elimina nada, y un pull request cuya previsualización nunca llegó a desplegarse se cierra limpiamente.

En un proyecto vinculado el entorno también se retira en velastack.dev, y cualquier nombre de host velastack.app que tuviera deja de responder en el borde. Así es como se elimina una previsualización terminada; un pull request cerrado a través de la acción de GitHub lo hace automáticamente.

Opciones

  • -t, --target <target> - Sobre qué copia de la aplicación actuar, por defecto production
  • --server <ssh> - Servidor en el que se ejecuta este objetivo, registrado en el primer uso
  • --purge - Borrar también la base de datos y los archivos subidos, tras guardar una instantánea en la papelera del servidor
  • -y, --yes - Omitir la confirmación. Por sí solo no basta para producción, ni para purgar cualquier cosa que no sea una previsualización
  • --confirm <app-name> - Confirmar la eliminación de producción, o una purga, nombrando la aplicación — lo que un terminal te pediría escribir
  • --lock-wait <seconds> - Cuánto esperar a que termine un despliegue, reversión o restauración del mismo objetivo antes de rendirse, por defecto 300
  • -i, --identity <file> - Clave privada SSH con la que autenticarse
  • --ssh-port <port> - Puerto SSH
  • --accept-host-keys - Confiar en una clave de host desconocida en la primera conexión (CI)

Confirmar

Eliminar producción, o purgar cualquier cosa que no sea una previsualización, te pide escribir el nombre de la aplicación. Fuera de un terminal — en CI — pasa --confirm <app-name> en su lugar. --yes por sí solo se rechaza en ambos casos, así que un workflow que pase --yes en todos los eventos no puede tirar producción por error; la acción de GitHub lo expone como confirm-name. Las previsualizaciones solo necesitan --yes, purga incluida.

Purgar los datos

Sin --purge, la base de datos y los archivos subidos se dejan en el servidor, de modo que el entorno puede desplegarse de nuevo sobre sus datos existentes. --purge los borra — después de empaquetarlos en /var/lib/vela/trash/<instancia>-<hora>.tar.gz en el servidor, legible solo por root y conservado dos semanas. Nada más antiguo sobrevive, y no se hace ninguna otra copia de seguridad.