Configuración SSH
Antes de crear el archivo del workflow, es necesario generar y registrar las llaves SSH de nuestro servidor. Para esto, me ubiqué en la carpeta ~/.ssh y ejecuté el siguiente comando:
ssh-keygen -t ed25519 -C "github-deploy" -f ./github_deploy_key
Con el fin de simplificar la configuración del workflow, estas llaves SSH no tendrán passphrase.
Una vez generadas, debemos copiar el contenido de la llave pública en el archivo ~/.ssh/authorized_keys.
En caso de que este archivo no exista, podemos crearlo manualmente:
cat github_deploy_key.pub >> ~/.ssh/authorized_keys
En mi caso, el VPS ya contaba con una llave SSH previamente configurada.
Por esta razón, fue necesario agregar la nueva llave al archivo ~/.ssh/config y asignarle un alias para diferenciarla de la anterior.
Un ejemplo de configuración sería:
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519
Host github-deploy
HostName github.com
User git
IdentityFile ~/.ssh/github/github_deploy_key
IdentitiesOnly yes
De esta manera, podemos conectarnos fácilmente utilizando el alias github-deploy sin tener que especificar toda la ruta de la llave en cada conexión.
Finalmente, actualicé la configuración del remote origin en mi repositorio para que utilice ese alias:
git remote set-url origin git@github-deploy:CarlosMateoM/mateo-martinez-dev.git
Configuración de secretos y llave ssh
El siguiente paso consistió en configurar la llave privada y los secretos en GitHub.
Se copió el contenido de la llave privada y se agregó en la sección de Deploy Keys del repositorio en GitHub, habilitando la opción de Allow write access para que el workflow pudiera hacer push si era necesario.
En la sección de Secrets and variables → Actions de GitHub, se agregaron las siguientes variables:
-
VPS_USER
→ Usuario con el que se realizó la conexión al servidor. -
VPS_HOST
→ Dirección IP o dominio del servidor. -
VPS_KEY
→ Contenido completo de la llave privada.
Esto permitió que el workflow tuviera acceso seguro al servidor sin necesidad de contraseñas, usando la llave SSH que se configuró previamente.
Creación del flujo de trabajo en GitHub Actions
El siguiente paso fue dirigirnos a Actions → New workflow y escribir el flujo de trabajo encargado del despliegue:
name: Deploy Nuxt App
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Deploy to VPS
uses: appleboy/ssh-action@v0.1.10
with:
host: ${{ secrets.VPS_HOST }}
username: ${{ secrets.VPS_USER }}
key: ${{ secrets.VPS_KEY }}
script: |
export PATH=$HOME/.nvm/versions/node/v20.18.0/bin:$PATH
cd /var/www/mateo/mateo-martinez-dev
git pull origin main
npm install
npm run build
pm2 reload mateo-web
Este flujo de trabajo se ejecutó cada vez que se realizaba un push en la rama main
, conectándose al servidor por SSH, actualizando el código, instalando dependencias, construyendo la aplicación y recargando el proceso con PM2.
Cabe aclarar que yo ya tenía configurado previamente pm2 con el proceso que ejecutaba mi aplicación. Además, la configuración del PATH fue necesaria debido a que no tenía instalado globalmente npm ni pm2.
Finalmente se guardan los cambios y se verifica que la configuración haya funcionado correctemente:
El animarme a implementar este flujo de despliegue automatizado me permitió agilizar el trabajo al subir nuevos cambios en mi portafolio. Aunque fue un primer paso y algo inicial, me ayudó bastante a ahorrar tiempo y a simplificar el proceso de actualización de la aplicación.