Gestionando despliegues con Openshift 3 y Kubernetes

19 de marzo de 2018

En este post vamos a mostrar cómo desplegar una pequeña aplicación web (dos microservicios con una base de datos) sobre la plataforma Openshift 3, basada en Docker y Kubernetes.

Desplegaremos la misma aplicación que hicimos sobre Minikube en un anterior blog, y que podéis consultar aquí: https://blog-es.mimacom.com/introduccion-a-kubernetes-y-minikube/ .

Nota: recomiendo revisar el anterior post, antes de seguir leyendo este, ya que en esta entrada se asumen conocimientos mínimos de Kubernetes.

Openshift Online 3

Openshift desde su última versión (3) ha evolucionado por completo a una herramienta basada en Kubernetes (https://docs.openshift.com/enterprise/3.1/release_notes/v2_vs_v3.html), proveyendo un panel de control propio y extensiones a los elementos de Kubernetes, pero manteniendo su base y la mayoría de sus elementos. En esta versión estaremos desplegando nuestras aplicaciones usando pods, servicios y reglas Ingress (llamadas Routes en Openshift).

Las principales ventajas que nos ofrece Openshift son:

Para empezar a trabajar con Openshift podemos crear una cuenta gratuita aquí: https://manage.openshift.com/, aunque con recursos bastante limitados (con algunas dificultades en replicación, teniendo que limitarnos a una réplica por servicio), pero suficientes para empezar a trabajar.

Resumiendo, nuestro objetivo será:

Sencillo, pero suficiente para hacernos una idea de Openshift.

¡Manos a la Obra!

Instalando Mysql Server

Para instalar un producto de terceros en Openshift, lo mejor es confiar en un catálogo ya precargado con configuraciones de despliegue de todos los productos. Para ello, desde nuestra vista principal del proyecto en Openshift pulsamos en “Add to Project” ⇒ “Browse Catalogue” y después seleccionamos “Mysql”.

Una vez seleccionado tendremos que especificar algunas configuraciones:

Hemos usado ese nombre de servicio y usuario/contraseña porque nuestras imágenes Docker tienen esta configuración:

Una vez que esté todo configurado, pulsamos en “Create” y a continuación, podemos echar un vistazo a lo que Openshift ha creado para nosotros.

Mysql – Configuración de despliegue

En la sección de despliegues observamos cómo Openshift ha creado un nuevo despliegue de Mysql con una réplica.

Podemos ver los detalles pulsando en su nombre:

En la primera pestaña vemos el histórico de versiones del despliegue y la versión actual en funcionamiento.

El trigger por defecto “Config Change” hará que se despliegue una nueva versión al cambiar la configuración. Por defecto, las nuevas versiones se realizan sin parar la instancia de antiguas versiones hasta que las nuevas han completado su despliegue. Sin embargo, si no hay recursos suficientes, este comportamiento puede ocasionar problemas, obligando a parar y arrancar las versiones a mano para poderlos solucionar.

En la pestaña de configuración podemos ver información relevante del despliegue, como la imagen Docker usada, la memoria asignada (que debería ser la misma que configuramos en el paso anterior), el volumen persistente asignado, etc.

En la pestaña de eventos podemos ver todos los eventos relacionados con nuestro despliegue, lo que es muy útil para resolución de problemas, ya que todos los problemas de estabilidad, arranques o paradas se escribirán aquí.

Mysql – Volumen persistente

Podemos ver que Openshift ha creado un nuevo volumen persistente y se ha encargado de asignárselo al pod de Mysql.

Mysql – Servicio

Así mismo, se ha encargado de crear un servicio sin acceso desde el exterior que será expuesto a nuestras aplicaciones.

Con esto tenemos todo lo que necesitamos para comenzar a desplegar nuestras aplicaciones SpringBoot.

Desplegando aplicaciones SpringBoot

Ya que el proceso es idéntico para ambas, tomaremos como ejemplo el microservicio de productos:

Si la imagen existe en DockerHub Openshift la encontrará y nos mostrará el formulario de configuración:

Nota: Hemos cambiado las “Labels” por defecto.

Aplicación SpringBoot – Configuración de despliegue y Pods

Podemos ver los pods que han creado para nuestra aplicación pulsando en “Pods”.

Una vez nuestra aplicación se haya desplegado correctamente, podemos ver en sus detalles toda la configuración relevante, así como la plantilla usada para crear los pods asociados.

La plantilla usa nuestra imagen Docker.

Al pulsar en “logs” podemos ver el caralina.out y visualizar cómo ha ido el arranque de nuestra aplicación.

Un aspecto que nos llama la atención en la configuración es que por defecto se han reservado 500m para la aplicación, esto es algo que tenemos que cambiar, si queremos posteriormente, desplegar otro servicio.

Recordamos que tenemos que encajar Mysql y dos aplicaciones en un GB de RAM. Para editar esto debemos dirigirnos a la configuración de despliegue, pulsando en “deployments” ⇒ “Product Service” ⇒”Configuration”.

Aquí mismo vemos que además de tener que configurar la memoria disponible, deberíamos añadir algunos “Health Checks” a nuestra aplicación para ayudar a Openshift con su monitorización. Para ello pulsamos en “Add Health Checks”.

Hemos añadido una simple petición GET a /health. Una vez que pulsemos en “Save”, podemos ir a la sección de histórico de nuestra aplicación para ver que un nuevo despliegue está ocurriendo, ya que hemos cambiado la configuración.

La antigua versión no se parará hasta que la nueva se haya completado. Posiblemente esto fallará, ya que ambas versiones están configuradas para usar 500m y solo quedan 756 tras usar Mysql. Si esto ocurre debemos parar a mano el antiguo despliegue, pulsando en “actions” ⇒ “delete” dentro de la configuración de despliegue y quizás iniciando un nuevo despliegue, si el nuevo no se relanza automáticamente.

Estos problemas no ocurren en entornos con sobrados recursos, aunque es interesante conocer las posibles limitaciones y problemas que pudieran ocurrir si se trabaja con recursos limitados. En cualquier caso, podemos evitar estos problemas pulsando en “Pause rollouts” en el menú de acciones hasta que hayamos finalizado la configuración. Si hacemos esto último al acabar, deberíamos parar manualmente la antigua versión, moviendo sus réplicas a 0, e iniciar la nueva, pulsando en “resume rollouts”.

Una vez configurado el “health check”, pasamos a configurar la memoria disponible. En la configuración de despliegue pulsamos en “Actions” ⇒ ”Edit resources”. Después podremos limitar nuestra aplicación a 350m, lo que nos permitirá desplegar otra aplicación después.

En el histórico de versiones podemos ver cómo ha añadido nuestra nueva versión tras los cambios.
En este ejemplo se ha usado el mecanismo Pause rollouts ⇒ Resume rollouts).

