DevOps

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

Qué hace Kubernetes Un contenedor de Docker en una máquina se ejecuta a mano sin problema. Cincuenta contenedores repartidos en diez máquinas no: hay que reiniciarlos cuando fallan, moverlos cuando una máquina se cae, repartir el tráfico entre ellos y actualizarlos sin cortes. Kubernetes (abreviado K8s) es el sistema que se encarga de esa gestión por ti. ¿Qué es Kubernetes? Kubernetes es una plataforma de código abierto para la orquestación de contenedores. Fue creada por Google en 2014 basándose en 15 años de experiencia gestionando contenedores a gran escala, y ahora es mantenida por la Cloud Native Computing Foundation (CNCF). ...

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