¿Qué aprenderemos?

Al terminar este bloque podrás explicar

• Qué es la tecnología de contenedores
• Qué problemas resuelve y cuáles no
• Cómo se relacionan Docker y los estándares abiertos
• Cómo se construye una imagen
• Cómo se ejecuta y administra un contenedor
• Cómo se conectan los servicios de una aplicación
• Cómo se conservan los datos
• Cómo se identifican errores comunes
• Qué elementos deben considerarse para desplegar una aplicación

Antes de hablar de Docker

¿Qué problema queremos resolver?

Imagina que desarrollaste una aplicación para administrar reservaciones

                ReservaFIC

                    │
          ┌─────────┴─────────┐
          ▼                   ▼
       Frontend               API
                                  │
                                  ▼
                              PostgreSQL

La aplicación funciona en tu computadora

Pero debes entregarla a otro equipo para que la ejecute

En mi máquina funciona

¿Por qué puede fallar?

El código puede ser el mismo pero el ambiente puede ser diferente

                   MISMO CÓDIGO

           ┌──────────┼──────────┐
           ▼          ▼          ▼

        Equipo A   Equipo B   Servidor

        PHP 8.3    PHP 8.2    PHP 8.3
        Node 24    Node 22    Node 20
        Config A   Config B   Config C

Un programa depende de algo más que sus archivos de código

El problema tiene varias partes

¿Qué necesitamos?

Queremos definir de forma controlada

Aplicación
    +
Dependencias
    +
Archivos necesarios
    +
Configuración de ejecución

Para poder crear un ambiente reproducible en diferentes equipos compatibles

Una primera definición

En el caso habitual de contenedores Linux

• Los procesos se ejecutan utilizando el kernel Linux disponible en su entorno de ejecución
• El aislamiento se implementa mediante mecanismos del sistema operativo
• Los archivos necesarios para ejecutar la aplicación se proporcionan mediante una imagen y sus capas

Una aplicación puede dividirse

                  APLICACIÓN

       ┌────────────┼────────────┐
       ▼            ▼            ▼

    Frontend       API       PostgreSQL

   contenedor   contenedor   contenedor

Cada componente puede tener su propio ciclo de vida y configuración

Una analogía para comenzar

Imagina una mudanza

ANTES

Ropa
Libros
Herramientas
Documentos

Todo mezclado

DESPUÉS

Caja 1 → libros
Caja 2 → herramientas
Caja 3 → documentos

Cada caja organiza los elementos que deben trasladarse juntos

Los contenedores ayudan a empaquetar y ejecutar software con sus archivos necesarios

La analogía tiene un límite

Una caja es un objeto físico

Un contenedor es un entorno de ejecución que el sistema operativo administra

Aplicación
    │
    ▼
Proceso aislado
    │
    ▼
Sistema operativo

Contenedor y máquina virtual

Arquitectura de una máquina virtual

┌───────────────────────────────┐
│ Aplicación                    │
├───────────────────────────────┤
│ Bibliotecas y dependencias    │
├───────────────────────────────┤
│ Sistema operativo invitado    │
├───────────────────────────────┤
│ Kernel del sistema invitado   │
└───────────────────────────────┘
                │
                ▼
            Hipervisor
                │
                ▼
             Hardware

Arquitectura de un contenedor Linux

┌───────────────────────────────┐
│ Aplicación                    │
├───────────────────────────────┤
│ Bibliotecas y dependencias    │
├───────────────────────────────┤
│ Archivos de la imagen         │
└───────────────────────────────┘
                │
                ▼
       Runtime de contenedores
                │
                ▼
┌───────────────────────────────┐
│ Kernel Linux compartido       │
└───────────────────────────────┘
                │
                ▼
             Hardware

La diferencia fundamental

La sobrecarga y el nivel de aislamiento dependen de la implementación y la configuración

¿Los contenedores siempre utilizan Linux?

No necesariamente

Existen contenedores Linux y contenedores Windows con diferentes requisitos

En este bloque estudiaremos principalmente contenedores Linux porque son la base de muchos entornos modernos de desarrollo y despliegue

Contenedores
    │
    ├── Contenedores Linux
    │
    └── Contenedores Windows

No se debe confundir el sistema operativo de tu computadora con el sistema operativo del entorno donde se ejecuta el contenedor

¿Qué pasa en Windows y macOS?

Una computadora Windows o macOS no proporciona de forma nativa el kernel Linux que necesitan los contenedores Linux

Por eso las herramientas habituales utilizan un entorno Linux

Windows o macOS
       │
       ▼
Entorno Linux
       │
       ▼
Motor de contenedores
       │
       ▼
Contenedores Linux

En Windows se utiliza comúnmente WSL 2 con Docker Desktop

En macOS Docker Desktop utiliza una máquina virtual Linux administrada por la herramienta

¿Qué puede contener una imagen?

Imagen de una aplicación

├── Archivos del programa
├── Bibliotecas necesarias
├── Dependencias
├── Certificados requeridos
├── Archivos de configuración predeterminados
└── Instrucciones de ejecución

Una imagen no tiene que contener todos los elementos de una computadora

Por ejemplo no necesita incluir un escritorio gráfico si ejecutará una API web

¿Qué no resuelven los contenedores automáticamente?

Los contenedores no garantizan por sí solos

• Que el código sea correcto
• Que la aplicación sea segura
• Que existan respaldos
• Que los datos sean persistentes
• Que el sistema soporte miles de usuarios
• Que todos los equipos tengan idéntico rendimiento
• Que un despliegue sea de alta disponibilidad

¿Qué es Docker?

Docker facilita el uso de la tecnología

Pero la tecnología de contenedores no pertenece exclusivamente a Docker

Herramientas del ecosistema

           TECNOLOGÍA DE CONTENEDORES

              ┌────────┼────────┐
              ▼        ▼        ▼

            Docker   Podman    otras

En este bloque utilizaremos Docker para los ejemplos y las actividades principales

Podman se presenta como alternativa para reconocer que existen otras implementaciones

¿Por qué utilizaremos Docker?

¿Qué herramienta utilizar según tu sistema operativo?

Consulta las instrucciones oficiales antes de instalar y verifica los requisitos de tu equipo

OrbStack no es un producto oficial de Docker

Windows: ¿qué piezas intervienen?

                    Windows
                       │
                       ▼
                Docker Desktop
                       │
                       ▼
                    WSL 2
                       │
                       ▼
                Entorno Linux
                       │
                       ▼
                 Contenedores

WSL 2 permite ejecutar un entorno Linux integrado con Windows

Docker Desktop administra los componentes necesarios para trabajar con contenedores Linux

¿Para qué sirve WSL 2?

WSL significa Windows Subsystem for Linux

Permite utilizar un entorno Linux desde Windows sin tener que reiniciar la computadora para cambiar de sistema operativo

En este curso puede utilizarse para practicar comandos como

pwd
ls -lah
mkdir proyecto

Docker Desktop y WSL 2 cumplen funciones relacionadas pero diferentes

macOS: opciones de trabajo

                  macOS
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼

Docker Desktop   OrbStack   Podman Desktop
       │            │            │
       ▼            ▼            ▼
              Entorno Linux
                    │
                    ▼
                Contenedores

Las alternativas tienen diferencias de instalación integración licenciamiento y administración

Para las actividades del curso se seguirá la configuración indicada por el docente

Linux: ejecución nativa

En una distribución compatible puede utilizarse Docker Engine directamente

Distribución Linux
        │
        ▼
    Docker CLI
        │
        ▼
   Docker Engine
        │
        ▼
    Contenedores

También existen alternativas como Podman

La instalación y los permisos dependen de la distribución y de la configuración elegida

¿Cómo comprobar que Docker funciona?

En una terminal compatible ejecuta

docker --version
docker compose version
docker info

