Docker init

Generar Dockerfile base

Docker init es una herramienta de línea de comandos que simplifica el proceso de inicialización de proyectos Docker. Esta utilidad permite generar automáticamente los archivos Docker necesarios para conteneurizar aplicaciones, eliminando la necesidad de escribir Dockerfiles desde cero y reduciendo significativamente el tiempo de configuración inicial.

flowchart TD
    DEV["Desarrollador<br/>en raíz del proyecto"] -->|docker init| WIZ{"Asistente<br/>interactivo"}
    WIZ -->|detecta package.json| NODE["Node.js / Bun"]
    WIZ -->|detecta pyproject.toml| PY["Python / FastAPI / Django"]
    WIZ -->|detecta pom.xml / build.gradle| JAVA["Java / Spring Boot"]
    WIZ -->|detecta go.mod| GO[Go modules]
    WIZ -->|detecta Cargo.toml| RUST[Rust]
    NODE --> OUT["Dockerfile multi-stage<br/>+ .dockerignore<br/>+ compose.yaml<br/>+ README"]
    PY --> OUT
    JAVA --> OUT
    GO --> OUT
    RUST --> OUT
    OUT --> CHK["docker build .<br/>docker compose up"]
    style OUT fill:#1d63ed,color:#fff

La funcionalidad principal de docker init consiste en analizar el proyecto actual y generar una configuración Docker base que incluye un Dockerfile optimizado, archivos de configuración y, opcionalmente, un archivo docker-compose.yaml. Este enfoque automatizado es especialmente útil para desarrolladores que quieren adoptar Docker rápidamente sin tener que dominar todos los detalles de configuración desde el primer momento.

Ejecutar docker init

Para inicializar un proyecto Docker, simplemente navega hasta el directorio raíz de tu aplicación y ejecuta:

docker init

El comando detectará automáticamente el tipo de proyecto y te guiará a través de un proceso interactivo donde podrás:

• Confirmar el lenguaje de programación detectado
• Especificar la versión del runtime
• Definir el puerto en el que la aplicación escucha
• Configurar el comando de inicio de la aplicación

Ejemplo práctico con Node.js

Supongamos que tienes un proyecto Node.js básico con un archivo package.json:

{
  "name": "mi-app-node",
  "version": "1.0.0",
  "main": "app.js",
  "scripts": {
    "start": "node app.js"
  },
  "dependencies": {
    "express": "^4.18.0"
  }
}

Al ejecutar docker init en este directorio, el asistente te presentará opciones similares a:

Welcome to the Docker Init CLI!

This utility will walk you through creating the following files with sensible defaults for your project:
  - .dockerignore
  - Dockerfile
  - compose.yaml

Let's get started!

? What application platform does your project use? Node
? What version of Node do you want to use? (18.19.0) 
? Which package manager do you want to use? npm
? What command do you want to use to start the app? npm start
? What port does your server listen on? 3000

Dockerfile generado

Docker init produce un Dockerfile multi-stage optimizado que sigue las mejores prácticas actuales. Para el ejemplo de Node.js anterior, generaría algo similar a:

# syntax=docker/dockerfile:1

ARG NODE_VERSION=18.19.0

FROM node:${NODE_VERSION}-alpine as base

WORKDIR /usr/src/app

# Install dependencies
COPY package*.json ./
RUN npm ci --only=production

# Copy application code
COPY . .

EXPOSE 3000

# Create non-root user
ARG UID=10001
RUN adduser \
    --disabled-password \
    --gecos "" \
    --home "/nonexistent" \
    --shell "/sbin/nologin" \
    --no-create-home \
    --uid "${UID}" \
    appuser
USER appuser

CMD ["npm", "start"]

Archivos adicionales generados

Además del Dockerfile, docker init crea varios archivos de soporte:

Archivo .dockerignore:

# Include any files or directories that you don't want to be copied to your
# container here (e.g., local build artifacts, temporary files, etc.)
#
# For more help, visit the .dockerignore file reference guide at
# https://docs.docker.com/engine/reference/builder/#dockerignore-file

**/.classpath
**/.dockerignore
**/.env
**/.git
**/.gitignore
**/.project
**/.settings
**/.toolstarget
**/.vs
**/.vscode
**/*.*proj.user
**/*.dbmdl
**/*.jfm
**/bin
**/charts
**/docker-compose*
**/compose*
**/Dockerfile*
**/node_modules
**/npm-debug.log
**/obj
**/secrets.dev.yaml
**/values.dev.yaml
**/target
README.md

