Rotas

Início
Criando Rotas

Início

Uma rota do OpenShift expõem um serviço em um hostname, como www.example.com, então clientes externos podem acessa-lo pelo nome.

A resolução DNS para um hostname é tratada separadamente do roteamento; seu administrador deve ter configurado um domínio publico que sempre resolve para a rota do OpenShift, ou se estiver usando um hostname diferente, você deve modificar os registros DNS para resolver para a rota.

Criando Rotas

Em nosso Console Web você pode administrar suas rotas ou domínios clicando em "Domínios e SSL" como na imagem abaixo:

Por padrão a Getup já fornece um domínio para seu projeto "app-projeto.getup.io", assim fica bem mais fácil de testar suas aplicações web, e você pode acessar suas aplicações de backend apenas com o nome da aplicação, facilitando ainda mais a integração entre os serviços.

Criando Rotas via CLI

Usando a CLI, você pode criar tanto rotas seguras como inseguras. No exemplo a seguir, uma rota insegura vai ser criada:

$ oc expose svc/frontend --hostname=www.example.com

A nova rota vai herdar o nome do serviço a menos que você especifique um, utilizando a flag --name.

Exemplo 1. Definição do YAML para criar a rota insegura acima

apiVersion: v1
kind: Route
metadata:
 name: frontend
spec:
 host: www.example.com
 to:
   kind: Service
   name: frontend

Rotas inseguras são a configuração default e são as mais simples de configurar. Porem, rotas seguras oferecem conexões privadas. Para criar uma rota segura HTTPS encriptada com uma chave e certificado (arquivos no formato PEM que você deve gerar e assinar separadamente), você pode usar o comando create route e opcionalmente prover o certificado e a chave. Para mais informações de rotas seguras, leia este artigo.

O TLS é o substituto do SSL para HTTPS e outros protocolos encriptados.

$ oc create route edge --serviec=frontend --cert=${MASTER_CONFIG_DIR}/ca.crt --key=${MASTER_CONFIG_DIR}/ca.key --ca-cert=${MASTER_CONFIG_DIR}/ca.crt --hostname=www.example.com

Exemplo 2. Definição do YAML para criar a rota segura acima

apiVersion: v1
kind: Route
metadata:
 name: frontend
spec:
 host: www.example.com
 to:
 kind: Service
 name: frontend
 tls:
 termination: edge
 key: |-
 -----BEGIN PRIVATE KEY-----
 [...]
 -----END PRIVATE KEY-----
 certificate: |-
 -----BEGIN CERTIFICATE-----
 [...]
 -----END CERTIFICATE-----
 caCertificate: |-
 -----BEGIN CERTIFICATE-----
 [...]
 -----END CERTIFICATE-----

Você pode criar rotas seguras sem especificar uma chave e certificado, neste caso o certificado de rotas default vai ser usado para terminações do TLS.

Terminação TLS no OpenShift depende do SNI para fornecer certificados customizados. Qualquer dado não-SNI recebido na porta 443 é tratado com terminação TLS e um certificado padrão, que pode não coincidir com o hostname solicitado, resultando em erros de validação.

Para mais informações sobre os tipos de terminações TLS, assim como roteamento baseado em caminhos estão disponíveis na seção de Arquitetura.