Sobre los dev containers: Una guía práctica

Introducción

Hace un tiempo empecé a implementar Dev Containers a algunos proyectos. Aunque no soy un experto en Docker (ni en nada, realmente), me gustaría compartir un poco sobre lo que he aprendido.

Los Dev Containers son una tecnología que permiten desarrollar dentro de un contenedor. Sabiendo un poco de Docker, es posible ahorrar mucho tiempo y dolores de cabeza a la hora de tener que trasladar el entorno de trabajo a un nuevo ordenador o a un nuevo miembro del equipo.

Ya sabéis, eso de que hay que instalar x versión de node, que en Windows no funciona (siempre pasa algo en Windows), que hay que instalar x extensiones. En general, todas las variantes de “en mi máquina funciona”. Una pérdida de tiempo tremenda. Gracias a los contenedores, ahora podemos crear un entorno y replicarlo cuantas veces queramos sin esfuerzo.

En este artículo, iré poco a poco implementando los Dev Containers a un par de proyectos, y al final os compartiré algunos casos específicos que he tenido, los cuales tal vez os sean útiles :>

Para los proyectos, os dejo el repositorio: https://github.com/michelangelo-valderrama/devcontainers-article.

Primer proyecto: Frontend con Vite

Fácil, tenemos una web con Vite (por hacer un proyecto rápido, pero podría ser cualquier frontend con Astro, Angular…) y queremos implementar los Dev Containers. No hay ninguna necesidad más que tener un Linux (p. ej. Debian o Ubuntu) con Node, NPM, Git y alguna extensión útil como GitLens o Pretty TypeScript Errors (claro está, en caso de usar TypeScript).

Para implementar los Dev Containers, primero hay que instalar la extensión oficial ms-vscode-remote.remote-containers y crear el archivo devcontainer.json en el directorio .devcontainer:

1
.devcontainer/
2
  devcontainer.json
3
public/
4
.gitignore

Este será el archivo que buscará la extensión para saber que tenemos un Dev Container y crearlo. Si quisiéramos, podríamos tener más de uno:

1
.devcontainer/
2
  python-backend/
3
    devcontainer.json
4
  react-frontend/
5
    devcontainer.json

Ahora hay que configurar la creación del Dev Container en el devcontainer.json. Si gustáis de más detalles podéis leer la referencia oficial: https://containers.dev/implementors/json_reference/.

1
{
2
  "name": "vite-example",
3

4
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
5

6
  "customizations": {
7
    "vscode": {
8
      "extensions": ["eamodio.gitlens", "esbenp.prettier-vscode"],
9
      "settings": {
10
        "editor.defaultFormatter": "esbenp.prettier-vscode",
11
        "editor.formatOnSave": true,
12
        "editor.tabSize": 2
13
      }
14
    }
15
  },
16

17
  "forwardPorts": [5173],
18

19
  "postCreateCommand": "npm i && npm run dev",
20
  // o yarn/pnpm install, pues la imagen también viene con yarn y pnpm.
21

22
  "remoteUser": "node"
23
}

La imagen mcr.microsoft.com/devcontainers/javascript-node:22 es oficial de Microsoft y es muy útil para proyectos de Node. Si queréis saber de más imágenes, os dejo el link a un repositorio: https://github.com/devcontainers/images/tree/main/src.

Una vez hecho esto, al volver a abrir el proyecto aparecerá una alerta abajo a la derecha para re-abrirlo en un contenedor. Pero también se puede mediante el comando Dev Containers: Reopen in Container desde el Command Palette (F1 o Ctrl + Shift + P).

Después, al abrir la terminal, veréis que tiene una terminal con ZSH y Oh My ZSH (gracias a la imagen de Microsoft), y que se encuentra en el directorio /workspaces/NOMBRE_DEL_DIRECTORIO_DEL_PROYETO.

Ahora se podrá ejecutar npm run dev y, si todo ha ido bien, ver algo así:

