Force_https no funciona con GCP Ingress

Soporte
1

Tengo una instancia de Kubernetes en GCP. Todo parece estar bien, pero de alguna manera force_https no está forzando una redirección y el sitio aún se puede acceder mediante http://.

Mi solución por ahora ha sido agregar este bloque a app.yml.

    - replace:
        filename: /etc/nginx/conf.d/discourse.conf
        from: '    add_header ETag "";'
        to: |
                  add_header ETag "";
                  if ($thescheme = "http") {
                    return 301 https://$host$request_uri;
                  }

(Y me encantaría entender cómo hacer que pups ajuste la indentación de esas líneas que inserté, pero me desvío del tema.)

Un tiempo después de ese cambio, el controlador de ingreso parece haber dejado de servir el sitio, aunque parecía estar funcionando correctamente y redirigiendo adecuadamente durante un tiempo.

Obviamente, esto cae en la categoría de unsupported-install, pero si alguien tiene alguna idea sobre qué revisar a continuación, se lo agradecería.

2

¿Estás usando un equilibrador de carga HTTP o uno TCP? Si es HTTP, el protocolo visto en la entrada puede estar contenido en un encabezado no estándar que Discourse no está buscando.

3

Parece que la configuración totalmente administrada se ve así:

$ gcloud compute addresses create discourse-ip-address --global
#                                 ^~~~~~~~~~~~~~~~~~~~ nombre personalizado
# ADVERTENCIA: reservar una dirección IP sin usarla genera un cargo penal de 0.010 USD/h
---
apiVersion: networking.gke.io/v1beta1
kind: ManagedCertificate
metadata:
  name: discourse-cert
spec:
  domains:
    - discourse.example.com  # personalizar
---
apiVersion: extensions/v1beta1
# si es v1.14 o posterior:
# apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: discourse-web-ingress
  annotations:
    networking.gke.io/managed-certificates: discourse-cert
    kubernetes.io/ingress.global-static-ip-name: discourse-ip-address
spec:
  backend:
    serviceName: discourse-web  # verificar que sea correcto
    servicePort: 80

fuentes:

4

Muchas gracias, @riking. Sí, parece que el balanceador de carga es el problema. Creo que Ingress está bien (y ahora tengo una idea de que hay una diferencia). Cambié a la configuración que muestras y obtengo los mismos resultados que con una configuración un poco más complicada. Supongo que el siguiente paso sería entender tcpdump y ver qué hay en esos encabezados…

EDIT: Parece que debería funcionar. Esto es lo que veo:

GET /thisisatest HTTP/1.1
User-Agent: Wget/1.19.4 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: community.example.com
X-Cloud-Trace-Context: 72c9f7219e6b541cad01153c52fb92c5/13509441707361831434
Via: 1.1 google
X-Forwarded-For: MI-DIRECCIÓN-IP, IP-INGRESS
X-Forwarded-Proto: http
Connection: Keep-Alive

Tengo un set_real_ip_from con la IP de Ingress (y los números de IP se están registrando correctamente).

5

@pfaffman Puedo ayudarte con eso: estoy en GCP y ya he resuelto este problema antes. Estoy ocupado durante unas horas, pero si puedes enviarme la configuración de tu equilibrador de carga (junto con lo de las comprobaciones de estado) aquí o en privado, puedo intentar encontrar el problema.

PD: Tanto TCP como HTTP funcionarán.

6

¡Mil gracias, @p16!

Bueno, aquí está la comprobación de estado. Cambié la ruta a /srv/status, pero sigo viendo que “GoogleHC/1.0” accede a /.

image
image485×576 20.9 KB

7

Gracias, ¿el backend aparece como saludable en el balanceador de carga? Por favor, agrega también www.yoursite.com al host (en “más”).

Además, esto es lo que agrego a mi app.yml:

  after_web_config:
    - replace:
       filename: "/etc/nginx/conf.d/discourse.conf"
       from: /server.+{/
       to: |
         server {
           if ($http_x_forwarded_proto = 'http'){
            return 301 https://$host$request_uri;
           }

No será necesario por mucho tiempo, ya que Google añadirá un redireccionador de http a https este trimestre.

8

Sí. ¡Parece que ahora funciona! Supongo que me confunde el puerto mágico 30182, pero imagino que es algún tipo de magia de k8s que entenderé otro día.
Voy a probar tu bloque after_web_config:. Parece un poco más limpio que lo que estaba haciendo.

Muchas gracias.