¡Participa de la Maratón Behind the Code, la competencia de programación más desafiante! Inscríbete aqui

Como usar un dominio personalizado con mi aplicación desplegada en RedHat OpenShift

Con frecuencia cuando implementamos una aplicación accesible mediante un dominio nos encontramos con la limitación de utilizar un dominio predefinido por nuestro proveedor. No resulta trivial la implementación de un dominio personalizado. Para ello es necesario conocer como funcionan distintas tecnologías y servicios.

Al finalizar este tutorial, podrás comprender como se vinculan los siguientes componentes:

  • Ruta personalizada (ej. www.miapp.com)
  • Certificados SSL
  • Servicios DNS

Si bien utilizamos Red Hat OpenShift en IBM Cloud para el despliegue de la aplicación, el mismo patrón aplica a cualquier plataforma que permita la creación de rutas (kubernetes, cloud foundry, etc), siempre que se tenga acceso a un servicio de DNS que habilite la creación de registros de tipo CNAME.

Requisitos

  1. Acceso a un cluster Red Hat OpenShift
  2. Aplicación desplegada y accesible
  3. Dominio personalizado y acceso a consola para gesión de DNS

Esquema del Tutorial

  1. Gestión de certificados SSL en Red Hat OpenShit.
  2. Creación de ruta personalizada.
  3. Configuración de servicio DNS.

Gestión de certificados SSL en Red Hat OpenShit

