Receber por email
← Voltar para o catálogo

dockerize

Generar Dockerfile optimizado. Activar cuando el usuario quiera crear contenedor, generar imagen Docker, configurar Docker Compose, contenerizar aplicacion o crear un Dockerfile multi-stage.

56estrelas
Atualizado há 4 meses

Ver no GitHub ↗

Como adicionar

/plugin marketplace add 686f6c61/alfred-dev

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/dockerize/svg)](https://www.skillteca.com.br/skills/dockerize)

Skills relacionadas

Ver todas de DevOps e Infra →

Alerta por categoria

Receba novas skills de DevOps e Infra toda segunda

1 email curto, só com as skills novas de DevOps e Infra. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

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

  1. 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-alpine o node:XX-slim.
  • Python: python:XX-slim o python:XX-alpine.
  • Rust: multi-stage con rust:XX para build y debian:XX-slim o gcr.io/distroless para runtime.
  • Go: multi-stage con golang:XX para build y scratch o gcr.io/distroless para runtime.
  1. Diseñar multi-stage build. Separar la fase de construcción de la de ejecución:

```dockerfile # 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 ```

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

  1. Configurar usuario no-root. Nunca ejecutar la aplicación como root dentro del contenedor:

``dockerfile RUN addgroup --system app && adduser --system --ingroup app app USER app ``

  1. Añadir health check. Permitir al orquestador (Docker Compose, Kubernetes) verificar que la aplicación está sana:

``dockerfile HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD curl -f http://localhost:3000/health || exit 1 ``

  1. Generar .dockerignore. Excluir todo lo que no es necesario en la imagen:

`` node_modules .git .env *.md tests/ .github/ ``

  1. Configurar variables de entorno. Usar ENV para valores por defecto y documentar qué variables se deben pasar en runtime con ARG o -e.
  1. 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 latest como tag de imagen base. Siempre fijar la versión concreta (por ejemplo, node:20.11-alpine) para mejorar la reproducibilidad de los builds.
  • 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_modules al 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.
Compartilhar X LinkedIn