Ejemplo de salida ilustrativa

$ docker --version
Docker version 28.x.x

$ docker compose version
Docker Compose version v2.x.x

Los números son ejemplos y pueden cambiar según la versión instalada

docker info muestra información del entorno y del motor

Primer comando con Docker

docker run --rm hello-world

¿Qué ocurre?

1. Docker recibe la petición
2. Busca la imagen local
3. Descarga la imagen si es necesario
4. Crea un contenedor
5. Ejecuta el programa
6. Muestra el resultado
7. Elimina el contenedor al terminar

La opción --rm elimina el contenedor cuando termina

La imagen puede permanecer en el equipo

¿Qué significa cada parte?

docker run --rm hello-world

Este comando es una comprobación inicial del funcionamiento de Docker

1 — Imagen

Por ejemplo una imagen puede incluir

PHP
+
Extensiones necesarias
+
Archivos de la aplicación
+
Instrucciones de ejecución

La imagen funciona como una plantilla para crear contenedores

Una imagen puede crear varios contenedores

               IMAGEN
             php-app:1.0
                  │
        ┌─────────┼─────────┐
        ▼         ▼         ▼
   Contenedor A Contenedor B Contenedor C

Los contenedores pueden compartir la misma imagen de origen

Cada uno tiene su propio estado de ejecución y su propia capa de escritura

2 — Contenedor

Imagen
   │
   │ docker run
   ▼
Contenedor
   │
   ▼
Proceso en ejecución

Un contenedor puede estar ejecutándose detenido o haber terminado

No es lo mismo un contenedor que un proceso necesariamente activo

Imagen contra contenedor

Los datos importantes no deben depender únicamente de la capa de escritura del contenedor

3 — Registry

Un registry es un servicio que almacena y distribuye imágenes

             Registry
                 │
       ┌─────────┴─────────┐
       ▼                   ▼
   Docker Hub       GitLab Container Registry

Ejemplos de operaciones

docker pull nginx:alpine
docker push registro.example.com/equipo/app:1.0.0

pull descarga una imagen

push publica una imagen en un registry al que tengas acceso

¿Qué es Docker Hub?

Docker Hub es un servicio de registro de imágenes que permite buscar descargar y distribuir imágenes

Antes de utilizar una imagen conviene revisar

• Quién la publica
• Qué software contiene
• Qué versiones ofrece
• Cuándo se actualizó
• Qué instrucciones y advertencias documenta
• Si su origen es confiable

No todas las imágenes disponibles en Internet son apropiadas para producción

4 — Red

Una aplicación puede tener componentes separados

frontend ─────► api ─────► db

Para comunicarse necesitan conectividad y una configuración correcta

Docker permite crear redes virtuales y conectar contenedores a ellas

Red del proyecto

  frontend ─── api ─── db

La red permite la comunicación entre servicios según sus conexiones y reglas

¿Qué significa localhost?

Dentro de un contenedor

CONTENEDOR APP

localhost
    │
    ▼
Este mismo contenedor

No significa automáticamente el contenedor de PostgreSQL ni la computadora del usuario

Si la aplicación necesita conectarse a otro servicio debemos usar una dirección accesible desde su entorno de red

Comunicación con Docker Compose

Si el proyecto define los servicios

services:
  app:
    image: ejemplo-app:1.0
  db:
    image: postgres:16

La aplicación puede utilizar el nombre del servicio como nombre de host dentro de la red de Compose

DB_HOST=db
DB_PORT=5432

Esto funciona cuando los servicios comparten una red apropiada y la base de datos está lista para recibir conexiones

¿Qué es un puerto?

Un puerto identifica un punto de comunicación de red asociado a un servicio

PostgreSQL utiliza normalmente el puerto 5432

Una publicación de puerto puede relacionar

HOST                         CONTENEDOR

localhost:5433 ─────────────► 5432

La aplicación que se conecta desde el host utiliza el puerto publicado

Los servicios conectados a la misma red Docker pueden comunicarse mediante el puerto interno del servicio

¿Cómo se publica un puerto?

docker run -d \
  --name web \
  -p 127.0.0.1:8080:80 \
  nginx:alpine

La publicación significa

127.0.0.1:8080
        │
        ▼
Puerto 80 del contenedor

En este ejemplo el puerto del host se publica solamente en la interfaz local

Si se omite la dirección de host el comportamiento de publicación puede exponer el puerto en otras interfaces según la configuración de Docker y del sistema

5 — Volumen

Imagina una base de datos que almacena reservaciones

Contenedor PostgreSQL
          │
          ▼
       Datos

Si eliminamos el contenedor no debemos asumir que los datos guardados únicamente en su capa de escritura se conservarán

Para persistir información utilizamos almacenamiento separado del ciclo de vida del contenedor

¿Qué es un volumen?

Contenedor
    │
    ▼
PostgreSQL
    │
    ▼
Volumen persistente
    │
    ▼
Datos

Eliminar un contenedor no elimina automáticamente todos los volúmenes asociados

Volumen y bind mount

Son dos formas de proporcionar almacenamiento a un contenedor

Ejemplos conceptuales

Volumen:
datos_postgres → directorio de datos

Bind mount:
./src → /app/src

Los cinco conceptos juntos

                 REGISTRY
                     │
                   pull
                     ▼
                  IMAGEN
                     │
                    run
                     ▼
                CONTENEDOR
                 /       \
                ▼         ▼
              RED       VOLUMEN
                │         │
                ▼         ▼
           comunicación  datos

Estos conceptos forman la base para comprender una aplicación contenerizada

¿Qué es docker ps?

docker ps

Muestra los contenedores que están ejecutándose

Ejemplo de salida ilustrativa

CONTAINER ID   IMAGE         COMMAND                  STATUS
a13c9e7d2b10   nginx:alpine  "/docker-entrypoint…"    Up 2 minutes

PORTS                  NAMES
127.0.0.1:8080->80/tcp web

Los identificadores y tiempos son ficticios

¿Qué información muestra?

El nombre puede facilitar la administración sin tener que copiar el ID

¿Y los contenedores detenidos?

docker ps -a

Ejemplo de salida ilustrativa

CONTAINER ID   IMAGE         STATUS                      NAMES
a13c9e7d2b10   nginx:alpine  Up 2 minutes                web
b51f0c8a8e90   hello-world   Exited (0) 5 minutes ago    hopeful_morse

docker ps muestra los contenedores activos

docker ps -a incluye también los contenedores detenidos y terminados

¿Qué imágenes tengo?

docker images

Ejemplo de salida ilustrativa

REPOSITORY    TAG       IMAGE ID       CREATED        SIZE
nginx         alpine    91ca84b4e7d1   2 weeks ago    48MB
hello-world   latest    74cc54e27dc4   3 months ago   10kB

Los identificadores tamaños y fechas son ejemplos

Una imagen puede existir localmente aunque no haya ningún contenedor ejecutándose con ella

Comandos para obtener imágenes

docker pull nginx:alpine

Descarga una imagen desde un registry

docker image ls

Lista las imágenes locales

docker image inspect nginx:alpine

Muestra metadatos de una imagen

docker image rm nginx:alpine

Elimina una referencia de imagen local cuando no existan dependencias que impidan hacerlo

Ejecutar un servidor web

docker run -d \
  --name web \
  -p 127.0.0.1:8080:80 \
  nginx:alpine

Ahora podemos consultar

docker ps

Y abrir en el navegador

http://localhost:8080

Si el puerto está ocupado o Docker no está disponible el resultado será diferente

¿Qué significa -d?

docker run -d nginx:alpine

La opción -d solicita ejecutar el contenedor en segundo plano

Sin ella la terminal puede permanecer conectada al proceso o mostrar directamente su salida

El comportamiento exacto también depende del programa ejecutado y de cómo maneja la entrada y salida estándar

