Hogyan lehet átirányítani a „www” -ra az Nginx Ingress segítségével – CloudSavvy IT

Avatar Gadam | 2021.03.19. 52 Views 0 Likes 0 Ratings

52 Views 0 Ratings Rate it

[ad_1]

A Kubernetes logót ábrázoló grafika

Gyakran érdemes egy webalkalmazást telepíteni a domain gyökerébe, valamint a „www” aldomainbe. Ez segít a felhasználóknak felfedezni az Ön szolgáltatását. Az Nginx Ingress beépített támogatást nyújt az eljáráshoz.

Az alábbiakban bemutatjuk, hogyan telepítsen egy munkaterhelést két behatoló gazdagéppel, a „www” és a csupasz tartományával. Aki meglátogatja a „www” címet, a szokásos módon folytatja. A tartománygyökér látogatóit átirányítják a „www” aldomainre. Az átirányítás használatával csökkentheti annak kockázatát, hogy mindkét végpont megjelenhet a keresési eredmények között.

Az Annotation használatával

Az Nginx Ingress egy Kubernetes-kommentárral rendelkezik, amely lehetővé teszi a viselkedés konfigurálását. A kommentár hozzáadása az Ingress erőforráshoz lehetővé teszi az átirányítási infrastruktúrát. Nem kell kézzel írni az átírási logikát az Nginx konfigurációjába.

nginx.ingress.kubernetes.io/from-to-www-redirect: "true"

Állítsa be ezt a jegyzetet a metadata.annotations az Ingress erőforrás-meghatározásának mezője. A teljes munkapéldát a következő szakasz tartalmazza.

A vendéglátók beállítása

Az Ingress gazdagép konfigurációját a szokásos módon kell hozzáadnia. Csak neked kell egy host vonal. Itt használja a „www” tartományt – az Nginx Ingress automatikusan kezeli az átirányítást a csupasz tartományból. Ha úgy tetszik, megírhatja a csupasz tartományt. A Nginx Ingress ekkor átirányít nak nek azt, tól től www.

Adja hozzá a többi behatolási konfigurációt a host vonal. Meg kell adnia a kiszolgáláshoz használt HTTP elérési utat (általában /) és a forgalom útvonaltervezésére irányuló szolgáltatás.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  namespace: my-namespace
  annotations:
    kubernetes.io/ingress.class: nginx-ingress
    nginx.ingress.kubernetes.io/from-to-www-redirect: "true"
spec:
  rules:
    - host: www.example.com
      http:
        paths:
        - path: /
          backend:
            serviceName: my-service
            servicePort: 80

Ennek a minimális működési példának lehetővé kell tennie az átirányítás működés közbeni megtekintését. A csupasz domain meglátogatásával azonnal a „www” oldalra jut. Biztos lehet benne, hogy a felhasználók egyetlen belépési ponton keresztül lépnek kapcsolatba a webhelyével, annak ellenére, hogy két lehetséges behatolási gazdagép van.

HTTPS támogatás hozzáadása

A fent bemutatott jegyzékből hiányzik a HTTPS támogatása. Valódi forgatókönyv esetén szinte biztosan meg akarja győződni arról, hogy minden behatoló gazdagépére TLS-tanúsítvány vonatkozik.

Ahhoz, hogy a HTTPS működjön ezzel a konfigurációval, meg kell adnia mindkét hosztot egyetlen TLS tanúsítványhoz. Itt egy frissített jegyzék a TLS támogatással:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  namespace: my-namespace
  annotations:
    kubernetes.io/ingress.class: nginx-ingress
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/from-to-www-redirect: "true"
spec:
  rules:
    - host: www.example.com
      http:
        paths:
        - path: /
          backend:
            serviceName: my-service
            servicePort: 80
  tls:
    - hosts:
        - example.com
        - www.example.com
      secretName: ingress-tls-secret

Csak még öt YAML-sorral rendelkeznie kell, ha mindkét lehetséges behatolási gazdagépen működő HTTPS működik. Ez feltételezi, hogy aktív tanúsítványkibocsátó van a fürtjében – mi ezt használjuk letsencrypt-prod, által biztosított cert-menedzser. Kövesse a dokumentációt telepítse a cert-manager alkalmazást ha nincs elérhető tanúsítványvezérlő.

