// workshop equipo de dev
Por qué usar Docker
Cada razón, con su receta. Sales convencido y con tu primer contenedor corriendo.
el problema
«En mi máquina funciona»
- ✕Cada quien tiene otra versión de Node, Python o la base de datos.
- ✕El onboarding es un README de 40 pasos que igual falla.
- ✕Anda en tu laptop y se rompe en producción.
Docker mata esa frase: el mismo entorno para todos, en todos lados.
analogía
Docker es el contenedor de barco: el mismo cajón viaja en el camión, el barco y el puerto.
// tu app y todo lo que necesita, empaquetado en una unidad estándar
la caja
Una caja que corre igual en todos lados
- →Imagen: la plantilla congelada (app + runtime + dependencias).
- →Contenedor: una instancia corriendo de esa imagen.
- →Dockerfile: la receta para construir la imagen.
Cada razón viene con su receta de cómo hacerlo.
$_
manos a la obra
Instala y arranca
Dos comandos y ya tienes Docker corriendo.
60 segundos
Dos comandos y estás adentro
# Linux
$ curl -fsSL https://get.docker.com | sh
# Mac / Windows: instala Docker Desktop
$ docker run hello-world
Si ves el "Hello from Docker!", ya estás adentro.
la receta
El ADN de tu app, en un archivo
FROM node:20-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]
Cada línea es un paso reproducible. La misma imagen para todo el equipo.
a la olla
De la receta al plato servido
$ docker build -t miapp . # construye la imagen
$ docker run -p 3000:3000 miapp # córrela
Abre localhost:3000. Corre igual en cualquier máquina con Docker.
analogía
La imagen es la receta. El contenedor es el plato servido. De una receta, muchos platos.
// build = cocinas una vez; run = sirves las veces que quieras
sin sorpresas
Se acabó «pero en prod es distinto»
- →La imagen que probaste en tu laptop es la misma que va a producción.
- →Nada de "en el server falta una librería" ni "otra versión".
Si funciona en la imagen, funciona en prod. Esa es la promesa.
el primer día
Todo el stack en un comando
# docker-compose.yml
services:
app:
build: .
ports: ["3000:3000"]
db:
image: postgres:16
environment: { POSTGRES_PASSWORD: dev }
$ docker compose up → app + base de datos arriba. El nuevo dev arranca en 2 minutos.
sin rastro
Tu laptop queda impecable
# Postgres al instante, sin instalar nada
$ docker run --rm -e POSTGRES_PASSWORD=dev \
-p 5432:5432 postgres:16
Pruébalo, úsalo, apágalo. Tu sistema queda limpio. Tres versiones de Postgres a la vez, sin conflicto.
analogía
No instalas medio mundo en tu laptop para siempre. Lo prendes y lo apagas.
// cada proyecto, su entorno; nada queda pegado a tu sistema
la caja fuerte
El contenedor es desechable, los datos no
$ docker run -v pgdata:/var/lib/postgresql/data \
postgres:16
El volumen (pgdata) sobrevive aunque borres el contenedor. Es la caja fuerte de tus datos.
peso pluma
Multi-stage: construye pesado, envía liviano
FROM node:20 AS build
WORKDIR /app
COPY . .
RUN npm ci && npm run build
FROM node:20-slim
COPY --from=build /app/dist ./dist
CMD ["node", "dist/server.js"]
Suma un .dockerignore (node_modules, .git, .env). Imagen más chica = deploy más rápido y seguro.
a producción
Lo que probaste es lo que se despliega
$ docker tag miapp registry/miapp:1.0
$ docker push registry/miapp:1.0
# o directo a un serverless
$ gcloud run deploy --source .
Lo que probaste es exactamente lo que se despliega. Sin sorpresas.
todo junto
Un Dockerfile de verdad
# etapa build
FROM node:20 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
# etapa final: liviana y sin root
FROM node:20-slim
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
RUN npm ci --omit=dev
COPY --from=build /app/dist ./dist
USER node
EXPOSE 3000
CMD ["node", "dist/server.js"]
comandos del día
Los que usas todo el tiempo
docker ps
Qué contenedores están corriendo.
docker logs -f app
Ver los logs en vivo.
docker exec -it app sh
Entrar al contenedor a mirar.
docker compose down
Bajar todo. `system prune` limpia lo viejo.
la letra chica
Cuándo NO sacar Docker
- ·Un script chico de una sola vez: no necesitas empaquetarlo.
- ·Front puramente estático: un CDN te sirve mejor.
- ·App de escritorio nativa: no es su terreno.
Brilla en servicios, APIs y entornos con dependencias. No es un martillo universal.
el lunes
Dockeriza un servicio tuyo
01Instala Docker y corre hello-world.
02Escribe un Dockerfile para un servicio real.
03docker build y docker run en tu máquina.
04Mueve las dependencias (DB, Redis) a un compose.
05Agrega un .dockerignore y un multi-stage.
06Push a un registry, deploy de esa imagen.
cierre
Una vez, en todos lados
Empaquetas una vez, corre igual en tu laptop, el CI, el server y la nube. Empieza dockerizando un servicio esta semana.
seguimos en contacto
Sígueme
# notas técnicas y proyectos
web dev.jotive.com.co
# instagram
ig @jotive.dev