¿Cómo consultamos los registros?

docker logs web

Para seguir la salida conforme aparecen nuevas líneas

docker logs -f web

Para limitar la cantidad inicial de líneas

docker logs --tail 50 web

Los registros ayudan a entender qué hizo el proceso y por qué pudo fallar

No todos los programas envían automáticamente todos sus registros a la salida estándar

¿Cómo entramos a un contenedor?

docker exec -it web sh

Descomposición

docker exec
Ejecuta un proceso en un contenedor existente

-it
Permite interactuar desde la terminal

web
Nombre del contenedor

sh
Intérprete de comandos solicitado

No todas las imágenes incluyen bash

Las imágenes mínimas pueden proporcionar solamente sh u otras herramientas reducidas

¿Qué podemos observar dentro?

pwd
ls -lah
ps

Los comandos disponibles dependen de la imagen

Al salir de la terminal

exit

normalmente termina la sesión interactiva pero no necesariamente el proceso principal del contenedor

Inspeccionar un contenedor

docker inspect web

Permite consultar información estructurada como

• Configuración de ejecución
• Direcciones de red
• Montajes
• Estado del contenedor
• Imagen de origen
• Configuración de puertos

Inspeccionar un contenedor: campos específicos

Para obtener solo algunos campos se puede utilizar el formato de salida de Docker

docker inspect --format '{{.State.Status}}' web

Salida ilustrativa

running

¿Qué recursos consume?

docker stats

Muestra información dinámica sobre el consumo de recursos de los contenedores

Ejemplo ilustrativo

CONTAINER   CPU %   MEM USAGE / LIMIT   MEM %
web         0.10%   12MiB / 2GiB        0.59%

Los valores dependen de la aplicación del host y de los límites configurados

Detener iniciar y eliminar

docker stop web

Solicita detener el contenedor

docker start web

Inicia un contenedor existente que está detenido

docker rm web

Elimina el contenedor detenido

docker image rm nginx:alpine

Elimina la imagen local si Docker permite retirarla

El ciclo de vida

             IMAGEN
                │
                ▼
          CREAR CONTENEDOR
                │
                ▼
           CONTENEDOR
                │
                ▼
          EJECUTAR PROCESO
             │       │
           stop    termina
             │       │
             ▼       ▼
          DETENIDO  EXITED
             │
             ▼
            start

¿Cómo se relacionan run y create?

docker create --name web nginx:alpine

Crea el contenedor sin iniciar el proceso principal

docker start web

Inicia el contenedor creado

En cambio

docker run --name web nginx:alpine

es una forma abreviada de solicitar la creación y ejecución del contenedor

¿Por qué necesitamos Linux?

Aunque Docker oculte parte de la complejidad es importante conocer los fundamentos del entorno

Los comandos de Linux ayudan a

• Navegar por directorios
• Inspeccionar archivos
• Leer registros
• Revisar procesos
• Comprender usuarios y permisos
• Diagnosticar problemas de ejecución

No necesitamos convertirnos en administradores Linux expertos para comenzar

La terminal y el directorio actual

pwd

Muestra el directorio actual

Ejemplo

/home/ana/proyectos/reservafic

ls

Lista los elementos del directorio

ls -lah

Muestra también archivos ocultos y detalles como permisos propietario y tamaño

Navegar por directorios

cd proyectos

Entra a un directorio relativo a la ubicación actual

cd ..

Sube al directorio padre

cd ~

Va al directorio personal del usuario

cd /var/log

Va a una ruta absoluta

La ruta absoluta comienza desde /

Crear directorios y archivos

mkdir proyecto

Crea un directorio

mkdir -p proyecto/config

Crea directorios intermedios si no existen

touch notas.txt

Crea un archivo vacío si no existe o actualiza sus marcas de tiempo

Copiar y mover archivos

cp notas.txt copia.txt

Copia un archivo

mv copia.txt respaldo.txt

Mueve o cambia el nombre de un archivo

Leer archivos y registros

cat archivo.txt

Muestra el contenido completo de un archivo pequeño

less archivo.txt

Permite revisar el contenido de forma interactiva

head -n 20 archivo.txt

Muestra las primeras 20 líneas

Leer archivos y registros: el final del archivo

tail -n 50 archivo.txt

Muestra las últimas 50 líneas

tail -f aplicacion.log

Sigue las líneas nuevas que aparecen en un archivo

Buscar archivos y texto

find . -name 'Dockerfile'

Busca archivos con ese nombre desde el directorio actual

grep -n 'ERROR' aplicacion.log

Busca líneas que contengan ERROR

grep -R 'DB_HOST' .

Busca una cadena en los archivos del directorio y sus subdirectorios

En proyectos grandes conviene limitar la búsqueda para evitar recorrer dependencias y archivos innecesarios

Procesos y consumo de recursos

ps aux

Muestra procesos del sistema en formatos habituales de Linux

top

Permite observar procesos y consumo de recursos de forma dinámica

kill PID

Envía una señal a un proceso identificado por su PID

No conviene terminar procesos sin identificar primero qué hacen

Dentro de un contenedor las herramientas disponibles pueden ser más limitadas que en el host

El comando rm requiere cuidado

rm archivo.txt

Elimina un archivo

rm -i archivo.txt

Solicita confirmación antes de eliminar el archivo

rm -r directorio

Elimina recursivamente un directorio y su contenido

Antes de eliminar conviene verificar la ruta y los permisos

Un comando destructivo no debe ejecutarse sin comprender su alcance

¿Quién ejecuta un proceso?

En Linux los procesos se ejecutan asociados a una identidad de usuario y a grupos

Usuario
   │
   ▼
Proceso
   │
   ▼
Permisos efectivos
   │
   ▼
Acceso a archivos y recursos

Los permisos ayudan a controlar qué acciones puede realizar cada identidad

Identificar al usuario actual

whoami

Ejemplo

ana

Para consultar el identificador numérico y los grupos

id

Ejemplo ilustrativo

uid=1000(ana) gid=1000(ana) groups=1000(ana),27(sudo)

Los números y grupos varían según el sistema

¿Qué es un grupo?

Un grupo permite asignar permisos compartidos a varios usuarios

Grupo: desarrollo

├── ana
├── luis
└── carlos

Un archivo puede pertenecer a un usuario y a un grupo

Los permisos pueden diferenciar entre el propietario el grupo y los demás usuarios

¿Cómo vemos los permisos?

ls -l

Salida ilustrativa

-rwxr-x--- 1 ana desarrollo 2048 oct 22 10:00 script.sh

Descomposición

-rwxr-x---

│ │   │  │
│ │   │  └── Otros usuarios
│ │   └───── Grupo
│ └───────── Propietario
└─────────── Tipo de archivo

El primer carácter

En la salida de ls -l el primer carácter representa el tipo de elemento

Después aparecen los permisos del propietario del grupo y de los demás usuarios

Los permisos básicos

El significado práctico depende del tipo de elemento y de los demás controles de acceso

Tres grupos de permisos

-rwxr-x---

  rwx  r-x  ---
   │    │    │
   │    │    └── Otros usuarios
   │    └─────── Grupo
   └──────────── Propietario

Para este ejemplo

• El propietario puede leer escribir y ejecutar
• Los miembros del grupo pueden leer y ejecutar
• Los demás no tienen permisos básicos

¿Qué es la notación octal?

Los permisos también pueden representarse mediante números

Cada permiso tiene un valor

Se suman los valores de los permisos que se desean conceder

¿Por qué se llama octal?

Porque utiliza ocho valores posibles del cero al siete para representar cada grupo de permisos

rwx = 4 + 2 + 1 = 7
rw- = 4 + 2 + 0 = 6
r-x = 4 + 0 + 1 = 5
r-- = 4 + 0 + 0 = 4