Archivo compose.yaml básico:

services:
  server:
    build:
      context: .
      target: base
    ports:
      - 3000:3000

Ventajas del Dockerfile generado

Los Dockerfiles creados por docker init incorporan mejores prácticas de seguridad y optimización:

• Uso de imágenes base oficiales y ligeras (como Alpine Linux)
• Creación de usuario no privilegiado para ejecutar la aplicación
• Optimización de capas para aprovechar mejor la cache de Docker
• Configuración correcta del WORKDIR y permisos
• Exposición explícita de puertos necesarios

Personalización post-generación

Una vez generados los archivos, puedes personalizarlos según las necesidades específicas de tu proyecto:

• Agregar variables de entorno adicionales
• Modificar el comando de inicio si tienes requisitos especiales
• Incluir pasos de build adicionales si tu aplicación lo requiere
• Ajustar la configuración de puertos para diferentes entornos

El enfoque de Docker init es proporcionar una base sólida y funcional que puedas extender, en lugar de una solución completamente rígida que no permita modificaciones.

Soporte de stacks comunes

Docker init cuenta con soporte nativo para los lenguajes y frameworks más utilizados en el desarrollo moderno. La herramienta incluye plantillas predefinidas que reconocen automáticamente la estructura de proyecto y generan configuraciones optimizadas específicas para cada tecnología.

Detección automática de lenguajes

El proceso de detección automática examina archivos característicos de cada ecosystem:

• Node.js: busca package.json, yarn.lock, o pnpm-lock.yaml
• Python: identifica requirements.txt, pyproject.toml, o Pipfile
• Go: detecta archivos go.mod y go.sum
• Java: reconoce pom.xml, build.gradle, o estructura Maven
• PHP: busca composer.json y archivos .php
• Rust: identifica Cargo.toml
• ASP.NET: detecta archivos .csproj o .sln

Configuración para Python

Para proyectos Python, docker init genera un Dockerfile que utiliza imágenes base oficiales y gestiona correctamente las dependencias:

ARG PYTHON_VERSION=3.11.7
FROM python:${PYTHON_VERSION}-slim as base

ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1

WORKDIR /app

ARG UID=10001
RUN adduser \
    --disabled-password \
    --gecos "" \
    --home "/nonexistent" \
    --shell "/sbin/nologin" \
    --no-create-home \
    --uid "${UID}" \
    appuser

RUN --mount=type=cache,target=/root/.cache/pip \
    --mount=type=bind,source=requirements.txt,target=requirements.txt \
    python -m pip install -r requirements.txt

USER appuser

COPY . .

EXPOSE 8000

CMD ["python", "app.py"]

Configuración para Go

Los proyectos Go reciben un tratamiento especializado que aprovecha las características del lenguaje para crear imágenes extremadamente ligeras:

ARG GO_VERSION=1.21
FROM golang:${GO_VERSION}-alpine AS build

WORKDIR /src

RUN --mount=type=cache,target=/go/pkg/mod/ \
    --mount=type=bind,source=go.sum,target=go.sum \
    --mount=type=bind,source=go.mod,target=go.mod \
    go mod download -x

RUN --mount=type=cache,target=/go/pkg/mod/ \
    --mount=type=bind,target=. \
    CGO_ENABLED=0 go build -o /bin/server .

FROM alpine:latest AS final

RUN --mount=type=cache,target=/var/cache/apk \
    apk --update add \
        ca-certificates \
        tzdata \
        && \
        update-ca-certificates

ARG UID=10001
RUN adduser \
    --disabled-password \
    --gecos "" \
    --home "/nonexistent" \
    --shell "/sbin/nologin" \
    --no-create-home \
    --uid "${UID}" \
    appuser
USER appuser

COPY --from=build /bin/server /bin/

EXPOSE 8080

ENTRYPOINT [ "/bin/server" ]

Configuración para Java con Maven

Para aplicaciones Java, Docker init reconoce tanto Maven como Gradle y genera configuraciones multi-stage apropiadas:

ARG JAVA_VERSION=17
FROM maven:3.9.0-openjdk-${JAVA_VERSION} AS build

WORKDIR /build

COPY --chown=maven:maven pom.xml .
RUN mvn dependency:go-offline

COPY --chown=maven:maven src ./src
RUN mvn clean package -Dmaven.test.skip

