Docker: Una introducción de alto nivel

Introducción

En los círculos profesionales de TI, especialmente entre los especialistas en centros de datos, Docker ha sido un tema extremadamente importante durante años. Los contenedores se han utilizado durante mucho tiempo en informática y, a diferencia de otros tipos de virtualización, los contenedores se ejecutan en la parte superior del kernel del sistema operativo.

Dicho esto, la virtualización del contenedor a menudo se denomina virtualización en el nivel del sistema operativo. Este tipo de virtualización permite que se ejecuten más instancias aisladas en una sola máquina.

Esto realmente está revolucionando, no solo en la forma en que desarrollamos y entregamos aplicaciones de TI, sino también en la forma en que entregamos infraestructura de TI.

En este artículo, comenzaremos desde arriba: explicaremos qué es realmente un contenedor y echaremos un vistazo a Docker, la compañía y la tecnología a la vanguardia de todo. También analizaremos las formas en las que esto lo afectará a usted, a su negocio y a su carrera, y abordaremos algunas de las formas en las que puede prepararse.

Además de todo eso, veremos algunos de los principales conceptos y tecnologías: cosas como los registros de contenedores, qué son y qué diferencia hacen. El objetivo es que al final de este artículo estarás bien informado sobre los contenedores, más que capaz de defenderte cuando los discutas y cuando realices tus propias investigaciones.

¿Qué son los contenedores?

En primer lugar, necesitará una comprensión decente de lo que realmente es un contenedor . Dicho esto, esta sección se dedicará a explicar los contenedores en una imagen más amplia para que pueda seguir bien el resto del artículo. Este conocimiento también debería darte la confianza para articularte cuando estás en una conversación relacionada con un contenedor.

Para hacer esto correctamente, realmente necesitamos una lección rápida sobre el historial de TI:

Las aplicaciones se ejecutan en empresas y las aplicaciones se ejecutan en servidores

Al más alto nivel, las aplicaciones son lo que maneja nuestro negocio, como banca por Internet, venta minorista en línea, reserva de aerolíneas, control de tráfico aéreo, transmisión de medios y educación. Sea cual sea su negocio, las aplicaciones son una parte importante de él y dependemos en gran medida de ellas para hacer posible nuestro trabajo.

En el mundo actual, ya no podemos distinguir entre nuestro negocio y las aplicaciones que lo impulsan. Son uno y lo mismo. Sin aplicaciones, no hay negocios. Estas aplicaciones se ejecutan en su mayor parte en servidores. Y en el pasado, desde principios hasta mediados de la década de 2000, la mayoría de las veces ejecutamos una aplicación en un servidor físico, por lo que TI funcionó un poco así:

Si una empresa necesita una nueva aplicación, por cualquier motivo, ya sea el lanzamiento de un nuevo producto o un nuevo servicio que ofrecen, se debe adquirir un nuevo servidor para ejecutar la nueva aplicación. Por supuesto, el servidor tiene un costo de CAPEX por adelantado , con la adición de un montón de costos de OPEX que se activan más tarde: el costo de alimentarlo y enfriarlo, la administración y todo eso.

Esto plantea muchas preguntas:

«¿Qué tipo de servidor requiere la aplicación?»

«¿Qué tan grande tiene que ser?»

«¿Qué tan rápido tiene que ser?»

Las respuestas a preguntas como esas suelen ser «No sabemos». En ese caso, se equivocaron por precaución y optaron por servidores grandes y rápidos. Lo último que alguien quería, incluido el negocio, era un rendimiento terrible: la incapacidad de ejecutar y la posible pérdida de clientes e ingresos.

Debido a ese miedo, muchas personas terminaron con servidores físicos dominados que utilizan mucho menos de lo que son capaces.

Sin embargo, se mire como se mire, es un desperdicio vergonzoso de capital y recursos de la empresa.

VMware e hipervisor

Luego aparecieron servicios como VMware e Hypervisor .

Te puede interesar:Cómo usar temporizadores y eventos en Node.js