Ejemplos adicionales

-wx = 2 + 1 = 3
-w- = 2
--x = 1
--- = 0

Tabla de conversión

¿Cómo se interpreta 750?

chmod 750 script.sh

Se divide en tres dígitos

7  5  0
│  │  │
│  │  └── Otros
│  └───── Grupo
└──────── Propietario

Por tanto

750 = rwx r-x ---

El propietario puede leer escribir y ejecutar

El grupo puede leer y ejecutar

Los demás no tienen permisos básicos

Ejemplos de permisos

chmod 644 documento.txt

644 = rw- r-- r--

El propietario puede leer y modificar

El grupo y los demás pueden leer

chmod 600 archivo.conf

600 = rw- --- ---

Solo el propietario tiene lectura y escritura según estos permisos básicos

Permisos típicos para archivos y directorios

chmod 755 script.sh

Permite al propietario leer escribir y ejecutar y al grupo y demás leer y ejecutar

chmod 640 configuracion.conf

El propietario puede leer y escribir y el grupo puede leer

chmod 700 ~/.ssh

Restringe el acceso básico al directorio al propietario

Los permisos adecuados dependen del contenido y de los requisitos de la aplicación

Cuidado con 777

chmod 777 archivo

Significa

rwx rwx rwx

El propietario el grupo y los demás reciben lectura escritura y ejecución

Esto suele conceder más permisos de los necesarios y puede permitir modificaciones no deseadas

Permisos de directorios

Un directorio necesita permisos adecuados para las operaciones que se quieren realizar

• r permite listar nombres
• w permite crear o eliminar entradas sujeto a las demás condiciones
• x permite atravesar el directorio y acceder a elementos conocidos

Un directorio sin permiso x puede impedir el acceso a sus archivos aunque estos tengan permisos de lectura

¿Qué hace chown?

chmod cambia permisos

chown cambia propietario o grupo de un archivo

sudo chown ana:desarrollo archivo.txt

Significa asignar

Propietario: ana
Grupo: desarrollo

La operación puede requerir privilegios administrativos

En Linux el nombre del usuario y el nombre del grupo deben existir para poder asignarlos

¿Qué significa sudo?

sudo permite ejecutar un comando con los privilegios autorizados por la política del sistema

Ejemplo

sudo systemctl status docker

Consulta el estado del servicio Docker en sistemas que utilizan systemd y tienen ese servicio configurado

No todos los sistemas operativos ni todos los entornos utilizan systemctl

Crear un usuario en Linux

En Debian y Ubuntu puede utilizarse

sudo adduser ana

El comando guía al administrador para crear la cuenta y completar datos solicitados

Para consultar los grupos del usuario

id ana

Para consultar los grupos a los que pertenece el usuario actual

groups

Los comandos exactos para crear usuarios pueden variar según la distribución

¿Qué es el grupo docker?

En algunas instalaciones de Docker Engine para Linux existe un grupo llamado docker

getent group docker

Un administrador puede agregar un usuario con

sudo usermod -aG docker ana

El usuario normalmente debe iniciar una nueva sesión para que se actualicen sus grupos efectivos

Importante: pertenecer al grupo docker concede capacidades muy elevadas sobre el host y puede equivaler en la práctica a privilegios de administrador

No agregues usuarios a este grupo sin evaluar las implicaciones de seguridad

¿Los permisos funcionan igual dentro de un contenedor?

No siempre

Debemos distinguir

Permisos del host
        │
        ▼
Montajes y volúmenes
        │
        ▼
Identidad del proceso
        │
        ▼
Permisos dentro del contenedor

Los UID y GID las opciones de montaje y el modo de ejecución pueden afectar el acceso

Un archivo que funciona en una computadora puede generar errores de permisos en otro entorno

¿Qué sucede al ejecutar un contenedor?

docker run --rm alpine:3.22 echo "Hola desde un contenedor"

Ejemplo de salida ilustrativa

Hola desde un contenedor

Docker puede descargar la imagen si no existe localmente

Después crea el contenedor ejecuta el comando y elimina el contenedor cuando termina

La imagen puede permanecer almacenada

Ejecutar una terminal dentro de Alpine

docker run --rm -it alpine:3.22 sh

Dentro del contenedor puedes probar

pwd
ls -lah
id
cat /etc/os-release

Alpine utiliza una distribución Linux ligera

Por eso no debes asumir que incluye todas las herramientas que encontrarías en una distribución de escritorio o servidor

¿Qué demuestra este ejemplo?

Docker CLI
    │
    ▼
Imagen Alpine
    │
    ▼
Contenedor
    │
    ▼
Proceso sh

El contenedor no necesita iniciar una computadora completa con escritorio

Ejecuta el proceso configurado en un entorno aislado

La arquitectura conceptual

                 PERSONA USUARIA
                        │
                        ▼
                   Docker CLI
                        │
                        ▼
                   Docker API
                        │
                        ▼
                  Docker Engine
                        │
           ┌────────────┼────────────┐
           ▼            ▼            ▼
        Imágenes       Redes      Volúmenes
                        │
                        ▼
                   Contenedores

Esta es una vista simplificada de las principales responsabilidades

Docker CLI

CLI significa Command-Line Interface

Es la interfaz que utilizamos desde la terminal

docker ps
docker images
docker run nginx:alpine

La CLI interpreta los argumentos y solicita operaciones a la API de Docker

La CLI por sí sola no es el motor que ejecuta los contenedores

Docker Engine

Docker Engine proporciona las funciones principales para construir y ejecutar contenedores

En una instalación habitual de Docker Engine para Linux intervienen

Docker CLI
    │
    ▼
Docker API
    │
    ▼
Docker daemon
    │
    ▼
Componentes de ejecución

El daemon dockerd administra objetos Docker y coordina las operaciones necesarias para crear ejecutar y detener contenedores

¿Qué hace Docker daemon?

El daemon puede encargarse de tareas como

• Gestionar imágenes locales
• Crear y administrar contenedores
• Administrar redes Docker
• Administrar volúmenes
• Gestionar operaciones de construcción
• Coordinar operaciones solicitadas por la API

En Docker Desktop el entorno de ejecución se administra mediante componentes adicionales y no debe suponerse que todo ocurre directamente en el kernel del sistema operativo de escritorio

¿Qué sucede cuando ejecutas docker ps?

Persona usuaria
      │
      │ docker ps
      ▼
Docker CLI
      │
      │ petición a la API
      ▼
Docker Engine
      │
      │ consulta el estado
      ▼
Lista de contenedores
      │
      ▼
Salida en terminal

La CLI solicita la información y muestra el resultado

¿Qué hay debajo del Engine?

Una arquitectura simplificada de una instalación común puede representarse así

Docker CLI
     │
     ▼
Docker Engine
     │
     ▼
containerd
     │
     ▼
runtime OCI
     │
     ▼
Kernel del entorno

Los detalles internos pueden variar según la versión la plataforma y la configuración

No todos los componentes tienen que administrarse directamente por el usuario

¿Qué es containerd?

containerd es un componente que administra aspectos del ciclo de vida de los contenedores y las operaciones relacionadas con sus imágenes

Docker Engine
      │
      ▼
containerd
      │
      ▼
Gestión de contenedores

En un uso habitual de Docker el estudiante no necesita ejecutar containerd directamente

¿Qué es runc?

runc es una implementación de runtime de bajo nivel compatible con la especificación OCI Runtime

Se encarga de crear y ejecutar procesos de contenedor a partir de la configuración preparada para el runtime

Docker Engine
      │
      ▼
containerd
      │
      ▼
runc
      │
      ▼
Proceso aislado

Esta representación simplifica una implementación habitual

¿Qué es OCI?

OCI significa Open Container Initiative

