Arquitectura basada en microservicios Parte 3

  • En el post (Arquitectura basada en microservicios Parte 2) continuamos con el modelo de implementación para una un sistema que seguía el nuevo estilo arquitectural basado en microservicios.
  • Ahora, en este último post vamos a describir un posible modelo de despliegue para un sistema basado en microservicios.

1 MODELO DE DESPLIEGUE

  • Para desplegar y ejecutar en entornos Cloud sistemas que siguen el estilo arquitectural basado en microservicios encaja muy bien el uso de tecnologías que sean capaces de de aislar a estos microservicios en procesos de ejecución y despliegue independientes.
  • Las virtualizaciones tradicionales de máquinas cumplen con este objetivo pero introducen sobre el sistema operativo una capa extra denominada hypervisor encargada de gestionar cada máquina virtual, además de que cada máquina virtual contiene su propio sistema operativo.
  • Ambas cosas suponen un consumo elevado de recursos de las máquinas anfitriona.
  • Los contenedores son una alternativa a las máquinas virtuales huésped para aislar y securizar las aplicaciones, pero de una forma más ligera (no cuenta con el hypervisor) lo que permite aprovechar mejor sus recursos.
  • Los contenedores ejecutan procesos ligeros dentro del sistema operativo anfitrión.

1.1 Docker

  • Docker es una plataforma de virtualización ligera y un conjunto de herramientas que nos ayudan a:
    • Aislar nuestros servicios y componentes dentro de contenedores Docker.
    • Empaquetar y distribuir los contenedores sobre nuestros entornos
    • Desplegar los contenedores en nuestro entorno productivo (Cloud)
  • Sus principales características son:
    • Aceleración del despliegue
    • Escalado sencillo
    • Permite entornos de alta densidad de servicios y carga
    • Proporciona un SaaS para compartir y manejar contenedores docker

1.1.1 Arquitectura

  • Docker usa una arquitectura cliente – servidor
  • El cliente de Docker habla con el demonio de Docker, el cual realiza las tareas pesadas de construir, ejecutar y distribuir los contenedores.
  • Tanto el cliente como el servidor Docker pueden correr en el mismo sistema y se comunican vía TCP o a través de un API RESTful.
  • El usuario nunca interactúa directamente con el demonio de Docker, siempre lo hace a través de un cliente.

  • Los componentes internos de Docker son tres:

Imágenes Docker

Plantillas de sólo lectura, por ejemplo un SO Ubuntu, una aplicación Spring Boot, etc…

Registros Docker

Se encargan de mantener las imágenes. El registro público se llama Docker Hub

Contenedores Docker

Su contenido es similar a un directorio. Contienen todo lo necesario para ejecutar una aplicación. Pueden ser ejecutados, iniciados, parados, movidos, borrados etc…

1.1.2 Aplicación de Docker al despliegue

  • Todos los componentes de infraestructura indicados en el modelo de implementación conforman uno o varios contenedor docker.
  • Cada uno de los microservicios se incorporan en un contenedor docker.

1.2 Kubernetes

  • Kubernetes es una herramienta de Google que permite pilotar los contenedores de Docker (También soporta otros tipos de contenedores como Rocket)
  • Kubernetes y Docker cumplen la promesa de trabajar en conjunto como un PaaS simplificado.
  • Mientras Docker proporciona el manejo del ciclo de vida de los contenedores, Kubernetes lo lleva al siguiente nivel, proporcionando orquestación y manejo de clusters de contenedores.
  • Una vez que instalamos Kubernetes, los desarrolladores están en disposición de subir código aplicativo a la infraestructura de contenedores Docker sin tener que preocuparse de tratar con líneas de comando, APIs, y consolas específicas de los proveedores de IaaS.
  • Para entender mejor el funcionamiento de Kubernetes junto con Docker vamos a recordar cómo funciona un IaaS en la actualidad. Los clientes del IaaS provisionan máquinas virtuales en AWS, MS Azure u otras Cloud públicas sin preocuparse por el hardware subyacente. Eligen el tipo de instancia, el sistema operativo, la localización geográfica, y una pieza software que se llama hypervisor o controlador de fábrica coordina el aprovisionamiento de las máquinas virtuales en uno de los servidores físicos dentro del centro de datos. El capa IaaS abstrae totalmente del hardware físico.
  • Cuando se aprovisionan contenedores, se repite el mismo proceso, pero en lugar de aprovisionar una nueva máquina virtual, el motor de orquestación de contenedores (Replication Controller) arranca un contenedor dentro de una máquina virtual. El orquestador de contenedores hace a las máquinas virtuales lo que el controlador de fábrica o hypervisor hace a los servidores físicos (hardware).
  • Kubernetes es capaz de lanzar contenedores en máquinas virtuales existentes o incluso aprovisionar nuevas máquinas virtuales y colocar contenedores en ellas.
  • Con Kubernetes, los administradores crean Pods, que son colecciones lógicas de contenedores Docker y que pertenecen a una aplicación.
  • Un Pod puede albergar un único contenedor, o múltiples contenedores que cooperan entre ellos, en este último caso se garantiza que los contenedores en el pod son situados en la misma máquina y pueden compartir recursos.
  • Un Pod puede también contener cero o más volúmenes, que son directorios privados al contenedor o compartidos a través de los contenedores del pod.
  • Si un contenedor del Pod se falla, puede ser automáticamente reiniciado por un agente de Kubernetes que se llama Kubelet, pero si el pod falla no es automáticamente reiniciado a menos que el usuario defina un controlador de replicación.
  • El controlador de replicación se encarga de crear las réplicas de Pods y de crear pods de reemplazo si han fallado. Define los pods en términos de plantilla que luego el sistema se encarga de instanciar.
  • El conjunto de réplicas de un pod es lo que constituiría un microservicio en nuestra sistema basado en mircroservicios.
  • Una vez que los pods son creados, Kubernetes continuamente monitoriza su “salud” y en qué máquina están ejecutándose; si un pod falla debido a problema con el software o a un problema con la máquina el controlador de replicación crea otro pod nuevo en otra máquina y mantiene el número de réplicas al nivel deseado.
  • Para facilitar a las aplicaciones basadas en microservicios, Kubernetes ofrece la abstracción de servicio, el cual proporciona una dirección IP estable y nombre DNS que corresponde al conjunto dinámico de replicas de pod que corresponden al microservicio.

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: