Pregúntale a un LLM genérico por la política de devoluciones de tu empresa o por los tickets de soporte de la semana pasada, y dirá que no lo sabe o inventará algo plausible. Su conocimiento termina en lo que había en sus datos de entrenamiento. Nunca ha visto tus documentos y no puede ir a consultarlos a mitad de la conversación. La retrieval-augmented generation (RAG) soluciona justo esto: antes de que el modelo responda, un paso separado busca el texto relevante en tus propios datos y se lo entrega como parte del prompt. ...

docker build && docker push desde tu portátil funciona hasta que otra persona tiene que publicar la misma imagen, o hasta que tiene que pasar en cada merge sin que tú estés delante del teclado. GitHub Actions ejecuta esa build en los runners de GitHub, etiqueta la imagen según lo que haya disparado el workflow y la publica en un registry desde el que tu paso de deploy puede hacer pull. Nada se ejecuta en local. ...

Ejecuta kubectl run nginx --image=nginx:1.27 y Kubernetes crea exactamente un Pod llamado nginx. Bórralo con kubectl delete pod nginx y desaparece para siempre — nadie se entera, nadie lo reemplaza. Un Pod es la unidad mínima desplegable en Kubernetes: uno o más contenedores que comparten un namespace de red y un conjunto de volúmenes, programados juntos en un mismo nodo. Ese Pod aislado es un callejón sin salida en producción. Si el contenedor que hay dentro falla, el kubelet lo reinicia en el mismo sitio. Si el nodo se reinicia, o alguien borra el Pod, nada lo vuelve a crear. Un Pod desnudo no tiene memoria de que debería seguir existiendo. ...

Dónde terminan las variables de entorno de un contenedor Arranca un contenedor con -e DB_PASSWORD=hunter2 y ejecuta docker inspect sobre él: 1 2 docker run -d --name api -e DB_PASSWORD=hunter2 nginx:alpine docker inspect --format '{{json .Config.Env}}' api 1 ["DB_PASSWORD=hunter2","PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"] La contraseña queda ahí en texto plano, legible por cualquiera con acceso al socket de Docker, por docker exec api env y por cualquier proceso que corra dentro del contenedor. No es un bug: es justo para lo que existen las variables de entorno. El problema es usarlas para valores que nunca deberían ser tan visibles. ...

Por qué una imagen Docker pesa diez veces más que la app Un servicio Node con unos pocos cientos de kilobytes de código fuente termina en una imagen de más de 1 GB. Es el resultado normal de una build que funciona, no un error en una línea concreta. El peso viene de una imagen base que arrastra un sistema operativo completo, una toolchain de build que la app en ejecución nunca llama, y una caché del gestor de paquetes que nadie limpia. ...

Lo que te cuesta un Dockerfile mal escrito 1 2 3 4 5 6 FROM node:latest COPY . . RUN npm install CMD ["node", "server.js"] Cuatro líneas, y cada una te cuesta algo. docker build vuelve a ejecutar npm install en cada cambio de código, porque COPY . . rompe la cache de capas antes de que el paso de instalación tenga oportunidad de reutilizarse. La imagen final arrastra la base Debian completa, todo el árbol de node_modules incluidas las dependencias de desarrollo, y cualquier herramienta de build que npm install haya bajado para compilar módulos nativos. No se descarta nada. El contenedor corre como root, porque nada le dice lo contrario, y node:latest significa que la imagen base puede cambiar bajo tus pies entre una build y la siguiente, sin dejar rastro de qué acabaste desplegando. ...

El problema que resuelve Compose Una aplicación real casi nunca es un solo contenedor. Una API web necesita una base de datos, la base de datos necesita un volumen para que sus datos sobrevivan a un reinicio, y luego añades una caché Redis y un worker en segundo plano. Son cuatro comandos docker run, cada uno con sus flags para puertos, volúmenes, variables de entorno y una red compartida. En el orden correcto. Cada vez que te pones a trabajar. ...

Por qué dos contenedores en el mismo host no se ven por defecto Levanta Postgres y tu API con un simple docker run y la API no puede llegar a la base de datos, aunque los dos contenedores estén en la misma máquina. 1 2 docker run -d --name db postgres:16 docker run -d --name api myapp Los dos caen en la bridge por defecto de Docker, la que recibe todo contenedor Docker que no diga lo contrario. Reciben una IP. Lo que no reciben es una forma de encontrarse por nombre, así que la API tendría que llevar la IP interna de la base de datos escrita a mano, una dirección que cambia cada vez que el contenedor se reinicia. ...

Docker y Podman ejecutan las mismas imágenes con los mismos comandos. Lo que los separa es la arquitectura: Podman no tiene un daemon en segundo plano y corre rootless por defecto, mientras que Docker aporta las herramientas más maduras, Docker Desktop y un Compose de primera. A continuación, las diferencias que de verdad afectan a tu trabajo: el daemon, root, Compose y los pods. ¿Qué es Podman? Podman (Pod Manager) es una herramienta para gestionar contenedores y pods, desarrollada por Red Hat como alternativa open source a Docker. ¿Su característica principal? No necesita un daemon en ejecución. ...

Qué hace Docker exactamente Docker es una plataforma open source que empaqueta una aplicación con todo lo que necesita para ejecutarse (código, librerías, runtime, configuración) en un contenedor que se comporta igual en cualquier máquina. Una mudanza deja clara la diferencia. Tienes dos opciones: Llevar todos tus objetos sueltos, esperando que lleguen intactos Poner todo en cajas organizadas, etiquetadas y fáciles de mover Docker hace exactamente esto con las aplicaciones de software: las “empaqueta” en contenedores que contienen todo lo necesario para funcionar. ...