Es una iniciativa abierta que mantiene especificaciones para mejorar la interoperabilidad entre herramientas de contenedores

Entre sus especificaciones principales se encuentran

• Image Specification
• Runtime Specification
• Distribution Specification

OCI define estándares y no sustituye herramientas como Docker o Podman

OCI Image Specification

Describe la estructura de una imagen de contenedor

Incluye elementos como

Manifest
    │
    ├── Configuración
    ├── Capas del sistema de archivos
    └── Descriptores de contenido

Su objetivo es favorecer herramientas interoperables para construir transportar y preparar imágenes

OCI Runtime Specification

Define aspectos de la configuración el entorno de ejecución y el ciclo de vida de un contenedor

Entre otros elementos puede describir

• El proceso que se ejecutará
• El sistema de archivos raíz
• Variables de entorno
• Parámetros de aislamiento
• Configuración de recursos
• Acciones del ciclo de vida

El runtime interpreta la configuración conforme a las capacidades que proporciona su plataforma

OCI Distribution Specification

Define un protocolo para distribuir contenido como imágenes mediante registries compatibles

Equipo de desarrollo
        │
        │ push
        ▼
      Registry
        │
        │ pull
        ▼
Servidor de despliegue

El objetivo es facilitar la distribución de imágenes entre herramientas compatibles

Docker y OCI son conceptos diferentes

Docker
Herramientas y plataforma
        │
        ▼
Construir y ejecutar contenedores

OCI
Estándares abiertos
        │
        ▼
Formatos y contratos de interoperabilidad

Una herramienta puede implementar o utilizar estándares abiertos sin que ambos conceptos sean equivalentes

¿Y dónde está Linux?

Linux proporciona mecanismos fundamentales utilizados por muchos entornos de contenedores

Runtime
   │
   ▼
Kernel Linux
   │
   ├── Namespaces
   ├── cgroups
   ├── Capacidades y permisos
   └── Otros mecanismos de seguridad

El runtime configura el entorno y el kernel aplica los mecanismos correspondientes

Namespaces: aislamiento

Los namespaces permiten proporcionar vistas aisladas de ciertos recursos del sistema

Algunos ejemplos

La disponibilidad y el comportamiento dependen de la plataforma y de la configuración

Namespace de procesos

En el host puede haber muchos procesos

HOST

PID 100 → nginx
PID 101 → postgres
PID 102 → php
PID 103 → bash

Dentro de un namespace de procesos un contenedor puede observar una vista distinta

CONTENEDOR

PID 1 → php

El PID que se ve dentro del contenedor no tiene por qué coincidir con el PID del host

Namespace de red

Un contenedor puede tener su propia vista de interfaces y configuración de red

HOST
 │
 ├── interfaz de red
 │
 └── entorno Docker
       │
       └── CONTENEDOR
             ├── interfaz virtual
             ├── dirección IP
             └── rutas

Esto ayuda a separar la configuración de red de distintos entornos de ejecución

La conectividad también depende de las redes y reglas configuradas por Docker y el host

cgroups: control de recursos

Los cgroups permiten organizar procesos y aplicar controles sobre el consumo de recursos compatibles con la plataforma

Por ejemplo

Contenedor A
CPU y memoria asignadas

Contenedor B
CPU y memoria asignadas

El objetivo es gestionar el uso de recursos y reducir el riesgo de que un proceso consuma recursos sin control

No todas las restricciones se comportan igual en todas las versiones o sistemas

¿Qué sucede con un límite de memoria?

Ejemplo

docker run --rm --memory 64m alpine:3.22 sh -c 'sleep 30'

Este ejemplo crea un contenedor con un límite de memoria configurado

No demuestra por sí solo qué ocurre cuando una aplicación supera el límite

Si los procesos consumen demasiada memoria pueden producirse errores o terminaciones por falta de memoria

¿Por qué importan namespaces y cgroups?

Junto con otros mecanismos contribuyen al funcionamiento de los contenedores Linux

El modelo mental completo

Persona usuaria
      ↓
Docker CLI
      ↓
Docker Engine
      ↓
Componentes de ejecución
      ↓
Runtime OCI
      ↓
Kernel del entorno
      │
      ├── Namespaces
      ├── cgroups
      └── otros mecanismos
      ↓
Proceso del contenedor

La arquitectura ayuda a comprender las responsabilidades y a diagnosticar fallos

De una imagen existente a una imagen propia

Registry
    │
    ▼
Imagen existente
    │
    ▼
Contenedor

Código
   │
   ▼
Dockerfile
   │
   ▼
Imagen propia
   │
   ▼
Contenedor

¿Qué es un Dockerfile?

Por ejemplo puede indicar

• Qué imagen se utilizará como base
• En qué directorio trabajar
• Qué archivos copiar
• Qué dependencias instalar
• Qué comando ejecutar al iniciar el contenedor

Dockerfile como receta

RECETA

1. Seleccionar ingredientes
2. Preparar los ingredientes
3. Seguir instrucciones
4. Obtener un resultado

DOCKERFILE

FROM
WORKDIR
COPY
RUN
CMD

Cada instrucción tiene una función específica durante la construcción o ejecución

Primer ejemplo con PHP

Archivo hola.php

<?php

echo "Hola desde PHP en un contenedor" . PHP_EOL;

Archivo Dockerfile

FROM php:8.3-cli

WORKDIR /app

COPY hola.php .

CMD ["php", "hola.php"]

La imagen base incluye PHP CLI y el Dockerfile agrega nuestro archivo y define el comando predeterminado

¿Qué significa FROM?

FROM php:8.3-cli

Indica la imagen base de la que partirá la construcción

Imagen base
php:8.3-cli
      │
      ▼
Nuestra imagen

La imagen base ya contiene archivos y componentes necesarios para ejecutar PHP CLI

Conviene elegir una versión compatible con la aplicación y revisar su mantenimiento

¿Qué significa WORKDIR?

WORKDIR /app

Establece el directorio de trabajo para las instrucciones posteriores que lo utilicen

Contenedor

/
├── usr
├── etc
└── app
    └── hola.php

Docker crea el directorio si es necesario durante la construcción

¿Qué significa COPY?

COPY hola.php .

Copia el archivo desde el contexto de construcción al directorio de trabajo de la imagen

Equipo de desarrollo
       │
       │ COPY
       ▼
Imagen
/app/hola.php

La ruta de origen se interpreta dentro del contexto de construcción

¿Qué significa RUN?

RUN comando

Ejecuta una instrucción durante la construcción de la imagen

Por ejemplo en una imagen basada en Debian o Ubuntu

RUN apt-get update

No es un comando que se repita automáticamente cada vez que se inicia el contenedor

La sintaxis y los paquetes disponibles dependen de la imagen base

¿Qué significa CMD?

CMD ["php", "hola.php"]

Define el comando predeterminado que se ejecutará al iniciar el contenedor si no se proporciona otro comando que lo sustituya

Imagen
   │
   ▼
docker run
   │
   ▼
php hola.php

La forma de lista JSON suele ser preferible para ejecutar directamente el programa y gestionar señales correctamente

RUN contra CMD

No deben utilizarse como si fueran instrucciones equivalentes

Construir la imagen

Desde el directorio que contiene el Dockerfile y hola.php

docker build -t hola-php:1.0 .

Significado

docker build
Construye una imagen

-t hola-php:1.0
Asigna nombre y etiqueta

.
Utiliza el directorio actual como contexto

La construcción puede descargar la imagen base si no está disponible localmente

Ejecutar la imagen

docker run --rm hola-php:1.0

Salida ilustrativa

Hola desde PHP en un contenedor

El comando inicia el proceso definido por CMD

Como se utiliza --rm el contenedor se elimina al terminar

La imagen hola-php:1.0 permanece disponible localmente

¿Qué es una etiqueta?