Választhat egy másik tanúsítványvezérlőt is. Frissítenie kell a cluster-issuer bejegyzési jegyzet az irányító által megadott kibocsátó nevével. Nem kell módosítania a tls szakasz a jegyzékben – ez minden Kubernetes tanúsítványvezérlővel együtt fog működni.

A tartomány változóvá tétele

Átalakíthatjuk a manifesztet a-ra Helm diagram hogy ne kelljen megismételnie a domain nevet. Ebben a példában feltételezzük, hogy a domain neve a következőre van állítva: ingressDomain a Helm-diagramodban values.yaml.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  namespace: my-namespace
  annotations:
    kubernetes.io/ingress.class: nginx-ingress
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/from-to-www-redirect: "true"
spec:
  rules:
    - host: {{ print "www." .Values.ingressDomain }}
      http:
        paths:
        - path: /
          backend:
            serviceName: my-service
            servicePort: 80
  tls:
    - hosts:
        - {{ print .Values.ingressDomain }}
        - {{ print "www" .Values.ingressDomain }}
      secretName: ingress-tls-secret

Ha valaha is módosítania kell a domain nevét, akkor most csak egy helyen kell frissítenie az értéket. Ez lehetővé teszi a manifeszt használatát a CI környezetben is. A CI-kiszolgáló felhasználhatja a diagramját, hogy minden egyes ághoz új átmeneti környezetet hozzon létre, dinamikus tartomány létrehozásával (pl my-branch.example.com) beállítani ingressDomain.

Fejlesztői környezetek kezelése

Most már működik egy működő www-átirányítás! Itt állhat meg, és telepítheti a termelésbe, ha akarja, mivel a bemutató fő célját elérték.

Ennek ellenére vannak problémáink a bemutatott megközelítéssel, különösen a CI fejlesztési környezetekben való munkavégzés során. Jelenleg minden környezetnek megvan www előkészítve az eredeti tartományához.

Ennek megoldásának egyik módja a pótlás ingressDomain két független változóval:

  • ingressBase – az alap domainje, pl example.com
  • ingressDomain – a jelenleg használt tartomány, ehhez a telepítéshez, pl my-branch.example.com

Ezután a Helm változó-összehasonlításokkal csak akkor engedélyezheti a www-átirányítást, ha éles környezetben tartózkodik.

spec:
  rules:
    {{ if eq .Values.ingressDomain .Values.ingressBase }}
    - host: {{ print "www." .Values.ingressDomain }}
    {{ else }}
    - host: {{ print .Values.ingressDomain }}
    {{ end }}
      http:
        paths:
          - path: /
            backend:
              serviceName: my-service
              servicePort: 80
  tls:
    - hosts:
      - {{ .Values.ingressDomain }}
      {{ if eq .Values.ingressDomain .Values.ingressBase }}
      - {{ print "www." .Values.ingressDomain }}
      {{ end }}
      secretName: {{ .Values.ingressTlsSecret }}

A gyártásba helyezéskor állítsa be ingressDomain az alaptartományhoz – annak meg kell egyeznie az értékével ingressBase. A if állapot meg fog egyezni, tehát a www behatolás jön létre.

Amikor egy aldomain környezetbe telepít, akkor a ingressDomain és ingressBase letiltja a www-átirányítást.

Következtetés

A puszta domainről az „www” aldomainre történő átirányítás számos nyilvános webhely alapvető elvárása. Az Nginx Ingress használatával ezt a hagyományos viselkedést alkalmazhatja a felhőben elhelyezett konténeres munkaterhelésekre.

Adja hozzá a jegyzetet a behatolási erőforráshoz, és győződjön meg róla mindkét a házigazdák a specifikációjában szerepelnek. Végül ellenőrizze, hogy a pár szerepel-e a TLS tanúsítványokban is. A felhasználóknak soha nem szabad egy nem védett végponttal beszélniük, még akkor sem, ha átirányítják őket ettől.

[ad_2]
Source link


52 Views 0 Ratings Rate it