OpenShift vs. Docker

Docker pro­po­r­cio­nó el triunfo de la vi­r­tua­li­za­ción basada en co­n­te­ne­do­res. Este software es una te­c­no­lo­gía básica para crear y ejecutar co­n­te­ne­do­res de apli­ca­cio­nes. Los de­sa­rro­lla­do­res utilizan Docker en sus po­r­tá­ti­les, por ejemplo, para es­ta­n­da­ri­zar los flujos de trabajo de de­sa­rro­llo. OpenShift, en cambio, se encuentra en el otro extremo del espectro de la vi­r­tua­li­za­ción y cubre re­qui­si­tos ope­ra­ti­vos de toda una or­ga­ni­za­ción, que utilizan como base los entornos de nube pública y privada.

Las dos te­c­no­lo­gías no son en absoluto co­m­pe­ti­do­ras directas. De hecho, OpenShift solía basarse in­di­re­c­ta­me­n­te en Docker y aún utiliza su formato de co­n­te­ne­do­res. A co­n­ti­nua­ción, ofrecemos una visión general y ana­li­za­mos los puntos fuertes y débiles, al igual que los re­s­pe­c­ti­vos es­ce­na­rios de im­ple­me­n­ta­ción de estas te­c­no­lo­gías.

En las di­s­cu­sio­nes online sobre OpenShift y Docker, así como en las pu­bli­ca­cio­nes de los blogs, a menudo se plantea la pregunta: “¿Cuál es la mejor he­rra­mie­n­ta para la vi­r­tua­li­za­ción de co­n­te­ne­do­res?”. Sin embargo, son te­c­no­lo­gías muy distintas. Tanto OpenShift como Docker tienen su razón de ser y suelen uti­li­zar­se de forma co­m­ple­me­n­ta­ria.

Hacer una co­m­pa­ra­ción entre las te­c­no­lo­gías OpenShift y Docker es difícil. De hecho, sería como preguntar: “¿Qué es mejor, un coche o el tra­n­s­po­r­te público?”. En principio, ambos tienen una tarea similar: trasladar personas y me­r­ca­n­cías. Además, las ruedas también están presentes en ambas te­c­no­lo­gías, pero son conceptos to­ta­l­me­n­te di­fe­re­n­tes.

A di­fe­re­n­cia de los co­n­te­ne­do­res físicos, el equi­va­le­n­te virtual no es un elemento de tra­n­s­po­r­te. Siendo este el caso, uti­li­ce­mos una analogía biológica para en­te­n­de­r­lo mejor. Los co­n­te­ne­do­res de apli­ca­cio­nes y las células bio­ló­gi­cas tienen mucho en común. Ambas son una unidad fu­n­da­me­n­tal de in­fo­r­ma­ción en­ca­p­su­la­da y sellada ex­te­r­na­me­n­te que en conjunto crea vida.

En el mundo de los seres vivos, la evolución tuvo lugar desde los or­ga­ni­s­mos uni­ce­lu­la­res hasta los or­ga­ni­s­mos plu­ri­ce­lu­la­res. Del mismo modo, en el mundo virtual se pasó de los co­n­te­ne­do­res in­di­vi­dua­les a las redes or­que­s­ta­das de co­n­te­ne­do­res que in­ter­ac­túan entre ellos. Por esta razón, los retos asociados a la mu­l­ti­ce­lu­la­ri­dad se asemejan a los desafíos que surgen de la in­ter­ac­ción de varios co­n­te­ne­do­res.

Las células bio­ló­gi­cas y los co­n­te­ne­do­res de apli­ca­cio­nes deben co­mu­ni­car­se entre sí. Según sea necesario, tienen que volver a crecer o morir. Los recursos totales di­s­po­ni­bles deben, por tanto, di­s­tri­bui­r­se entre las unidades in­di­vi­dua­les. Todo esto debe estar bien coor­di­na­do para que el sistema global pueda reac­cio­nar a las demandas ca­m­bia­n­tes y pe­r­ma­ne­cer estable a largo plazo. Con el siguiente resumen, te ex­pli­ca­mos la gama de vi­r­tua­li­za­ción de co­n­te­ne­do­res, desde Docker hasta OpenShift:

