Infraestructura con CoreOS - Parte II

22 October 2014, Edrans DevOps team Componentes de CoreOS En esta entrega, hoy vamos a ver un poco mas en detalle las partes principales que conforman a CoreOS, que juntas proveen la base para tener una arquitectura redundante y de alta disponibilidad. Como mencionamos en Parte I, CoreOS se basa

Recent Posts

CoreOS

22 October 2014, Edrans DevOps team

Componentes de CoreOS

En esta entrega, hoy vamos a ver un poco mas en detalle las partes principales que conforman a CoreOS, que juntas proveen la base para tener una arquitectura redundante y de alta disponibilidad.

Como mencionamos en Parte I, CoreOS se basa en 3 grandes tecnologías, a continuación mencionaremos cada una de ellas y cual es al función que proveen en el panorama general de CoreOS.

Docker

Es el principal componente de CoreOS, un sistema de contenedores basado en Linux donde todas nuestras aplicaciones correrán. Es en estos contenedores donde nuestras aplicaciones correrán (servidores web, bases de datos, aplicativos) independientemente de su ubicación o requerimientos.

Docker tiene como ventaja la estandarización del entorno donde las aplicaciones corren. Con su sistema de creación de contenedores nos permite definir todos los pasos necesarios para que las aplicaciones contenidas en ellos corran y sean portables a cualquier sistema. Para que esto último sea posible, el requerimiento es que los servidores host de nuestros containers tengan Docker instalado.

Esto permite que la fricción entre ambientes de desarrollo / QA / producción sea minimizada, dado que una vez el contenedor es creado, el mismo contienen toda la información / paquetes necesarios para que sea ejecutado independientemente de las diferencias de sistemas operativos que pueda existir dentro de la infraestructura.

(VMs|Bare metal) vs. Docker containers

Notamos una significativa reducción de overhead al momento de escalar nuestra aplicacion mediante contenedores Docker respecto a escalar instanciando VMs. Esto se debe principalmente a que al instanciar VMs utilizamos recursos que el sistema operativo requiere para poder correr nuestra aplicación.

Docker, sinembargo, solamente corre un proceso aislado sobre el sistema operativo que ya tenemos instalado, haciendo que varios procesos puedan correr segregados bajo el mismo sistema operativo. Esto nos permite reducir este overhead haciendo uso de las ventajas de el aislamiento de recursos y asignación de los mismos a la hora de instanciar multiples contenedores para escalar nuestra aplicacion.

La mayor ventaja se ve a la hora de tener varios stacks de aplicativos corriendo bajo el mismo hardware, al minimizar el overhead de los recursos que cada uno de los aplicativos necesita y manteniendo la separación de recursos y ambientes para cada aplicativo, se obtiene lo mejor de ambos mundos, el uso reducido de recursos de los contenedores, pero sacando provecho de la segregación de ambientes y recursos que brindan las maquinas virtuales.

IMPORTANTE: Se podria realizar un analisis mas exaustivo, pero por el momento queda por fuera del alcance de esta investigación

Fleet

Fleet presenta a nuestro clúster de instancias como un solo sistema. Esto permite que el desarrollo y mantenimiento de nuestras aplicaciones pase a ser simplemente una tarea de definición de como queremos que corra, permitiendo a los administradores olvidarse de la ubicación de sus aplicativos y del manejo de recursos de su clúster. Fleet facilita esto al manejar los aplicativos mediante un sistema centralizado de unidades que permite que los aplicativos migren automáticamente entre el clúster basado en reglas pre establecidas.

Por medio de estas unidades de sistema, fleet permite asegurar que todas las instancias están corriendo en algún lugar del clúster, asegurándose de que si algun miembro del clúster falla, los contenedores serán movidos a otra instancia de CoreOS para continuar con sus operaciones con el menor impacto posible al servicio. También permite la creación de servicios con alta disponibilidad asegurándose que contenedores de aplicativos críticos no estén corriendo en el mismo servidor físico, evitando de esta forma puntos de fallas únicos por medio de la definición de reglas de afinidad entre los mismos.

Se puede pensar de fleet como una extensión de systemd que opera a nivel de clúster en vez de a nivel de maquina física. Fleet trabaja por medio de archivos de unidades de systemd con algunos atributos extras que controlan como los contenedores son distribuidos a través del clúster.

Para lograr esto, fleet contiene dos entidades principales, un servicio master y un agente:

  • Servicio Master: Es el responsable de asignar los trabajos y pedidos de los agentes así como también reaccionar ante cambios en el tamaño del clúster.

  • Agentes: Estos corren en cada maquina de CoreOS y hacen peticiones al master para nuevos trabajos (contenedores en nuestro caso). Una vez una unidad es asignada al agente, el mismo inicia los archivos de unidad y reporta el estado del proceso al master.

etcd

etcd es un servicio que permite almacenar valores que serán utilizados por el clúster. Al tener un repositorio centralizado de valores, CoreOS puede hacer uso del mismo para almacenar configuraciones y valores de los aplicativos que deben correr en el clúster. etcd permite que se almacene información en forma de "nombre":"valor" que luego puede ser consumida de forma externa por el clúster.

etcd es replicado en cada uno de los servidores del clúster, por lo cual, cualquier modificación hecha en cualquiera de los servidores es automáticamente replicada a todos los miembros del clúster para que consuman esa información.

Un ejemplo claro del uso de etcd es para evitar que se deban poner valores estáticos dentro de nuestros archivos de configuración, por ejemplo, en un servidor web, en vez de poner el valor de nuestra base de datos en el archivo de configuración de nuestro contenedor, podemos por ejemplo hacer una referencia y obtener esta información desde etcd directamente, permitiendo mucha mas versatilidad a nuestra infraestructura.

Por otro lado, y como podremos ver en un ejemplo en la próxima entrega, se puede utilizar etcd para hacer service discovery de nuevos aplicativos y reconfigurar nuestra plataforma para incluir estos cambios, por ejemplo un servidor de nginx que funciona como balanceador de carga para varias instancias de apache puede auto re configurarse cuando detecte que una nueva instancia de apache fue agregada a nuestro clúster, o incluso proveer protección contra errores, eliminando una instancia de su configuración cuando la misma no este mas presente en el clúster, haciendo todo esto de forma automática sin requerir intervención de los administradores.

Es la suma de estas tres herramientas lo que hace de CoreOS un sistema operativo que permite a los administradores mantener una infraestructura no solo que provee alta disponibilidad, sino también una gran versatilidad ante los cambios dado que la suma de estas tecnologías permite que la infraestructura donde corren nuestros aplicativos este preparada para afrontar los cambios en la disposición / disponibilidad de las diferentes partes móviles que componen una aplicación.

Llego la hora!

Creemos que un poco de teoría era fundamental para el siguiente paso, principalmente por que CoreOS rompe el molde del sistema operativo tradicional al que todos estamos acostumbrados.

En la próxima entrega estaremos realizando un setup práctico de como infraestructura CoreOS puede adaptarse al cambio y proveer un servicio de alta disponibilidad independientemente de donde este corriendo.