Cómo publicar tu proyecto en el servidor

El servidor es un edificio con una sola puerta

Todas las visitas de internet entran por la misma puerta. Justo detrás hay una recepción que mira qué dirección ha escrito la persona en el navegador y la acompaña hasta la habitación correcta. Cada proyecto vive en su propia habitación, aislado de los demás.

Esto tiene dos consecuencias prácticas para ti. La primera: tu proyecto no necesita saber nada de HTTPS ni de certificados, la recepción pone el candado por él. La segunda: tu proyecto no abre puertas propias a internet, solo escucha en un puerto interno que la recepción conoce.

Prepara tu proyecto

Para que se pueda publicar, tu proyecto tiene que cumplir esta lista. Casi todo se reduce a "que funcione con Docker".

• Funciona con Docker. Tienes un Dockerfile o una imagen ya publicada, y un docker-compose.yml que lo arranca. Si nunca lo has hecho, la guía de inicio de Docker es un buen punto de partida.
• Escucha en un puerto y sabes cuál. Por ejemplo el 3000 o el 8080. Es el número que la recepción usará para llegar a tu habitación.
• Escucha en todas las interfaces, no solo en localhost. Dentro de Docker eso suele significar arrancar con 0.0.0.0 en vez de 127.0.0.1. Si tu app solo escucha en localhost, la recepción no la encontrará.
• Las claves y contraseñas van en variables de entorno. Nunca escritas en el código ni subidas al repositorio. Se entregan aparte, en un archivo .env.
• Sabes qué datos tienen que sobrevivir. Una base de datos, archivos subidos, una carpeta de configuración. Todo lo que no esté en un volumen se pierde al reiniciar.
• Sabes qué dirección quieres. Lo explicamos en el siguiente punto.

Elige tu dirección

Hay tres formas de tener una dirección en este servidor. Las dos primeras son para cualquiera.

Los pasos

Cada paso indica quién lo hace. Tú preparas y entregas; el administrador instala y conecta.

1. Entrega el proyecto TúPasa el enlace al repositorio o el nombre de la imagen, el docker-compose.yml, el puerto en el que escucha, el dominio elegido y las variables de entorno por un canal privado.
2. Se instala en su habitación AdministradorEl proyecto se copia a una carpeta propia del servidor y se arranca con Docker. Los datos que deban persistir quedan en esa carpeta.
3. Se presenta en la recepción AdministradorSe le dice a la recepción que ese dominio va a esa habitación y a ese puerto. En ese momento se pide el certificado, que se renueva solo para siempre.
4. Compruebas que funciona TúAbre tu dominio en el navegador. Debe cargar con candado. Si algo falla, pide los registros de tu proyecto y se revisan juntos.

Ejemplo mínimo de docker-compose

Así se ve un proyecto listo para este servidor. Fíjate en tres cosas: no hay línea ports hacia fuera, el contenedor tiene un nombre claro, y está conectado a la red proxy, que es donde vive la recepción.

services:
  tienda:
    image: ghcr.io/tu-usuario/tienda:latest   # o build: .
    container_name: tienda
    restart: unless-stopped
    env_file: .env                             # claves y contraseñas, fuera del repo
    volumes:
      - ./data:/app/data                       # lo que debe sobrevivir a reinicios
    expose:
      - "3000"                                 # puerto interno, visible solo para la recepción
    networks:
      - proxy

networks:
  proxy:
    external: true                             # la red ya existe en el servidor

Con este archivo, lo único que hay que decirle a la recepción es: tienda.kipups.com va a tienda en el puerto 3000. Si tu proyecto lleva base de datos, añádela como otro servicio en el mismo archivo, sin conectarla a la red proxy: solo tu app necesita hablar con ella.

Reglas de la casa

• Sin puertas propias a internet. Ningún proyecto publica puertos en el servidor. Todo entra por la recepción. Es lo que mantiene a todos protegidos.
• Nadie entra al servidor por SSH salvo el administrador. Quien controla Docker controla todos los proyectos, así que ese acceso no se comparte. Todo lo que necesites se pide.
• Secretos por canal privado. Claves de API, contraseñas de base de datos y similares nunca van en el repositorio ni en un mensaje público.
• Un proyecto, una carpeta. Cada uno vive en su carpeta con su compose y sus datos. Nada se mezcla.
• Recursos con cabeza. El servidor se comparte. Si tu proyecto va a consumir mucha memoria o disco, avísalo antes.
• Copias de seguridad son cosa tuya. Tus datos están en tu carpeta, pero decide tú qué hay que respaldar y con qué frecuencia, y pídelo.

Preguntas frecuentes