Una vez dentro de nuestra cuenta de Digital Ocean, en la sección Create Droplet, seleccionamos en la región del Datacenter, uno localizado en Estados Unidos (punto intermedio para todos los integrantes del grupo). El SO elegido fue Linux con distribución Ubuntu 24.04 LTS.

Seleccionamos la “máquina que vamos a alquilar” (plan que detalla CPU, RAM, Disco, ancho de banda)

Acto seguido, cada integrante creó una llave SSH que cargamos para poder tener acceso (por motivos de seguridad este paso fue recreado con datos falsos y luego la llave fue eliminada)

Por último, le dimos nombre a nuestro Droplet

Así queda una vez funcional

En el buscador de VS Code ponemos >Remote-SSH (extensión previamente descargada) => Configurar Host SSH... => C:\Users\Sofia(en mi caso, sino el usuario)\.ssh \config y ponemos los datos del host (primeramente, configuramos todos los usuarios como root para comprobar a conexión sin problemas, luego los cambiaremos y otorgaremos los permisos pertinentes a cada usuario)

Una vez guardado, en el buscador de VS Code ponemos >Remote-SSH => Conectar al Host... => IntegradorSO2 . Saldrá un aviso de que la conexión se está estableciendo, y finalmente se conectará. Podemos comprobarlo en la esquina inferior izquierda de la ventana de VS Code:

A partir de este momento estamos navegando en un entorno Linux, usando la máquina virtual a través de VS Code, podemos comprobarlo al ver la estructura de archivos del entorno Unix

Después de comprobar que todos pudimos establecer la conexión correctamente, procedemos a crear los usuarios. El usuario root agrega el comando: adduser “usuario” (en nuestro ejemplo: adduser rami)

Automáticamente se le otorga número de id, se crea por defecto un grupo para el usuario, le crea un directorio “home”, y le copia los archivos de etc/skel (carpeta de plantillas del sistema, para poder establecer su entorno base predefinido)

Luego continua pidiendo contraseña, nombre completo, y otros datos personales, que podrían servir, por ejemplo, para firmas o logs (por eso con los nombres de usuario decidimos utilizar camelCase y nombres sencillos). Por último pide corroborar os datos.

Con todos los usuarios generados, procedemos a la creación del grupo. Para ello, escribimos el comando groupadd “nombre del equipo” (en nuestro caso escribimos: groupadd equipo-trabajo) y agregamos a este los usuarios con el comando: usermod –aG equipo-trabajo rami ( podemos leerlo como: modificar usuario addgroup (agregar al grupo) nombre del grupo usuario)

(Nota:

En este momento podría aplicarse

chown –R root:equipo-trabajo / opt/ ( cambiar el dueño recursivamente, root es el dueño y el grupo asignado es equipo-trabajo, sobre ese directorio y todo lo que haya dentro)

este comando aplica el grupo y dueño a todo lo que ya existe en /opt en este momento. Si se ejecuta al principio antes de crear cualquier subcarpeta, se pueden omitir los comandos chown posteriores en la mayoría de los casos, salvo un comando específico que omite los permisos heredados, que se verá en su momento.)

chmod -R 2775 /opt (cambiar permisos recursivo (para la carpeta y todo lo que haya dentro) 2=todo archivo nuevo que se crea hereda el grupo de a carpeta, 7=permisos del dueño (root) de lectura, escritura y ejecución, 7= permisos del grupo de lectura, escritura y ejecución, 5= permiso de otros de lectura y ejecución, sobre la carpeta opt)

newgrp equipo-trabajo ( aplicá el grupo equipo-trabajo a mi sesión actual sin necesidad de cerrar y volver a abrir sesión)

Para cada usuario, en el directorio home/ se crea el directorio .ssh , y en él el fichero authorized_keys con el contenido de la llave de cada uno.

Con esto último hecho, ya podemos poner nuestros usuarios en la configuración, y entrar con estos. Nos damos cuenta porque en la terminal vemos el nombre del usuario y de la computadora:

