Gestionando despliegues con Openshift 3 y Kubernetes
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:
- El panel de control: Openshift ha creado una gran Interfaz para manejar Kubernetes. Seguimos teniendo la opción de configurar Kubernetes a través de ficheros YAML, pero en la mayoría de las acciones podremos prescindir de ellos. A lo largo de esta entrada mostraremos cómo realizar toda la instalación, reduciendo al mínimo la edición de los ficheros YAML de configuración.
- Administración de RED y Servidores: No tendremos que preocuparnos en saber cuántos servidores necesitamos, simplemente pediremos recursos a Openshift en total y él se encargara de proporcionarlos, alojando las máquinas que sean necesarias.
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á:
- Instalar Mysql
- Desplegar dos microservicios basados en SpringBoot desde DockerHub , disponibles aquí : https://hub.docker.com/r/abenitezsan/.
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:
- Memory Limit: 256M de memoria son suficientes para nuestras pequeñas aplicaciones.
- ServiceName: Es el nombre del servicio de Kubernetes que se creará. Usaremos “mysql”.
- Username/password: springboot/springboot
- MySQL Database Name: “kubernetesDemo”
- Volume Capacity:”1gb” es lo máximo que podremos darle en nuestra cuenta gratuita. Esto se encarga de crear el volumen persistente y el claim asociado a él.
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:
- Lo primero es asegurarnos que la imagen sigue viva en el repositorio, entrando en https://hub.docker.com/r/abenitezsan/productservice/ .
- Una vez que hemos comprobado que sigue correcta, establecemos el nombre de nuestra imagen para Openshift, que será una composición del repositorio y el nombre de la imagen Docker “abenitezsan/productservice“.
- Para añadirla a Openshift, pulsamos de nuevo en “Add to project”, “Deploy Image” y después escribimos el nombre de nuestra imagen.
Si la imagen existe en DockerHub Openshift la encontrará y nos mostrará el formulario de configuración:
Nota: Hemos cambiado las “Labels” por defecto.
- Después de pulsar en “deploy” podemos ver que un nuevo servicio y un despliegue han sido creados.
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