Docker

Cada llamada a una API de LLM alojada envía tu prompt al servidor de otra persona y te cobra por token. Se cae la red y deja de responder. Ollama elimina los dos problemas: descarga un modelo de pesos abiertos en tu máquina y lo sirve mediante una API REST en localhost:11434. Un solo binario hace de gestor de modelos, cliente de chat y servidor. Qué hace Ollama en realidad Ollama envuelve llama.cpp y motores de inferencia similares, así que nunca tocas un flag del compilador ni una ruta de biblioteca CUDA. ollama pull llama3.2 descarga un archivo de modelo cuantizado (formato GGUF) desde el propio registro de Ollama en lugar de Hugging Face, aunque también puede importar archivos GGUF desde allí. Ejecutar el modelo pasa esos pesos a un servidor en segundo plano, que los carga en RAM (o VRAM, si encuentra una GPU compatible), los mantiene en memoria unos minutos después de tu última petición para que la siguiente sea rápida, y los libera en cuanto dejas de preguntar. ...

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. ...

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. ...

Por qué un contenedor pierde sus datos al reiniciarse Escribe una fila en una base de datos que corre en un contenedor de Docker, para el contenedor y arráncalo otra vez: la fila ya no está. Cada contenedor recibe su sistema de archivos recién sacado de su imagen cada vez que arranca. Todo lo que el propio contenedor escribe (archivos de base de datos, subidas, logs) va a parar a una capa de escritura que se descarta cuando el contenedor se elimina. Un volumen Docker es la forma de mantener esos datos fuera del contenedor, donde sobreviven. ...