Y podemos ver nuestro nuevo pod, donde se reflejan los cambios de configuración.

Aplicación SpringBoot – Servicio

Para ver el servicio creado por Openshift podemos pulsar en “Services”⇒ “productservice”.

Podemos ver que nuestro servicio está mapeando el puerto 8080 al 8080, lo cual no es correcto. Queremos mapear 80 a 8080, y no está exponiendo nuestro servicio al exterior. Para solucionar esto tendremos que crear una ruta.

Empezaremos configurando el servicio y cambiando el mapeo de puertos. Para ello tendremos que editar el fichero YAML, pulsando en “Actions”⇒”Edit YAML”.

apiVersion: v1

kind: Service

metadata:

annotations:

openshift.io/generated-by: OpenShiftWebConsole

creationTimestamp: '2017-12-03T18:20:28Z'

labels:

app: productsPod

name: productservice

namespace: test-kubernetes

resourceVersion: '220894315'

selfLink: /api/v1/namespaces/test-kubernetes/services/productservice

uid: a3822fb3-d856-11e7-9701-02ac3a1f9d61

spec:

clusterIP: 172.30.147.69

ports:

- name: 8080-tcp

port: 80

protocol: TCP

targetPort: 8080

selector:

app: productsPod

sessionAffinity: None

type: ClusterIP

status:

loadBalancer: {}

Después de esto vamos a crear una nueva ruta, pulsando en “Actions”⇒”Create route” con la configuración por defecto.

Una vez hecho esto, tendremos una url autogenerada a nuestro servicio y podemos acceder por url para comprobar si está funcionando.

Finalizando:

Una vez desplegada nuestra aplicación SpringBoot deberemos desplegar la otra, usando la imagen “abenitezsan/customerservice“, siguiendo exactamente los mismos pasos.

Como resultado tendremos nuestras dos aplicaciones expuestas al exterior, ocupando prácticamente el 100% de recursos asignados a nuestra cuenta.

Para finalizar, las urls de las dos aplicaciones desplegadas como ejemplo de esta entrada:

http://customerservice-test-kubernetes.193b.starter-ca-central-1.openshiftapps.com
http://productservice-test-kubernetes.193b.starter-ca-central-1.openshiftapps.com

Sobre el autor: Adolfo Benítez
Comments
Únete a nosotros