El directorio /opt sobre el que hemos otorgado los permisos será sobre el cual trabajaremos con el repositorio que es uno de los objetivos de este trabajo.

Como tenemos nuestro repositorio privado, vamos a establecer una conexión entre Droplet y GitHub por medio de SSH. Para ello, crearemos una llave para nuestra “computadora” remota (esto sera para el root, lugo cada uno tendrá una particular repitiendo los pasos)

Para esto usamos el comando:

ssh-keygen -t rsa -b 4096 –f /opt/shared_key ( generá un par de claves SSH (pública y privada) el tipo de cifrado será RSA la cantidad de bits de la clave, y guarda el fichero en opt con el nombre de shared_key)

(se adjunta la imagen incompleta por temas de seguridad)

Luego hay que dar permisos al grupo:

chown root:equipo-trabajo /opt/shared_key ( cambiar el dueño, root es el dueño del archivo, y el grupo asignado al archivo es equipo-trabajo, el archivo al que se le aplica es shared_key)

chmod 660 /opt/shared_key (cambiar permisos 6 = dueño (root): lectura + escritura, 6 = grupo (equipo-trabajo): lectura + escritura, 0 = otros: sin ningún permiso, quiere decir que el dueño y el grupo pueden leer y escribir la clave, cualquier otro usuario no puede ni verla, por seguridad) shared_key)

¿Pero opt no tenía ya definidos los permisos? En teoría sí, porque /opt ya tiene el grupo equipo-trabajo y el setgid (el 2 de 2775) que hace que los archivos nuevos hereden el grupo automáticamente.

Pero hay una trampa: ssh-keygen es un programa especial que crea el archivo con permisos muy restrictivos por defecto (600, solo el dueño puede leerlo) justamente por seguridad, ignorando el setgid de la carpeta.

Para asegurarnos de que utilice esa llave, vamos al /.ssh de a máquina virtual y creamos un fichero “config” con los datos de la llave que va a utilizar y donde lo hará (esto o hacemos en cada usuario)

Con la llave creada, vamos a nuestro repositorio, Perfil => Settings => SSH and GPG Keys, y allí nombramos la llave y pegamos la llave pública generada

Por último, clonamos el repositorio entrando en la terminal el comando:

git clone git@github.com:TPI-Sistemas-4/mundodigital-api.git

Si todo está bien, se descarga el repositorio. Esto es suficiente que lo haga un solo integrante del equipo, no es necesario repetirlo

Ahora tenemos que instalar las dependencias. Podemos o no verificar si ya están instaladas en el proyecto haciendo

npm -v

En nuestro caso no estaba instalado, por lo que lo hicimos con

sudo apt install npm

Verificamos la versión nuevamente

npm -v

Y tenemos la 9.2.0. Ahora instalamos node mánager de la siguiente manera en la carpeta compartida del proyecto

export NVM_DIR="/opt/nvm" (creá una variable llamada NVM_DIR con el valor /opt/nvm y hacela disponible para toda la sesión)

sudo mkdir -p /opt/nvm ( ejecutá el comando como superusuario, creá una carpeta, si las carpetas del camino no existen, crealas también (En este caso si /opt no existiera lo crearía también, sin dar error),la carpeta a crear es nvm)

sudo chown root:equipo-trabajo /opt/nvm (igual que vimos antes, el dueño es root y el grupo es equipo-trabajo)

sudo chmod 775 /opt/nvm (dueño y grupo pueden hacer todo, otros solo leer y ejecutar)

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | NVM_DIR=/opt/nvm bash (descarga el contenido de la URL y mostralo en pantalla, el script de instalación de NVM, | el pipe tomá lo que salió del comando anterior y pasáselo al siguiente, antes de ejecutar, establecé esta variable de entorno para que NVM sepa dónde instalarse, ejecutá lo que recibiste como script)

