Recientemente he estado haciendo un uso frecuente de Docker. Cosas que recordar, problemas y dudas, me han llevado a repasar su instalación, uso y algunos issues (en especial uno que no dejaba de dar vueltas en mi cabeza). Toda esta revisión (y la investigación asociada) me llevó a pensar en algunas cosas y (re)descubrir otras.
Curiosamente, esto ha coincidido con el reciente lanzamiento del framework de «contenedorización» (containerization) de Apple1-6,8-11, que si bien agrega una variable más al asunto, puede ser la respuesta a poder tener algo más «nativo» en macOS que nos permita obtener una mejor experiencia de los dichosos contenedores y, en general, de todo lo que uno puede experimentar gracias a la virtualización.
Bueno, ahora algo de contexto. Independientemente de las limitaciones de hardware que pudiera haber (me refiero, por ejemplo, a cosas como la imposibilidad de implementar virtualizaciones anidadas en el M1), consideremos, por simplicidad, lo que tenemos actualmente disponible en macOS. Por un lado, apoyándonos en productos de código abierto o comerciales, la posibilidad de tener máquinas virtuales y, por otro, contenedores.
Sabemos que las máquinas virtuales son lo más «pesado» (cuando virtualizamos todo el entorno que una computadora física provee) y la literatura nos habla de la ventaja que los contenedores ofrecen en respuesta, al ser una alternativa más «ligera». Este «peso» del que hablamos se refiere a la potencia de cómputo que necesitamos (CPU y memoria principalmente) del anfitrión (la computadora que corre los programas que dan vida a la máquina virtual o a los contenedores, que serían los huéspedes). Explicaciones7 que van acompañadas de diagramas como el siguiente, a las o a los que todos dicen «ok».
Fuente: ver referencia 7.
Pero, lo que resulta un poco obscuro (y nadie lo pregunta tampoco) es cómo se consigue esa «ligereza» que los contenedores implican. Apoyándome en el diagrama anterior, la explicación es simple. El «hypervisor» no es más que el programa que permite crear y ejecutar las máquinas virtuales. Por su parte, los «supporting files runtime» del lado de los contenedores son, digámoslo así por el momento, servicios que el kernel del sistema operativo provee. En este caso muy en particular, el kernel Linux. Así, lo siguiente será más fácil de entender.
La literatura también nos dice que «macOS no puede ejecutar contenedores de Linux de forma nativa.» ¿Qué quiere decir esto? Bueno, pues está muy relacionado con esa enorme interrogante que he mencionado y tratado de dar una primera aproximación a su entendimiento en el párrafo previo. Primero, entendamos que en el entorno propio de linux, los contenedores obtienen su ligereza de gracias a características propias del kernel para llevar a cabo la virtualización (namespaces y cgroups). El kernel, por diseño, está preparado para «virtualizar» aplicaciones
Estas características no existen en macOS ni en Windows, por lo que todas las soluciones en ambos se basan en correr, al final, una máquina virtual Linux (de alguna manera creada para ser «más ligera») como capa intermedia, a partir de la cual es posible desprender los contenedores (una máquina virtual que provee esos «supporting files runtime»).
Esta es la razón por la que uno necesita levantar Docker Desktop para poder ejecutar los contenedores. La percepción general es que se necesita este producto para poder administrar las imágenes y los contenedores pero es un hecho que lo mismo se puede hacer desde la línea de comando con docker y sus subcomandos.
Si bien el comando docker revisará que esté activo el proceso de soporte de segundo plano (el «demonio de Docker«) cuando es invocado, lo cierto es que busca que esa «máquina virtual ligera» esté corriendo. Esto es lo que Docker Desktop principalmente provee.
Referencias
- «WWDC25: Meet Containerization,» youtube.com, Apple Developer channel. Published: 2025.06.09; Visited: 2025.07.08. URL: https://www.youtube.com/watch?v=JvQtvbhtXmo.
- Apple, Inc., github.com, repositories. Visited: 2025.07.08. URL: https://github.com/apple.
- «Apple supercharges its tools and technologies for developers to foster creativity, innovation, and design,» apple.com, press release, web. Published: 2025.06.09; visited: 2025.07.08. URL: https://www.apple.com/newsroom/2025/06/apple-supercharges-its-tools-and-technologies-for-developers/.
- ________, «containerization«, github.com, repository. Visited: 2025.07.08. URL: https://github.com/apple/containerization.
- ________, «Virtualization Framework«, Apple Developer Documentation, web. Visited: 2025.07.08. URL: developer.apple.com/documentation/virtualization.
- ________, «Package containerization«, apple.github.io, web. Visited: 2025.07.08. URL: https://apple.github.io/containerization/documentation/.
- «Containers vs. VMs«, redhat.com, web. Updated: 2023.12.20; visited: 2025.07.17. URL: https://www.redhat.com/en/topics/containers/containers-vs-vms.
- «Getting Started with the Static Linux SDK«, swift.org, web. Visited: 2025.07.08. URL: https://www.swift.org/documentation/articles/static-linux-getting-started.html.
- «Open Container Initiative«, The Linux Foundation Projects, web. Visited: 2025.07.08. URL: https://opencontainers.org/.
- «Kata Containers«, github.com, repository. Visited: 2025.07.08. URL: https://github.com/kata-containers/kata-containers.
- Simardeep Singh, «Apple’s Containerization Framework and the Future of Secure Computing«, medium.com, blog. Published: 2025.06.09; visited: 2025.07.08. URL: https://medium.com/@simardeep.oberoi/apples-containerization-framework-and-the-future-of-secure-computing-ba68f2e8097d.
Dr. Edu 