Force_https لا يعمل مع GCP Ingress

الدعم
1

لديك مثيل Kubernetes على GCP. يبدو أن كل شيء على ما يرام، لكن يبدو أن 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 يوسّط الأسطر التي أضفتها، لكنني أشتت الانتباه.)

بعد هذا التغيير بوقت ما، بدا أن وحدة تحكم Ingress توقفت عن تقديم الموقع، رغم أنها كانت تعمل—وتقوم بإعادة التوجيه بشكل صحيح—لمدة معينة على الأقل.

من الواضح أن هذا يندرج تحت فئة #unsupported-install، لكن إذا كان لدى أي شخص فكرة عن أين يجب البحث بعد ذلك، فسأقدّر ذلك كثيرًا.

2

هل تستخدم موزع أحمال HTTP أم موزع أحمال TCP؟ في حالة استخدام HTTP، قد يكون البروتوكول المرئي عند نقطة الدخول مُضمنًا في رأس غير قياسي لا يبحث عنه Discourse.

3

يبدو أن الإعداد المُدار بالكامل يبدو كالتالي:

$ gcloud compute addresses create discourse-ip-address --global
#                                 ^~~~~~~~~~~~~~~~~~~~ اسم مخصص
# تحذير: حجز عنوان IP دون استخدامه يؤدي إلى رسوم عقوبة قدرها 0.010 دولار أمريكي/ساعة
---
apiVersion: networking.gke.io/v1beta1
kind: ManagedCertificate
metadata:
  name: discourse-cert
spec:
  domains:
    - discourse.example.com  # تخصيص
---
apiVersion: extensions/v1beta1
# إذا كانت الإصدار 1.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

المصادر:

4

شكرًا جزيلاً لك، @riking! نعم، يبدو أن مشكلة التحميل المتوازن (load balancer) هي المشكلة. أعتقد أن 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 مع عنوان IP الخاص بـ ingress (وتُسجل أرقام عناوين IP بشكل صحيح).

5

@pfaffman يمكنني المساعدة في ذلك - فأنا أستخدم GCP وقد حلت هذه المشكلة من قبل. لكنني مشغول لعدة ساعات، لذا إذا أرسلت لي إعدادات موازن التحميل لديك (إلى جانب إعدادات فحص الصحة) هنا أو بشكل خاص، سأحاول العثور على المشكلة.

ملاحظة: كل من TCP و HTTP سيعملان.

6

شكرًا جزيلًا لك، @p16!

حسنًا، إليك فحص الحالة. لقد غيّرت المسار إلى /srv/status، لكنني ما زلت أرى “GoogleHC/1.0” يهاجم /.

image
image485×576 20.9 KB

7

شكرًا لك، هل يظهر الخلفية (backend) كصحي في موزع الحمل؟ يُرجى أيضًا إضافة 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;
           }

لن يكون هذا ضروريًا لفترة طويلة، حيث ستقوم جوجل بإضافة أداة تحويل من HTTP إلى HTTPS خلال هذا الربع.

8

نعم. يبدو أن الأمر يعمل الآن! أعتقد أنني مشوش بشأن المنفذ السحري 30182، لكنني أفترض أن هذا نوع من السحر في k8s سأفهمه في يوم آخر.
سأجرب قسم after_web_config: الخاص بك. يبدو أنه أنظف مما كنت أفعله.

شكرًا جزيلاً.