Name: Tremplin Numérique
Price range: $$$

Graphique montrant le logo Kubernetes

Vous souhaiterez souvent déployer une application Web à la racine de votre domaine, ainsi que le sous-domaine «www». Cela aide les utilisateurs à découvrir votre service. Nginx Ingress a un support intégré pour la procédure.

Voici comment déployer une charge de travail avec deux hôtes d’entrée, «www» et votre domaine nu. Toute personne visitant «www» procédera normalement. Les visiteurs de la racine du domaine seront redirigés vers le sous-domaine «www». En utilisant une redirection, vous réduisez le risque que les deux points de terminaison apparaissent dans les résultats de recherche.

Sommaire

Utilisation de l’annotation

Nginx Ingress fournit une annotation Kubernetes qui vous permet de configurer ce comportement. L’ajout de l’annotation à votre ressource Ingress active l’infrastructure de redirection. Vous n’avez pas besoin d’écrire manuellement la logique de réécriture dans votre configuration Nginx.

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

Définissez cette annotation dans le metadata.annotations champ de la définition de ressource de votre Ingress. Un exemple de travail complet est fourni dans la section suivante.

Configuration de vos hôtes

Vous devez ajouter votre configuration d’hôte Ingress de la manière habituelle. Tu a juste besoins une host ligne. Utilisez le domaine «www» ici – Nginx Ingress gérera automatiquement la redirection depuis le domaine nu. Si vous préférez, vous pouvez écrire le domaine nu à la place. Nginx Ingress redirigera alors à il, de www.

Ajoutez le reste de la configuration d’entrée sous le host ligne. Vous devrez indiquer le chemin HTTP à servir (généralement /) et le service vers lequel acheminer le trafic.

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

Cet exemple de travail minimal devrait vous permettre de voir la redirection en action. Visiter le domaine nu vous mènera immédiatement à «www» à la place. Vous pouvez être sûr que les utilisateurs interagissent avec votre site via un seul point d’entrée, même s’il existe deux hôtes d’entrée possibles.

Ajout de la prise en charge HTTPS

Le manifeste illustré ci-dessus ne prend pas en charge HTTPS. Dans un scénario réel, vous voudrez presque certainement vous assurer que tous vos hôtes d’entrée sont couverts par un certificat TLS.

Pour utiliser HTTPS avec cette configuration, vous devez ajouter vos deux hôtes à un seul certificat TLS. Voici un manifeste mis à jour avec le support TLS:

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

Avec seulement cinq lignes supplémentaires de YAML, vous devriez maintenant avoir un HTTPS fonctionnel sur les deux hôtes d’entrée possibles. Cela suppose que vous avez un émetteur de certificat actif dans votre cluster – nous utilisons letsencrypt-prod, fourni par cert-manager. Vous devez suivre la documentation pour installer cert-manager s’il n’y a pas de contrôleur de certificat disponible.

Vous pouvez également choisir un autre contrôleur de certificat. Vous auriez besoin de mettre à jour le cluster-issuer annotation d’entrée avec le nom d’un émetteur fourni par votre contrôleur. Vous n’aurez pas besoin de changer le tls section du manifeste – cela fonctionnera avec tous les contrôleurs de certificats Kubernetes.

Faire du domaine une variable

Nous pouvons convertir le manifeste en un graphique Helm pour éviter d’avoir à répéter le nom de domaine. Dans cet exemple, nous supposerons que votre nom de domaine est défini comme ingressDomain dans votre tableau Helm 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

Si jamais vous avez besoin de changer votre nom de domaine, vous n’aurez plus qu’à mettre à jour la valeur à un seul endroit. Cela permet également d’utiliser le manifeste dans les environnements CI. Votre serveur CI peut utiliser votre graphique pour créer un nouvel environnement de préparation pour chaque branche, créant ainsi un domaine dynamique (par exemple my-branch.example.com) pour définir comme ingressDomain.

Gestion des environnements de développement

Nous avons maintenant une www-redirect qui fonctionne! Vous pouvez vous arrêter ici et déployer en production si vous le souhaitez, car l’objectif principal de ce didacticiel a été atteint.

Cela dit, l’approche que nous avons montrée pose certains problèmes, en particulier lorsque vous travaillez dans des environnements de développement CI. Actuellement, chaque environnement aurait www ajouté à son domaine d’origine.

Une façon de résoudre ce problème est de remplacer ingressDomain avec deux variables indépendantes:

ingressBase – votre domaine de base, par exemple example.com
ingressDomain – le domaine actuellement utilisé, pour ce déploiement, par exemple my-branch.example.com

Vous pouvez ensuite utiliser les comparaisons de variables Helm pour activer la redirection www uniquement lorsque vous êtes dans un environnement de production.

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 }}

Lors du déploiement en production, définissez ingressDomain au domaine de base – il doit avoir la même valeur que ingressBase. Le if la condition sera assortie, de sorte que la www l’entrée sera créée.

Lorsque vous déployez dans un environnement de sous-domaine, les différentes valeurs de ingressDomain et ingressBase désactivera la redirection www.

Conclusion

La redirection d’un domaine nu vers le sous-domaine «www» est une attente fondamentale de nombreux sites Web destinés au public. À l’aide de Nginx Ingress, vous pouvez appliquer ce comportement traditionnel à vos charges de travail conteneurisées déployées dans le cloud.

Ajoutez l’annotation à votre ressource d’entrée et assurez-vous tous les deux les hôtes sont répertoriés dans ses spécifications. Terminez en vérifiant que la paire est également répertoriée dans tous les certificats TLS. Les utilisateurs ne doivent jamais parler à un point de terminaison non sécurisé, même s’ils vont en être redirigés.