Ir al contenido

Conceptos 01 - Conceptos fundamentales de contenedores

Un contenedor encapsula una aplicación y su entorno de ejecución con una estructura más ligera que una máquina virtual. En lugar de empaquetar un sistema operativo completo, incluye la aplicación, sus dependencias y las bibliotecas necesarias.

  • 7 conceptos
  • 6 elementos interactivos
  • Autoevaluación final

Concepto 1 de 7

Conceptos básicos

Cuatro conceptos que conviene distinguir antes de profundizar en el funcionamiento de los contenedores.

Imagen

Artefacto empaquetado e inmutable que contiene la aplicación, sus dependencias y la configuración necesaria para ejecutarla.

Contenedor

Instancia en ejecución de una imagen. Puede iniciarse, detenerse, reiniciarse o eliminarse.

Runtime

Componente que ejecuta el contenedor y aplica los mecanismos de aislamiento y control definidos por la plataforma.

Kernel compartido

Los contenedores no arrancan su propio kernel. Todos utilizan el kernel del sistema operativo anfitrión.

Pruébalo: crea varios contenedores a partir de la misma imagen y cambia su estado. Observa que la imagen nunca se modifica.

Imagen inmutable

mi-app:1.0

app · dependencias · configuración

Aún no hay contenedores. Crea el primero desde la imagen.

    0 contenedores desde una sola imagen

    $docker images # mi-app:1.0 está lista para ejecutarse

    Concepto 2 de 7

    Contenedor y proceso

    Un contenedor no es una mini máquina virtual. Es un proceso o conjunto de procesos del sistema operativo anfitrión ejecutados con aislamiento adicional.

    Cambia el punto de vista: primero mira los procesos desde dentro del contenedor y luego desde el host. Son los mismos procesos con otra numeración.

    docker exec web ps
    PIDProcesoDescripción
    1systemdinit del sistema anfitrión
    812dockerddaemon de Docker
    845containerdruntime de contenedores
    4190containerd-shimsupervisa el contenedor
    1appPID 1 dentroproceso principal de la aplicación
    2workerPID 2 dentroproceso auxiliar (opcional)
    3log-agentPID 3 dentroproceso auxiliar (opcional)
    5120sshdservicio del host
    6034bashterminal de un usuario del host
    Kernel del sistema operativo anfitrión

    Procesos del contenedor

    Dentro del contenedor, el namespace PID muestra solo sus propios procesos, numerados desde 1. El proceso principal de la aplicación es el PID 1.

    Concepto 3 de 7

    Máquinas virtuales vs. contenedores

    Dos modelos de aislamiento con diferencias fundamentales en su estructura y consumo de recursos.

    Selecciona cada capa para ver qué aporta y usa Simular arranque para comparar cuánto trabajo hace cada modelo antes de que la aplicación esté disponible.

    Máquina virtual4 pasos hasta la app

    Contenedor2 pasos hasta la app

    Explora las capas

    Selecciona una capa para ver qué aporta, o simula el arranque de ambos modelos.

    Animación ilustrativa: muestra los pasos, no tiempos reales.

    Concepto 4 de 7

    Contenedores de aplicación vs. contenedores de sistema

    Dos enfoques distintos para usar contenedores, con propósitos y herramientas diferentes.

    Contenedor de aplicación

    En este curso

    Empaqueta y ejecuta un servicio o proceso principal de la forma más ligera posible. Es el enfoque típico de Docker y el estándar predominante en el desarrollo de software moderno, microservicios, CI/CD y despliegues en la nube.

    Qué ejecuta
    Un servicio o proceso principal
    Objetivo
    Ser lo más ligero posible
    Uso típico
    Microservicios, CI/CD y despliegues en la nube
    Herramientas
    Docker

    Contenedor de sistema

    Ofrece una experiencia más cercana a un sistema completo, con múltiples servicios y un init, sin llegar a virtualizar hardware. Herramientas como LXC y gestores como LXD o Incus apuntan a este caso de uso.

    Qué ejecuta
    Múltiples servicios y un init
    Objetivo
    Parecerse a un sistema completo
    Uso típico
    Entornos con varios servicios, como un servidor tradicional
    Herramientas
    LXC, LXD e Incus

    Concepto 5 de 7

    Por qué los contenedores son más ligeros y rápidos

    No requieren arrancar un kernel ni un sistema operativo invitado. Su ciclo de vida se asemeja al de los procesos del sistema operativo.

    Los contenedores suelen ser rápidos de crear e iniciar. Sin embargo, no son “gratuitos” en términos de costo operativo. En escenarios reales existe una sobrecarga asociada a los siguientes factores. Abre cada uno para ver de dónde viene.

    Mito

    “Los contenedores no tienen costo operativo.”

    Realidad

    Tienen menos sobrecarga que una VM, pero no cero. Estos factores la explican:

    1Runtime de contenedores

    El daemon y los procesos que gestionan el ciclo de vida de cada contenedor (dockerd, containerd, containerd-shim) consumen CPU y memoria propios.

    2Sistema de archivos por capas

    OverlayFS combina capas de solo lectura con una capa escribible. La copia en escritura añade costo cuando la aplicación modifica muchos archivos.

    3Networking virtual

    Bridges, interfaces veth y reglas NAT agregan saltos al tráfico entre contenedores y hacia el exterior.

    4Logging, sidecars y auxiliares

    Recolectores de logs, proxies y agentes que acompañan a la aplicación también consumen recursos del host.

    Concepto 6 de 7

    Implicación práctica del kernel compartido

    Un contenedor depende del tipo de kernel del host. Esto define qué contenedores pueden ejecutarse en cada sistema.

    La regla es simple: el contenedor necesita el mismo tipo de kernel para el que fue construido. Elige un sistema anfitrión y un tipo de contenedor para ver qué ocurre.

    Contenedor LinuxKernel Linux
    Contenedor WindowsKernel Windows

    Sistema anfitrión

    Tipo de contenedor

    Nativo

    1. Contenedor Linux
    2. Kernel Linux del host

    El contenedor comparte directamente el kernel Linux del host. Es el caso más común en servidores y en la nube.

    Concepto 7 de 7

    Aislamiento y control de recursos en Linux

    Los contenedores utilizan capacidades nativas del kernel Linux para aislar procesos y controlar el consumo de recursos.

    Dos mecanismos trabajan juntos: los namespaces deciden qué ve un proceso y los cgroups deciden cuánto puede consumir. Explora cada uno en su pestaña.

    Aíslan la vista del proceso sobre los recursos. Responden a la pregunta: ¿qué puede ver?

    • Árbol de procesospid

      Ve todos los procesos del host.

      Solo ve sus propios procesos; el principal es el PID 1.

    • Interfaces de rednet

      Usa las interfaces, direcciones IP y puertos del host.

      Tiene su propia interfaz (eth0), su IP y sus puertos.

    • IDs de usuariouser

      root dentro del proceso es root en el host.

      root dentro puede corresponder a un usuario sin privilegios en el host (en Docker requiere userns-remap o modo rootless).

    • Sistemas de archivosmnt

      Ve el sistema de archivos del host.

      Ve su propio árbol de archivos, construido a partir de la imagen.

    Autoevaluación

    Comprueba lo que aprendiste

    Cinco preguntas rápidas para verificar las ideas clave de la lectura. Cada respuesta incluye una explicación.

    1. 1¿Qué relación existe entre una imagen y un contenedor?
    2. 2Desde el sistema anfitrión, ¿cómo se ve un contenedor en ejecución?
    3. 3¿Por qué un contenedor suele arrancar más rápido que una VM?
    4. 4En un host Linux, ¿qué contenedores pueden ejecutarse de forma nativa?
    5. 5¿Qué mecanismo limita cuánta memoria puede consumir un contenedor?

    0/5 respuestas correctas