Force_https が GCP Ingress で機能しない

[pfaffman (Jay Pfaffman)]

GCP に Kubernetes インスタンスを構築しています。全体としては問題なさそうに見えるのですが、なぜか force_https がリダイレクトを強制せず、サイトが http:// で依然としてアクセスできてしまいます。

現時点での私の解決策は、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;
                  }

（追記：追加した行を pups でどのようにインデントさせるか理解したいのですが、それはさておき。）

その変更の後、イングレスコントローラーがサイトを提供しなくなったようですが、それまでは少なくともしばらく正常に動作し、正しくリダイレクトもしていました。

明らかにこれは unsupported-install のケースですが、次にどこを確認すべきかアイデアがあれば、教えていただければ幸いです。

[riking (Kane York)]

HTTP ロードバランサーを使用していますか、それとも TCP ロードバランサーを使用していますか？HTTP の場合、イングレスで観測されるプロトコルは、Discourse が検出しない非標準ヘッダーに格納されている可能性があります。

[riking (Kane York)]

完全マネージド設定は以下のようになります：

$ gcloud compute addresses create discourse-ip-address --global
#                                 ^~~~~~~~~~~~~~~~~~~~ カスタム名
# 警告：IP アドレスを予約しても使用しない場合、0.010USD/時間の罰金が課されます
---
apiVersion: networking.gke.io/v1beta1
kind: ManagedCertificate
metadata:
  name: discourse-cert
spec:
  domains:
    - discourse.example.com  # カスタマイズ
---
apiVersion: extensions/v1beta1
# v1.14 以降の場合：
# 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  # 正しいか確認してください
    servicePort: 80

ソース：

GKE Ingress for Application Load Balancers  |  GKE networking  |  Google...

Secure traffic for GKE Ingress  |  GKE networking  |  Google Cloud Documentation

[pfaffman (Jay Pfaffman)]

ありがとうございます、@riking！はい、問題のようです。ロードバランサーが原因のようです。Ingress は問題ないと思います（そして、違いがあるという考えが少しあります）。あなたが示した設定に切り替えたところ、少し複雑な設定だったときと同じ結果が出ています。次のステップの一つは、tcpdump を理解して、そのヘッダーに何が含まれているかを確認することかもしれません。 . .

編集：それは機能するはずのようです。私が確認したのは以下の通りです：

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

set_real_ip_from に Ingress の IP を設定しており（IP アドレスも正しくログに記録されています）。

[P16]

@pfaffman それについてお手伝いできますよ。私は GCP を利用しており、以前にこの問題を解決した経験があります。ただ、数時間ほど手が離せないのですが、もしロードバランサーの設定（ヘルスチェックの設定も含めて）をこちらかプライベートで送っていただければ、問題の原因を探ってみます。

追伸：TCP と HTTP の両方で動作します。

[pfaffman (Jay Pfaffman)]

本当にありがとうございます、@p16！

さて、これがヘルスチェックです。パスを /srv/status に変更しましたが、まだ “GoogleHC/1.0” が / にアクセスしているようです。

[P16]

ありがとうございます。ロードバランサーでバックエンドが正常（healthy）として表示されていますか？また、ホスト設定（「その他」の下）に www.yoursite.com を追加してください。

また、私が 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;
           }

これは長く必要なくなるでしょう。Google が今四半期に HTTP から HTTPS へのリダイレクト機能を追加する予定です。

[pfaffman (Jay Pfaffman)]

はい、今は動作しているようです！魔法のポート 30182 については少し混乱していますが、それはある日理解するだろう k8s の魔法の一種だと思います。
あなたの after_web_config: スタンザを試してみます。私がやっていた方法よりも少しクリーンなようです。

ありがとうございます。