Una etiqueta permite identificar una versión o variante de una imagen

hola-php:1.0
hola-php:1.1
hola-php:2.0

No se debe asumir que una etiqueta garantiza por sí sola que el contenido nunca cambiará

Para identificar contenido de manera más precisa existen referencias por digest

¿Qué son las capas de una imagen?

Las imágenes se construyen mediante capas y metadatos

┌─────────────────────────────┐
│ Archivos de la aplicación   │
├─────────────────────────────┤
│ Dependencias                │
├─────────────────────────────┤
│ PHP                         │
├─────────────────────────────┤
│ Archivos de la imagen base  │
└─────────────────────────────┘

Las capas permiten reutilizar contenido compartido y optimizar construcciones y descargas

¿Por qué importa el orden?

Si una instrucción cambia puede invalidarse parte de la caché de construcción

Menos eficiente para muchos proyectos

COPY . .
RUN composer install

Una alternativa común

COPY composer.json composer.lock ./
RUN composer install
COPY . .

Así los archivos de dependencias pueden aprovechar la caché cuando no cambian

La estrategia correcta depende del sistema de construcción y de la aplicación

¿Qué es .dockerignore?

Es un archivo que indica qué rutas deben excluirse del contexto de construcción enviado a Docker

Ejemplo

.git
.env
.env.*
node_modules
vendor
storage/logs

La lista debe adaptarse al proyecto

No conviene excluir archivos que sean necesarios para construir correctamente la imagen

¿Por qué es importante?

El contexto de construcción puede incluir

Código
Dependencias locales
Archivos temporales
Credenciales
Historial Git
Registros

Un .dockerignore adecuado reduce archivos innecesarios y ayuda a evitar que información sensible se incorpore accidentalmente al contexto

No es un mecanismo suficiente para proteger secretos por sí solo

Configuración y secretos

CÓDIGO

app/
routes/
controllers/

CONFIGURACIÓN

APP_ENV
DB_HOST
DB_PORT

SECRETOS

DB_PASSWORD
API_KEY
APP_KEY

La configuración debe separarse del código siempre que sea posible

Los secretos no deben quedar incrustados en el Dockerfile ni en las capas de la imagen

Un Dockerfile problemático

FROM php:latest

ENV DB_PASSWORD=ClaveReal

COPY . /var/www/html

RUN chmod -R 777 /var/www/html

CMD ["php", "-S", "0.0.0.0:8000"]

Problemas que debemos reconocer

• La etiqueta latest puede cambiar
• Se incorpora una contraseña a la imagen
• Se conceden permisos excesivos
• No se documentan claramente las dependencias
• El servidor integrado de PHP no debe asumirse apropiado para producción

Principios para mejorar una imagen

Las decisiones deben responder a los requisitos reales de la aplicación

¿Qué significa ejecutar como usuario no root?

En Linux el usuario root tiene privilegios muy elevados

Cuando sea compatible con la aplicación podemos configurar un usuario específico

USER app

El usuario debe existir y tener permisos suficientes para ejecutar el programa y acceder a sus archivos

No se debe asumir que todas las imágenes incluyen un usuario llamado app

Multi-stage builds

Algunas aplicaciones necesitan herramientas para construir pero no para ejecutarse

Una construcción por etapas permite separar ambos entornos

Etapa de construcción
Compiladores y herramientas
        │
        ▼
Artefactos generados
        │
        ▼
Etapa de ejecución
Solo componentes necesarios

Esta técnica puede reducir el tamaño de la imagen final y la cantidad de herramientas disponibles en ejecución

Su implementación depende del lenguaje y del proceso de construcción

Cuando un contenedor no es suficiente

Nuestra aplicación puede requerir

ReservaFIC

├── app
├── db
└── proxy

Cada servicio tiene una responsabilidad diferente

Necesitamos definir cómo se construye cómo se conecta y cómo se ejecuta cada componente

El problema de administrar cada servicio manualmente

docker network create reservafic
docker volume create datos_pg
docker run ...
docker run ...
docker run ...

Una aplicación multicontenedor puede requerir muchas opciones de configuración

Si cada integrante del equipo ejecuta comandos diferentes el ambiente puede volverse difícil de reproducir

¿Qué es Docker Compose?

El archivo describe servicios redes volúmenes y otras opciones de ejecución

compose.yaml
     │
     ▼
docker compose up
     │
     ▼
Aplicación multicontenedor

Un primer archivo Compose

services:
  web:
    image: nginx:alpine
    ports:
      - "127.0.0.1:8080:80"

Este archivo define un servicio llamado web

El servicio utiliza la imagen nginx:alpine y publica el puerto 80 del contenedor en el puerto 8080 del host

El puerto se publica solamente en la interfaz local

¿Cómo ejecutamos Compose?

En el directorio que contiene compose.yaml

docker compose up -d

Consulta los servicios y contenedores

docker compose ps

Consulta los registros

docker compose logs

Sigue los registros

docker compose logs -f

¿Cómo detenemos el proyecto?

docker compose down

Detiene y elimina los recursos de contenedores y redes del proyecto que administra Compose según su configuración

Los volúmenes no se eliminan normalmente con este comando

docker compose down -v

Solicita eliminar también los volúmenes asociados incluidos en el alcance del comando

Eliminar volúmenes puede provocar pérdida de datos

Un ejemplo con dos servicios

services:
  web:
    image: nginx:alpine
    ports:
      - "127.0.0.1:8080:80"

  app:
    image: php:8.3-cli
    command: ["php", "-v"]

Este ejemplo demuestra la definición de dos servicios

No constituye todavía una aplicación web completa porque no conecta el servidor Nginx con una aplicación PHP funcional

¿Cómo se comunican los servicios?

Compose crea una red para el proyecto de forma predeterminada

Red del proyecto

┌──────────┐          ┌──────────┐
│ web      │          │ app      │
│          │          │          │
└──────────┘          └──────────┘

Los servicios conectados a esa red pueden localizarse mediante el nombre del servicio cuando la configuración y el protocolo son correctos

El nombre de servicio no reemplaza la configuración de puertos ni hace que una aplicación escuche automáticamente

Una aplicación con base de datos

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: reservafic
      POSTGRES_USER: reservafic
      POSTGRES_PASSWORD: ejemplo-no-produccion
    volumes:
      - datos_pg:/var/lib/postgresql/data

volumes:
  datos_pg:

Este ejemplo crea un servicio de PostgreSQL y un volumen nombrado para sus datos

La contraseña es ilustrativa y no debe utilizarse en producción

¿Qué significa cada parte?

services
    │
    └── db
         │
         ├── image
         ├── environment
         └── volumes

volumes
    │
    └── datos_pg

services define los componentes de la aplicación

environment establece variables de entorno

volumes declara almacenamiento persistente administrado por Docker

Configuración sensible en Compose

Las variables de entorno pueden servir para configurar una aplicación pero no deben considerarse un almacén de secretos de producción

Para un entorno real debemos evaluar

• Mecanismos de gestión de secretos
• Permisos de acceso
• Archivos excluidos de Git
• Rotación de credenciales
• Separación de ambientes
• Riesgos de exponer variables en registros o herramientas de diagnóstico

Un archivo .env tampoco debe publicarse con credenciales reales en un repositorio público

depends_on no significa que todo esté listo

Un servicio puede haberse iniciado aunque la aplicación todavía no esté lista para recibir conexiones

Contenedor DB iniciado
        │
        ▼
PostgreSQL inicializando
        │
        ▼
PostgreSQL listo

El orden de inicio y la disponibilidad del servicio son conceptos distintos

Las aplicaciones deben manejar errores temporales y reintentos cuando corresponda

Health checks

Un health check permite definir una comprobación de salud para un contenedor cuando la imagen o la configuración lo permiten

Servicio
   │
   ▼
