Como redirecionar para "www" com Nginx Ingress

Com frequência, você desejará implantar um aplicativo da web na raiz do seu domínio, bem como o diretório “ www ” subdomínio. Isso ajuda os usuários a descobrirem seu serviço. O Nginx Ingress tem suporte integrado para o procedimento.

Veja aqui como implantar uma carga de trabalho com dois hosts de entrada, “ www ” e seu domínio vazio. Qualquer pessoa que visite “ www ” continuará normalmente. Os visitantes da raiz do domínio serão redirecionados para a página “ www ” subdomínio. Ao usar um redirecionamento, você reduz o risco de que ambos os endpoints apareçam nos resultados da pesquisa.

Usando a anotação

O Nginx Ingress fornece uma anotação do Kubernetes que permite configurar esse comportamento. Adicionar a anotação ao 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 esta anotação no campo metadata. annotations do seu Ingress &’ definição de recursos. 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 de host. Use o “ www ” domínio aqui – O Nginx Ingress tratará automaticamente o redirecionamento do domínio vazio. Se preferir, você pode escrever o domínio simples. O Nginx Ingress irá então redirecionar para ele, fromwww.

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

apiVersion: networking.k8s. io/v1beta1 kind: Metadados de entrada: nome: my-ingress namespace: my-namespace anotações: kubernetes. io/ingress. class: nginx-ingress nginx. ingress. kubernetes. io/from- para redirecionar para www: " verdadeiro " especificações: regras: - host: www. example. com http: caminhos: - caminho: / backend: serviceName: my-service servicePort: 80

Este exemplo mínimo de trabalho deve permitir que você veja o redirecionamento em ação. A visita ao domínio simples o levará imediatamente para “ www ” em vez de. Você pode ter certeza de que os usuários interagem com o 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 tem 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.

Para que o HTTPS funcione com esta configuração, é necessário adicionar os dois hosts a um único certificado TLS. Aqui está um manifesto atualizado com suporte TLS:

apiVersion: networking.k8s. io/v1beta1 kind: Metadados de entrada: nome: my-ingress namespace: my-namespace anotações: kubernetes. io/ingress. class: nginx-ingress certmanager.k8s. io/cluster-issuer: letsencrypt-prod nginx. ingress. kubernetes. io/from-to-www-redirect: " true " especificações: regras: - host: www. example. com http: caminhos: - caminho: / backend: serviceName: my-service servicePort: 80 tls: - hosts: - example. com - www. example. com secretName: ingress-tls -secreto

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ê &’ possui um emissor de certificado ativo em seu cluster – estamos usando o letsencrypt-prod, fornecido pelo cert-manager. Você deve seguir a documentação para instalar o cert-manager se não houver nenhum controlador de certificado disponível.

Você também pode escolher um controlador de certificado alternativo. Você precisaria atualizar a anotação de entrada do emissor do cluster 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 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 de domínio. Neste exemplo, vamos presumir que seu nome de domínio está definido como ingressDomain nos valores do Helm chart. 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 " especificação: regras: - host: & # 123; & # 123; imprimir " www. " . Values. ingressDomain & # 125; & # 125; http: caminhos: - caminho: / backend: serviceName: my-service servicePort: 80 tls: - hosts: - & # 123; & # 123; imprimir . Values. ingressDomain & # 125; & # 125; - & # 123; & # 123; imprimir " www " . Values. ingressDomain & # 125; & # 125; secretName: ingress-tls-secret

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

Gerenciando ambientes de desenvolvimento

Agora temos um redirecionamento de www funcionando! Você pode parar aqui e implantar na produção se quiser, 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 prefixado 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, meu-branch. example. com

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

especificações: regras: & # 123; & # 123; if eq . Values. ingressDomain . Values. ingressBase & # 125; & # 125; - host: & # 123; & # 123; imprimir " www. " . Values. ingressDomain & # 125; & # 125; & # 123; & # 123; mais & # 125; & # 125; - host: & # 123; & # 123; imprimir . Values. ingressDomain & # 125; & # 125; & # 123; & # 123; fim & # 125; & # 125; http: caminhos: - caminho: / backend: serviceName: my-service servicePort: 80 tls: - hosts: - & # 123; & # 123; . Values. ingressDomain & # 125; & # 125; & # 123; & # 123; if eq . Values. ingressDomain . Values. ingressBase & # 125; & # 125; - & # 123; & # 123; imprimir " www. " . Values. ingressDomain & # 125; & # 125; & # 123; & # 123; fim & # 125; & # 125; secretName: & # 123; & # 123; . Values. ingressTlsSecret & # 125; & # 125;

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 o ingresso www será criado.

Quando você está implantando em um ambiente de subdomínio, os diferentes valores de Domínio de entrada e Base de entrada desabilitarão o redirecionamento www.

Conclusão

Redirecionando de um domínio vazio para o “ www ” subdomínio é uma expectativa fundamental de muitos sites voltados ao público. Usando o Nginx Ingress, você pode aplicar esse comportamento tradicional às suas cargas de trabalho em contêineres 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. Conclua verificando se o par também está listado em qualquer certificado TLS. Os usuários nunca devem falar com um endpoint desprotegido, mesmo que sejam redirecionados para longe dele.