Breaking

Post Top Ad

Your Ad Spot

martes, 9 de julio de 2019

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 por el 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 la infraestructura de TI.
En este artículo vamos a comenzar desde la parte superior: 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 veremos formas en que esto lo afectará a usted, a su negocio y a su carrera, así como a algunas de las formas en que puede prepararse.
Además de todo eso, veremos algunos de los principales conceptos y tecnologías, como los registros de contenedores, qué son y qué diferencia hacen. La meta al final de este artículo estará bien informada sobre los contenedores, más que capaz de mantener la suya cuando los analice y cuando realice sus propias investigaciones.

Que son los contenedores

Primero que todo, necesitarás un buen entendimiento de lo que realmente es un Contenedor . Dicho esto, esta sección se dedicará a explicar los contenedores en una imagen más grande para que pueda seguirlos bien junto con el resto del artículo. Este conocimiento también debería darle la confianza para articularse cuando esté en una conversación relacionada con un contenedor.
Para hacer esto correctamente, realmente necesitamos una lección rápida sobre el historial de TI:

Aplicaciones Ejecutar Empresas y Aplicaciones Ejecutar en Servidores

En el nivel más alto, las aplicaciones son lo que dirige nuestro negocio, como la banca por Internet, el comercio minorista en línea, la reserva de líneas aéreas, 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 masiva de la misma y confiamos en ellas para que nuestro trabajo sea posible.
En el mundo de hoy, ya no podemos distinguir entre nuestro negocio y las aplicaciones que lo potencian. Son una y la misma. No hay aplicaciones, no hay negocio. Estas aplicaciones se ejecutan en su mayor parte en los 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 funcionó un poco así:
Si una empresa necesita una nueva aplicación, por el motivo que sea, ya sea el lanzamiento de un nuevo producto o un nuevo servicio que ofrecen, debe procurarse 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 implementarán más adelante: el costo de alimentarlo y enfriarlo, la 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 a menudo son "No sabemos" . En ese caso, se equivocaron por el lado de la precaución y optaron por servidores grandes y rápidos. Lo último que todos querían, incluido el negocio, era un rendimiento espantoso: la incapacidad de ejecutar y la posible pérdida de clientes e ingresos.
Debido a ese temor, muchas personas terminaron con servidores físicos sobrecargados que utilizan mucho menos de lo que son capaces de hacer.
Sin embargo, aunque lo vea, es una vergonzosa pérdida de capital y recursos de la empresa.

VMware e hipervisor

Luego vinieron servicios como VMware y Hypervisor .
Era casi de la noche a la mañana que teníamos tecnología que nos permitirí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 varias aplicaciones de forma segura en un solo servidor.
A diferencia de lo que ocurría anteriormente, cuando una empresa estaba creciendo, expandiéndose y diversificándose al agregar nuevos servicios y aplicaciones, no había necesidad de un servidor físico nuevo y brillante. Esto llevó a la reducción de los costos de CAPEX y OPEX, así como al uso eficiente de los servidores poderosos ya existentes.
En este punto, la compra de nuevos servidores solo se producía cuando realmente los necesitábamos. Las empresas más pequeñas pudieron prosperar debido a la reducción de los costos, y las empresas más grandes podrían centrarse 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
Los hipervisores permiten múltiples aplicaciones por servidor.
Tomemos este servidor por un 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 para discutir, 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 configurar y mantener. Dado que cada aplicación utiliza una máquina virtual, otra gran parte de estos recursos se divide en el 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 reino de equipaje operacional 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 aún tienen problemas. Se pueden encontrar soluciones más eficientes si seguimos moviéndonos hacia mejores tecnologías y metodologías.

Contenedores

Todo esto nos lleva a los contenedores como la mejor solución actual para estos problemas. Echemos un vistazo a las diferencias entre el uso de contenedores e hipervisores:
Contenedores vs hipervisores
Las mismas cuatro aplicaciones empresariales 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, 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 ingresando a la arquitectura de microservicios, sino a 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 utilizar nuestros recursos de manera más eficiente.
El resultado final es que nos deshacemos de las máquinas virtuales de la arquitectura del hipervisor y terminamos con una gran cantidad de espacio libre para 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 de iniciar la aplicación y, lo que es más importante, no hay que consumir más recursos.
Se ejecuta un contenedor ejecutando una imagen. Una imagen es un paquete ejecutable que incluye todo lo necesario para ejecutar una aplicación: el código, el tiempo de ejecución, las bibliotecas, las variables de entorno y los archivos de configuración. Una imagen se ejecuta dentro del contenedor y se construye utilizando capas.
Su software se agrega a una imagen, después de lo cual otras personas de su equipo de desarrollo pueden desarrollarlo para expandirlo y agregar otra funcionalidad.

