Hay oleadas de viralidad cuando se trata de tecnologías emergentes. Los contenedores están practicando surf en la ola de punto de quiebre. Lo que significa que están aquí con una entrada explosiva y están aquí para quedarse. Esta entrada sucedió hace un par de años. Entonces, ¿por qué sigo hablando de esto?
Porque, todavía hay ciertas preguntas que prevalecen como: ¿Cuál es el futuro de los contenedores y máquinas virtuales? ¿Cuánto tiempo ha pasado? Para que los principiantes se mantengan al tanto, comencemos por lo básico: ¿qué son los contenedores?.
Vamos a encontrar respuestas a estas tres preguntas ahora, por supuesto en el orden inverso.
Para comprender los Contenedores, debemos comprender la virtualización. Cuando emula una computadora en la parte superior de una computadora real utilizando un software de hipervisor, que abstrae el hardware, se conoce como virtualización de servidor. Por lo tanto, en una única máquina física poderosa, puede haber varias máquinas virtuales en ejecución, explotando así la capacidad informática máxima.
Esto significa que, para cada máquina virtual, tiene que haber un espacio separado para el procesamiento, núcleo, interfaz de red, esquemas IP, sistemas de archivos y cientos de otras cosas. No es algo malo Todavía es la tecnología de ir a. Pero, ¿por qué la necesidad de depender del sistema operativo invitado para cada máquina virtual?
Imagínese, en lugar de ejecutar múltiples máquinas virtuales en un solo hardware físico, puede ejecutar una aplicación y sus datos asociados en un espacio de usuario confinado (la memoria limitada a la que se permite el acceso de un proceso) en un kernel único. Lo que imaginaste se llama contenedor.
¿Qué es la Containerización?
Containerización es una virtualización de nivel de sistema operativo para implementar y ejecutar aplicaciones distribuidas sin iniciar una máquina virtual separada para cada aplicación.
Respondiendo nuestra segunda pregunta: ¿cuánto tiempo lleva ?, lleva más de tres décadas, en algún momento de 1982, cuando se intentó una virtualización con un nombre extraño llamado OS, donde se podía crear una copia virtualizada del software del sistema. . Nadie más allá de un grupo de fans de virtualización entendió lo que significaba entonces. 23 años después, Solaris lanzó la primera de las aplicaciones en contenedores basándose en Chroot. Incluso llamaron a sus contenedores, Chroots con esteroides. En 2008, Linux Containers (LXC) se convirtió en una versión más refinada de esta tecnología utilizando la funcionalidad cgroups en Linux Kernel.
Este punto en la línea de tiempo que establece una serie de eventos que conducen a nuestro estado actual de Contenedores, debe ser observado de cerca. ¿Qué hizo LXC correctamente que eventualmente llevó a que Docker se construyera sobre esto? Los contenedores se convirtieron en un éxito porque Docker fue un éxito y es por esto que LXC fue un éxito.
Entonces, para avanzar, debemos entender LXC. ¡Volvamos al 2008!
En LXC, se usaron espacios de nombres y cgroups. ¿Recuerda cómo cada una de las máquinas virtuales cree que son las únicas que se ejecutan en el hardware? De manera similar, los espacios de nombres le dan a un grupo de procesos la ilusión de ejecutar un proceso singular en el sistema. Básicamente, limitan la vista de cada proceso sobre varios recursos del kernel. Actualmente hay 6 espacios de nombres completados e implementados. Son y son para: UID y GID, comunicación entre procesos, red, identificación de proceso, sistema de archivos y dominio / nombre de host.
Los recursos antes mencionados se pueden controlar desde una interfaz unificada llamada cgroups (grupos de control). Con estas dos funcionalidades, los recursos del kernel están aislados para cada uno de los procesos. Además de esto, Union File System es una de las funciones básicas que hacen que los contenedores sean livianos.
Básicamente es un sistema de archivos de copia sobre escritura. Esto significa que, en un proceso, donde hay varias personas que llaman que acceden al mismo recurso, el recurso no se copia y se envía a cada uno de los llamantes. El recurso permanece donde está, mientras que se les da un puntero a las personas que llaman para leer el recurso. Cuando se necesita una modificación, y solo entonces, se toma una copia del recurso y se realizan los cambios, dejando el original intacto.
Solo los cambios realizados se apilan como imágenes de cambio delta sobre la imagen base (los directorios y utilidades mínimos viables de Linux) formando un único sistema de archivos. Esto ayuda a una mejor segregación de las capas y evita la creación de duplicados.
Incluso con estas características existentes durante un largo período, no pasó mucho hasta hace poco. ¿Por qué? Cualquier tecnología debe ser accesible para aprovechar el impulso.
Docker hizo esto por Contenedores. Es el software que realiza la contenedorización completa. Hizo que el proceso de construir uno-fácil, ejecutandose mas rápido y reunió a una gran comunidad que hizo que muchas imágenes disponibles públicamente sean utilizadas por muchos. "Muchos" es una simplificación excesiva teniendo en cuenta que el año pasado se sacaron 12 mil millones de imágenes (la jerga de Docker se descargó).
Entonces, un usuario crea un archivo Docker que se usa para construir la imagen de Docker junto con la aplicación y sus dependencias. Esto se comunica a Docker Daemon utilizando Docker Client. Los usuarios pueden subir una imagen o descargar una imagen disponible públicamente. Esto empaqueta la aplicación y sus dependencias en un contenedor invisible, eliminando así la sobrecarga que puede incurrir al iniciar y mantener una máquina virtual.
Esto nos lleva a la pregunta que planteé al comienzo de este blog, es decir, ¿cuál es el futuro de los Contenedores y VM?
Los contenedores son preferidos para el arranque instantáneo, la modularidad, la portabilidad y el uso de varias copias de una sola aplicación. Cuando se elimina la jerga, significa que las aplicaciones utilizan el mismo sistema operativo, superando así la demora en el arranque. Cuando dije modular, me refiero al microservicio que ofrece la contenedorización. Una aplicación se puede dividir en módulos en función de su funcionamiento y cada operación se puede crear de forma separada e instantánea.
Las imágenes base se pueden distribuir a diferentes máquinas mediante la descarga desde el registro, lo que lo hace portátil.
¿Dónde gana VM entonces? Básicamente en cualquier otro caso. Los contenedores solo funcionan si las aplicaciones se ejecutan en el mismo sistema operativo. ¿Qué sucede si un usuario necesita usar diferentes aplicaciones que se ejecutan en diferentes sistemas operativos? Las máquinas virtuales brindan una solución confiable. Proporcionan una mejor seguridad.
Los problemas que pueden surgir con la expansión de los segmentos de los contenedores: administrar numerosos micro segmentos, pueden ser una carga. Cuando está creando un contenedor, es un recinto de seguridad, lo que significa que agregar otras dependencias es una causa de preocupación. Estos puntos dolorosos no existen en las máquinas virtuales. Esto no significa que las VM vencen a los Contenedores y tampoco significa que los Contenedores eliminarán las VM. Ni siquiera están uno contra el otro.
La estrategia más eficiente y más utilizada es tener una máquina física que tenga varias máquinas virtuales y cada máquina virtual tenga varios contenedores. Existe una razón por la cual se realiza el formato de máquina Contenedores en máquinas virtuales en lugar de simplemente saltar cara a cara en los contenedores. Los usuarios deben optimizar sus recursos informáticos, pero al mismo tiempo deben tener la libertad de elegir la forma en que desean utilizar los recursos.
Los contenedores resuelven los problemas planteados por las máquinas virtuales y ayudan a avanzar en la optimización de los entornos informáticos.
Experimente la protección de datos moderna con esta última edición GRATIS de Vembu BDR Suite v.3.9.0. Pruebe la versión de prueba gratuita de 30 días aquí: https://www.vembu.com/vembu-bdr-suite-download/