Casi de la noche a la mañana, tuvimos tecnología que nos permitiría tomar el mismo servidor físico y sacarle mucho más partido. En lugar de dedicar un servidor físico a una sola aplicación, de repente pudimos ejecutar de forma segura varias aplicaciones en un solo servidor.

A diferencia de lo que ocurría anteriormente, cuando una empresa crecía, se expandía y se diversificaba al agregar nuevos servicios y aplicaciones, no había necesidad de un servidor físico nuevo y brillante. Esto conduce a una reducción de los costos de CAPEX y OPEX, así como a un uso eficiente de los potentes servidores ya existentes.

En este punto, la compra de nuevos servidores solo ocurría cuando realmente los necesitábamos. Las empresas más pequeñas pudieron prosperar debido a la reducción de costos, y las empresas más grandes pudieron enfocarse más en el desarrollo y el progreso debido al mismo razonamiento.

Sin embargo, en última instancia, incluso esta no fue la solución ideal.

Los hipervisores permiten múltiples aplicaciones por servidor.

Tomemos este servidor como ejemplo. Tiene procesadores, memoria y espacio en disco. Podemos ejecutar múltiples aplicaciones en este servidor, en nuestro caso, cuatro aplicaciones diferentes.

Para ello, creamos cuatro máquinas virtuales o servidores virtuales diferentes. Básicamente, se trata de partes del hardware del servidor físico.

Por el bien del argumento, digamos que cada una de estas máquinas virtuales utiliza el 25% de la potencia de procesamiento, la memoria y el espacio en disco, respectivamente.

Cada sistema operativo virtual utiliza una parte de la potencia de procesamiento, la memoria y el espacio en disco. Pueden tener un costo de licencia y requieren tiempo para su instalación y mantenimiento. Dado que cada aplicación utiliza una máquina virtual, otra gran parte de estos recursos se extrae del servidor físico, solo para ejecutarse incluso sin ninguna aplicación implementada en el servidor.

Algunas distribuciones de Linux no son gratuitas, y Windows ciertamente no lo es; esto hace mella tanto en los recursos como en el presupuesto.Cada máquina virtual también necesita supervisión del administrador: parches de seguridad, administración de antivirus, etc.

Hay todo un bagaje operativo que viene con cada uno, y VMware y otros hipervisores, por muy buenos que sean, no hacen nada para ayudarnos con este tipo de problemas.

Revolucionaron la forma en que desarrollamos e implementamos aplicaciones, pero aún tienen problemas. Se pueden encontrar soluciones más eficientes si seguimos avanzando hacia mejores tecnologías y metodologías.

Contenedores

Todo ello nos lleva a los contenedores como la mejor solución actual a estos problemas. Echemos un vistazo a las diferencias entre el uso de contenedores e hipervisores:

Las mismas cuatro aplicaciones comerciales deben implementarse en el mismo servidor físico que antes. Sin embargo, esta vez, en lugar de instalar un hipervisor y cuatro sistemas operativos virtuales individuales encima, instalamos un solo sistema operativo para todos ellos.

En este sistema operativo, creamos cuatro contenedores, uno para cada aplicación respectivamente. Está dentro de estos contenedores, en el mismo sistema operativo que ejecutamos nuestras aplicaciones. Todavía no estamos entrando en la Arquitectura de Microservicios, sino en una simple aplicación o servicio por contenedor.

Los contenedores son mucho más pequeños y mucho más eficientes que las máquinas virtuales, por lo que este enfoque cuesta menos y nos permite usar nuestros recursos de manera más eficiente.

El resultado final es que nos deshacemos de las VM de la Arquitectura del hipervisor y terminamos con mucho espacio libre para hacer girar más contenedores. Esto significa que podemos implementar aún más aplicaciones en el mismo servidor físico que antes. No hay máquinas virtuales, ni sistemas operativos adicionales que deban iniciarse antes incluso de iniciar la aplicación y, lo que es más importante, no más desperdicio de recursos.

Un contenedor se lanza ejecutando una imagen. Una imagen es un paquete ejecutable que incluye todo lo necesario para ejecutar una aplicación: el código, un tiempo de ejecución, bibliotecas, variables de entorno y archivos de configuración. Una imagen se ejecuta dentro del contenedor y se crea utilizando capas.

Te puede interesar:Revisión del curso: Exploraciones tecnológicas Raspberry Pi Full Stack

Su software se agrega a una imagen, después de lo cual otras personas de su equipo de desarrollo pueden construir sobre él para expandirlo y agregar otras funcionalidades.

Persistencia de Docker

Mucho se ha dicho y escrito sobre la persistencia de los contenedores, o la supuesta falta de persistencia. Es cierto que los contenedores son una excelente opción para cargas de trabajo no persistentes, pero no es que los contenedores por diseño no puedan conservar los datos, pueden y lo hacen.

El primer problema con el que se encuentran los contenedores Docker es la seguridad. El sistema de archivos del host debe estar completamente separado del sistema de archivos en cualquier contenedor. Y el sistema de archivos de los contenedores no debería estar conectado de ninguna manera también si sus aplicaciones representan servicios diferentes.

Hacer un buen sistema de aislamiento fue crucial para la seguridad tanto de los contenedores como del servidor host. Para responder a este problema, Docker adoptó el sistema de archivos Union.

Esto es lo que hace que las imágenes de contenedor estén en capas: el sistema de archivos de unión combina diferentes directorios que actúan como capas separadas.

Cuando crea un contenedor con docker run, entra en estado de ejecución. A partir de ahí, podemos detenerlo, reiniciarlo y también eliminarlo. Sin embargo, cuando detienes un contenedor, no es como si se hubiera ido para siempre o desaparecido. Todavía está allí junto con sus datos en el host de Docker.

Por lo tanto, cuando lo reinicie, volverá a la vida con todos sus datos intactos, siempre que no lo elimine explícitamente con un docker rmcomando, no debe tener miedo de perder ningún dato.

Si está interesado en leer más sobre la administración de la persistencia para contenedores Docker, aquí hay un excelente artículo al que puede recurrir. Es muy detallado y cubre una gran variedad de temas e inquietudes, vale la pena leerlo.

Que es Docker

Docker es una aplicación de código abierto que automatiza el desarrollo de aplicaciones en un contenedor. Con Docker, los desarrolladores solo se encargan de las aplicaciones que se lanzan en un contenedor, en lugar de la administración de contenedores en sí.

Definitivamente existen otras tecnologías de contenedores, y buenas en eso, pero Docker es donde se encuentra la mayor parte del desarrollo y la mayor parte de la acción. Podemos decir que Docker es para los contenedores lo que VMware es para los hipervisores.

Muchos de ustedes han oído hablar de la frase de Java «WORA»: escriba una vez, ejecute en cualquier lugar, incluso si no es un desarrollador de Java. Esto es posible porque la JVM actúa como un mediador entre el código Java compilado y el sistema operativo. Es suficiente compilarlo en un .classformato de archivo o un paquete como un archivo JAR, WAR o EAR.

JVM se ejecuta en una variedad de sistemas operativos y traduce estos archivos al código de bytes que requiere el sistema operativo.

En la misma línea, Docker nos presenta la frase «PODA»: empaquetar una vez, implementar en cualquier lugar .

Su aplicación se puede escribir en cualquier idioma, se puede implementar en cualquier sistema operativo y puede tener una gran variedad de controladores, complementos, extensiones y bibliotecas que deben empaquetarse.

Toda la aplicación está empaquetada en una sola imagen y esta imagen se utiliza para ejecutarse en una amplia variedad de sistemas.

Aunque, Docker afirma apoyar el concepto de «PODA» pero no es un verdadero «PODA» porque una imagen creada en Linux se ejecutaría en Linux, de manera similar, una imagen creada en Windows se ejecutaría en Windows.

Cómo empezó Docker

Docker Inc., la principal empresa y el principal patrocinador de la tecnología de contenedores que actualmente está cambiando el mundo, es una startup tecnológica con sede en San Francisco. Sin embargo, Docker originalmente no estaba en el negocio de cambiar la forma en que creamos, enviamos y ejecutamos aplicaciones.