NOTA: Estos pasos son requeridos para segurizar la URL de la aplicación (https://) y evitar bloqueos de los navegadores o aplicaciones de antivirus.

Para obtener un dominio personalizado y seguro, es decir, accesible mediante el protocolo https es necesario gestionar de alguna manera un certificado SSL que valide el origen del sitio. Esta tarea puede realizarse en forma manual, más no es recomendable. El proceso de implementación de certificados es engorroso y debe realizarse periódicamente en tanto es necesario renovar dichos certificados.

Para el caso de Red Hat OpenShift, el equipo interno de Red Hat desarrolló un controlador (algo así como un robot) que se encarga de generar y renovar certificados de manera automática. Para ello utiliza el protocolo ACME (Automated Certificate Management Environment) en su versión 2.

A continuación, los pasos para realizar el paso 1 del patrón, es decir, la implementación de ACME para la gestión de certificados SSL:

Clonar repositorio

Realizar una copia local (clon) de openshift-acme. En un terminal, ejecutar:

git clone https://github.com/tnozicka/openshift-acme.git

NOTA: Es posible realizar la instalación directa desde git, para mas información sobre esta posibilidad visitar el sitio del desarrollador incluido al final del documento.

Deplegar ACME

Antes de ejecutar los comandos para implementar acme, es necesario registrarse (acción de login) en el cluster. Si no tiene tus credenciales a mano, recuerda que puedes obtenerlas desde la pestaña Access dentro de los detalles de tu cluster, donde dice oauth token request page

Screenshot de página mostrando el acceso al cluster

Una vez que nos registramos continuamos con el despliegue mediante los comandos de openshift


oc apply y oc create:
oc apply -fdeploy/cluster-wide/{clusterrole,serviceaccount,issuer-letsencrypt-live,deployment}.yaml

oc create clusterrolebinding openshift-acme --clusterrole=openshift-acme --serviceaccount="$( oc project -q ):openshift-acme" --dry-run -o yaml | oc apply -f -

NOTA: Este despliegue funcionara dentro del proyecto reservado para controladores de sistema default. Y estará disponible para todo los projectos. No es necesario realizar este paso cada vez.

Verificar logs

Para verificar que el estado del controlador ACME, buscamos dentro de nuestro cluster, el proyecto default, y luego revisamos los logs de los pods que contienen openshift-acme en su nombre. El status de estos pods debe ser running:

Screenshot de página mostrando los Pods de OpenShifht-ACME

Creación de ruta personalizada

Para la creación de la ruta personalizada es necesario acceder al dashboard de administración de Red Hat Openshift. Seleccionar el proyecto en que se encuentra la aplicación. Sobre el menu de la izquierda eleguir la sección Project, luego acceder a Routes y luego elegir Create Route

Screenshot de página mostrando el inventario de proyectos

La ruta se configura de la siguiente manera:

  • Name: Es sólo un nombre de referencia, puedes ingresar algo como «miapp»
  • Hostname: Este el dominio personalizado que deseas utilizar. Por ejemplo «www.miapp.com»
  • Path: No modificar a menos que sepas lo que estás haciendo.
  • Service: Aquí seleciona el servicio de tu aplicación.
  • Target Port: Debes elegir 8080->5000 (TCP) o similar. Es el puerto expuesto por el servicio de tu aplicación. Problemente puedas elegir solo uno. Si no aparece nada, significa que tu aplicación no es accesible por fuera del cluster.
  • Security: Marca Secure route, y aparecen dos opciones mas.
  • TLS Termination: Edge
  • Insecure Traffic: Allow redirect

El resto de la información relacionada a certificados la completará luego el controlador ACME.

Presionar Create.

Una vez creada la ruta es necesario agregar una annotation para que esta sea gestionada, en sus certiciados SSL, por el controlador ACME. Para esto, se agrega una anotación en la metadata de nuestra ruta. Este paso se puede realizar en forma manual, editando el yaml de la ruta e ingresando la siguiente información:


metadata:
  annotations:
    kubernetes.io/tls-acme: 'true'

O puede usar el editor web y agregarla de la siguiente manera:

Screenshot de página mostrando el editor web

Finalmente, en las mismas propiedades de la ruta, toma nota del Router Canonical Hostname.

Screenshot de página mostrando el Router Canonical Hostname

Configuración de servicio DNS

Ahora toca vincular nuestra aplicación con el dominio personalizado. Esto occure mediante la creación un registro CNAME, que hace de indice, y vincula a nuestro dominio con nuestro cluster. Para ello necesitamos obtener el canonical name de nuestro cluster. Si no tomaste nota en el paso previo, lo puedes obtener desde la ruta tu consola de administración.

Por ejemplo, si accedes a tu consola mediante:


https://miconsola.ig-cp4apps-717122-26562a7d6831df3dfa02975385757d2d-0000.us-south.containers.appdomain.cloud/dashboards

Tu canonical name es todo lo que se encuentra entre https://miconsola y /dashboards. Para este ejemplo sería ig-cp4apps-717122-26562a7d6831df3dfa02975385757d2d-0000.us-south.containers.appdomain.cloud.

Con este dato a mano, accede a tu consola de adminsitración de DNS. Independientemente del servicio utilzado (GoDaddy, Domain.com, Heroku, etc), el objetivo es el mismo: la creación de un registro CNAME.

En este ejmplo yo utilizaré el servicio de IBM Cloud, mediante el cual adquirí mi dominio personalizado.

Screenshot de página mostrando el sitio de configuración del DNS

El registro se crea de la siguiente manera:

  • Resource Type: CNAME
  • Host: *
  • Points To: cluster cannonical name_.*
  • TTL: 900 (15min): Puede desar el valor por defecto.

Siguiente el ejemplo anterior, el valor de Points To sería:


ig-cp4apps-717122-26562a7d6831df3dfa02975385757d2d-0000.us-south.containers.appdomain.cloud.

NOTA: Importantísimo incluir el punto del final.

Una vez creado el registro hay que dar tiempo a la dispersión del dominio a travéz de los servidores DNS. Es normal una demora de hasta 2hs, aunque en ocasiones se aconseja esperar hasta 24hs.

¡Listo! Una vez realizado este pattern tiene un dominio listo para ser utilizado para tanas aplicaciónes como desees. El único paso a reiterar cada vez, es la anotación en la ruta para que el controlador ACME se encarge de la gestión de certificados ACME.

Pero tanto la instalación del controlador, como la creación del registo CNAME son tareas ¡de una sola vez!

Información Adicional

Algunas fuentes de información que usaré para este code pattern son los siguientes.

License

This code pattern is licensed under the Apache License, Version 2. Separate third-party code objects invoked within this code pattern are licensed by their respective providers pursuant to their own separate licenses. Contributions are subject to the Developer Certificate of Origin, Version 1.1 and the Apache License, Version 2.

Apache License FAQ