Persistencia del 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 un excelente ajuste para cargas de trabajo no persistentes, pero no es como 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 los contenedores sean en capas: el sistema de archivos de unión combina diferentes directorios que actúan como capas separadas.
Cuando creas un contenedor con docker run, entra en estado de ejecución. A partir de ahí, podemos detenerlo, reiniciarlo y también eliminarlo. La cosa es que cuando detienes un contenedor, no parece que se haya ido para siempre o que haya desaparecido. Todavía está allí junto con sus datos en el host Docker.
Entonces, cuando lo reinicies, volverá a la vida con todos sus datos intactos, siempre que no lo elimines explícitamente con un docker rmcomando, no debes tener miedo de perder ningún dato.
Si está interesado en leer más sobre la administración de la persistencia de Docker Containers, aquí hay un gran artículo al que puede dirigirse. Es muy detallado y cubre una gran variedad de temas y preocupaciones, vale la pena leerlo.

¿Qué 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 ocupan de las aplicaciones que se inician en un contenedor, en lugar de la administración del contenedor en sí.
Definitivamente hay otras tecnologías de contenedores por ahí, y buenas en eso, pero Docker es donde está la mayor parte del desarrollo y la mayor parte de la acción. Podemos decir que Docker es para contenedores lo que VMware es para hipervisores.
Muchos de ustedes han oído hablar de la frase Java "WORA" : escriba una vez, ejecútela 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 compilado de Java y el sistema operativo. Es suficiente compilarlo en un .classformato de archivo 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 la frase "PODA"- Paquete una vez, implementado en cualquier lugar .
Su aplicación puede escribirse en cualquier idioma, podría implementarse en cualquier sistema operativo y podría tener una gran variedad de controladores, complementos, extensiones y bibliotecas que deben empaquetarse.
La aplicación completa está empaquetada en una sola imagen, y esta imagen se utiliza para ejecutarse en una amplia variedad de sistemas.
Aunque, Docker afirma que apoya 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 comenzó Docker

Docker Inc. , la compañía más importante y el principal patrocinador de la tecnología de contenedores que actualmente está cambiando el mundo, es una empresa tecnológica con sede en San Francisco. Sin embargo, Docker originalmente no estaba en el negocio de cambiar la forma en que construimos, enviamos y ejecutamos aplicaciones.
La compañía comenzó como una plataforma como un proveedor de servicios dotCloud Inc . La idea detrás del negocio era ofrecer una plataforma de desarrollador en la parte superior de los servicios web de Amazon . Detrás de escena, en dotCloud Inc *, utilizaban esta tecnología de gestión de contenedores y tiempo de ejecución funky como su principal motor de implementación.
Entonces, mientras que su negocio principal de vender una plataforma de desarrolladores en la parte superior de AWS estaba menguando, estaban sentados en silencio sobre algo especial. En 2013, decidieron hacer un giro importante y apostar al negocio por esta tecnología de contenedor que llamaban Docker , y hoy Docker Inc. es considerada 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 el mismo que Docker Inc. Son un importante patrocinador y la fuerza impulsora detrás de él, pero Docker, la tecnología de contenedores, pertenece a la comunidad. Si lo miras, te darás cuenta de que todo el mundo está contribuyendo desde IBM, Cisco, Microsoft, Red Hat, etc.
Lo primero y lo más importante, es el código abierto. Esto significa que todos y cada uno es libre de contribuir, descargarlo, modificarlo y usarlo siempre que cumplan con los términos de la licencia de Apache versión 2.
El código está allí para que el mundo lo vea en GitHub. Los componentes de Core 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, puedes ver el ciclo de lanzamiento planeado que prácticamente logran.
El proyecto Docker se trata de proporcionar herramientas abiertas impresionantes para construir, enviar y ejecutar mejor las aplicaciones modernas. 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 simple hipervisor, bueno, el proyecto Docker es mucho más que un simple motor Docker.
El motor Docker es la pieza central del software para construir imágenes, detener y ejecutar contenedores. Es el tipo de tecnología central que todas las demás tecnologías de proyectos de Docker, más las herramientas de terceros, construyen y desarrollan.
Tecnología relacionada con el motor Docker
Si colocamos el motor Docker aquí en el medio como una tecnología central, todo lo demás, como el agrupamiento, la organización, el registro y la seguridad, se construirán alrededor del motor y se conectarán 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 de imágenes, especialmente Docker Hub, se están convirtiendo literalmente en las tiendas de aplicaciones o en las tiendas de Google Play de TI para empresas.
Al igual que la App Store es fundamental para todo lo que haces en tu iPhone, Docker Hub o potencialmente cualquier registro de contenedores de terceros que decidas usar, también es el centro de todo lo que haces con los contenedores.
Docker Hub
Los registros de contenedores, en el nivel más alto y más básico, son lugares para almacenar y recuperar imágenes de contenedores. Docker Hub es el registro oficial de Docker Inc. pero también hay muchos registros de terceros.
Cuando ingreses a Docker Hub, verás 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 usted está alojando Docker en su computadora portátil. Tu Docker está limpio o, mejor dicho, no tiene ninguna imagen.
Los contenedores se ejecutan en imágenes, por lo que tener ninguno significa que no puede ejecutar ningún contenedor. Naturalmente, lo primero que querría hacer es arrastrar (descargar) una imagen a su host Docker.
Por ejemplo, vamos a tirar una imagen de MongoDB a nuestro host Docker. Una vez que haya descargado e instalado Docker para su plataforma respectiva:
Primero, ejecute el docker pscomando: esto le muestra una lista de contenedores instalados:
docker ps
Para tirar de MongoDB, ejecute el docker pull mongocomando - esto extrae la última versión del repositorio:
docker pull mongo
Por último, ejecute el docker imagescomando; esto le muestra su lista de imágenes:
imágenes docker

