Force_https ne fonctionne pas avec GCP Ingress

Soutien
1

J’ai une instance Kubernetes sur GCP. Tout semble fonctionner correctement, mais force_https ne force pas la redirection et le site est toujours accessible via http://.

Ma solution temporaire a consisté à ajouter ce bloc à 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;
                  }

(J’adorerais aussi comprendre comment faire en sorte que pups mette correctement en retrait les lignes que j’ai ajoutées, mais je m’éloigne du sujet.)

Quelque temps après ce changement, le contrôleur d’entrée (ingress controller) semble avoir cessé de servir le site, alors qu’il fonctionnait correctement et assurait la redirection pendant un certain temps.

Bien sûr, il s’agit d’une installation unsupported-install, mais si quelqu’un a une idée de la piste à explorer ensuite, je vous serais reconnaissant de me le dire.

2

Utilisez-vous un équilibreur de charge HTTP ou un équilibreur de charge TCP ? Si c’est HTTP, le protocole observé à l’entrée peut être encapsulé dans un en-tête non standard que Discourse ne recherche pas.

3

Voici à quoi ressemble la configuration entièrement gérée :

$ gcloud compute addresses create discourse-ip-address --global
#                                 ^~~~~~~~~~~~~~~~~~~~ nom personnalisé
# AVERTISSEMENT : réserver une adresse IP sans l'utiliser entraîne des frais de 0,010 USD/heure
---
apiVersion: networking.gke.io/v1beta1
kind: ManagedCertificate
metadata:
  name: discourse-cert
spec:
  domains:
    - discourse.example.com  # personnaliser
---
apiVersion: extensions/v1beta1
# si version 1.14 ou ultérieure :
# 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  # vérifier que c'est correct
    servicePort: 80

sources :

4

Merci beaucoup, @riking ! Oui, c’est bien le répartiteur de charge qui semble poser problème. Je pense que l’ingress fonctionne correctement (et j’ai maintenant une idée de la différence qui existe entre les deux). J’ai basculé vers la configuration que vous montrez et j’obtiens les mêmes résultats qu’avec une configuration un peu plus complexe. Je suppose que la prochaine étape serait de comprendre tcpdump et de voir ce qu’il y a dans ces en-têtes. . .

EDIT : Il semble que cela devrait fonctionner. Voici ce que je vois :

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

J’ai un set_real_ip_from configuré avec l’adresse IP de l’ingress (et les numéros d’adresse IP sont bien consignés dans les journaux).

5

@pfaffman Je pourrais vous aider avec cela — j’utilise GCP et j’ai déjà résolu ce problème. Je suis occupé pendant quelques heures, mais si vous pouvez m’envoyer votre configuration de l’équilibreur de charge (ainsi que les éléments relatifs aux vérifications de santé) ici ou en privé, je peux essayer de trouver le problème.

PS : TCP et HTTP fonctionneront tous les deux.

6

Un grand merci, @p16 !

Voici donc le contrôle de santé. J’ai changé le chemin en /srv/status, mais je vois toujours “GoogleHC/1.0” accéder à /.

image
image485×576 20.9 KB

7

Merci, le backend apparaît-il comme sain dans l’équilibreur de charge ? Veuillez également ajouter www.yoursite.com à l’hôte (dans plus).

Voici ce que j’ajoute à mon 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;
           }

Ce ne sera pas nécessaire pendant très longtemps, car Google ajoutera un redirigeur de http vers https ce trimestre.

8

Oui. Ça semble fonctionner maintenant ! Je suppose que je suis confus au sujet du port magique 30182, mais je pense que c’est une sorte de magie k8s que je comprendrai un autre jour.
Je vais essayer votre bloc after_web_config:. Il semble un peu plus propre que ce que je faisais.

Merci beaucoup.