Despliegue con nginx en Ubuntu

Fecha: 2026-10-25. Estado: preparación, sin ejecución en el servidor del usuario. El usuario informó nginx 1.28.3, PHP 8.3.33, MySQL 8.4.11, Docker 29.1.3, Node.js 22.23.2 y Ubuntu 26.04.1 LTS. Son versiones declaradas, no verificadas mediante acceso remoto.

La web actual necesita únicamente nginx sirviendo archivos estáticos. PHP, MySQL, Node y Docker quedan disponibles para evaluar la futura WebApp; no se adopta todavía un backend. No se necesita ejecutar el servidor Python de desarrollo en producción.

Antes de aplicar configuración

Confirmar si nginx corre de forma nativa o dentro de Docker y si existe un panel que gestione sus archivos. Los pasos siguientes corresponden solo a nginx nativo administrado por archivos. Un panel podría reemplazar modificaciones manuales; un contenedor necesita rutas y volúmenes propios. No iniciar un segundo nginx que compita por los puertos del existente.

También confirmar una carpeta libre para el checkout, el usuario de despliegue y el acceso GitHub de lectura. Propuesta de ruta: /srv/aleman/AlemanSinMiedo, con raíz pública exclusivamente en su subcarpeta aleman-sin-miedo/. La ruta es una propuesta, no una ubicación ya creada.

1. DNS y primera descarga

Crear un registro A de aleman.brunobohm.com hacia la IPv4 pública del servidor. Solo añadir AAAA si el servidor tiene IPv6 pública funcional y nginx está preparado para escucharla. Si hay CDN o proxy, conservar su configuración y verificar el origen antes de ajustar HTTPS.

El administrador prepara una carpeta libre para el usuario de despliegue. Con ese usuario, clonar en una ubicación nueva:

git clone --branch main https://github.com/brunobohm82/AlemanSinMiedo.git /srv/aleman/AlemanSinMiedo

Si el repositorio es privado, configurar acceso de lectura en el servidor antes de clonar. No compartir claves privadas por chat ni guardarlas en el repositorio.

El usuario del proceso trabajador de nginx debe poder atravesar los directorios superiores y leer aleman-sin-miedo/. El usuario de despliegue debe ser dueño de los archivos que actualiza Git. Comprobar los permisos existentes; no dar permisos 777 ni cambiar propietarios de otros sitios. Las actualizaciones por Git deben ejecutarse siempre como el usuario de despliegue.

2. Sitio HTTP independiente

Revisar la plantilla nginx, adaptar su raíz y crear un archivo nuevo para el subdominio. No reemplazar nginx.conf, el sitio principal ni un archivo de otro dominio.

En una instalación con sites-available y sites-enabled, después de confirmar que no existe un sitio con este nombre:

# Comprobar primero que estas rutas no existen. Si existen, revisar su contenido.
sudo test ! -e /etc/nginx/sites-available/aleman.brunobohm.com
sudo test ! -e /etc/nginx/sites-enabled/aleman.brunobohm.com

Si cualquiera devuelve un error, detenerse y revisar; no continuar copiando encima. Una vez confirmada su ausencia y adaptada la plantilla, crear el archivo sin sobreescritura:

sudo cp --no-clobber /srv/aleman/AlemanSinMiedo/deploy/nginx/aleman.http.conf /etc/nginx/sites-available/aleman.brunobohm.com
sudo ln -s /etc/nginx/sites-available/aleman.brunobohm.com /etc/nginx/sites-enabled/aleman.brunobohm.com
sudo nginx -t

Leer también las advertencias: un server_name duplicado puede requerir corrección aunque la sintaxis pase. Solo si el resultado es correcto, recargar el servicio:

sudo systemctl reload nginx
curl --fail --resolve aleman.brunobohm.com:80:127.0.0.1 http://aleman.brunobohm.com/

El último comando comprueba el sitio local nativo por HTTP sin depender de la propagación DNS; no comprueba acceso público. Si nginx usa otra dirección de escucha, adaptarlo. No recargar tras una validación fallida. En instalaciones que usan conf.d en lugar de sites-enabled, el administrador debe instalar el bloque en la ruta incluida por su configuración.

3. HTTPS

Usar el mecanismo de certificados ya adoptado en el servidor: panel, proxy o cliente ACME. HTTP es solo el paso inicial. Configurar el certificado para aleman.brunobohm.com, su renovación y la redirección de HTTP a HTTPS. No inventar rutas de certificados que aún no existen.

La plantilla incluye una ubicación de desafío webroot en /var/lib/letsencrypt; solo usarla si ese es el método elegido y el cliente ACME puede escribir allí. Si el cliente usa otro mecanismo, ajustar esa ubicación. La emisión HTTP-01 necesita que el nombre resuelva al servidor y sea accesible públicamente por el puerto 80. La escucha HTTPS requiere el puerto 443 disponible.

Una vez configurado HTTPS, validar nuevamente con nginx -t, recargar y comprobar desde fuera del servidor:

curl --fail --head https://aleman.brunobohm.com/
curl --fail --head https://aleman.brunobohm.com/documents/docs-specification-pedagogia-v1.2.html

Abrir la portada y un documento desde el navegador. Confirmar certificado válido y redirección HTTP a HTTPS. /.git/HEAD debe devolver 403 o 404. No publicar el checkout completo.

4. Actualizaciones habituales

Con el usuario de despliegue:

cd /srv/aleman/AlemanSinMiedo
git status --short
git pull --ff-only origin main

Si hay modificaciones locales, conservarlas y resolverlas antes de actualizar; no usar reset --hard ni clean. Para cambios de HTML y CSS no se necesita reiniciar nginx ni compilar en producción. Si Codex cambia la plantilla de nginx en Git, el pull no la copia automáticamente a /etc/nginx: revisar ese cambio por separado, validar y recargar cuando corresponda.

El pull actualiza los archivos directamente y no es un despliegue atómico. Es suficiente para la web inicial; para la futura aplicación evaluar releases y cambio atómico de directorio, migraciones y recuperación según sus requisitos.

Validación y límites

Las pruebas locales del proyecto verifican HTML, enlaces y generación. La configuración nativa y HTTPS deben validarse en el servidor real antes de declarar el subdominio publicado. La presencia de Docker o una versión de PHP no demuestra que estén configurados para este proyecto.

Estado confirmado — 2026-10-25

El usuario confirmó que la portada y la especificación abren por HTTPS en el subdominio. DNS apunta a 2.28.40.150; se aportó respuesta HTTP 200 del VPS, renovación simulada exitosa y temporizador Certbot activo. No volver a ejecutar la instalación inicial para actualizar HTML. La configuración activa de HTTPS fue modificada por Certbot en el VPS: no reemplazarla por la plantilla HTTP del repositorio. Las actualizaciones habituales siguen siendo git pull --ff-only origin main desde /srv/aleman/AlemanSinMiedo.