Skip to content

Leer la receta real

Con Docker operativo y la app completa ya movida a lab, abrí lab/Dockerfile en el editor del host. Vamos a leer la receta antes de construir para saber qué herramientas y usuario tendrá la imagen.

Los archivos necesarios ya están dentro de lab. No traigas otro Dockerfile del material.

Archivo dentro de labPara qué se usa
Dockerfiledocker build local para la imagen taller
.dockerignoreArchivos fuera del contexto de build
.devcontainer/devcontainer.jsonSólo demo opcional de Codespaces

Abrí ese archivo, no un Dockerfile en la raíz del material ni .devcontainer/. Este extracto es para leer, no para reemplazar la receta:

FROM node:22.23.4-bookworm-slim
RUN npm install --global pnpm@10.20.0
WORKDIR /workspace
USER node
CMD ["bash"]

Leé el extracto en orden. FROM elige la base y RUN instala durante la construcción. WORKDIR fija la carpeta de trabajo, USER define el usuario de ejecución y CMD abre Bash al iniciar la instancia. La receta usa privilegios durante la construcción para instalar paquetes y termina con USER node. No ejecutes las sesiones del taller como root.

HerramientaUso
Node 22.23.4 y pnpm 10.20.0Aplicación y checks
Git y gh 2.103.3Git y API de GitHub
cloudflared 2026.10.3Túneles de los ejercicios 4 a 6
Runner 2.338.2Ejecutar un job de Actions

La receta completa instala dependencias del sistema, selecciona descargas para amd64 o arm64 y verifica sus SHA-256. Prepara /opt/actions-runner, /workspace y el home de node. El store de pnpm queda fuera del proyecto. No copia credenciales, no registra runners y no instala Hermes. El proyecto se montará después, en otras instancias, no en el runner.

Entre esas dependencias está libatomic1. Aporta libatomic.so.1, que necesita el Node administrado por Hermes en Linux. La instalamos al construir la imagen para que después puedas instalar Hermes como node, también en ARM, sin darle sudo al agente.

.devcontainer/devcontainer.json configura la demo opcional de Codespaces con una imagen Node independiente. No participa en este build.

El Dockerfile es la receta que acabás de leer. Cuando ejecutes docker build, Docker la usará para producir una imagen con archivos y herramientas preparados. Eso todavía no deja las herramientas corriendo. Con docker run vas a crear un container a partir de esa imagen y arrancar su proceso inicial. Cada container tiene sus propios cambios de archivos y puede estar activo o detenido.

Vamos a reutilizar la misma imagen con instancias separadas para runner, agente y app. Esas instancias no comparten automáticamente sus archivos. Tené presente que reconstruir la imagen no actualiza containers ya creados, aunque vuelvas a usar el nombre taller.

Dockerfile pasa por build para producir una imagen y cada run crea un container independiente

Diagrama del taller; ejemplo conceptual.

Comprobá que leíste las versiones y el USER node final en el archivo real. No sigas si estás leyendo otra receta o falta el Dockerfile de lab.