La empresa comenzó como una plataforma como proveedor de servicios dotCloud Inc. La idea detrás de la empresa era ofrecer una plataforma de desarrollo en la parte superior de Amazon Web Services . Detrás de escena, en dotCloud Inc *, estaban usando esta tecnología de ejecución y administración de contenedores funky como su principal motor de implementación.

Te puede interesar:Cómo iniciar un servidor de node: ejemplos con los marcos más populares

Entonces, mientras su negocio principal de vender una plataforma de desarrollo sobre AWS estaba menguando, estaban sentados en silencio sobre algo especial. En 2013, decidieron dar un gran giro y apostar el negocio por esta tecnología de contenedores que llamaban Docker, y hoy Docker Inc. es vista como una empresa de tecnología líder con una valoración de mercado de alrededor de mil millones de dólares.

El «Proyecto Docker» no es en absoluto lo mismo que Docker Inc. Son un patrocinador importante y la fuerza impulsora detrás de él, pero Docker, la tecnología de contenedores, pertenece a la comunidad. Si lo miras, notarás que todos están contribuyendo desde empresas como IBM, Cisco, Microsoft, Red Hat, etc.

Lo primero y más importante es que es de código abierto. Esto significa que todos y cualquier persona son libres de contribuir, descargarlo, modificarlo y usarlo siempre que cumplan con los términos de la versión 2 de la licencia de Apache.

El código está ahí para que el mundo lo vea en GitHub. Los componentes principales de Docker están escritos en Go o Golang , el lenguaje de programación que ha estado acumulando bastante popularidad recientemente y que fue producido por ingenieros de Google. Además, puede ver el ciclo de lanzamiento planificado que prácticamente logran.

El proyecto Docker se trata de proporcionar herramientas abiertas increíbles para construir, enviar y ejecutar aplicaciones modernas mejor. Y hay más de una herramienta y tecnología para el proyecto Docker. De la misma manera que VMware es mucho más que un hipervisor, el proyecto Docker es mucho más que el motor Docker.

El motor Docker es la pieza central de software para crear imágenes, detener y ejecutar contenedores. Es una especie de tecnología central sobre la que todas las demás tecnologías de proyectos de Docker, además de las herramientas de terceros, se basan y desarrollan.

Si colocamos el motor Docker aquí en el medio como tecnología central, entonces todo lo demás, como la agrupación en clústeres, la orquestación, el registro y la seguridad, se construye alrededor del motor y se conecta a él.

Instalación de Docker

Docker está disponible en múltiples plataformas. Aquí puede ver las plataformas compatibles y lo que debe saber antes de instalar Docker.

Docker Hub y otros registros de contenedores

Docker Hub , el registro público de Docker, es un lugar donde puede almacenar y recuperar imágenes de Docker.

Hay más de 250.000 repositorios. Las imágenes de esos repositorios se han descargado y utilizado más de mil millones de veces. Los registros de contenedores o imágenes, en particular Docker Hub, se están convirtiendo literalmente en App Stores o Google Play Stores de TI empresarial.

Al igual que la App Store es fundamental para todo lo que hace en su iPhone, Docker Hub o, potencialmente, cualquier registro de contenedores de terceros que decida utilizar, también es el centro de todo lo que hace con los contenedores.

Los registros de contenedores, en el nivel más alto y básico, son lugares para almacenar y recuperar imágenes de contenedores. Docker Hub es el registro oficial de Docker de Docker Inc., pero también existen muchos registros de terceros.

Cuando ingrese a Docker Hub, notará un montón de repositorios oficiales allí. Y siempre que tenga un host Docker con conexión a Internet, puede acceder a cualquiera de estos. Pero, ¿cómo se hace esto?

Digamos que está alojando Docker en su computadora portátil. Su Docker está limpio, o mejor dicho, no tiene ninguna imagen.

Los contenedores se ejecutan en imágenes, por lo que no tener ninguno significa que no puede ejecutar ningún contenedor. Naturalmente, lo primero que querría hacer es extraer (descargar) una imagen a su host de Docker.

Por ejemplo, llevemos una imagen de MongoDB a nuestro host de Docker. Una vez que haya descargado e instalado Docker para su plataforma respectiva:

Primero, ejecute el docker pscomando; esto le solicita una lista de contenedores instalados:

Para extraer MongoDB, ejecute el docker pull mongocomando; esto extrae la última versión del repositorio:

Te puede interesar:Preguntas de la entrevista de programación

Por último, ejecute el docker imagescomando; esto le muestra su lista de imágenes:

Imágenes de ejecución

Una vez que hayamos instalado MongoDB, sería adecuado ejecutarlo:

docker run --name some-mongo -d mongo:tag

• –name: el nombre que desea asignar a su contenedor
• some-mongo: el valor literal del atributo de nombre
• etiqueta: la etiqueta que especifica la versión de MongoDB

Ejecutar docker-psahora nos indicará con:

Una vez hecho esto, cada uno de nuestros hosts de Docker tiene su propia copia de la imagen de Mongo, por lo que todos pueden ejecutar contenedores basados ​​en MongoDB.

Puede empujar contenedores para cargar la imagen actualizada en una central. De esa forma, cualquier host que quiera ejecutar su imagen personalizada puede simplemente bajarla y seguir adelante.

¿Significa esto que cualquier persona con Docker y acceso a Internet puede acceder y descargar mis cosas?

Para repositorios públicos, sí. Están muy abiertos al mundo, o al menos están muy abiertos al mundo para tirar.

Algunos repositorios están marcados como privados. Esto significa que no está abierto a todos. Si desea que sus repositorios permanezcan cerrados para todo el mundo, simplemente márquelos para que sean privados.

¿Todos pueden ingresar a mi propio repositorio y enviar código?

Los repositorios públicos están ahí para que todos los extraigan, pero solo usted o las cuentas autorizadas pueden acceder a ellos.

Los repositorios privados solo pueden ser accedidos por personas o cuentas que tengan permisos específicos.

La mayoría de los registros en estos días le permiten definir organizaciones y equipos.

¿Son seguros mis repositorios?

Hay más en la seguridad del registro que establecer permisos y esconderse detrás de firewalls … ¿confianza?

Cuando bajamos imágenes, ¿cómo sabemos que podemos confiar en lo que estamos obteniendo? Es absolutamente necesario que sepa que puede confiar en lo que está tirando. Docker tiene una tecnología llamada Docker Content Trust , y es exactamente para este propósito.

Le permite verificar la integridad de la imagen que está extrayendo y verificar el editor de la imagen. Hoy en día, los flujos de trabajo automatizados se ven así:

Una aplicación se escribe, modifica, parchea y actualiza. Luego se envía a su repositorio de software. A partir de ahí, puede realizar pruebas, después de todo, desea asegurarse de que ninguno de los cambios que acabamos de hacer realmente no rompa la aplicación.

Suponiendo que la prueba salga bien, la enviamos a nuestro Container Registry. El registro realiza una compilación automatizada. Esto nos brinda una imagen de contenedor actualizada desde la que implementar; desde allí, implementamos la aplicación actualizada. Podemos implementarlo en nuestros propios centros de datos locales o en la nube.

Te puede interesar:Ejemplos de Websocket de Node.js con Socket.io

El Container Registry en el medio es el punto de pivote o más bien el punto muerto de este tipo de flujos de trabajo. Por supuesto, todo esto se puede automatizar para que pueda probar y automatizar cada cambio que haya realizado en su aplicación, así como enviarlos a un entorno de desarrollo, prueba o incluso de producción.

Orquestación de contenedores

Si el concepto de orquestación de contenedores es ajeno a usted total o parcialmente, hagamos una comparación de la vida real:

En el baloncesto, hay muchos jugadores. En cualquier momento del juego, algunos jugadores están en la cancha y otros no. Cada jugador tiene un rol o trabajo específico, por lo que tener muchos jugadores significa que hay muchos trabajos diferentes dentro y fuera de la cancha.