FROM openjdk:${JAVA_VERSION}-jre-slim

ARG UID=10001
RUN adduser \
    --disabled-password \
    --gecos "" \
    --home "/nonexistent" \
    --shell "/sbin/nologin" \
    --no-create-home \
    --uid "${UID}" \
    appuser
USER appuser

COPY --from=build /build/target/*.jar /app/app.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "/app/app.jar"]

Configuración específica por framework

Docker init va más allá de la detección básica del lenguaje y puede identificar frameworks específicos:

Para aplicaciones Express.js:

# compose.yaml generado
services:
  server:
    build:
      context: .
    ports:
      - 3000:3000
    environment:
      - NODE_ENV=production
    volumes:
      - ./:/app
      - /app/node_modules

Para aplicaciones Flask:

services:
  web:
    build:
      context: .
    ports:
      - 5000:5000
    environment:
      - FLASK_ENV=development

Para aplicaciones Spring Boot:

services:
  app:
    build:
      context: .
    ports:
      - 8080:8080
    environment:
      - SPRING_PROFILES_ACTIVE=docker

Personalización de configuraciones

Después de la generación inicial, puedes adaptar las configuraciones según requisitos específicos:

Modificar versiones de runtime:

# Cambiar la versión de Node.js
ARG NODE_VERSION=20.10.0
FROM node:${NODE_VERSION}-alpine as base

Agregar dependencias del sistema:

# Para aplicaciones que requieren dependencias nativas
RUN apk add --no-cache \
    build-base \
    python3 \
    make \
    g++

Configurar múltiples puertos:

services:
  api:
    build: .
    ports:
      - "3000:3000"  # API
      - "3001:3001"  # WebSocket
      - "9229:9229"  # Debug port

Ventajas del soporte multi-stack

El enfoque multi-lenguaje de Docker init ofrece consistencia en los equipos de desarrollo que trabajan con tecnologías heterogéneas:

• Estandarización de configuraciones Docker independientemente del stack
• Reducción de errores comunes en configuraciones manuales
• Optimizaciones específicas por lenguaje aplicadas automáticamente
• Facilita la adopción de Docker en equipos con experiencia limitada

Esta funcionalidad es especialmente valiosa en entornos empresariales donde diferentes equipos pueden utilizar distintas tecnologías, pero necesitan mantener un enfoque coherente para la conteneurización y despliegue de aplicaciones.

Limitaciones de docker init en proyectos B2B reales

docker init funciona muy bien para arrancar prototipos y para que un desarrollador novato vea un Dockerfile correcto en menos de un minuto, pero no sustituye a una plantilla corporativa. En consultoras IT con varios clientes, el Dockerfile generado se queda corto en cuatro frentes:

• Versiones de runtime obsoletas. El asistente sugiere la última versión LTS al momento de generar la plantilla, pero no se adapta a un cliente que requiere Java 21 con BellSoft Liberica o Python 3.13 con wolfi-base. Hay que parchear manualmente.
• Imágenes base sin firmar. Docker init genera FROM node:22-alpine, no FROM registry.empresa.es/base/node:22-alpine con cosign verify. La plantilla corporativa fuerza el segundo.
• Sin healthcheck explícito. Falta HEALTHCHECK CMD curl -f http://localhost:8080/actuator/health || exit 1 que Compose y Kubernetes esperan para arranque ordenado.
• Cache mounts ausentes. Genera RUN npm ci en lugar de RUN --mount=type=cache,target=/root/.npm npm ci --omit=dev, perdiendo el 60% del beneficio de BuildKit.

La pauta madura es usar docker init solo como semilla y aplicar después un make harden o un script de plantilla corporativa que añada los cuatro elementos anteriores y reemplace la imagen base por la golden image firmada.

Alternativas: backstage scaffolder, copier y nx

Cuando la organización tiene plataforma interna (IDP), el scaffolder de Backstage y herramientas como copier o cookiecutter ofrecen plantillas Docker mucho más ricas: heredan del catálogo corporativo, generan también .github/workflows/build-image.yml, compose.yaml con servicios estándar (Postgres + Redis + Keycloak) y políticas de seguridad pre-rellenas. nx añade además grafo de dependencias entre proyectos para construir solo las imágenes afectadas en cada PR. Para una pyme con un solo equipo, docker init sigue siendo suficiente; para una consultora con cinco clientes y veinte proyectos, una plantilla parametrizada es estrictamente necesaria.