Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Pero este auge de la Inteligencia Artificial, este crecimiento de la palabra IA o Inteligencia Artificial ha venido a reemplazar o hacer que nos olvidemos de otros buzzwords en lo que es el mundo de IT, tanto en desarrollo, en sistemas, en DevOps. Y uno de esos buzzwords que antes sonaba un montón por todos lados era Docker.
ese buzzword ha decaído mucho últimamente pero eso no significa que docker como herramienta en general se ha dejado de utilizar y sobre todo pues docker desktop como tal
Hola a todos y bienvenidos a Dev & Ops.
este es su espacio favorito de desarrollo, tecnología, DevOps y su cultura en general. Y el día de hoy, mi buen amigo y co-host Juan Ramos no me va poder acompañar, así que van a tener que escucharme solo a mí hablar el día de hoy. Pero siempre nos ponemos de acuerdo con Juan cuando alguno de nosotros dos no puede estar, obviamente por motivos de fuerza mayor. Nos ponemos de acuerdo en siempre
para ustedes, las personas que nos ven y nos escuchan, a quienes siempre le agradecemos por su sintonía, por el tiempo que se toman, no solo de ver y escuchar nuestro contenido, sino también de compartirlo a otros, a otras personas, porque nuestro objetivo es poderles generar valor. Y el día de hoy quiero hablar, quiero tocar un tema que a mí en lo personal me resulta muy interesante y espero que sea de la misma manera.
para ustedes también y tiene que ver con Docker Desktop. Hoy quiero hablar de usos de Docker Desktop en la era de la inteligencia artificial y es que ahorita en 2026, desde hace dos años realmente, pero los últimos meses y ahorita comenzando en 2026.
los ojos de la industria están puestos en la inteligencia artificial y con mucha razón. Hay una razón válida para ella y para ello y es que esta nueva tecnología, que es la inteligencia artificial, ha trastornado y ha cambiado muchos flujos. De hecho, ha cerrado trabajos, ha cerrado compañías y tenemos que abrazar esa realidad.
Pero este auge de la Inteligencia Artificial, este crecimiento de la palabra IA o Inteligencia Artificial ha venido a reemplazar o hacer que nos olvidemos de otros buzzwords en lo que es el mundo de IT, tanto en desarrollo, en sistemas, en DevOps. Y uno de esos buzzwords que antes sonaba un montón por todos lados era Docker.
ese buzzword ha decaído mucho últimamente pero eso no significa que docker como herramienta en general se ha dejado de utilizar y sobre todo pues docker desktop como tal
⁓ Y es lo que quiero yo hoy hablar con ustedes, es lo que quiero compartirle un par de usos donde tal vez lo podemos considerar. Ya dijimos que el enfoque está de toda la tecnología, está en Inteligencia Artificial, eso hace que los equipos de desarrollo, los equipos de sistemas, los equipos de DevOps,
También hayan cambiado su enfoque, su mirada a lo que tiene que ver con la inteligencia artificial. Su flujo de trabajo ahora incluye probablemente correr modelos, LLMs locales o correrlos en la nube, agentes de inteligencia artificial, el desarrollo de agentes o el trabajar con agentes tooling alrededor de lo que tiene que ver con agentes o asistentes, verdad, de la inteligencia artificial.
Pero esto no ha quitado el trabajo que hemos venido haciendo siempre. Puede ser que algunos desarrolladores trabajen, pues no, esperaría yo que ya nadie haga vibe coding. Yo creo que eso se ha demostrado que el vibe coding como tal no trae los resultados que se creían o que se esperan. Pero sí, hoy en día es muy común desarrollar con agentes, estar realmente dirigiendo un agente para que produzca
el
código que yo quiero. Pero aunque hoy tengamos eso a disposición, ¿verdad? No quita que tengamos todavía estas cargas de trabajo que antes teníamos como parte de nuestro puesto de trabajo, ya sea los developers o las personas de operaciones o sistemas, ¿verdad? El continuar desarrollando. De nuevo, tal vez un agente hace el heavy lifting, tal vez un agente es el que está haciendo el trabajo y yo lo estoy dirigiendo, pero hay que seguir desarrollando.
seguir con las entregas rápidas, nuevos features de la aplicación o los servicios que nosotros manejamos y hay que continuar con despliegues y...
y entregas rápidas, la parte de seguridad y todo eso que lo terminamos haciendo o comienza en nuestro ambiente local, nuestro ambiente de desarrollo, ser un desarrollador, nuestro ambiente local desde donde interactuamos con diferentes servidores, servicios, clúster de Kubernetes, etcétera, si somos alguien de operaciones, ¿verdad? Pero justo por eso, porque tenemos que, si bien es cierto, la inteligencia artificial nos está quitando
cargas, nos está quitando la, tal vez la carga de pensar en cómo desarrollar el código o pensar en cómo hacer una configuración, cómo tal ejecutarlo, el estar pendiente de estar typeando o escribiendo todo el código, tal vez nos ha quitado eso,
en realidad seguimos con el trabajo que teníamos que hacer antes agregado a ir de la mano con cómo va avanzando este mundo de la inteligencia artificial va avanzando tan rápido que si alguien se encuentra un tutorial ahí en internet que tiene más de dos meses probablemente ya esté obsoleto cualquier tutorial que tiene que ver con inteligencia artificial de entre dos a tres meses de antigüedad probablemente ya esté obsoleto así de rápido va entonces tenemos que llevar esas dos cosas de la mano
y es ahí donde los contenedores se vuelven una herramienta importante y en nuestro local
Docker Desktop, ¿verdad? Se convierte en una herramienta que nos permite pivotar entre esos dos enfoques, ¿no? Entre el enfoque de seguir con las nuevas herramientas de Inteligencia Artificial y continuar con nuestros flujos de desarrollo que hemos estado siguiendo antes, Que la parte que hemos venido haciendo por años con Docker Desktop, y aquí, bueno, quiero aclarar, ¿no?
Probablemente no todos utilizan Docker Desktop, puede que algunos utilicen Podman.
o trabajan en un ambiente donde tienen Linux directamente y ahí nomás instalan Docker porque por algún momento Docker Desktop o Docker como tal ha recibido hate también de parte de la industria porque comenzaron a cobrar por Docker Desktop para empresas como un individuo puede seguirlo instalando en tu local para continuar con tus flujos diarios y no hay ningún problema, pero si ya como parte de empresa se comienza a utilizar
Docker Desktop y varias personas lo utilizan se ha vuelto un producto de paga, entonces eso ha generado cierto hype, quiero reconocer eso, sin embargo de cierta manera hemos venido utilizando siempre Docker Desktop o algunas personas se han pasado a Podman y el enfoque que voy a hacer yo en esta plática de hoy, en lo que quiero tratar hoy y hablar hoy va a ser en Docker Desktop porque algunas de las herramientas que les voy a mencionar o las herramientas en realidad que les voy a mencionar
han sido, están ahí, en Docker Desto, ¿verdad? Pero en fin, habiendo aclarado eso y continuando con el tema,
ese uso le damos a contenedores a Docker Desktop que hemos venido haciendo siempre, ahí están, ambientes de desarrollo locales con Docker Compose, saben ustedes, corren su backend, su base de datos, corren su frontend, corren su API, hacen mock de data, etcétera, y con eso se levantan ambientes de desarrollo locales y cada uno está aislado y no ocupa instalar
MySQL o Postgres local para correr la base de datos, no ocupo de instalar o PHP o Node.js para correr el backend, etcétera. Entonces eso sigue siendo parte de nuestro flujo, ahí está, ya lo conocemos ustedes. También tenemos Kubernetes local, verdad. Si ya tenemos Docker Desktop para otras cosas, no necesitamos instalar Minikube u otra herramienta de Kubernetes. Docker Desktop nos da Kubernetes y las personas que trabajamos en sistemas podemos probar nuestros manifestos, podemos probar nuestros
on chart nuestras configuraciones, existen limitantes, siempre han existido, pero en su mayoría podemos continuar con esas pruebas o los mismos desarrolladores si quieren probar cómo va a ser el despliegue final a producción pueden hacerlo con Kubernetes local que corre en Docker, eso siempre ha estado ahí ¿verdad?
Y si alguien de los que nos ve y nos escucha no ha aprovechado esas funcionalidades de Docker Desktop, pues yo los animo a que comiencen por ahí. Realmente que mover a contenedores nuestro flujo de trabajo es lo mejor que nos puede pasar. Es lo mejor que nos puede ocurrir. Nos quita esa carga de estar tratando de resolver dependencias, conflictos, actualizaciones y que se actualizo una cosa
esa actual, nueva versión quiebra otras funcionalidades y me quito solo ese dolor de cabeza y el aislamiento que me da los contenedores y en ambientes locales pues normalmente con Docker Desktop es algo que deberían de estar aprovechando entonces si estas primeras dos que ya mencioné que no es el enfoque solo las quiero recordar pero si no estás ahí te recomiendo que comiencen por ahí verdad ahora
Dentro de lo que tiene que ver con los nuevos flujos de trabajo que están surgiendo en nuestros equipos de desarrollo, equipos de operaciones y sistemas o en toda la cultura de DevOps en nuestras empresas, en nuestros departamentos, verdad, en todo lo que tiene que ver con estos flujos de trabajo alrededor de la inteligencia artificial, quiero traer a la mesa dos enfoques para que consideres utilizar Docker Desktop en tu ambiente local.
Y aquí el punto importante, que lo consideres, no estás obligado a hacerlo, no estoy de nuevo, no estoy haciendo una campaña como tal en favor de Docker Desktop, simplemente yo siempre estoy a favor de utilizar la herramienta más simple y la que ya tengo disponible para trabajar. Y si ya estoy trabajando con Docker Desktop para levantar mi ambiente local, ya estoy trabajando con Docker Desktop para levantar mi base de datos local y mi API y mi front-end,
de repente pudiera aprovechar estas dos funcionalidades que voy a mencionar ahorita para que se mantengan dentro de Docker y no tener que levantar más servicios, estar pendientes de otras herramientas y probablemente la integración va a ser más fácil para mí, ¿verdad? Pero bueno.
La primera funcionalidad que quiero traerles para que consideren es correr modelos locales. es que sabemos que Olamas es herramienta más común en la que ha ganado el mercado en lo que tiene que ver con correr los modelos locales, los LLMs, ¿verdad? Y, pues, es una gran herramienta, ¿no? Aquí no venimos a ponerlo en discusión el hecho de que Olamas es una gran herramienta y de reemplazar una
herramienta con otra no siempre es porque la herramienta con la cual estoy reemplazando la anterior es mejor, sino que muchas veces es más conveniente para mí o es mejor para mí por mi flujo de trabajo, por mi funcionalidad, pero no necesariamente es mejor, entonces aquí no estoy viniendo a decir de que...
la funcionalidad de Docker Desktop es mejor que la de Lama, simplemente pudiera trabajar mejor ya que está integrado. Docker Desktop tiene una funcionalidad que se llama Docker Model Runner, verdad, Docker Model Runner que básicamente te permite bajar y ejecutar modelos LLMs
en docker, los baja de docker del docker hub o los baja de cualquier oci registry muchas empresas tienen sus propios registry de imágenes de contenedores y pues mientras sea un oci o c-i registry verdad de ahí puede bajar los contenedores y permite correrlos verdad permite correr los modelos de de los LLMs y esto no sólo es ollama en un contenedor sino que
Docker como tal está orquestrando, bajar el modelo y ejecutarlo y lo sirve en modelos via APIs tipo OpenAI y APIs tipo ollama verdad, y es que sabemos o para quienes no sepan verdad que la interacción o el tipo de API como el de OpenAI es el que se vuelto como estándar de la industria.
incluso Gemini, Grog, el mismo Anthropic han lanzado sus APIs que sigan el estándar de OpenAI porque es el que comenzó a utilizar la comunidad de manera masiva, verdad, y entonces estos nuevos modelos comenzaron como que lanzando su propio API y es entendible, no, pero como que no querían comenzar a aprender el tipo del otro de los
APIs y la gente se quedaba con el de OpenAI, entonces estos modelos han comenzado, comenzaron a estandarizar su tipo de llamados de API al mismo estilo que lo hacía con el que comenzó OpenAI, de hecho yo desarrollo en Python cosas que tienen que ver con sistemas y con S &Reno, pero cuando interactúo con los modelos de inteligencia artificial uso la librería de OpenAI y no solo yo, es un estándar entre lo que
desarrollan agentes o los que desarrollan MCP servers usar la librería de Python de OpenAI ya sea que vayas a conectarte a Anthropic, sea que vayas a conectarte a Gemini o modelos locales, verdad. Entonces este Docker model runner
bajan los modelos, los ejecuta y los sirve vía APIs tipo OpenAI o Lama, o sea que tu aplicación, tu código como está estructurado hoy va a funcionar con este Docker Model Runner, verdad. Aparte de eso, como está integrado en Docker, internamente los contenedores van a poder conectarse a tu, estás corriendo local, a tu
a tu modelo utilizando la red interna de Docker, un contenedor se puede conectar a otro contenedor usando host.docker.internal y así si estuviera mostrado, si tengo mi ambiente de desarrollo en Docker Compose y utilizo olama para levantar el modelo, este es un ejemplo, tengo que correr el contenedor en modo host,
el modo host este hace que la red sea la misma pero eso no siempre es tan seguro, no siempre es la mejor solución y usualmente esa es la manera en que nos conectamos pero si uso docker model runner voy a poder conectarme de manera interna porque está corriendo en otro contenedor el modelo al cual yo con el cual yo quiero trabajar verdad entonces esa es una parte muy interesante y por eso mencionaba al principio
vale la pena considerarlo porque no estamos diciendo que sea mejor que olama pero ya que está todo integrado ya que tal vez ya tengo mi ambiente de desarrollo en docker desktop corriendo puede que me sea una buena opción y también este lo controla tiene docker model pool
y otros comandos como los de olama y así no tengo yo que estar bajando un modelo y hacer un docker run y tal ver hacer un script que haga un wrapper sobre estos contenedores para ejecutarlos verdad, docker model run ⁓
Docker Model Pool, perdón, para descargarlo. También está Docker Model Configure para configurar los modelos, uno le configura el contexto y si quiere que sea que piense más, que piense menos, uno configura ese tipo de cosas con el Docker Model Configure y esto no se trata de una guía how-to, estoy trayendo nada más las funcionalidades que están disponibles en Docker Desktop para que las considerar, ¿verdad?
Entonces, yo quiero aclarar que personalmente no es que lo utilizo en mi día a día porque yo no corro tanto modelo local. La naturaleza de mi trabajo no corro modelos locales todo el tiempo. Sin embargo, sí lo he probado y he comenzado a que cuando necesito modelos locales lo he estado comenzando a trabajar con esta nueva herramienta de Docker Desktop.
Entonces realmente que vale la pena considerarlo en mi opinión, vale la pena tenerlo ahí en mente porque si queremos correr modelos locales para que nuestro código interactúe con él, ya tenemos todo listo en Docker. Si probablemente no usas Docker Desktop para nada más en tu local y solamente tienes
otros servicios corriendo en tu local que se conecten a LLMs locales pues sigues haciendo en olama y no necesitas hacerlo pero si ya utilizas Docker Desktop en tu local que de nuevo yo pienso que deberías por la ventaja que traen los contenedores esta funcionalidad en Docker Desktop creo que vale la pena considerarla verdad no estoy advocando a la fuerza por Docker Desktop
Esto no es publicidad, ya quisiera, ya quisiéramos aquí en Deben Ops que la gente de Docker nos quisiera patrocinar. Simplemente queremos poner sobre la mesa las herramientas que ahí existen y que nosotros creemos que para algunos de ustedes pueden ser de valor y por eso lo mencionamos, ¿verdad? Ahora, continuando, una funcionalidad más, esta es la segunda y última que quiero traer a la mesa.
que corre en Docker Desktop y que ustedes puedan considerarla es correr MCP servers, MCP, MCP. Y para quienes no sepan MCP son iniciales de Model Context Protocol, ¿verdad? Básicamente es un open source estándar para conectar aplicaciones de inteligencia artificial con sistemas externos. Básicamente aplicaciones de inteligencia artificial se ocupan hablar, no sé, tiene su aplicación que ocupa hablar con Git,
es un uso muy común. aplicación de inteligencia artificial ocupa hablar con GitHub y entonces una se conecta por el API y una lo hace de una manera, otra interactúa, viene Anthropic y lo hace de una manera, OpenAI lo hace de otra y tal vez cada empresa lo empezaba a hacer de manera distinta y eso se volvía complicado. O los endpoints que exponían los fabricantes o quienes hacían
estas herramientas para que pudieran hacer soluciones con LLMs, con inteligencia artificial, una empresa lo hacía de una manera, otra empresa lo hacía de otra y el código era amigable y entonces así nacen los MCP servers, Model Context Protocol que busca...
Estandarizar la manera en que servicios crean este tipo de servidores para que aplicaciones que corren en base a modelos LLMs o modelos de inteligencia artificial puedan interactuar con ellos. Al ser estándar, ya sé yo que mi código va a funcionar...
en cualquier lugar, verdad, para quienes no sepan eso es un MCP y levantar MCP locales de nuevo se vuelto parte de ese flujo muchas veces en desarrollo porque o estoy trabajando en un MCP para que mi servicio, tengo un servicio, una herramienta, yo trabajo la herramienta local puede ser de hora de entrada de empleados, verdad, o manejo de horas y vacaciones de empleados, entonces, pero los, herramienta, el agente que están haciendo con inteligencia artificial que va a
reportería de la hora de entrada y salida de empleados ocupan ellos conectarse, verdad, pero también ocupa conectarse los de contabilidad.
para hacer el cálculo de las planillas y entonces hay otro equipo que está encargado de esa herramienta, entonces ya son dos equipos diferentes que necesitan conectarse a mi herramienta, perdón, a la aplicación que yo estoy manejando internamente, entonces probablemente voy a desarrollar un MCP server para que los demás departamentos que ocupan jalar información o interactuar con información, hacer, crear, lo hagan por medio de ese MCP server.
⁓ de la manera que correr modelos locales, LLMs locales, se vuelto parte del día a día de muchos con la Inteligencia Artificial, correr MCP servers también es parte de ello, Entonces eso llega a ser muchas veces frustrante, ¿por qué? Manejo de dependencias, verdad.
correr instancias diferentes de un mismo MCP server para configuraciones distintas. Por ejemplo, voy a necesitar correr el MCP server de GitHub, poniéndolo como ejemplo, para Cloud Code. Pero tal vez ahora voy a probar Cursor. Y entonces, instalar el MCP server de nuevo, otra instancia para Cursor. Y entonces se comienza a volver tedioso.
corremos código de terceros directamente en nuestros locales cuando levantamos un MCP porque seamos honestos a veces cuando estamos probando cosas y estoy urgido porque MCP no es lo que voy a probar sino otra herramienta que estoy haciendo busco el primer proyecto que me encontré en GitHub el primer MCP server que haga un poquito remotamente lo que yo quiero y a veces nos arriesgamos a correr a correr ese código
directamente en nuestros locales, lo cual pues obviamente no es bueno. Ahora, miren que interesante, estos retos que les estoy hablando con los MCP Server no son retos exclusivos para MCP o para herramientas de inteligencia artificial en general, ¿verdad? Son retos que existen para todo tipo de herramientas.
y son retos que los contenedores solucionan. De la misma manera en que utilizar contenedores para mi ambiente local de desarrollo, Docker Desktop específicamente y con Docker Compose, porque no tengo que instalar base de datos, un backend, un frontend, no necesito instalar todo eso. De esa misma manera, los contenedores...
resuelven el problema o los retos que introducen los MCP servers. Los MCP servers son muy buenos y vienen a resolver un problema muy grande, pero administrarlos, manejarlos, se vuelve un reto y Docker lo resuelve, los contenedores en general, y Docker lo resuelve con Docker Desktop de manera local. ¿Cuál es la herramienta que Docker Desktop tiene para MCP? Tiene Docker, MCP Catalog y Docker MCP Toolkit.
⁓ son principalmente las dos herramientas verdad? el toolkit me provee dos cosas y de nuevo este no es un tutorial de cómo utilizarlo pero son herramientas que quiero poner en su mente para que las consideren si les sirve
El Docker MCP Toolkit me da dos diferentes servicios, me da el MCP Client que es el que típicamente se conecta a las aplicaciones basadas en LLMs, el que usan para conectarse, por ejemplo como Cloud Code, Cloud Code se va a conectar en el MCP Server, se va a conectar al client que está corriendo y también da, este MCP Toolkit también da el
MCP server, entonces el toolkit me da el MCP client y me da el MCP server, el MCP server pues es el que ejecuta las tareas, es la forma más simple de decirlo, la forma más simple de explicarlo, básicamente es un MCP server completo, me da el cliente para que las aplicaciones se conecten a él y me da el servidor para que los procesos se ejecuten, verdad y también este el
el MCP toolkit es una de las soluciones y como mencioné también tenemos el MCP catalog verdad y simple y sencillamente el MCP catalog es una lista curada y verificada de MCP servers ya listos para ejecutar es un catálogo de MCP servers donde cuando necesitan interactuar con necesitan un MCP para Grafana para reportería
Ahí va a un MCP server que o es desarrollado por el vendedor.
el fabricante o es desarrollado por una entidad verificada y de confianza, verdad, necesito un MCP para GitHub, ahí va a estar el MCP server de nuevo, es un catálogo donde va a ser mi primer punto para ir y ver y buscar el MCP server que necesito para interactuar cuando estoy desarrollando mi agente, cuando estoy desarrollando mi aplicación que necesita, verdad.
trabajar con una herramienta externa por medio de un MCP server. De nuevo, si tener que depender del código de... ⁓ No es una manera de desnigrar, la comunidad en general así trabaja, pero sin tener que depender del código de ningún fulano o de ningún John Doe, como se dice en inglés, hay en internet en GitHub. Porque el problema con esto es, no es la persona...
que de buena voluntad expuso su código para su MCP server para que otros lo usen, más bien gracias a esas personas porque ellas forman la comunidad. El problema es aquellas personas con intenciones no tan buenas que expuso su código ahí para que alguien con necesidad...
creyendo que le solventan un problema, le pueden estar robando información o le pueden estar creando algo dañino en su sistema. Entonces esa es la ventaja de tener un catálogo verificado. La desventaja es que aunque hay muchísimos MCP servers ahí, puede ser que yo tenga, ocupe conectarme a algo que no muchas personas lo necesiten y en ese catálogo no exista un MCP server para ello. Entonces
como todo en la vida tiene sus pros y sus contras, pero está ahí para que lo consideremos. Y parte de este sistema que me deja ejecutar MCP servers de manera local, ¿verdad? La herramienta trae algo que se llama Docker MCP Gateway. Esto normalmente no tenés que configurarlo cuando corres los MCP servers en Docker.
pero internamente así funciona, el Docker MCP Gateway es básicamente un orquestrador de MCP Servers que funciona como proxy centralizando el flujo entre clientes y servers, verdad, miremoslo como tu NGINX.
donde llegan los requests y él manda donde tiene que mandarlo o como tu load balancer donde llegan los requests y él manda donde tiene que mandarlo. Sin el gateway necesitarías configurar las aplicaciones de manera individual, cada aplicación para que se conecte con cada MCP, ¿verdad? Pero el gateway se encarga de eso, el gateway levanta si haces un llamado, él levanta el contenedor con el MCP server que necesitas, permisos, redes, el MCP.
GetWeb se encarga de ello verdad, entonces de nuevo
Todo esto permite una integración fácil si yo ya tengo mi ambiente de desarrollo en Docker Desktop. Si yo ya corro Docker Compose para levantar mi ambiente de desarrollo o si solo corro un contenedor local, ya lo puedo probar. O hablando de Kubernetes, si estoy probando funcionalidades en Kubernetes con Kubernetes en Docker Desktop y ocupo hablar con un MCP Server o ocupo hablar con un LLM,
local usando estas dos funciones de Docker Desktop lo puedo tener de manera interna y que se comuniquen fácilmente entonces no estoy tratando de crear aquí vendor log porque en realidad no se está creando un vendor log
recuerden que si corres los LLMs locales con Docker Desktop, él te va a dar un API como el de OpenAI o el de los modelos de Olamas, entonces cuando quieras volver a Olamas solo cambias el endpoint en vez de host.internal.docker lo cambias a tu endpoint y listo, entonces no estás creando un perdón un vendor log con esto verdad y de nuevo yo
aclaro que no son como tal herramientas.
que uso a diario porque la naturaleza de mi trabajo no necesito correr local constantemente ese tipo de herramientas pero por las últimas semanas cada vez que necesito ejecutarla para pruebas, cada vez que necesito ejecutarlas para probar resultados lo he estado haciendo con Docker Desktop y de momento la experiencia ha sido buena para mí, ¿verdad?
Entonces son herramientas que quería traer a su conocimiento, por si alguien no sabía que existían, para su consideración. ¿Cómo quiero cerrar con esto? ¿Cómo quiero cerrar aquí? Y es que si has dejado de utilizar Docker Desktop, espero que con esto, al menos vuelvas a considerarlo. No estoy tratando de forzarte a nada.
No estoy tratando de arrinconarte a nada, pero sé que los cambios que hizo Docker Desktop con la parte de licencia, hizo que muchas personas quisieran dejar de utilizarlo, ¿verdad?
y se cambiaron a Podman, una muy buena herramienta y sobre todo en cuestión de seguridad es más segura, es nativamente rootless, o sea que no necesitas conectarte como root y tiene otras funciones que son muy seguras y si estás usando Podman y quieres seguir usando Podman sigo lo haciendo, pero si en general lo has dejado de usar para todo tu flujo, tal vez con estas dos funcionalidades puedas considerarlo y si ya lo estás usando
para tus flujos locales pero corres tus LLMs con Olama o con otra herramienta ⁓ algunas personas he visto yo que corren sus LLMs en
contenedores pero hacen un Docker run y exponen los puertos verdad pero ya con este plugin con esta herramienta integrada que lo puedas considerar si estás corriendo tus MCP servers de manera local de otra manera que entonces que puedas considerar Docker Desktop para estas funcionalidades no estamos haciendo ningún tipo de campaña a favor pero sí son funcionalidades que se
que si las consideras por lo menos y les das una prueba, hay una posibilidad muy alta de que comiences a integrarlas de manera constante y permanente en tu flujo de trabajo diario.
Entonces eso es todo lo que yo les quería compartir hoy, un episodio un poco más corto, más directo y conciso, lastimosamente no tenemos la, no vamos a tener la opinión y perspectiva de Juan en estas dos funcionalidades de Docker Desktop, verdad, sin embargo eso no quita que este contenido puede llegar a ser de mucho valor para ustedes. Les agradezco por su tiempo, les agradezco por haber llegado hasta el final, compartan esta información con alguien que ustedes
que le pueda ser de mucha utilidad y espero verlos a todos en el próximo episodio. ¡Hasta la próxima!