Cómo redirigir a "www" con Nginx Ingress

A menudo, querrá implementar una aplicación web en la raíz de su dominio, así como en el subdominio "www". Esto ayuda a los usuarios a descubrir su servicio. Nginx Ingress tiene soporte incorporado para el procedimiento.

A continuación, se explica cómo implementar una carga de trabajo con dos hosts entrantes, "www" y su dominio básico. Cualquiera que visite "www" procederá normalmente. Los visitantes de la raíz del dominio serán redirigidos al subdominio "www". Al usar una redirección, reduce el riesgo de que ambos extremos aparezcan en los resultados de búsqueda.

Usando anotación

Nginx Ingress proporciona una anotación de Kubernetes que le permite configurar este comportamiento. Agregar la anotación a su recurso de Ingress habilita la infraestructura de redireccionamiento. No es necesario escribir manualmente la lógica de reescritura en la configuración de Nginx.

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

Establecer esta anotación en el archivo metadata.annotations campo de la definición de recurso de Ingress. En la siguiente sección se proporciona un ejemplo de trabajo completo.

Configuración de host

Debe agregar la configuración del host de Ingress de la forma habitual. Solo necesitas uno host línea. Utilice el dominio "www" aquí: Nginx Ingress manejará automáticamente la redirección desde el dominio simple. Si lo prefiere, puede escribir el dominio desnudo en su lugar. A continuación, se redirigirá Nginx Ingress por eso, desde www.

Agregue el resto de la configuración de entrada debajo del archivo host línea. Deberá indicar la ruta HTTP que se servirá (generalmente /) y el servicio al que encaminar el tráfico.

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

Este ejemplo de trabajo mínimo debería permitirle ver la redirección en acción. Visitar el dominio simple lo llevará inmediatamente a "www". Puede estar seguro de que los usuarios interactúan con su sitio a través de un único punto de entrada, incluso si hay dos posibles hosts de entrada.

Soporte HTTPS agregado

El archivo de manifiesto que se muestra arriba no es compatible con HTTPS. En un escenario del mundo real, seguramente querrá asegurarse de que todos sus hosts entrantes estén cubiertos por un certificado TLS.

Para que HTTPS funcione con esta configuración, ambos hosts deben agregarse a un solo certificado TLS. Aquí hay un manifiesto actualizado con soporte 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

Con solo cinco líneas más de YAML, ahora debería tener HTTPS funcionando en los dos posibles hosts entrantes. Esto supone que tiene un emisor de certificado activo en su clúster; estamos usando letsencrypt-prod, suministrada por cert-manager. Debe seguir la documentación para instalar cert-manager si no hay ningún controlador de certificado disponible.

También puede elegir un controlador de certificado alternativo. Deberías actualizar el archivo cluster-issuer anotación de entrada con el nombre de un emisor proporcionada por el controlador. No necesitarás modificar el archivo. tls sección de manifiesto: funcionará con todos los controladores de certificados de Kubernetes.

Haga del dominio una variable

Podemos convertir el manifiesto en un archivo. Carta de timón para evitar tener que repetir el nombre de dominio. En este ejemplo, asumiremos que su nombre de dominio está configurado como ingressDomain en tu tarjeta 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 necesita cambiar su nombre de dominio, ahora solo necesita actualizar el valor en un solo lugar. Esto también permite el uso del manifiesto en entornos de CI. Su servidor de CI podría usar su gráfico para crear un nuevo entorno de ensayo para cada rama, creando un dominio dinámico (p. Ej. my-branch.example.com) para establecer como ingressDomain.

Gestión de entornos de desarrollo

¡Ahora tenemos un redireccionamiento www que funciona! Puede detenerse aquí y pasar a producción si lo desea, ya que se ha logrado el objetivo principal de este tutorial.

Dicho esto, existen algunos problemas con el enfoque que hemos mostrado, particularmente cuando se trabaja en entornos de desarrollo de CI. Actualmente, cualquier entorno tendría www antepuesto a su dominio original.

Una forma de solucionar este problema es reemplazar ingressDomain con dos variables independientes:

• ingressBase - su dominio base, p. ej. example.com
• ingressDomain - el dominio que se utiliza actualmente para esta distribución, p. ej. my-branch.example.com

Luego, puede usar las comparaciones de variables de Helm para habilitar la redirección de www solo cuando se encuentra en un entorno de producción.

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

Al implementar en producción, configure ingressDomain al dominio base: debe tener el mismo valor que ingressBase. los if la condición coincidirá, entonces la www se creará la entrada.

Al implementar en un entorno de subdominio, los diferentes valores de ingressDomain es ingressBase desactivará www.

Conclusión

Redirigir desde un dominio simple al subdominio "www" es una expectativa básica de muchos sitios web públicos. Con Nginx Ingress, puede aplicar este comportamiento tradicional a sus cargas de trabajo en contenedores implementadas en la nube.

Agregue la anotación a su recurso entrante y asegúrese de ambos los hosts se enumeran en sus especificaciones. Para finalizar, verifique que el par también esté incluido en todos los certificados TLS. Los usuarios nunca deben hablar con un punto final no seguro, incluso si serán redirigidos fuera de él.