Luego, abrimos nano:

sudo nano /etc/profile.d/nvm.sh

/etc/profile.d/ es una carpeta especial de Linux donde los scripts que pongas se ejecutan automáticamente para todos los usuarios cuando abren una sesión.

En nano ponemos

export NVM_DIR="/opt/nvm"

[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

export PATH="/opt/nvm/versions/node/v22.22.3/bin:$PATH"

Así todos los usuarios del grupo tienen NVM disponible automáticamente al conectarse, sin tener que configurar nada en cada uno por separado.

Instalamos la versión de nvm que usamos en el proyecto

nvm i 22.22.3

Y por ultimo, instalamos npm

npm i

Para terminar con la preparación de proyecto, copiamos las variables de entorno que estábamos usando en local (pegamos el archivo directamente en el explorador de archivos de VS Code para simplificar)

Para asegurarnos de que todo esté correcto hacemos una build

npm run build

Y por último, ya podemos arrancar el servidor

npm run start:dev

Y en el navegador probamos con

162.243.174.168:3001/api

Y podemos ver el swagger al que anteriormente teníamos acceso cuando corríamos en local.

Instalamos PM2 de manera global (toda la máquina virtual) haciendo:

sudo npm install -g pm2

Para que todos los usuarios tengan acceso, creamos un directorio para pm2 en el directorio compartido

mkdir -p /opt/pm2

sudo chown root:equipo-trabajo /opt/pm2

chmod 775 /opt/pm2

Y en nano agregamos el path del home de pm2

sudo nano /etc/profile.d/nvm.sh

export PM2_HOME=/opt/pm2

Y actualizamos la autoreferenciaidad del archivo (“sourcear”)

source /etc/profile.d/nvm.sh

E iniciaizamos con

sudo pm2 startup

El propio pm2 genera un comando que modificamos, basándonos en la documentación oficial de PM2, para que se instale donde queríamos y no donde lo sugería, así funcione en una sola instalación para todos los usuarios:

sudo env PATH=$PATH:/opt/nvm/versions/node/v22.22.3/bin

/opt/nvm/versions/node/v22.22.3/lib/node_modules/pm2/bin/pm2 startup systemd -u

root --hp /root

Levantamos la app:

pm2 start npm --name "api" -- run start:dev

Si ponemos pm2 log api podemos ver el estado del servicio:

Y lo comprobamos:

Y guardamos con

pm2 save

Ahora, aunque cerremos la consola, si hacemos pm2 list podemos ver el servicio que corre y no se detuvo

Nginx se configuró para actuar como "recepcionista" o proxy inverso, recibiendo todos los pedidos HTTP y derivándolos a la app Node en el puerto 3001. Se establecieron también las reglas del firewall con UFW.

Por defecto, el sitio funciona con HTTP, lo que significa que la comunicación entre el usuario y el servidor viaja sin cifrar. Certbot es LA herramienta que permite obtener e instalar automáticamente un certificado SSL gratuito de Let's Encrypt, habilitando HTTPS en el sitio. Esto cifra toda la comunicación, protege los datos de los usuarios y además es requerido por la mayoría de los navegadores modernos que muestran advertencias de "sitio no seguro" cuando no hay certificado. (O mejor explicado en palabras de nuestro compañero: es como el certificado de SENASA pero para sitios webs, y lo que estamos haciendo es que nuestro sitio esté “blanqueado”, va a tener papeles, y se pueda comunicar con otros sitios que están en iguales condiciones) Empezamos por instalar Cerbot: sudo snap install core; sudo snap refresh core Luego, confirmamos si la configuración de nuestro firewall permite la comunicacion del tipo que necesitamos: sudo ufw status

Tras aproximadamente 6 horas de configuración, correcciones y aprendizaje, logramos tener el servidor corriendo en la máquina virtual remota, con el Swagger del backend de nuestra aplicación disponible y accesible desde cualquier lugar.