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, plexample.com
ingressDomain
– a jelenleg használt tartomány, ehhez a telepítéshez, plmy-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.