Como redirecionar para “www” com Nginx Ingress

Muitas vezes, você deseja implantar um aplicativo da Web na raiz do seu domínio, bem como no subdomínio “www”. Isso ajuda os usuários a descobrir seu serviço. O Nginx Ingress possui suporte integrado para o procedimento.

Veja como implantar uma carga de trabalho com dois hosts de entrada, www e seu domínio simples. Qualquer pessoa que visite “www” procederá normalmente. Os visitantes da raiz do domínio serão redirecionados para o subdomínio “www”. Ao usar um redirecionamento, você reduz o risco de que ambos os pontos de extremidade possam ser exibidos nos resultados da pesquisa.

Usando a anotação

O Nginx Ingress fornece uma anotação do Kubernetes que permite configurar esse comportamento. Incluir a anotação em seu recurso Ingress ativa a infraestrutura de redirecionamento. Você não precisa escrever manualmente a lógica de reescrita em sua configuração Nginx.

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

Defina essa anotação no campo metadata.annotations da definição de recurso do seu Ingress. Um exemplo de trabalho completo é fornecido na próxima seção.

Configurando seus hosts

Você deve adicionar sua configuração de host do Ingress da maneira usual. Você só precisa de uma linha host. Use o domínio “www” aqui – o Nginx Ingress manipulará automaticamente o redirecionamento do domínio simples. Se preferir, você pode escrever o domínio simples. O Nginx Ingress irá então redirecionar para ele, de www.

Adicione o restante da configuração de ingresso abaixo da linha host. Você precisará indicar o caminho HTTP para servir (geralmente /) e o serviço para o qual rotear o tráfego.

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 exemplo de trabalho mínimo deve permitir que você veja o redirecionamento em ação. Visitar o domínio simples o levará imediatamente para “www”. Você pode ter certeza de que os usuários interagem com seu site por meio de um único ponto de entrada, mesmo que haja dois hosts de entrada possíveis.

Adicionando suporte HTTPS

O manifesto mostrado acima não oferece suporte para HTTPS. Em um cenário real, você quase certamente desejará garantir que todos os seus hosts de entrada sejam cobertos por um certificado TLS.

Fazer o HTTPS funcionar com essa configuração exige que você adicione seus dois hosts a um único certificado TLS. Aqui está um manifesto atualizado com suporte a 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

Com apenas mais cinco linhas de YAML, agora você deve ter HTTPS funcionando em ambos os hosts de entrada possíveis. Isso pressupõe que você tenha um emissor de certificado ativo em seu cluster – estamos usando letsencrypt-prod, fornecido pelo cert-manager. Você deve seguir a documentação para instalar o cert-manager se não houver um controlador de certificado disponível.

Você também pode escolher um controlador de certificado alternativo. Você precisaria atualizar a anotação de entrada cluster-issuer com o nome de um emissor fornecido pelo seu controlador. Você não precisará alterar a seção tls do manifesto – isso funcionará com todos os controladores de certificado do Kubernetes.

Tornando o domínio uma variável

Podemos converter o manifesto em um gráfico do Helm para evitar a repetição do nome do domínio. Neste exemplo, assumiremos que seu nome de domínio está definido como ingressDomain no values.yaml do gráfico do 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

Se você precisar alterar seu nome de domínio, agora só precisará atualizar o valor em um local. Isso também permite o uso do manifesto em ambientes de CI. Seu servidor CI pode usar seu gráfico para criar um novo ambiente de preparação para cada ramificação, criando um domínio dinâmico (por exemplo, my-branch.example.com) para definir como ingressDomain .

Manipulando Ambientes de Desenvolvimento

Agora temos um redirecionamento www funcionando! Você pode parar aqui e implantar em produção, se desejar, pois o objetivo principal deste tutorial foi alcançado.

Dito isso, existem alguns problemas com a abordagem que mostramos, principalmente ao trabalhar em ambientes de desenvolvimento de CI. Atualmente, cada ambiente teria www anexado ao seu domínio original.

Uma maneira de resolver isso é substituir ingressDomain por duas variáveis independentes:

ingressBase – seu domínio base, por exemplo example.com
ingressDomain – o domínio usado atualmente, para esta implantação, por exemplo minha-branch.example.com

Você pode usar as comparações de variáveis do Helm para habilitar o redirecionamento www apenas quando estiver em um ambiente de produção.

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

Ao implantar para produção, defina ingressDomain para o domínio base – ele deve ter o mesmo valor que ingressBase. A condição if será correspondida, então a entrada www será criada.

Ao implantar em um ambiente de subdomínio, os valores diferentes de ingressDomain e ingressBase desativarão o www-redirect.

Conclusão

O redirecionamento de um domínio simples para o subdomínio “www” é uma expectativa fundamental de muitos sites voltados para o público. Usando o Nginx Ingress, você pode aplicar esse comportamento tradicional às suas cargas de trabalho em contêiner implantadas na nuvem.

Adicione a anotação ao seu recurso de entrada e certifique-se de que ambos os hosts estejam listados em suas especificações. Termine verificando se o par também está listado em qualquer certificado TLS. Os usuários nunca devem falar com um terminal não seguro, mesmo que sejam redirecionados para fora dele.