La pregunta de cuál es mejor solo puede re­s­po­n­de­r­se adoptando una pe­r­s­pe­c­ti­va es­pe­cí­fi­ca. Es decir, depende del punto de vista para saber cuál de los dos enfoques es “mejor”. Este también es el caso de la co­m­pa­ra­ción entre OpenShift y Docker.

Docker po­pu­la­ri­zó la vi­r­tua­li­za­ción de co­n­te­ne­do­res y desplazó en gran medida a las máquinas virtuales (VM), que eran do­mi­na­n­tes en ese momento. El triunfo de los co­n­te­ne­do­res web re­vo­lu­cio­nó la forma de construir, em­pa­que­tar y ejecutar apli­ca­cio­nes, dado que los co­n­te­ne­do­res son una unidad de software es­ta­n­da­ri­za­da. Estos pueden uti­li­zar­se sin problemas siempre y cuando se disponga del co­rre­s­po­n­die­n­te runtime de co­n­te­ne­do­res.

A di­fe­re­n­cia de las an­te­rio­r­me­n­te om­ni­pre­se­n­tes, pero bastante pesadas máquinas virtuales, los co­n­te­ne­do­res son ligeros. De esta manera, se pueden ejecutar miles de co­n­te­ne­do­res en un solo host. Esta ventaja inherente a la vi­r­tua­li­za­ción de los co­n­te­ne­do­res condujo a la extensión del uso de ar­qui­te­c­tu­ras de mi­cro­se­r­vi­cios di­s­tri­bui­dos. En lugar de construir una apli­ca­ción mo­no­lí­ti­ca, se divide el ámbito funcional en co­m­po­ne­n­tes in­di­vi­dua­les y cada co­m­po­ne­n­te se empaqueta como un servicio en su propio co­n­te­ne­dor. A co­n­ti­nua­ción, los co­n­te­ne­do­res se inician y los servicios se comunican entre sí a través de la red.

El enfoque de mi­cro­se­r­vi­cios es es­pe­cia­l­me­n­te práctico para el de­sa­rro­llo de software porque permite utilizar las te­c­no­lo­gías más adecuadas para cada servicio. En lugar de estar atados a lenguajes y pa­ra­di­g­mas de pro­gra­ma­ción in­di­vi­dua­les, pueden variar entre los servicios. Además, a medida que se añaden nuevas te­c­no­lo­gías, es más fácil re­im­pla­n­tar servicios in­di­vi­dua­les.

La po­si­bi­li­dad de clonar varios co­n­te­ne­do­res se­me­ja­n­tes a partir de una imagen de co­n­te­ne­dor redunda en la es­ca­la­bi­li­dad del sistema global. Si la demanda aumenta, se ponen en marcha co­n­te­ne­do­res adi­cio­na­les y el servicio re­s­pe­c­ti­vo escala ho­ri­zo­n­ta­l­me­n­te. Sin embargo, esto requiere un sistema que supervise los co­n­te­ne­do­res en ejecución y los termine o, mejor dicho, inicie nuevos co­n­te­ne­do­res cuando sea necesario. Además, las so­li­ci­tu­des entrantes deben di­s­tri­bui­r­se a los co­n­te­ne­do­res in­di­vi­dua­les.

Con la es­ca­la­bi­li­dad, la co­m­ple­ji­dad del sistema crece co­n­si­de­ra­ble­me­n­te y, por tanto, es re­co­me­n­da­ble tener en cuenta los si­guie­n­tes aspectos:

• Recepción de las so­li­ci­tu­des a través del balance de carga
• Di­s­tri­bu­ción de las tareas a los co­n­te­ne­do­res in­di­vi­dua­les
• Su­pe­r­vi­sión del estado de las in­s­ta­n­cias del co­n­te­ne­dor
• Terminar e iniciar nuevas in­s­ta­n­cias
• Es­ta­ble­cer una red entre los co­n­te­ne­do­res
• Mantener los co­n­te­ne­do­res o imágenes con ac­tua­li­za­cio­nes, etc.