Para trabajar como un equipo eficiente, necesitan algún tipo de organización, o más bien orquestación. Este es el trabajo de un entrenador o de un equipo de entrenadores. Orquestan a todo el mundo, le dicen a la gente qué hacer, dónde ir, hacer llamadas de juego, etc.

El equipo está realizando muchas tareas específicas y únicas, organizadas por un entrenador o un equipo de entrenadores. Lo mismo ocurre con nuestras aplicaciones: generalmente están compuestas por un grupo de servicios individuales o pequeños que están orquestados de tal manera que actúan como una sola aplicación unificada. Como un equipo de baloncesto.

Entonces, casi cualquier aplicación contenida en contenedores, ciertamente cualquier aplicación digna de producción, estará compuesta por múltiples contenedores interconectados, probablemente abarcando múltiples hosts y tal vez incluso múltiples infraestructuras en la nube. Y si estamos hablando de muchos componentes de nuestra aplicación, muchos microservicios que abarcan miles de contenedores en decenas o cientos de hosts, honestamente, no queremos coser todo eso manualmente.

Lo que necesitamos es una especie de plan de juego, algo que componga todo en la aplicación general. Estamos pensando en cosas como:

• Definir todos los diferentes componentes o servicios que componen la aplicación
• Cómo encajarlos juntos
• Redes
• Colas de mensajes
• Llamadas a API, etc …

Luego, una vez definida nuestra aplicación, necesitamos una forma de implementarla y escalarla. Definitivamente no queremos elegir manualmente qué contenedores se ejecutan en qué hosts. Solo queremos un grupo de hosts, y luego poder encender contenedores y hacer que nuestra herramienta de orquestación coloque los contenedores correctos en los hosts correctos.

Todo esto es de alto nivel, pero de eso se trata la orquestación de contenedores. Definir nuestra aplicación, cómo interactúan todas las partes, aprovisionar la infraestructura y luego implementar la aplicación potencialmente con un solo clic.

Después de esto, puede levantar los pies y disfrutar de la actuación.

Desde la perspectiva de Docker Inc., tienen cuatro productos que hacen todo esto por nosotros.

• Docker Machine nos proporciona los hosts de Docker localmente, en la nube.
• Docker Compose se está utilizando para definir y componer nuestra aplicación de contenedores múltiples. Qué imágenes usar, qué puertos de red abrir y la configuración que une nuestros contenedores de aplicaciones.
• Docker Swarm se utiliza para encargarse de la programación real de nuestros contenedores en nuestro patrimonio de hosts Docker.
• Docker Totem nos brinda una bonita interfaz de usuario y nos permite controlar y administrar todo, además de todo lo anterior.

Como siempre, existe el ecosistema más amplio. Tecnologías y marcos como Kubernetes, Mesosphere Datacenter OS, CoreOS, OpenStack Magnum. Todos estos se pueden usar para organizar aplicaciones en contenedores. Y, obviamente, cada uno tiene sus pros y sus contras.

Por ejemplo, Kubernetes fue desarrollado por Google y ahora es un marco de código abierto.

 

Dominio de Docker: el conjunto de herramientas completo

¿Quiere aprender más sobre los contenedores y el ecosistema de herramientas de Docker? Intente realizar un curso de formación paso a paso para enseñarle cómo crear y utilizar rápidamente contenedores de Docker para sus aplicaciones.

 

Conclusión

Algunos de ustedes serán técnicos, desarrolladores, administradores de sistemas y DevOps prácticos, mientras que otros se centrarán más en la gestión y, en general, menos en la práctica. Si eres del tipo práctico, haz precisamente eso, consigue estas cosas.

Todo lo que necesita es una máquina virtual, en su computadora o en la nube, realmente no importa dónde.

Te puede interesar:Cómo crear una aplicación CLI de Node.js

Instale Docker y haga lo que hace: juegue con él, desarrolle y dockerice una aplicación, cree imágenes, inicie contenedores, rómpalos, tírelos a la basura, simplemente ensucie sus manos jugando con él.