npx claudepluginhub 686f6c61/alfred-dev --plugin alfred-devWant just this skill?
Add to a custom plugin, then install with one command.
Generar Dockerfile optimizado. Activar cuando el usuario quiera crear contenedor, generar imagen Docker, configurar Docker Compose, contenerizar aplicacion o crear un Dockerfile multi-stage.
This skill uses the workspace's default tool permissions.
Generar Dockerfile optimizado
Resumen
Este skill genera un Dockerfile siguiendo las mejores prácticas de la industria: multi-stage builds para reducir el tamaño de la imagen final, ejecución con usuario no-root para seguridad, capas optimizadas para aprovechar la caché y health checks para la orquestación.
Un buen Dockerfile no es solo "que funcione", sino que sea seguro, rápido de construir, pequeño y mantenible.
Proceso
-
Detectar el stack del proyecto. Consultar el stack detectado en la configuración de Alfred para seleccionar la imagen base adecuada. Identificar el lenguaje, framework y runtime necesarios:
- Node.js:
node:XX-alpineonode:XX-slim. - Python:
python:XX-slimopython:XX-alpine. - Rust: multi-stage con
rust:XXpara build ydebian:XX-slimogcr.io/distrolesspara runtime. - Go: multi-stage con
golang:XXpara build yscratchogcr.io/distrolesspara runtime.
- Node.js:
-
Diseñar multi-stage build. Separar la fase de construcción de la de ejecución:
# Fase de build: incluye herramientas de compilación FROM node:20-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci --only=production COPY . . RUN npm run build # Fase de runtime: solo lo necesario para ejecutar FROM node:20-alpine AS runtime WORKDIR /app COPY --from=builder /app/dist ./dist COPY --from=builder /app/node_modules ./node_modules -
Optimizar el orden de capas para caché. Las capas que cambian menos van primero:
- Primero: ficheros de dependencias (package.json, requirements.txt, Cargo.toml).
- Segundo: instalación de dependencias.
- Tercero: copia del código fuente.
- Cuarto: build.
Esto asegura que un cambio en el código no invalida la caché de dependencias.
-
Configurar usuario no-root. Nunca ejecutar la aplicación como root dentro del contenedor:
RUN addgroup --system app && adduser --system --ingroup app app USER app -
Añadir health check. Permitir al orquestador (Docker Compose, Kubernetes) verificar que la aplicación está sana:
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD curl -f http://localhost:3000/health || exit 1 -
Generar .dockerignore. Excluir todo lo que no es necesario en la imagen:
node_modules .git .env *.md tests/ .github/ -
Configurar variables de entorno. Usar
ENVpara valores por defecto y documentar qué variables se deben pasar en runtime conARGo-e. -
Verificar la imagen resultante. Comprobar el tamaño final, que no incluye herramientas de build innecesarias y que arranca correctamente.
Criterios de éxito
- El Dockerfile usa multi-stage build.
- La imagen base es mínima (alpine, slim o distroless).
- La aplicación se ejecuta con usuario no-root.
- Las capas están ordenadas para maximizar el uso de caché.
- Hay un health check configurado.
- Existe un .dockerignore que excluye ficheros innecesarios.
- La imagen final no incluye herramientas de build, tests ni código fuente innecesario.
Que NO hacer
- No usar
latestcomo tag de imagen base. Siempre fijar la versión concreta (por ejemplo,node:20.11-alpine) para garantizar builds reproducibles. - No ejecutar la aplicación como root dentro del contenedor. Crear un usuario de sistema dedicado con los permisos mínimos necesarios.
- No copiar
node_modulesal contenedor desde el host. Instalar las dependencias dentro del contenedor para evitar incompatibilidades de plataforma y binarios nativos. - No incluir secretos en la imagen (ficheros
.env, claves privadas, tokens). Los secretos se pasan en runtime como variables de entorno o mediante sistemas de gestión de secretos.