Todo ello supone una enorme so­bre­ca­r­ga ad­mi­ni­s­tra­ti­va, pero eso no es todo. Además, está el ma­n­te­ni­mie­n­to del propio sistema ad­mi­ni­s­tra­ti­vo. Este nivel de control, que realiza todos los puntos me­n­cio­na­dos an­te­rio­r­me­n­te, también debe ser mantenido, su­pe­r­vi­sa­do y provisto de ac­tua­li­za­cio­nes. Por supuesto, nunca debería haber una pérdida de re­n­di­mie­n­to notable por parte del usuario y la seguridad de todo el sistema debe estar ga­ra­n­ti­za­da en todo momento.

Por último, pero no menos im­po­r­ta­n­te, también se ha de destacar la or­que­s­ta­ción de los clústeres de co­n­te­ne­do­res a través de los límites de la in­frae­s­tru­c­tu­ra. A más tardar en este punto, la co­m­ple­ji­dad del sistema ha crecido hasta tal punto que es difícil para el ser humano de manejar. Por eso, las or­ga­ni­za­cio­nes necesitan he­rra­mie­n­tas es­pe­cia­les para hacer frente a esta co­m­ple­ji­dad, por lo que surgen las al­te­r­na­ti­vas a OpenShift.

Como ya se ha me­n­cio­na­do, OpenShift y Docker son te­c­no­lo­gías que están muy alejadas entre ellas. La co­m­pa­ra­ción tiene más sentido cuando se considera el software “Ku­be­r­ne­tes”, también conocido como K8s. El paso de Docker a K8s es co­m­pa­ra­ble a la tra­n­si­ción de un organismo uni­ce­lu­lar a un organismo mu­l­ti­ce­lu­lar. Y de manera similar, el paso de K8s a OpenShift es co­m­pa­ra­ble a la tra­n­si­ción de un solo organismo a un grupo de seres vivos. Desde este punto de vista, exa­mi­ne­mos de nuevo las te­c­no­lo­gías uti­li­za­das:

De hecho, OpenShift se basa en K8s, que a su vez se basó ori­gi­na­l­me­n­te en Docker, pero Docker y K8 se separaron hace poco tiempo. Veamos los dos extremos del espectro (OpenShift y Docker) en detalle.

Docker es una te­c­no­lo­gía de código abierto que puede uti­li­zar­se para em­pa­que­tar apli­ca­cio­nes en co­n­te­ne­do­res o ejecutar co­n­te­ne­do­res de apli­ca­cio­nes. Se utiliza para crear co­n­te­ne­do­res de apli­ca­cio­nes po­r­tá­ti­les y au­to­co­n­te­ni­dos que pueden eje­cu­tar­se en un entorno de nube o en hardware in­fo­r­má­ti­co local. Este software proviene de la empresa homónima Docker Inc., que ofrecen, además de la versión gratuita de código abierto, varios productos por los que cobra una cuota.

Docker es tres he­rra­mie­n­tas en una:

1. Docker Engine, que pro­po­r­cio­na las fu­n­cio­na­li­da­des pri­n­ci­pa­les de la vi­r­tua­li­za­ción de co­n­te­ne­do­res.
2. Docker Compose, una fu­n­cio­na­li­dad que orquesta múltiples co­n­te­ne­do­res como un compuesto.
3. Docker Swarm, un modo que permite la or­que­s­ta­ción de clústeres de co­n­te­ne­do­res en múltiples hosts.

Docker Engine consta a su vez de tres co­m­po­ne­n­tes pri­n­ci­pa­les:

1. El daemon de Docker, que se ejecuta como dockerd en el host.
2. La API de Docker, que es pro­po­r­cio­na­da por el daemon de Docker. El daemon de Docker se dirige y controla a través de la API.
3. La interfaz de la línea de comandos (CLI), que se utiliza como un comando de Docker para co­mu­ni­car­se con la API de Docker.

