Docker: una introducción de alto nivel

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 usado para un l...

Introducción

En los círculos profesionales de TI, especialmente entre los especialistas en centros de datos, Estibador 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 por el contenedor a menudo se denomina virtualización en el nivel del sistema operativo. Este tipo de virtualización permite ejecutar instancias más 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 analizaremos Docker, la empresa y la tecnología a la vanguardia. También analizaremos las formas en que esto lo afectará a usted, a su negocio y a su carrera, y también mencionaremos algunas de las formas en que puede prepararse.

Además de todo eso, veremos algunos de los principales conceptos y tecnologías, cosas como registros de contenedores, qué son y qué diferencia hacen. El objetivo es que al final de este artículo esté al tanto de los contenedores, más que capaz de defenderse cuando los discuta y cuando haga sus 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 un panorama más amplio para que pueda seguir el resto del artículo sin problemas. Este conocimiento también debería darle la confianza para articularse cuando esté en una conversación relacionada con contenedores.

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

Las aplicaciones ejecutan empresas y las aplicaciones se ejecutan en servidores

Al más alto nivel, las aplicaciones son lo que hace funcionar nuestro negocio, como la banca por Internet, las ventas minoristas en línea, las reservas de aerolíneas, el control del tráfico aéreo, la transmisión de medios y la 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, sin negocio. 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 ejecutábamos una aplicación en un servidor físico, por lo que la TI funcionaba 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 inicial de gastos de capital, con la adición de un montón de [OPEX](https://en.wikipedia.org /wiki/Operating_expense) costos que se activan más tarde: el costo de encenderlo y enfriarlo, administración y todo ese jazz.

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 nadie deseaba, incluido el negocio, era un rendimiento terrible: la incapacidad de ejecución y la posible pérdida de clientes e ingresos.

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

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

VMware e hipervisor

Luego llegaron servicios como vmware y hipervisor.

Casi de la noche a la mañana teníamos la tecnología que nos permitía tomar el mismo servidor físico y exprimirlo mucho más. 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 antes, 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 reluciente. Esto conduce a una reducción de los costos de CAPEX y OPEX, así como al 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 concentrarse más en el desarrollo y el progreso debido al mismo razonamiento.

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

VMware{.img-responsive}

Los hipervisores permiten varias aplicaciones por servidor.

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

Para ello, creamos cuatro máquinas virtuales o servidores virtuales diferentes. Estos son esencialmente partes del hardware del servidor físico.

Solo 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 configurarse y mantenerse. Dado que cada aplicación usa una máquina virtual, otra gran parte de estos recursos se separa 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 la supervisión del administrador: parches de seguridad, administración de antivirus, etc.

Hay todo un bagaje operativo que viene con cada uno, y VMware, así como 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 todavía 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:

Contenedores vs hipervisores{.img-responsive}

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 en el que ejecutamos nuestras aplicaciones. Todavía no estamos entrando en la Arquitectura de Microservicios, sino en una aplicación o servicio simple 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 máquinas virtuales de la arquitectura de 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 incluso antes 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.

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 funciones.

Persistencia de la ventana acoplable {#persistencia de la ventana acoplable}

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 las cargas de trabajo no persistentes, pero no es que los contenedores por diseño no puedan conservar los datos, pueden hacerlo 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 tampoco debería estar conectado de ninguna manera si sus aplicaciones representan diferentes servicios.

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, la cuestión es que cuando detienes un contenedor, no es como si se hubiera ido para siempre o hubiera desaparecido. Todavía está allí junto con sus datos en el host Docker.

Entonces, cuando lo reinicie, volverá a la vida con todos sus datos intactos, siempre que no lo elimine explícitamente con un comando docker rm, no debe tener miedo de perder cualquier dato.

Si está interesado en leer más sobre cómo administrar la persistencia de los contenedores Docker, aquí tiene un gran artículo para consultar. Es muy detallado y cubre una gran variedad de temas y preocupaciones, vale la pena leerlo.

Qué es Docker

Estibador 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 inician en un contenedor, en lugar de la administración del contenedor en sí.

Definitivamente existen otras tecnologías de contenedores, y buenas, pero Docker es donde está 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" - escribe una vez, ejecuta en cualquier lugar incluso si no eres un desarrollador de Java. Esto es posible porque la JVM actúa como mediador entre el código Java compilado y el sistema operativo. Es suficiente compilarlo en un formato de archivo .class, o en 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 con 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 admitir 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 se inició Docker

Docker Inc., la principal empresa y el principal patrocinador detrás de la tecnología de contenedores que actualmente está cambiando el mundo, es una empresa emergente tecnológica con sede en San Francisco. Sin embargo, Docker no estaba originalmente 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 del negocio era ofrecer una plataforma de desarrollo en la parte superior de [Servicios web de Amazon] (https://aws.amazon.com/). Detrás de escena, en dotCloud Inc*, estaban utilizando esta tecnología de tiempo de ejecución y administración de contenedores original como su principal motor de implementación.

Entonces, mientras su negocio principal de vender una plataforma de desarrollo sobre AWS estaba decayendo, 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 líder en tecnología 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 uno de los principales patrocinadores y la fuerza impulsora detrás de él, pero Docker, la tecnología de contenedores, pertenece a la comunidad. Si lo mira, notará que todos están contribuyendo desde IBM, Cisco, Microsoft, Red Hat, etc.

Lo primero y más importante es que es de código abierto. Esto significa que todo el mundo es libre de contribuir, descargarlo, modificarlo y usarlo, siempre y cuando cumpla con los términos de la licencia de Apache versión 2.

El código está ahí para que el mundo lo vea en GitHub. Los componentes principales de Docker están escritos en Ir o Golang, el lenguaje de programación que ha acumulado 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 tiene que ver con proporcionar impresionantes herramientas abiertas para construir, enviar y ejecutar mejor las aplicaciones modernas. Y hay más de una herramienta y tecnología en el proyecto Docker. De la misma manera que VMware es mucho más que el hipervisor, el proyecto Docker es mucho más que el motor Docker.

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

Tecnología relacionada con el motor Docker{.img-responsive}

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

Instalación de Docker {#instalación de Docker}

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

Docker Hub y otros registros de contenedores

Centro acoplable, 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 las tiendas de aplicaciones o las tiendas Google Play de TI empresarial.

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

Docker Hub{.img-responsive}

Los registros de contenedores, al 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 hay 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á hacer es extraer (descargar) una imagen a su servidor Docker.

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

Primero, ejecute el comando docker ps - esto le muestra una lista de contenedores instalados:

docker ps{.img-responsive}

Para extraer MongoDB, ejecute el comando docker pull mongo - esto extrae la última versión del repositorio:

docker pull mongo{.img-responsive}

Por último, ejecute el comando docker images - esto le muestra su lista de imágenes:

docker images{.img-responsive}

Imágenes en ejecución {#imágenes en ejecución}

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

1
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-ps ahora nos pedirá:

Docker se está ejecutando{.img-responsive}

Una vez hecho esto, cada uno de nuestros hosts 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 manera, cualquier host que quiera ejecutar su imagen personalizada puede simplemente bajarla y activarla.

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

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

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

¿Todo el mundo puede acceder a mi propio repositorio y enviar código?

Los repositorios públicos están disponibles 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 cortafuegos... ¿confianza?

Al bajar las imágenes, ¿cómo sabemos que podemos confiar en lo que estamos obteniendo? Necesita absolutamente saber que puede confiar en lo que está haciendo. Docker tiene una tecnología llamada Confianza de contenido de Docker, y es exactamente para este propósito.

Le permite verificar tanto la integridad de la imagen que está extrayendo como 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, quiere asegurarse de que ninguno de los cambios que acabamos de hacer realmente rompa la aplicación.

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

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 realizó en su aplicación, así como llevarlos a un entorno de desarrollo, prueba o incluso producción.

Orquestación de contenedores {#orquestación de contenedores}

Si el concepto de orquestación de contenedores le resulta completamente o parcialmente extraño, 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, mejor dicho, orquestación. Este es el trabajo de un entrenador o un equipo de entrenadores. Orquestan a todos, le dicen a la gente qué hacer, adónde ir, hacen llamadas de juego, etc.

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

Por lo tanto, casi cualquier aplicación en contenedores, sin duda cualquier aplicación digna de producción, se compondrá de múltiples contenedores interconectados, probablemente abarcando múltiples hosts, y tal vez incluso múltiples infraestructuras de 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, sinceramente, no queremos unir todo eso manualmente.

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

  • Definición de todos los diferentes componentes o servicios que componen la aplicación
  • Cómo encajarlos
  • Redes
  • Colas de mensajes
  • Llamadas 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 activar 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, puedes levantar los pies y disfrutar de la actuación.

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

  • Máquina acoplable proporciona hosts de Docker para nosotros en las instalaciones, en la nube.
  • Componer ventana acoplable se está utilizando para definir y componer nuestra aplicación multicontenedor. Qué imágenes usar, qué puertos de red abrir y la configuración que une nuestros contenedores de aplicaciones.
  • Enjambre Docker se utiliza para encargarse de programar realmente nuestros contenedores en nuestra propiedad de hosts Docker.
  • Tótem estibador nos brinda una interfaz de usuario bonita y nos permite controlar y administrar todo, además de todo lo anterior.

Como siempre, está el ecosistema más amplio. Tecnologías y marcos como Kubernetes, Mesosphere Datacenter OS, CoreOS, OpenStack Magnum. Todos estos se pueden usar para orquestar 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.

Docker Docker: el conjunto de herramientas completo ¿Desea obtener más información sobre los contenedores y el ecosistema de herramientas de Docker? ¡Intente tomar un curso de capacitación paso a paso para aprender cómo crear y usar rápidamente contenedores Docker para sus aplicaciones!

Conclusión

Algunos de ustedes serán expertos en tecnología, desarrolladores, administradores de sistemas y DevOps, mientras que otros se centrarán más en la administración y, en general, menos prácticos. Si eres uno de los tipos prácticos, haz exactamente eso, pon tus manos en este material.

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

Instale Docker y haga lo que hace: juegue con él, desarrolle y dockerice una aplicación, cree imágenes, inicie contenedores, destrúyalos, deséchelos, simplemente ensucie sus manos jugando con él.