Comprobación
   │
   ├── no saludable
   │
   └── saludable

Un servicio puede estar ejecutándose y aun así no responder correctamente a las solicitudes

La comprobación debe evaluar una condición significativa para el servicio

El aislamiento no es una frontera mágica

La seguridad depende de varios componentes

Host
 │
 ├── Kernel
 ├── Motor
 ├── Runtime
 ├── Imagen
 ├── Red
 ├── Volúmenes
 ├── Secretos
 └── Permisos

Una configuración insegura puede reducir las ventajas del aislamiento

Ejecutar como root

Un proceso ejecutado como root dentro de un contenedor puede tener privilegios elevados dentro de su entorno

No significa automáticamente que tenga todos los privilegios del host pero tampoco debe asumirse que está completamente protegido

Cuando sea compatible

• Utiliza usuarios no privilegiados
• Evita capacidades innecesarias
• No uses el modo privilegiado sin justificación
• Revisa los montajes del host
• Mantén actualizado el motor y las imágenes

Cuidado con los montajes del host

Un montaje puede dar acceso a archivos externos al contenedor

HOST
 │
 └── directorio compartido
          │
          ▼
      CONTENEDOR

Si se monta un directorio sensible con permisos de escritura el contenedor puede modificar los archivos que tenga autorizados

No montes rutas críticas del host sin comprender el efecto

Cuidado con los puertos publicados

Una base de datos normalmente no necesita estar expuesta públicamente para que la aplicación la utilice

Arquitectura preferible para muchos casos

Internet
   │
   ▼
Proxy HTTPS
   │
   ▼
Aplicación
   │
   ▼
Base de datos en red interna

La exposición de servicios debe limitarse a los componentes que realmente necesitan acceso externo

Imágenes y cadena de suministro

Antes de utilizar una imagen revisa

• Su origen
• Su mantenimiento
• Sus versiones
• Sus dependencias
• Sus vulnerabilidades conocidas
• La forma en que se distribuye
• Los mecanismos disponibles para verificar su integridad

Utilizar una imagen oficial puede ayudar a identificar su origen pero no elimina la necesidad de mantenerla actualizada y evaluar sus riesgos

Contenedores desechables

La estrategia habitual de actualización consiste en crear una nueva imagen y reemplazar los contenedores correspondientes

Imagen V1
    │
    ▼
Contenedor V1
    │
    ▼
Construir imagen V2
    │
    ▼
Crear contenedor V2

No conviene depender de entrar manualmente a un contenedor en ejecución para modificarlo como mecanismo principal de actualización

Los cambios hechos solo en la capa de escritura pueden perderse al recrear el contenedor

Desarrollo y producción

En desarrollo buscamos facilidad para modificar el código y observar resultados

En producción necesitamos además controlar disponibilidad seguridad configuración datos y recuperación

DESARROLLO

Código + imágenes + Compose

PRODUCCIÓN

Imágenes versionadas
+ configuración controlada
+ datos persistentes
+ monitoreo
+ respaldos
+ seguridad

Contenerizar no sustituye la planeación de operación

¿Qué llevamos al servidor?

Aplicación
    │
    ├── Imagen
    ├── Configuración
    ├── Datos persistentes
    ├── Redes
    └── Dependencias de infraestructura

No necesitamos trasladar literalmente toda la computadora del desarrollador

Necesitamos definir los artefactos y servicios necesarios para ejecutar la aplicación en el ambiente destino

Distribución de imágenes

Equipo de desarrollo
        │
        ▼
docker build
        │
        ▼
Imagen versionada
        │
        ▼
Registry
        │
        ▼
Servidor
        │
        ▼
docker compose up

El registry puede ser Docker Hub o un registro privado como GitLab Container Registry

El servidor debe tener acceso autorizado al registro y a la configuración requerida

¿Por qué versionar imágenes?

Ejemplo

reservafic:1.0.0
reservafic:1.1.0
reservafic:1.2.0

Las etiquetas permiten identificar versiones de la aplicación

Para despliegues reproducibles debemos controlar también las imágenes base las dependencias y la configuración

Una etiqueta por sí sola no garantiza que el contenido de una referencia sea inmutable

¿Qué significa reproducibilidad?

Equipo A
   │
   ▼
Repositorio
   │
   ▼
Definición de ambiente
   │
   ▼
Ejecución

Equipo B
   │
   ▼
Repositorio
   │
   ▼
Definición de ambiente
   │
   ▼
Ejecución

Buscamos que ambos equipos utilicen versiones y configuraciones controladas

El resultado puede seguir dependiendo de diferencias de arquitectura recursos y del entorno de ejecución

¿Cómo diagnosticamos un contenedor detenido?

Primero observamos

docker ps -a

Después consultamos sus registros

docker logs nombre_contenedor

Y examinamos su configuración

docker inspect nombre_contenedor

No comenzamos eliminando todo ni reconstruyendo la aplicación sin entender el problema

Error frecuente: puerto ocupado

Supongamos que aparece un error al publicar

Bind for 127.0.0.1:8080 failed
port is already allocated

Una causa posible es que otro proceso o contenedor ya utilice el puerto

Podemos revisar

docker ps

También debemos comprobar los procesos y servicios del host mediante las herramientas apropiadas para el sistema operativo

Error frecuente: conexión rechazada

Aplicación
    │
    ▼
localhost:5432
    │
    ▼
Connection refused

Preguntas de diagnóstico

• ¿PostgreSQL está ejecutándose?
• ¿Está listo para aceptar conexiones?
• ¿La dirección es correcta?
• ¿La aplicación está dentro o fuera de un contenedor?
• ¿El puerto corresponde al servicio correcto?
• ¿Los servicios comparten la red adecuada?

Error frecuente: permisos denegados

Permission denied

Antes de cambiar permisos revisamos

whoami
id
ls -l archivo

También debemos verificar

• Quién es el propietario
• Qué grupos intervienen
• Qué permisos tiene el directorio padre
• Qué usuario ejecuta el proceso del contenedor
• Si hay un volumen o bind mount involucrado

No utilices chmod 777 como solución automática

Error frecuente: desaparecieron los datos

Primero preguntamos dónde se almacenaban

¿Capa de escritura del contenedor?
        │
        ▼
Datos ligados al ciclo de vida del contenedor

¿Volumen nombrado?
        │
        ▼
Datos separados del ciclo de vida del contenedor

Después revisamos si el volumen existe y si fue eliminado

Los respaldos siguen siendo necesarios aunque utilicemos volúmenes

Comandos para revisar el entorno

docker version
docker info
docker ps -a
docker images
docker network ls
docker volume ls

Para un contenedor específico

docker inspect nombre_contenedor
docker logs nombre_contenedor
docker stats

Estos comandos ayudan a obtener evidencia antes de cambiar la configuración

Contenedores y escalabilidad

Los contenedores facilitan empaquetar y ejecutar componentes de una aplicación

Pero no garantizan por sí solos que el sistema soporte más usuarios

Contenerizar
     │
     ▼
Estandarizar el entorno
     │
     ▼
Medir el comportamiento
     │
     ▼
Identificar límites
     │
     ▼
Tomar decisiones de escalabilidad

No confundamos usuarios y solicitudes

Usuarios registrados
        ↓
Usuarios activos
        ↓
Usuarios concurrentes
        ↓
Solicitudes por segundo

Son medidas diferentes

No es correcto afirmar que una aplicación soporta una cantidad determinada de usuarios solamente porque utiliza Docker

La capacidad debe medirse con un escenario definido

¿Qué debemos observar?

• Solicitudes por segundo
• Latencia
• Percentiles como p95
• Errores
• CPU
• Memoria
• Capacidad de la base de datos
• Consumo de conexiones
• Comportamiento durante la recuperación