Corriendo imagenes

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
Correr docker-psahora nos indicará con:
Docker esta corriendo
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 tirar hacia abajo y agrietarse.
¿Significa esto que cualquier persona con Docker y acceso a Internet puede acceder y descargar mis cosas?
Para los repositorios públicos, sí. Están abiertos al mundo, o al menos están 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 el mundo, simplemente márquelos como privados.
¿Pueden todos empujar a mi propio repositorio y enviar código?
Los repositorios públicos están disponibles para que todos los puedan extraer, pero solo usted o las cuentas que están autorizadas pueden empujarlo.
Solo se puede acceder a los repositorios privados por personas o cuentas a las que se les otorga específicamente permisos.
La mayoría de los registros en estos días le permiten definir organizaciones y equipos.
¿Están mis repositorios seguros?
Hay más en la seguridad del registro que establecer permisos y esconderse detrás de los firewalls ... ¿confiar?
Al bajar las imágenes, ¿cómo sabemos que podemos confiar en lo que estamos obteniendo? Es absolutamente necesario saber que puedes confiar en lo que estás haciendo. 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 parecen a esto:
Una aplicación está escrita, modificada, parcheada y actualizada. 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 realizar realmente no interrumpa la aplicación.
Suponiendo que la prueba salga bien, la enviamos a nuestro Registro de Contenedores . 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 Registro de Contenedores en el medio es el punto de giro o, más bien, el centro muerto de estos tipos 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 llevarlos al desarrollo, prueba o incluso a un entorno de producción.

Orquestación de contenedores

Si el concepto de orquestación de contenedores es completamente extraño o parcial, hagamos una comparación en la vida real:
En el baloncesto, hay muchos jugadores. En cualquier punto 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 un equipo de entrenamiento. Organizan a todos, les dicen a las personas qué hacer, dónde ir, hacer llamadas, etc.
El equipo está realizando muchas tareas específicas y únicas, organizadas por un entrenador o un equipo de entrenamiento. Lo mismo ocurre con nuestras aplicaciones: generalmente están formadas por un conjunto de servicios individuales o pequeños que están organizados de tal manera que actúan como una única aplicación unificada. Al igual que un equipo de baloncesto.
Por lo tanto, casi cualquier aplicación contenida en contenedores, sin duda alguna, una aplicación digna de producción, estará compuesta de múltiples contenedores interconectados, que probablemente abarquen múltiples hosts, y tal vez incluso múltiples infraestructuras en la nube. Y si estamos hablando de una gran cantidad de componentes en nuestra aplicación: muchos microservicios que abarcan miles de contenedores en decenas o cientos de hosts, honestamente, no queremos que se cosan manualmente todo eso.
Lo que necesitamos es un tipo de plan de juego, algo que componga todo en la aplicación general. Estamos pensando en cosas como:
  • Definición de todos los diferentes componentes o servicios que conforman la aplicación.
  • Cómo encajarlos
  • Redes
  • Colas de mensajes
  • API llamadas, etc ...
Luego, una vez que nuestra aplicación está definida, necesitamos una manera 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 esto se trata la orquestación de contenedores. Definiendo nuestra aplicación, cómo interactúan todas las partes, aprovisionando la infraestructura y luego implementando 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.
  • Docker Machine provisiones Docker nos aloja en las instalaciones, en la nube.
  • Docker componer se utiliza para definir y componer nuestra aplicación de múltiples contenedores. 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 programar realmente nuestros contenedores a través de nuestra propiedad 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, está el ecosistema más amplio. Tecnologías y marcos como Kubernetes, Mesosphere Datacenter OS, CoreOS, OpenStack Magnum. Todos estos pueden usarse 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.

Conclusión

Algunos de ustedes serán expertos en tecnología, desarrolladores, administradores de sistemas y DevOps, mientras que otros se enfocarán más en la administración y, en general, menos en la práctica. Si eres uno de los tipos prácticos, haz solo eso, pon tus manos en estas cosas.
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 acople una aplicación, cree imágenes, inicie contenedores, destrúyalos, destrúyalos, simplemente ensucie sus manos.

No hay comentarios.:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

Post Top Ad

Your Ad Spot

Páginas