Año nuevo, serie nueva 😝 y es que estos días he estado entreteniéndome con OpenShift, a mi modo, viendo cómo empezar a usar esta plataforma a partir de un ejemplo, mi Tour of heroes. Hoy quiero compartir contigo el primer artículo de esta serie por si tú también quieres aprender sobre ello.

¿Qué es Openshift?

Si te ha tocado trabajar con contenedores o Kubernetes es muy probable que hayas oído hablar de OpenShift, pero quizás no tengas claro qué es lo que significa o porque debes saber sobre ello. Si vienes de Kubernetes te habrás dado cuenta de que este es súper potente, pero requiere que tengas conocimientos avanzados en diferentes áreas, como en redes y seguridad para “hacer las cosas bien”. OpenShift es la propuesta de Kubernetes de Red Hat, la cual te da una capa por encima de tu clúster, ayudándote a gestionar estos aspectos avanzados, además de una rica interfaz. Son muchas las empresas que optan por este modelo, con el objetivo de asegurarse un correcto uso de Kubernetes, además del respaldo de Red Hat y no solamente de la comunidad. Este, obviamente, es de pago aunque en este artículo quiero mostrarte cómo montar un entorno de desarrollo sin coste alguno para ti.

Entorno de desarrollo de OpenShift 4.x con CodeReady Containers

Si bien en la versión 3.x de OpenShift se utilizaba minishift como entorno de desarrollo, en la versión 4.x tenemos CodeReady Containers o CRC. Para poder descargarlo primero debes crearte una cuenta de Red Hat a través de este enlace, lo cual es totalmente gratuito. Una vez la tengas podrás descargar el instalador para tu sistema operativo en este otro enlace.

En la misma página, copia también el pull secret, el cual se te pedirá al ejecutar el segundo de estos dos comandos:

# setup local cluster
crc setup
# start local cluster
crc start

Este proceso puede llevar unos minutos. Cuando finalice verás algo como esto:

Started the OpenShift cluster.
The server is accessible via web console at:
  https://console-openshift-console.apps-crc.testing
Log in as administrator:
  Username: kubeadmin
  Password: 87z5d-wG6Sf-iEPMX-sMnhQ
Log in as user:
  Username: developer
  Password: developer
Use the 'oc' command line interface:
  $ eval $(crc oc-env)
  $ oc login -u developer https://api.crc.testing:6443

Como puedes ver, se han generados dos usuarios: un administrador y un desarrollador. Podemos decir que son los dos tipos principales y en base a estos dos roles se reparte incluso la interfaz web. También se ha descargado oc, nuestro kubectl en OpenShift, que a través de eval se configura como parte de la variable de entorno PATH para poder usarlo cómodamente en el terminal actual.

Aplicación de ejemplo

Ahora que ya tienes un clúster en local, lo siguiente es desplegar una aplicación de ejemplo. Para ello, voy a volver a apoyarme en mi Tour of heroes, con unos manifiestos que cree para Kubernetes (ligeramente modificados), que puedes encontrar en este repo de GitHub. Mi objetivo va a ser desplegarlos, sin errores, y acceder a la aplicación de la misma forma que lo haría en un clúster de Kubernetes sin OpenShift.

Lo primero que voy a hacer es iniciar sesión con el usuario developer:

# configure oc command
eval $(crc oc-env)
# login as developer
oc login -u developer https://api.crc.testing:6443

En esta plataforma se trabaja por proyectos (que en realidad son nuestros namespaces de Kubernetes), por lo que creamos uno para alojar nuestros recursos:

# Create a new project
oc new-project tour-of-heroes

Ahora, al igual que lo haría con kubectl, utilizo oc para desplegar los manifiestos de mi ejemplo:

# Deploy resources in a project
oc create -f tour-of-heroes/ --recursive

No hace falta indicar el namespace proyecto, ya que una vez creado/seleccionado todas las operaciones se hacen sobre él. Cuando ejecutes este comando verás algunos avisos relacionados con algunos de los recursos que estás desplegando:

Esto es así porque OpenShift viene de base con lo que se conoce como Security Context Constraints o SCC, que comentaré más abajo. Para ver el estado de lo desplegado puedes usar el siguiente comando:

# Check project status
oc status

En este caso comprobarás que algo no va bien:

Si revisas los logs del despliegue de tour-of-heroes-web comprobarás que estos están intentando crear un archivo en el sistema de ficheros (el comentado en este artículo anterior) y no tienen permiso:

oc logs deploy/tour-of-heroes-web

El error es como el que sigue:

Dentro de los constraints existen diferentes configuraciones. Para saber cuál es la que está afectando puedes usar oc adm policy scc-subject-review de la siguiente forma:

oc get pod -l app=tour-of-heroes-web -o yaml | oc adm policy scc-subject-review -f -

Esto nos devolverá algo como lo siguiente:

Restricted-v2 es el grupo por defecto y el más restrictivo que viene de caja, al menos en la versión 4.11, que es la actual en el momento de este artículo. Si quisieras cambiarlo debes iniciar sesión como administrador, crear una service account, asociar el SCC que quieres que aplique sobre esta y utilizar la misma con tu despliegue:

# Login as kubeadmin
oc login -u kubeadmin -p 87z5d-wG6Sf-iEPMX-sMnhQ https://api.crc.testing:6443
# Create service account
oc create sa tour-of-heroes-sa
# Add anyuid security context
oc adm policy add-scc-to-user anyuid -z tour-of-heroes-sa
# Assign sa to the deployment
oc set sa deploy tour-of-heroes-web tour-of-heroes-sa

Si vuelves a comprobar verás que ahora todo está en estado Running.

La otra opción, en muchas ocasiones la recomendada, será ceñirte a las restricciones que te dan estas reglas para cumplir con los mínimos de seguridad definidos por la empresa. Sin embargo, para este ejemplo, solo quería que supieras que existen y que son ajustables.

Routes en OpenShift

Para terminar con el artículo de hoy lo último que quiero conseguir es poder acceder a la API de Tour of heroes y al frontal web. Si recuperas los objetos Service generados son todos del tipo ClusterIP, es decir que sólo se puede acceder a ellos desde dentro del clúster:

# Get services
oc get services

En OpenShift existe el concepto de rutas (Routes) que nos recuerda a las reglas de Ingress en Kubernetes, pero sin tener que instalar ningún Ingress Controller. Para exponer tanto la API como la web puedes lanzar lo siguiente:

# Expose services
oc expose service tour-of-heroes-web -l route=external --name=tour-of-heroes-web
oc expose service tour-of-heroes-api -l route=external --name=tour-of-heroes-api

Con este otro comando puedes recuperar las rutas generadas:

# See routes
oc get routes

En CodeReady Containers el dominio proporcionado es *.apps-crc.testing (configurado de manera automática para ti en el /etc/hosts de tu máquina), por lo que puedes acceder a lo expuesto a través de estas URLs:

# Call services
curl http://tour-of-heroes-web-tour-of-heroes.apps-crc.testing
curl http://tour-of-heroes-api-tour-of-heroes.apps-crc.testing/api/hero

Puedes utilizar este archivo para incluir algunos héroes en la base de datos a través de la API y comprobar que funciona correctamente.

Todo lo comentado en este artículo puedes visualizarlo de una forma muy rica a través de la interfaz web, la cual puedes lanzar ejecutando este comando:

# Launch web UI
crc console

o bien a través de https://console-openshift-console.apps-crc.testing, que aparecía como resultado de ejecutar crc start.

Para eliminar el proyecto puedes hacerlo así:

# Delete project
oc delete project tour-of-heroes

Y, por último, si quieres parar o eliminar el clúster completo estos dos comandos son los que necesitas:

# stop cluster
crc stop
# delete cluster
crc delete

¡Saludos!