Los resultados deben distinguirse entre valores medidos estimaciones y objetivos de diseño

Escalamiento vertical y horizontal

CPU y memoria
      ↑
  más recursos

app  app  app
  \   |   /
  tráfico

La estrategia adecuada depende de la arquitectura y de los límites de cada componente

¿Qué ocurre si la base de datos es el límite?

app 1 ──┐
app 2 ──┼──► PostgreSQL
app 3 ──┘

Agregar más instancias de la aplicación puede aumentar la presión sobre la base de datos

Antes de escalar hay que identificar el cuello de botella

Puede estar en el código la CPU la memoria el almacenamiento la red o una dependencia externa

¿Cuándo aparece Kubernetes?

Cuando hay muchos contenedores y servicios puede ser necesario automatizar tareas como

• Programar contenedores en distintos nodos
• Recuperar servicios después de ciertos fallos
• Distribuir tráfico
• Gestionar actualizaciones
• Escalar cargas de trabajo
• Descubrir servicios

Kubernetes es una plataforma de orquestación de contenedores

En este bloque se estudian sus fundamentos conceptuales sin convertirlo en la herramienta principal

Docker y Kubernetes cumplen funciones diferentes

Contenedores
    │
    ▼
Docker y otras herramientas
    │
    ▼
Construir distribuir y ejecutar imágenes

Orquestación
    │
    ▼
Kubernetes
    │
    ▼
Administrar cargas de trabajo en un clúster

La orquestación se estudia después de comprender imágenes contenedores redes y almacenamiento

Arquitectura de referencia

                   Usuario
                      │
                      ▼
                 Proxy HTTPS
                      │
                      ▼
                 Aplicación
                Laravel / PHP
                      │
                ┌─────┴─────┐
                ▼           ▼
            PostgreSQL    Redis

Esta arquitectura es ilustrativa

La cantidad de servicios y sus relaciones dependen de las necesidades reales de la aplicación

¿Qué componentes debemos identificar?

También debemos identificar configuración secretos y dependencias externas

El recorrido tecnológico

Código fuente
     │
     ▼
Dockerfile
     │
     ▼
Imagen versionada
     │
     ▼
Registry
     │
     ▼
Docker Compose
     │
     ▼
Servicios y redes
     │
     ▼
Servidor de despliegue

El objetivo es comprender qué hace cada componente y cómo se relaciona con el resto

Antes de ejecutar un comando

Predice el resultado

¿Qué imagen utilizará?

¿Qué contenedor se creará?

¿Qué proceso ejecutará?

¿Qué puerto se publicará?

¿En qué red estará?

¿Dónde se guardarán los datos?

¿Qué ocurrirá al detenerlo?

¿Qué ocurrirá al eliminarlo?

La predicción permite relacionar los comandos con el modelo conceptual

Después de ejecutar

No basta con afirmar que funcionó

Debemos explicar

Qué hizo Docker

Qué hizo el contenedor

Qué proceso se ejecutó

Qué hizo la red

Qué hizo el volumen

Qué evidencia confirma el resultado

El objetivo es desarrollar capacidad de análisis y diagnóstico

Pregunta 1

¿Qué es un contenedor?

Respuesta esperada

Un entorno de ejecución aislado para procesos que utilizan los archivos y dependencias necesarios para ejecutar una aplicación

Pregunta 2

¿Docker y los contenedores son lo mismo?

Respuesta

NO

Contenedores = tecnología

Docker = plataforma y conjunto de herramientas

Pregunta 3

¿Qué diferencia existe entre imagen y contenedor?

Respuesta esperada

La imagen es una plantilla de solo lectura y el contenedor es una instancia creada a partir de ella con una configuración y un ciclo de vida propios

Pregunta 4

¿Para qué sirve un volumen?

Respuesta esperada

Para conservar datos fuera de la capa de escritura del contenedor y separarlos de su ciclo de vida

Pregunta 5

¿Qué ocurre con localhost dentro de un contenedor?

Respuesta esperada

Normalmente identifica al propio contenedor y no automáticamente a otro servicio ni a la computadora del usuario

Pregunta 6

¿Qué diferencia existe entre RUN y CMD?

Respuesta esperada

RUN ejecuta instrucciones durante la construcción de la imagen y CMD define el comando o los parámetros predeterminados al iniciar el contenedor

Pregunta 7

¿Qué significa el permiso 750?

Respuesta esperada

750 = rwx r-x ---

El propietario tiene lectura escritura y ejecución

El grupo tiene lectura y ejecución

Los demás no tienen permisos básicos

Pregunta 8

¿Qué hacen namespaces y cgroups?

Respuesta esperada

Los namespaces proporcionan aislamiento de vistas de recursos del sistema y los cgroups permiten controlar recursos utilizados por grupos de procesos

Pregunta 9

¿Qué es OCI?

Respuesta esperada

Una iniciativa abierta que mantiene especificaciones para formatos ejecución y distribución de contenedores

Pregunta 10

¿Por qué no basta con ejecutar docker compose up?

Respuesta esperada

Porque debemos comprender qué imágenes y servicios se ejecutan cómo se comunican dónde se guardan los datos qué permisos tienen y cómo se diagnostican los fallos

Del problema a la aplicación

PROBLEMA
"En mi máquina funciona"
       ↓
TECNOLOGÍA DE CONTENEDORES
       ↓
IMÁGENES Y CONTENEDORES
       ↓
DOCKER CLI Y ENGINE
       ↓
REDES Y VOLÚMENES
       ↓
DOCKERFILE Y COMPOSE
       ↓
REGISTRY Y VERSIONADO
       ↓
DESPLIEGUE
       ↓
OPERACIÓN Y DIAGNÓSTICO
       ↓
ESCALABILIDAD

Y debajo de la herramienta

Docker
  │
  ▼
Componentes de ejecución
  │
  ▼
Runtime OCI
  │
  ▼
Kernel del entorno
  │
  ├── Namespaces
  ├── cgroups
  └── Otros mecanismos

La herramienta nos oculta parte de la complejidad

El profesional debe comprender las responsabilidades de cada capa

Fuentes oficiales para profundizar

Docker

• Introducción a Docker
  https://docs.docker.com/get-started/
• Docker Engine
  https://docs.docker.com/engine/
• Docker Compose
  https://docs.docker.com/compose/
• Referencia de comandos
  https://docs.docker.com/reference/cli/docker/

Fuentes oficiales para profundizar

Entornos de desarrollo

• Instalación de Docker Engine en Linux
  https://docs.docker.com/engine/install/
• Docker Desktop para Windows
  https://docs.docker.com/desktop/setup/install/windows-install/
• Docker Desktop para macOS
  https://docs.docker.com/desktop/setup/install/mac-install/
• WSL
  https://learn.microsoft.com/es-es/windows/wsl/about

Fuentes oficiales para profundizar

Estándares y alternativas

• Open Container Initiative
  https://opencontainers.org/
• OCI Image Specification
  https://github.com/opencontainers/image-spec
• OCI Runtime Specification
  https://github.com/opencontainers/runtime-spec
• OCI Distribution Specification
  https://github.com/opencontainers/distribution-spec
• Documentación de Podman
  https://podman.io/docs/
• Documentación de Podman Desktop
  https://podman-desktop.io/docs/

Fuentes oficiales para profundizar

Linux y orquestación

• Manuales de Linux
  https://man7.org/linux/man-pages/
• Conceptos de contenedores en Kubernetes
  https://kubernetes.io/docs/concepts/containers/

Lo que debes llevarte

Y también

Imagen
   ↓
Contenedor
   ↓
Red
   ↓
Volumen
   ↓
Dockerfile
   ↓
Compose
   ↓
Registry

Linux
Permisos
Runtime
Namespaces
cgroups
Seguridad
Diagnóstico

La idea profesional