1
  VITE v5.4.2  ready in 123 ms
2

3
  ➜  Local:   http://localhost:5173/
4
  ➜  Network: use --host to expose
5
  ➜  press h + enter to show help

Problema con Vite y los dev containers

Si intentáis acceder a localhost:5173, notaréis que no carga. Esto es un problema un tanto extraño con Vite y los dev containers, pero en principio debería arreglarse añadiendo el argumento --host:

1
{
2
  //...
3
  "scripts": {
4
    "dev": "vite --host",
5
    "build": "vite build",
6
    "preview": "vite preview --host"
7
  }
8
  //...
9
}

Si se ejecuta otra vez npm run dev y accedéis a localhost:5173 desde el navegador, debería ver la web del proyecto.

Partir de un Dockerfile

Si lo que se busca es una imagen más personalizada, se puede partir de la imagen de un Dockerfile:

1
FROM mcr.microsoft.com/devcontainers/javascript-node:22
2

3
RUN apt-get update && apt-get install git-flow -y \
4
    && rm -rf /var/lib/apt/lists/*

1
{
2
  // ...
3
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
4
  "build": {
5
    "dockerfile": "Dockerfile"
6
  }
7
  // ...
8
}

En este Dockerfile, además, instalo Git Flow y elimino la caché para optimizar la imagen².

Git

No hace falta hacer nada en especial para configurar Git en un Dev Container, por defecto VS Code se encarga y puedes seguir trabajando con normalidad.

Segundo proyecto: Backend con Node y Mongo

Cuando se tienen proyectos más complejos que necesitan una base de datos y un servidor, se necesitará a su vez gestionar más contenedores. Pero no hay problema porque los Dev Containers también soportan Docker Compose.

Con respecto al archivo devcontainer.json, solo hay algunas diferencias:

1
{
2
  "name": "node-example",
3

4
  "dockerComposeFile": "compose.yml", // (1)
5
  "service": "api", // (2)
6
  "workspaceFolder": "/workspace", // (3)
7

8
  "customizations": {
9
    "vscode": {
10
      "extensions": ["mongodb.mongodb-vscode", "Postman.postman-for-vscode"]
11
    }
12
  },
13
  "forwardPorts": [3000],
14
  "postCreateCommand": "npm i && npm run dev",
15
  "remoteUser": "node"
16
}

(1) En el atributo dockerComposeFile, indicamos la ruta del archivo Docker Compose compose.yml (o docker-compose.yml).

(2) Establecemos el servicio al que debe conectarse el Dev Container.

(3) Cuando se parte de una imagen o un Dockerfile, no hace falta indicar el workspaceFolder porque el Dev Container puede asumirlo. Sin embargo, cuando se usa un archivo Docker Compose, se necesita definir explícitamente.

Y este es el archivo compose.yml:

1
services:
2
  api:
3
    image: mcr.microsoft.com/devcontainers/javascript-node:22
4
    container_name: node-example-api
5
    network_mode: service:db # (1)
6
    volumes:
7
      - ..:/workspace:cached # (2)
8
    command: /bin/sh -c "while sleep 1000; do :; done" # (3)
9
  db:
10
    image: mongo:7
11
    container_name: node-example-db
12
    ports:
13
      - 27017:27017 # (4)
14
    volumes:
15
      - node-example-db-data:/data/db # (5)
16

17
volumes:
18
  node-example-db-data:

(1) network_mode enlaza directamente la red del contenedor del api con la del db, esto permite acceder a la base de datos mediante el localhost.

(2) Monta el directorio del proyecto (.., porque este compose.yaml está en el directorio .devcontainer), en el directorio /workspace dentro del contenedor. La flag :cached solo afecta a MacOS y mejora el rendimiento en lecturas pesadas, a coste de alguna inconsistencia temporal entre el host y el contenedor.

(3) Este comando evita que el contenedor se detenga al terminar algún proceso pues es un proceso infinito.

(4) Mapeo el puerto de la base de datos para poder acceder a esta desde el host. No es necesario si se usa la extensión de MongoDB (mongodb.mongodb-vscode, que se instala automáticamente en el contenedor), pero en lo personal prefiero Mongo Compass. A gustos colores.

(5) Determino un volumen (gestionado por Docker) para persistir la base de datos. También se podría usar un bind mount, pero en este escenario no ofrece ninguna ventaja.

Algunos casos específicos

Ahora, algunos casos específicos que me han ocurrido y quiero contaros.

Acceder desde la IP

A veces queremos poder comprobar el funcionamiento de una web desde el móvil, o necesitamos que una aplicación móvil haga peticiones al API en nuestro ordenador durante el desarrollo. En este caso, es mejor borrar network_mode: service:db y mapear el puerto del API:

1
services:
2
  api:
3
    image: mcr.microsoft.com/devcontainers/javascript-node:22
4
    container_name: node-example-api
5
    network_mode: service:db
6
    volumes:
7
      - ..:/workspace:cached
8
    command: /bin/sh -c "while sleep 1000; do :; done"
9
    ports:
10
      - 3000:3000
11
  #...

Optimizar el node_modules

Si el npm i va muy lento, a lo mejor se soluciona optimizando el acceso al directorio node_modules. Esto es porque en MacOs y en Windows, los contenedores se ejecutan en una Máquina Virtual³, lo que hace que los bind mounts no sean tan eficientes. Para solucionar esto solo hay que añadir la configuración pertinente:

Dockerfile o imagen

1
"mounts": [
2
  "source=${localWorkspaceFolderBasename}-node_modules,target=${containerWorkspaceFolder}/node_modules,type=volume"
3
],
4
"postCreateCommand": "sudo chown node node_modules" // necesario si no eres root

Docker Compose

1
services:
2
  api:
3
    # ...
4
    volumes:
5
      - ..:/workspace:cached
6
      - node-example-node_modules:/workspace/node_modules
7
  # ...

Instalar herramientas

Si, por ejemplo, necesitas el CLI de AWS, en lugar de intentar configurarlo desde cero, puedes usar una Feature y gozarlo:

1
{
2
  //...
3
  "features": {
4
    "ghcr.io/devcontainers/features/aws-cli:1": {
5
      "version": "latest"
6
    } // (1)
7
  },
8
  "mounts": [
9
    "source=${localEnv:HOME}/.aws,target=/workspace/.aws,type=bind,readonly"
10
  ] // (2)
11
  //...
12
}

1
services:
2
  api:
3
    environment:
4
      - AWS_CONFIG_FILE=/workspace/.aws/config
5
      - AWS_SHARED_CREDENTIALS_FILE=/workspace/.aws/credentials # (3)
6
  #...

(1) Configuro la feature de AWS CLI. Aquí un repositorio con más features: https://github.com/devcontainers/features.

(2) Configuro un bind mount de la carpeta ~/.aws/ (con los archivos config y credentials) a la de /workspace/.aws/ en el contenedor, para mantener mi configuración y credenciales.

(3) Configuro las variables de entorno de AWS.

Despedida

Y esto es todo. Todavía no he usado los Dev Containers en muchos proyectos, pero quería contar algo de lo que he aprendido sobre ellos.

Hace tiempo que no escribo algo técnico, y lo echaba un poco en falta. Todavía no me veo volviendo a escribir un artículo de investigación, matemáticas o física; pero bueno, solo es cuestión de tiempo.

Personalmente, veo los Dev Containers algo muy útil, pero que chupan bastantes recursos del sistema. Creo que lo mejor sería usarlos en monorepos, pero no lo he probado todavía, así que nada.

Espero que este artículo haya sido útil, que te haya animado a probar esta nueva tecnología o que simplemente hayas aprendido algo nuevo, que nunca viene mal.