El Docker Engine es nativo de Linux. También hay un paquete fácil de instalar para Mac y Windows llamado Docker Desktop. Docker Desktop si­m­pli­fi­ca la co­n­fi­gu­ra­ción e incluye una interfaz gráfica de usuario. Además, se incluyen otras te­c­no­lo­gías derivadas de Docker, como, por ejemplo, Docker Compose.

Docker se ha es­ta­ble­ci­do como el estándar para la vi­r­tua­li­za­ción de co­n­te­ne­do­res durante la última década. Por ello, no es de extrañar que el software funcione en una amplia variedad de sistemas ope­ra­ti­vos. Además, Docker es re­la­ti­va­me­n­te fácil de instalar y también es fácil empezar con la fu­n­cio­na­li­dad básica. Otra ca­ra­c­te­rí­s­ti­ca que resulta es­pe­cia­l­me­n­te práctica es la enorme gama de co­n­te­ne­do­res de imágenes pre­di­se­ña­dos. Estos contienen entornos de software para el de­sa­rro­llo y la pro­du­c­ción y pueden obtenerse en los registros públicos de co­n­te­ne­do­res. En co­m­pa­ra­ción con OpenShift, Docker es una te­c­no­lo­gía mucho menos compleja.

Los mayores in­co­n­ve­nie­n­tes de Docker provienen de su cre­ci­mie­n­to orgánico a lo largo de los años. Lo que comenzó como una vi­r­tua­li­za­ción de co­n­te­ne­do­res se ha co­n­ve­r­ti­do hoy en día en una pla­ta­fo­r­ma mo­no­lí­ti­ca que hace de­ma­sia­das cosas a la vez. Con Docker Swarm y Docker Compose, el uso de Docker va mucho más allá de sus objetivos ori­gi­na­les. En co­m­pa­ra­ción con los enfoques modernos, Docker es re­la­ti­va­me­n­te débil en términos de seguridad y re­n­di­mie­n­to.

Ac­tua­l­me­n­te, Docker está fue­r­te­me­n­te po­si­cio­na­do como una he­rra­mie­n­ta para el de­sa­rro­llo de software. Los entornos de de­sa­rro­llo locales se en­ca­p­su­lan como co­n­te­ne­do­res junto con las he­rra­mie­n­tas y los flujos de trabajo uti­li­za­dos. Las imágenes creadas de este modo pueden co­m­pa­r­ti­r­se entre los de­sa­rro­lla­do­res y sentar las bases de un de­sa­rro­llo es­ta­n­da­ri­za­do y re­pro­du­ci­ble.

Además, Docker sirve de base para las te­c­no­lo­gías co­n­s­trui­das sobre él. Las he­rra­mie­n­tas de de­sa­rro­llo como, por ejemplo, DDEV y Lando, utilizan Docker para si­m­pli­fi­car el de­sa­rro­llo local. Con pla­ta­fo­r­mas como Portainer y Mirantis (antes Docker En­te­r­pri­se), existen potentes he­rra­mie­n­tas para la or­que­s­ta­ción de co­n­te­ne­do­res.

Como ya se ha me­n­cio­na­do, OpenShift se sitúa al otro lado del espectro de co­n­te­ne­do­res. Este software se utiliza para construir entornos de apli­ca­ción y de­sa­rro­llo di­s­tri­bui­dos y es­ca­la­bles según el modelo “platform as a service” (PaaS). Para ello, pro­po­r­cio­na un entorno de ejecución completo en el que se de­s­plie­gan, ejecutan, gestionan y orquestan los co­n­te­ne­do­res. Las he­rra­mie­n­tas in­te­gra­das si­m­pli­fi­can los flujos de trabajo de de­sa­rro­llo e im­pla­n­ta­ción.

