Una consulta que tarda 200ms contra tu base de datos sigue tardando 200ms la millonésima vez que alguien la ejecuta, y cada una de esas ejecuciones compite por las mismas conexiones, el mismo I/O de disco y la misma CPU. Redis guarda la respuesta en memoria, en un servidor que no hace nada más, así que la lectura número un millón cuesta un round trip de red en lugar de un plan de consulta. ...
Qué hay entre el navegador y tu app Apunta el navegador a example.com y la petición nunca toca el proceso que ejecuta tu código. Primero llega a otra cosa: un servidor que lee la petición, decide qué backend debe responder, la reenvía ahí y devuelve la respuesta como si la hubiera generado él mismo. Ese servidor es un reverse proxy. Nginx, Caddy, Traefik y HAProxy hacen todos este trabajo, igual que el load balancer que se sienta delante de un clúster de Kubernetes. El esquema no cambia nunca: los clientes hablan con el proxy y con nada más. Los servidores reales quedan detrás, sean los que sean y estén donde estén. ...
Haces pull del último main y Git se detiene con CONFLICT (content): Merge conflict in checkout.js. Resuelves el conflicto y el log muestra ahora un commit llamado Merge branch 'main' into feature/checkout, sentado encima de los tres commits que en realidad escribiste tú. Cuatro commits, un solo cambio real. Un compañero que lea ese historial el mes que viene no puede saber cuál es cuál. git merge y git rebase responden a la misma pregunta: cómo pongo mi rama al día con los cambios hechos en otro sitio. Dejan rastros muy distintos, y elegir el equivocado en una rama compartida causa daño real. ...
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. ...