Configuración de Cloudflare con subcarpeta

[tig3 (Tig)]

Solo quería compartir los pasos que seguí para configurar una subcarpeta junto con Cloudflare, especialmente cuando el sitio web principal ya está en línea y el dominio raíz no se puede apuntar al servidor del foro (ni siquiera temporalmente).

Puntos Clave

• El miweb.com existente actualmente apunta a 1.1.1.1 y está en línea.
• Deberíamos enrutar miweb.com/foro (y sus subdirectorios) a 2.2.2.2.
• Dado que durante la instalación de Discourse no podemos pasar la validación de letsencrypt (que verifica si el dominio resuelve el servidor actual), deberíamos usar la validación de DNS.

Cambios en app.yml

Actualizaciones de Letsencrypt

Crea una nueva plantilla de letsencrypt y configúrala en app.yml según este tema: LetsEncrypt DNS Validation Template Using Cloudflare

Sin embargo, asegúrate de copiar solo el método issue_cert de esa publicación, y el resto del contenido tómalo del web.letsencrypt.ssl.template.yml original (ya que se modificó después de que se publicó el tema).

LETSENCRYPT_CF_TOKEN: ""
LETSENCRYPT_CF_ACCOUNT_ID: ""
LETSENCRYPT_CF_ZONE_ID: ""
LETSENCRYPT_DNS_PROVIDER: "dns_cf"

• Puedes crear el token de Cloudflare desde la página Mi perfil de CF → “Tokens de API”.
• El ID de cuenta y el ID de zona se muestran en la página de Descripción general del dominio.
• Deja el valor del proveedor de DNS como está arriba.

Actualizaciones de subcarpetas

Según este tema Serve Discourse from a subfolder (path prefix) instead of a subdomain, configura DISCOURSE_RELATIVE_URL_ROOT: /foro en env: y actualiza la sección run:.
Ten en cuenta esta publicación para las IPs de usuario: Serve Discourse from a subfolder (path prefix) instead of a subdomain - #111 by varun21

Reconstruir

Después de cambiar el app.yml para ejecutar el comando de reconstrucción, necesitamos omitir la verificación de Discourse para que el dominio resuelva la IP del servidor actual (ya que nuestro miweb.com ya apunta a 1.1.1.1, y Discourse verifica el dominio raíz), para ello ejecuta:

./launcher rebuild app --skip-connection-test

Configuración de Cloudflare

Sé que algunas personas recomiendan usar Workers para enrutar /foro a 2.2.2.2, sin embargo, encontré que es mucho más fácil hacerlo con Balanceo de Carga. De todos modos, con Workers no pude resolver problemas relacionados con CSS/JS, incluso con rocket loader y otras configuraciones similares deshabilitadas. Entonces,

• Activa el Balanceo de Carga (en Tráfico)
• Selecciona “Administrar pools” → “Crear”
• Crea 2 pools (para el sitio web principal y para el foro), cada uno debe tener un solo endpoint.

• Crea el Balanceador de Carga, el nombre de host debe ser miweb.com.
• En la sección de endpoints, elige ambos pools.
• Omite los Monitores (ya que no necesitamos monitorear el estado del servidor, el sitio web principal siempre debe apuntar a 1.1.1.1 y el foro a 2.2.2.2), Omite la Dirección de Tráfico (el valor predeterminado es desactivado).
• En Regla Personalizada, crea una con la condición de ruta como /foro y apunta al endpoint del foro.

• Guarda/Implementa.

Notas

• Por alguna razón, copiar el app.yml de ejemplo y luego reconstruir no funcionó para mí (probablemente estaba haciendo algo mal). Entonces, como solución, ejecuté discourse-setup por primera vez con otro dominio y luego, junto con otros cambios en app.yml, cambié el nombre de host e hice la reconstrucción final.
• Discourse genera 2 certificados de letsencrypt, RSA cert y ECDSA cert, y letsencrypt tiene un límite de 5 certificados por dominio exacto por semana. Si haces algo mal 2 veces seguidas, el tercer intento solo emitirá un certificado y el foro no funcionará (puedes verificar el límite actual con este script GitHub - sahsanu/lectl: Script to check issued certificates by Let's Encrypt on CTL (Certificate Transparency Log) using https://crt.sh).
• CF Load Balancer no es gratuito, sin embargo, considerando (a partir de ahora) el costo de 5 USD por 500k solicitudes DNS, creo que vale la pena, en comparación con la molestia con nginx, etc.