Se utiliza una di­s­tri­bu­ción especial de Ku­be­r­ne­tes (K8s) como base de OpenShift. Esto puede de­s­ple­gar­se a través de los límites de la nube y la in­frae­s­tru­c­tu­ra, logrando una ex­pe­rie­n­cia de usuario co­n­si­s­te­n­te. La fu­n­cio­na­li­dad principal del K8 se co­m­ple­me­n­ta con funciones de seguridad y su­pe­r­vi­sión y se basa en la gestión ce­n­tra­li­za­da de políticas. Con esto, se garantiza un alto nivel de calidad en todo el entorno de software de una or­ga­ni­za­ción.

En primer lugar, OpenShift domina la co­m­ple­ji­dad operativa asociada a la ad­mi­ni­s­tra­ción de clústeres K8s au­to­ge­s­tio­na­dos. Se pueden gestionar de forma ce­n­tra­li­za­da varios clústeres K8s a través de los límites de las in­frae­s­tru­c­tu­ras de nube pública y privada. Siguiendo el enfoque de PaaS, los de­sa­rro­lla­do­res internos pueden solicitar au­to­má­ti­ca­me­n­te recursos para sus proyectos a través de una interfaz web. Las he­rra­mie­n­tas y los flujos de trabajo in­te­gra­dos para in­te­gra­ción continua (Co­n­ti­nuous In­te­gra­tion) y entrega continua (Co­n­ti­nuous Delivery) (CI/CD) completan la gama de funciones y permiten reducir drá­s­ti­ca­me­n­te los plazos de entrega.

OpenShift se basa en una di­s­tri­bu­ción especial K8s para orquestar los co­n­te­ne­do­res y los clústeres. Ori­gi­na­l­me­n­te, K8s se basaba en Docker como tiempo de ejecución de co­n­te­ne­do­res, pero esta de­pe­n­de­n­cia se ha disuelto. En su lugar, se utiliza el container runtime interface de la Open Container Ini­tia­ti­ve (CRI-O), que tiene ventajas en términos de seguridad y re­n­di­mie­n­to.

En general, OpenShift resulta positivo por sus medidas de seguridad in­te­gra­das. Con “Quay”, se dispone de un registro de co­n­te­ne­do­res es­pe­cia­l­me­n­te protegido. La au­to­ri­za­ción y la au­te­n­ti­ca­ción de extremo a extremo limitan el acceso de los usuarios a las distintas áreas del sistema. Además, el alo­ja­mie­n­to de clústeres in­di­vi­dua­les en di­fe­re­n­tes regiones geo­grá­fi­cas permite un mejor cu­m­pli­mie­n­to en términos de pro­te­c­ción de datos.

OpenShift solo se ejecuta en sistemas ope­ra­ti­vos es­pe­cia­les de Red Hat, como “Red Hat En­te­r­pri­se Linux CoreOS” (RHCOS) y “Red Hat En­te­r­pri­se Linux” (RHEL) y se considera que la in­s­ta­la­ción requiere mucho tiempo. De hecho, en los proyectos de mayor en­ve­r­ga­du­ra, la in­s­ta­la­ción puede durar varias semanas. Debido a las estrictas pre­cau­cio­nes de seguridad, no se pueden utilizar todas las imágenes de los co­n­te­ne­do­res de los registros públicos.

Las “platform as a service” (PaaS), los “software as a service” (SaaS) y los “co­n­tai­ne­rs as a service” (CaaS) de las empresas se im­ple­me­n­tan sobre la base de OpenShift. El objetivo se centra cla­ra­me­n­te en las grandes or­ga­ni­za­cio­nes y, de hecho, OpenShift es demasiado grande y difícil de manejar para los de­sa­rro­lla­do­res in­di­vi­dua­les.

Aunque sea difícil comparar di­re­c­ta­me­n­te OpenShift y Docker, existe la po­si­bi­li­dad de comparar las ca­ra­c­te­rí­s­ti­cas in­di­vi­dua­les de las dos te­c­no­lo­gías. Para ser más exhau­s­ti­vos, volvemos a incluir a Ku­be­r­ne­tes (K8s) en la co­m­pa­ra­ción: