Как перенаправить на «www» с помощью Nginx Ingress

Вам часто потребуется развернуть веб-приложение в корне вашего домена, а также в субдомене «www». Это помогает пользователям обнаружить ваш сервис. Nginx Ingress имеет встроенную поддержку этой процедуры.

Вот как развернуть рабочую нагрузку с двумя входными хостами, «www» и вашим пустым доменом. Любой, кто посещает «www», будет действовать как обычно. Посетители корня домена будут перенаправлены на субдомен «www». Используя перенаправление, вы снижаете риск того, что обе конечные точки могут отображаться в результатах поиска.

Использование аннотации

Nginx Ingress предоставляет аннотацию Kubernetes, которая позволяет настроить это поведение. Добавление аннотации к вашему ресурсу Ingress включает инфраструктуру перенаправления. Вам не нужно вручную прописывать логику перезаписи в конфигурацию Nginx.

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

Установите эту аннотацию в поле metadata.annotations вашего определения ресурса Ingress. Полный рабочий пример приведен в следующем разделе.

Настройка ваших хостов

Вы должны добавить конфигурацию хоста Ingress обычным способом. Вам нужна только одна строка host. Используйте здесь домен «www» — Nginx Ingress автоматически обработает перенаправление с «голого» домена. Если вы предпочитаете, вы можете вместо этого написать голый домен. Затем Nginx Ingress будет перенаправлять на его, с www.

Добавьте остальную часть входящей конфигурации под строкой host. Вам нужно будет указать HTTP-путь для обслуживания (обычно /) и службу, на которую будет перенаправляться трафик.

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

Этот минимальный рабочий пример должен позволить вам увидеть перенаправление в действии. Посещение пустого домена сразу же приведет вас к «www». Вы можете быть уверены, что пользователи взаимодействуют с вашим сайтом через единую точку входа, даже если есть два возможных входных хоста.

Добавление поддержки HTTPS

Показанный выше манифест не поддерживает HTTPS. В реальном сценарии вы почти наверняка захотите убедиться, что все ваши входящие хосты защищены сертификатом TLS.

Чтобы HTTPS работал с этой конфигурацией, вам нужно добавить оба хоста к одному сертификату TLS. Вот обновленный манифест с поддержкой 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

Имея всего пять строк YAML, теперь у вас должен быть работающий HTTPS на обоих возможных входных хостах. Это предполагает, что в вашем кластере есть активный эмитент сертификата — мы используем letsencrypt-prod, предоставленный cert-manager. Вы должны следовать документации, чтобы установить cert-manager, если нет доступного контроллера сертификатов.

Вы также можете выбрать альтернативный контроллер сертификатов. Вам потребуется обновить входную аннотацию cluster-issuer, указав имя эмитента, предоставленное вашим контроллером. Вам не нужно будет изменять раздел tls манифеста — это будет работать со всеми контроллерами сертификатов Kubernetes.

Преобразование домена в переменную

Мы можем преобразовать манифест в диаграмму Helm, чтобы не повторять доменное имя. В этом примере мы предполагаем, что ваше доменное имя установлено как ingressDomain в values.yaml диаграммы Helm.

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

Если вам когда-нибудь понадобится изменить свое доменное имя, теперь вам нужно будет обновить значение только в одном месте. Это также позволяет использовать манифест в средах CI. Ваш CI-сервер может использовать вашу диаграмму для запуска новой промежуточной среды для каждого филиала, создавая динамический домен (например, my-branch.example.com), который будет установлен как ingressDomain. .

Работа со средами разработки

Теперь у нас есть работающий www-redirect! Вы можете остановиться на этом и развернуть в рабочей среде, если хотите, так как основная цель этого руководства была достигнута.

Тем не менее, есть некоторые проблемы с подходом, который мы показали, особенно при работе в средах разработки CI. В настоящее время перед исходным доменом каждой среды будет стоять www.

Чтобы решить эту проблему, замените ingressDomain двумя независимыми переменными:

ingressBase — ваш базовый домен, например. example.com
ingressDomain – текущий используемый домен для данного развертывания, например. my-branch.example.com

Затем вы можете использовать сравнение переменных Helm, чтобы включить перенаправление www только тогда, когда вы находитесь в производственной среде.

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

При развертывании в рабочей среде задайте для ingressDomain базовый домен — он должен иметь то же значение, что и ingressBase. Условие if будет выполнено, поэтому будет создан вход www.

При развертывании в среде поддомена разные значения ingressDomain и ingressBase отключат переадресацию www.

Заключение

Перенаправление с пустого домена на поддомен «www» является фундаментальным ожиданием многих общедоступных веб-сайтов. Используя Nginx Ingress, вы можете применить это традиционное поведение к своим контейнерным рабочим нагрузкам, развернутым в облаке.

Добавьте аннотацию к входному ресурсу и убедитесь, что оба хоста указаны в его спецификации. Завершите, проверив, что пара также указана во всех сертификатах TLS. Пользователи никогда не должны обращаться к незащищенной конечной точке, даже если они будут перенаправлены с нее.