Force_https não está funcionando com GCP Ingress

Suporte
1

Tenho uma instância do Kubernetes no GCP. Tudo parece estar correto, mas de alguma forma o force_https não está forçando um redirecionamento e o site ainda pode ser acessado via http://.

Minha solução por enquanto foi adicionar este trecho ao 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;
                  }

(E adoraria entender como fazer o pups indentar corretamente as linhas que inseri, mas isso é outro assunto.)

Algum tempo após essa alteração, o controlador de ingress parece ter parado de servir o site, embora ele estivesse funcionando e redirecionando corretamente por um bom tempo.

Obviamente, isso se enquadra em unsupported-install, mas se alguém tiver uma ideia de onde procurar a seguir, agradeço muito.

2

Você está usando um balanceador de carga HTTP ou um balanceador de carga TCP? Se for HTTP, o protocolo observado na entrada pode estar inserido em um cabeçalho não padrão que o Discourse não está procurando.

3

Parece que a configuração totalmente gerenciada fica assim:

$ gcloud compute addresses create discourse-ip-address --global
#                                 ^~~~~~~~~~~~~~~~~~~~ nome personalizado
# AVISO: reservar um endereço IP sem usá-lo acarreta uma taxa de penalidade de 0,010 USD/h
---
apiVersion: networking.gke.io/v1beta1
kind: ManagedCertificate
metadata:
  name: discourse-cert
spec:
  domains:
    - discourse.example.com  # personalize
---
apiVersion: extensions/v1beta1
# se v1.14 ou 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  # verifique se está correto
    servicePort: 80

fontes:

4

Muito obrigado, @riking! Sim, parece ser o balanceador de carga o meu problema. Acho que o ingress está OK (e agora tenho uma ideia de que há uma diferença). Mudei para a configuração que você mostrou e estou obtendo os mesmos resultados que com uma configuração um pouco mais complicada. Acredito que o próximo passo seria entender o tcpdump e ver o que há nesses cabeçalhos. . .

EDIT: Parece que deveria funcionar. Veja o que eu vejo:

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: MEU-IP, IP-INGRESS
X-Forwarded-Proto: http
Connection: Keep-Alive

Tenho um set_real_ip_from com o IP do ingress (e os números de IP estão sendo registrados corretamente).

5

@pfaffman Posso ajudar com isso — estou no GCP e já resolvi esse problema antes. Estou ocupado por algumas horas, mas se você puder me enviar sua configuração do balanceador de carga (junto com as verificações de saúde) aqui ou em particular, posso tentar identificar o problema.

PS: Tanto TCP quanto HTTP funcionarão.

6

Muito obrigado, @p16!

Bem, aqui está a verificação de saúde. Alterei o caminho para /srv/status, mas ainda vejo “GoogleHC/1.0” acessando /.

image
image485×576 20.9 KB

7

Obrigado, o backend está aparecendo como saudável no balanceador de carga? Por favor, adicione também www.yoursite.com ao host (em mais).

Além disso, aqui está o que eu adiciono ao meu 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;
           }

Isso não será necessário por muito tempo, pois o Google adicionará um redirecionador de http para https neste trimestre.

8

Sim. Parece que está funcionando agora! Acho que estou confuso com a mágica porta 30182, mas imagino que seja algum tipo de mágica do k8s que vou entender outro dia.
Vou tentar sua seção after_web_config:. Parece um pouco mais limpa do que o que eu estava fazendo.

Muito obrigado.