Bienvenid@s, este Encora webinar, realizado en abril de 2021 para nuestros clientes, explicamos de la mano de David Marquina, CTO de Encora, qué ventajas aportan al mundo IT las tecnologías de contenedores y por qué son un factor imprescindible en nuestro viaje cloud.
También veremos las diferentes plataformas más populares del mercado y qué nos ofrece cada una de ellas.
¿QUÉ SON LAS TECNOLOGÍAS DE CONTENEDORES?
Un contenedor es “un recipiente” donde podemos ejecutar procesos o aplicaciones junto a todas las dependencias.
Cuando hacemos referencia a las dependencias, nos estamos refiriendo a librerías o ficheros necesarios de forma totalmente aislada al sistema operativo.
¿QUÉ NOS PERMITEN LAS TECNOLOGÍAS DE CONTENEDORES?
Las tecnologías de contenedores nos van a permitir que prácticamente cualquier máquina que tenga un demonio de Docker corriendo, en este caso de contenedores, sea capaz de ejecutar ese contenedor.
Es un proceso algo parecido al de la virtualización, pero con mucha más abstracción del hardware.
Concretamente, estos contenedores lo que buscan es su demonio de Docker, que es lo que les permite funcionar.
EJEMPLO DE APLICACIÓN DE TECNOLOGÍAS DE CONTENEDORES
Imaginemos que tenemos una aplicación web que tiene el demonio del sistema web y una serie de procesos además de que necesita de Java 7 para funcionar.
En este caso concreto, ¿cómo funcionaría un contenedor?
Tendría empaquetada nuestra aplicación web con todas sus dependencias incluyendo el java.
Esto nos permitiría hacer una portabilidad de la aplicación hacia cualquier sistema en el que se ejecute un contenedor (el demonio de Docker) y de forma totalmente independiente a lo que hay por debajo.Imaginemos que tenemos una aplicación que funciona con Java 7 y funciona en un sistema operativo. Este sistema operativo está actualizado al Java 8 y la aplicación deja de funcionar. En este caso, con los contenedores, se evitan estas situaciones porque básicamente lo que hacen es ejecutar la aplicación de forma aislada/ independiente (procedimiento muy similar al de virtualización de aplicaciones).
Definiendo de manera visual lo que son los contenedores, podemos observar en el gráfico, en la parte de la izquierda, que realmente se trata de servidores.
Cuando hablamos de infraestructura hablamos de un servidor tradicional que tiene un sistema operativo, normalmente un Linux o Windows. Estos servidores ejecutan el proceso de Docker. Este “demonio” lo que hace es ejecutar todas las aplicaciones independientes y aisladas entre sí.
A la derecha del gráfico podemos observar el entorno tradicional.
Un entorno tradicional consiste en que tenemos una infraestructura (Host) sobre la que ejecutamos un Hypervisor. Sobre estos Hypervisores ejecutamos los sistemas operativos virtualizados. Sobre éstos, las aplicaciones con las dependencias y la estructura de toda la vida.
El concepto es que, con la contenerización de aplicaciones, perdemos la capa de Hypervisor ya que el demonio y las aplicaciones ya se van a ejecutar de forma totalmente aislada y transportable/independiente entre ellas sin necesidad de un Hypervisor.
TECNOLOGÍAS DE CONTENEDORES CLOUD NATIVE
La estructura de contenedores y la portabilidad nos ejecutarán el Cloud Native Application.
Es una nueva filosofía en la cual estructuramos las aplicaciones partiendo del desarrollo de estas en estructura de contenedores, que, a su vez, me permitirá toda una granularidad ya que va a estar con una tecnología de microservicios en la cual podemos dividir una aplicación de forma granular y tener muchísimo control sobre las aplicaciones.
Todo ello nos habilitará una estructura de desarrollo continuo. Los contenedores son imágenes inmutables hecho que nos permite tener una estructura y un flujo de control de desarrollo continúo mucho más avanzado y, a su vez, nos permitirá aplicar una filosofía de Devops en la cual desplegamos aplicaciones basadas en código.
Los contenedores son la base para poder transformar todas las aplicaciones en estructuras transportables y movibles entre cualquier tipo de infraestructura.
Al final, las aplicaciones tienen que ser como contenedores. Los contenedores de los barcos son una medida universal que transportan estructuras entre los diferentes puertos del mundo y entre distintos barcos, pero siempre con unos estándares. Transfiriendo esta definición a la de las tecnologías de contenedores, son la puerta para que nuestras aplicaciones puedan ejecutarse en la nube.
MOTORES DE CONTENEDORES
En este apartado, explicaremos los diferentes tipos de motores de contenedores que siguen los estándares del mercado.
- LXC. Está prácticamente olvidado. Fue la primera implementación técnica de los contenedores Docker.
- Docker. Es el estándar del mercado.
- Podman. Desarrollo de RedHat que seguramente en un futuro no muy lejano vaya a sustituir a Docker.
Todos estos tipos de contenedores siguen teniendo la misma estructura y funcionan de la misma manera. Lo que cambia entre ella es la implementación.
DIFERENCIAS ENTRE DOCKER Y PODMAN
Docker tiene una serie de limitaciones que Podman (estructura en un núcleo enterprise o empresarial) sustituirá.
- Docker necesita de un un servicio, un demonio, que se encarga de ejecutar todos los contenedores. En este caso en concreto, Podman está diseñado para no tener este demonio centra.
Cuando ejecutemos con Docker sobre un Host, por ejemplo, 20 contenedores o 10 contenedores, el demonio empieza a crecer porque es el que gestiona y ejecuta estos contenedores y lo hace muy pesado. Podtman ya está pensado para una estructura empresarial. - En Docker, necesito tener privilegios de root para ejecutar los contenedores en la mayoría de las implementaciones y, en cambio, con Podman es root-less Podemos ejecutar con usuarios delegados lo cual para estructuras empresariales y enterprise viene a ser muy serio.
ARQUITECTURA DE DOCKER
Tenemos un demonio en cada Host y este demonio, de cada Host, nos ejecuta los contenedores. Este demonio es un proceso.
Lo que hacemos es que desde un cliente al que nos conectamos, ejecutamos los comandos sobre estos demonios. Es una arquitectura sencilla.
Tenemos que crear imágenes a través de DockerFile. La imagen es la aplicación con todas sus dependencias. Esta aplicación con todas sus dependencias lo inyectamos y lo guardamos dentro de un contenedor.
¿POR QUÉ LAS IMÁGENES?
Podemos tener diferentes versiones y diferentes imágenes que luego ejecutamos en diferentes contenedores.
Nos permitirá hacer todos los cambios que deseemos, así como volver para atrás a una versión antigua, etc.
Es importante recordar que estas imágenes son inmutables, es decir, yo para hacer cambios tengo que crear una nueva imagen, aplicar esos cambios, guardarlo y luego hacer un pull que es subirlo. No se pueden hacer cambios en caliente, esto me permite hacer una estructura para temas web muy interesantes.
DOCKER REGISTRY
El Docker Registry es el estándar, el almacén de mis imágenes de mis contenedores.
Podemos utilizar el propio Docker Hub que es la propietaria que trae Docker pero también tenemos públicos como jfrog, github, Azure Container, etc.
ORQUESTACIÓN
Kubernetes es una estructura de contenedores que no es una una solución de contenedores. Es una solución de orquestación y automatización de contenedores, es decir, tenemos los contenedores, basados en Podman o en Docker (el 90% suelen estar basados en Docker) y yo lo que hacemos es desplegar y automatizar todo este desarrollo y todo este despliegue de forma automática.
Kubernetes nos permite hacer un escalado automático de la aplicación cuando tenemos subidas de carga, pero no tenemos demandas de rendimiento.
Existen tres nodos en el mercado. Uno de ellos es Docker Swarm pero hoy en día ya está prácticamente en desuso.
- Openshift. Es una solución muy focalizada en entornos enterprise.
- Kubernetes.
KUBERNETES
Es una estructura muy sencilla. Hay un nodo master que es donde haremos todos los cambios y un nodo que controla todo el cluster o grupo de nodos de Kubernetes.
Cada nodo de Kubernetes, viene a ser un Hardware. En esa solución, no existe capa de virtualización.
Los diferentes nodos de Kubernetes, ejecutan Pod y los usuarios se conectan a ellos.
Cuando desarrollamos una aplicación, debe tener un balanceo porque, como os decía, todo está basado en una estructura de auto despliegue en caso de demandas de carga. Tenemos los nodos de proceso donde ejecutamos los contenedores y un nodo master.
En Kubernetes aparece una cosa muy interesante que son los Pods. Los Pods son un grupo de contenedores con volúmenes, es decir, hasta ahora hablábamos de que tenemos un contenedor con una aplicación, pero imaginemos que tenemos un grupo de contenedores con varias aplicaciones web, que a su vez tienen varias aplicaciones de balance de carga así como aplicaciones de caché web, pues en este caso, lo podremos meter en grupos de Pods que nos van a permitir manejarlo como un grupo de contenedores.
Es una estructura más grande y es una estructura específica de Kubernetes.
Cada grupo de Pods puede tener un grupo de IP’s y además nos permite tener volúmenes.
Las tecnologías de contenedores no están concebidas para tener almacenamiento persistente, es decir, están pensados para no guardar datos. Los contenedores actúan contra la base de datos o contra un repositorio.
Kubernetes nos permite conectarnos con almacenamiento de espacio, con un sistema de almacenamiento persistente a través de API y utilizarlos como volúmenes de datos persistentes.
K8S CLOUD AS A SERVICE
Kubernetes lo podemos ejecutar onpremise pero también en entornos públicos, es decir, podemos coger la arquitectura de Kubernetes y los contenedores (totalmente portables) y llevarlos a infraestructuras cloud.
Amazon, Google, IBM o Azure, los cuatro, nos permiten tener Kubernetes as a service. No tendremos que desplegar un nodo Kuberenetes ni montar toda la infraestructura si no que ya los despliegan ellos con sus IP’s y solamente tendremos que subir nuestros contenedores.
También tenemos soluciones onpremise, basadas en cloud.
- VMware -> Tanzu (capa adicional a su Hypervisor).
- Google -> Anthos.
- IBM -> Cloud Packs.
- Microsoft -> Azure Arc (stack que viene dentro de la parte de Azure Stack). Sirve para poder desplegar contenedores como servicios onpremise.
Todo lo que sea como servicio, no nos tendremos que preocupar de administrar la arquitectura de Kubernetes. Es un servicio e inyectamos en un paquete cerrado nuestros contenedores. No tenemos porqué ser especialistas en administración de Kubernetes.
CI/CD
Una de las grandes ventajas que nos permite tener en cuenta es tener un flujo de desarrollo continuo. Esto en una estructura tradicional, era imposible de hacer.
Con Kubernetes podremos desplegar, restaurar, subir, bajar, etc. versiones de diferentes imágenes que han hecho diferentes programadores y hacer toda una línea de seguimiento de código con issues con repositorios. Es tremendamente sencillo.
Esto es hacia dónde vamos todas las compañías. El tener una capacidad de desarrollo continuo y capacidad rápida de integración porque tenemos nuestra aplicación tan fragmentada y dividida en micro servicios que somos capaz de hacer cambios pequeños y de forma muy ágil y rápida sobre las distintas partes de forma independiente.
EVOLUCIÓN DEL DESARROLLO
En la siguiente imagen entendemos de una forma súper clara cómo se desarrollaba antes, cómo se desarrolla con tecnología de contenedores y cómo se desarrolla con Kubernetes.
En todas las aplicaciones aparece una cosa muy interesante. En las bases de datos, no aparecen dentro de la estructura de Kubernetes.
Si tenemos una base de datos tradicional, Transact SQL, es imposible que lleguemos a un auto crecimiento. En este caso, debería tener todavía una estructura de bases de datos pensada para poder crecer a la par que crece toda mi infraestructura.
SOLUCIÓN UNIVERSAL
Kubernetes o tecnologías de contenedores, tienen mucho sentido cuando nuestra aplicación necesita de un escalado, cuándo vamos a poder crecer, cuando queremos tener portabilidad.
No es para una aplicación Legacy. No tiene sentido meter esta clase de aplicaciones en un contenedor porque la gente habla de rendimiento, pero yo creo que está muy claro.
La furgoneta grande es lo que consume el Pod de Kubernetes. Lo que me queda después es para el contenedor de Docker y al final el cochecito pequeño es lo que me queda en la app en Go.
Kubernetes y los contenedores son unas soluciones magníficas, pero hay que hacer una reingeniería de las aplicaciones y hay que adaptarlas a un mundo en el cual van a tener escalabilidad.
No son para un mundo de aplicaciones monolíticas y de aplicaciones legacy.
La aplicación debe tener auto escalado, por contra, no tendrá sentido.
En cuanto a las bases de datos tienen que poder crecer de forma dinámica y tienen que poder estar distribuidas y replicadas entre ellas (base de datos no SQL).
Para bases de datos como Microsoft SQL o Oracle, no tendrá sentido.
Esperamos que os haya gustado este webinar de introducción a las tecnologías de contenedores.
Recordad que podéis consultar todos los webinars y que os podéis suscribir a la Encora Newsletter para estar al día de todas nuestras novedades.
Gracias por compartirlo en redes sociales. Esperamos vuestros comentarios.
¡Hasta pronto!
