Imágenes, volúmenes y redes

Tres recursos que sostienen a todo contenedor: de dónde sale (imágenes), dónde guarda sus datos (volúmenes) y cómo se comunica (redes). Portainer expone los tres con sus propias secciones.

Imágenes

La sección Images lista las imágenes presentes en el host, con su tamaño, tags y antigüedad.

Pull

Para descargar una imagen indicás repositorio:tag (ej. nginx:alpine) y el registry de origen (Docker Hub por defecto, o uno privado del capítulo 8). Portainer ejecuta el docker pull.

Build

Build a new image te deja construir desde:

• Un editor web donde pegás el Dockerfile.
• Un archivo .tar o un repositorio Git con el Dockerfile.

Le das uno o varios tags y Portainer corre el build en el host.

Import / Export

• Export: descargás una o varias imágenes como .tar para moverlas a otro host sin registry.
• Import: subís un .tar y queda disponible localmente.

Limpieza

Las imágenes se acumulan. Portainer marca las unused (sin contenedor que las use) y permite borrarlas. Tené cuidado con el borrado forzado: una imagen “no usada” ahora puede ser la base de un build futuro.

Tip: una imagen “dangling” (<none>:<none>) suele ser una capa huérfana de un rebuild. Es seguro limpiarlas periódicamente.

Volúmenes

Los volúmenes son el mecanismo de Docker para persistir datos fuera del ciclo de vida del contenedor. La sección Volumes los lista con su driver y punto de montaje.

Crear y usar

Creás un volumen con nombre y, al desplegar un contenedor o stack, lo montás en una ruta (ej. postgres_data → /var/lib/postgresql/data). Aunque borres y recrees el contenedor, los datos persisten en el volumen.

Navegar contenido (browse)

El agent de Portainer habilita el Browse de un volumen: explorás sus archivos, subís y descargás desde la UI sin tocar el host. Es muy práctico para inspeccionar configuraciones o recuperar un archivo. (Requiere el agent; en el entorno local conectado solo por socket puede no estar disponible.)

Volúmenes vs bind mounts

	Volumen con nombre	Bind mount
Gestión	Docker/Portainer	Vos (ruta del host)
Portabilidad	Alta	Atado al host
Caso típico	Datos de apps (DB, uploads)	Config del host, código en dev

Para datos de producción preferí volúmenes con nombre.

Redes

La sección Networks gestiona cómo se comunican los contenedores.

Tipos de red

• bridge: la red por defecto de Docker en un host. Los contenedores en la misma bridge custom se ven por nombre.
• host: el contenedor comparte la pila de red del host (sin aislamiento de puertos).
• none: sin red.
• overlay: para comunicación entre nodos en Swarm (capítulo 9).
• macvlan: asigna al contenedor una MAC/IP propia en la LAN.

Crear una red custom

Lo habitual es crear una bridge custom por aplicación. Ventaja clave: dentro de una bridge custom, los contenedores se resuelven por nombre vía el DNS interno de Docker (ej. la app llega a la base de datos como db:5432). En la bridge por defecto eso no funciona.

Conectar y desconectar

Desde el detalle de una red ves qué contenedores están conectados, y podés conectar/desconectar contenedores en caliente. Un contenedor puede pertenecer a varias redes a la vez (ej. una red frontend y otra backend).

Buena práctica de segmentación: poné el reverse proxy y la app en una red, y la app y la base de datos en otra. Así la base de datos nunca queda expuesta a la red del proxy. Esto se declara naturalmente en un stack de Compose.

---

Anterior → Capítulo 4: Contenedores · Siguiente → Capítulo 6: Stacks y Compose