Uno de los problemas con la programación de computadoras es que los mismos nombres se usan constantemente para diferentes propósitos. Por ejemplo, el término espacio de nombres se utiliza de muchas maneras diferentes. A menudo me confundo cuando la gente habla de espacios de nombres dentro de Kubernetes. Por ejemplo, algunas personas escuchan el término y piensan en clústeres virtuales, pero cuando lo escucho, pienso en los espacios de nombres de Linux que se usan con pods y contenedores. Del mismo modo, imagen puede hacer referencia a una imagen de máquina virtual, una imagen de contenedor o una imagen OCI almacenada en un registro de contenedor.
[ También te pueden interesar: 7 funciones divertidas de transporte de imágenes/contenedores de Linux ]
Pero en el mundo de los contenedores, no hay un término más usado que contenedor .
Recientemente, un usuario creó un problema de Podman, expresando su frustración por esta terminología:
Terminología poco clara:imagen frente a contenedor
Tengo entendido que la imagen es una plantilla de solo lectura, mientras que el contenedor es algo de lectura y escritura. Siempre. Por lo tanto, si algo es un contenedor, tanto podman como buildah lo consideran como contenedor. Cuando algo es una imagen, tanto podman como buildah lo consideran como una imagen.
Llamo a buildah desde --name abc scratch. Las imágenes de buildah y las imágenes de podman tienen el mismo resultado y no consideran que lo nuevo sea una imagen.
podman containers ls no muestra nada, por lo que lo nuevo es desde la perspectiva de podman, no un contenedor.
los contenedores buildah, sin embargo, devuelven lo nuevo, de modo que lo nuevo es un contenedor (con CONTAINER NAME=abc, IMAGE NAME=scratch, BUILDER=*=yes IMAGE ID ="").
Entonces, lo nuevo es un contenedor desde la perspectiva de buildah, pero no es un contenedor desde la perspectiva de podman. Esto es completamente confuso.
Explique la diferencia entre contenedor en términos de buildah y contenedores en términos de podman.
Pienso en contenedores como ejecutar procesos dentro de un entorno o algo que está preparado para ser ejecutado. Por el contrario, las imágenes son contenedores comprometidos, que están preparados para ser compartidos con otros para crear nuevos contenedores.
Los motores de contenedores con los que trabajamos (Podman, Buildah, CRI-O y Skopeo) comparten el mismo concepto de imágenes.
Las imágenes se definen en contenedores/imagen y se almacenan en diferentes almacenamientos o transportes, como registros de contenedores, archivos Docker, archivos OCI, docker-daemon y contenedores/almacenamiento. Escribí sobre estos tipos de almacenamiento o transporte en un artículo anterior.
La mayoría de la gente piensa en las imágenes como colocadas en contenedores/almacenamiento o registros de contenedores. Para el resto de esta descripción, nos concentraremos en contenedores/almacenamiento.
Por cierto, Skopeo no es realmente un motor de contenedores ya que no tiene concepto de contenedores. En su lugar, Skopeo solo trata con imágenes de contenedores y las mueve entre diferentes tipos de almacenamiento de contenedores.
Contenedor/contenedores de almacenamiento
La biblioteca de contenedor/almacenamiento también proporciona su propio concepto de contenedor de almacenamiento. Básicamente, los contenedores de almacenamiento son contenido de almacenamiento intermedio que aún no se ha comprometido. Piense en esto como archivos en el disco y algo de JSON que describe el contenido.
Podman, Buildah y CRI-O utilizan contenedores de almacenamiento . Los tres motores de contenedores también tienen datos adicionales específicos para ellos mismos.
Contenedores Buildah
Los contenedores de Buildah incluyen contenido adicional referente a los diferentes comandos que componen el Containerfile o Dockerfile.
Por ejemplo, Workingdir, Env variables y otros datos se utilizan para crear una imagen de contenedor.
Contenedores Podman
Podman tiene su propio almacén de datos relacionados con un contenedor de Podman. Hay muchos más datos almacenados en la base de datos de Podman que en la base de datos de Buildah. Podría pensar en la base de datos de Buildah como un subconjunto de la base de datos de Podman.
Contenedores CRI-O
CRI-O también tiene su propio almacén de datos para describir sus contenedores.
Las tres herramientas han evolucionado de manera diferente y tienen diferentes ideas y requisitos para sus propios contenedores.
Por ejemplo, los contenedores CRI-O evolucionaron con la dependencia de un solo demonio que los controlaba. El énfasis está en el rendimiento y la necesidad de compartir cientos/miles de respuestas al CRI de Kubernetes por segundo. Dado que CRI-O sabe que es el único que se ocupa del almacén de datos, puede aprovechar el almacenamiento de la información en la memoria. CRI-O no necesita preocuparse por otros procesos que ingresan y cambian los contenedores sin su conocimiento.
Podman, por otro lado, necesita tratar con múltiples usuarios de sus contenedores al mismo tiempo. Necesita confiar más en el bloqueo del sistema de archivos y garantizar que cientos de ejecutables de Podman puedan compartir de manera confiable el mismo almacén de datos. Hemos hablado de fusionar eventualmente el almacén de datos de Podman en CRI-O para que CRI-O y Podman puedan trabajar mejor juntos, pero con el tiempo, sentimos que el riesgo/beneficio es difícil de justificar la fusión.
Buildah también se desarrolló como una herramienta independiente. Los mantenedores se han negado a asumir el peso y la complejidad innecesarios del almacén de datos de Podman por poco o ningún beneficio adicional. Los contenedores Buildah tienen un propósito:crear una imagen de contenedor, mientras que la mayoría de los contenedores Podman tienen más que ver con la ejecución de aplicaciones y servicios. Los contenedores Buildah no contienen toda la información que podría requerir Podman.
¿Cómo manejaría Podman un contenedor creado con buildah from scratch? comando?
Todavía necesitaríamos tratar estos contenedores parcialmente creados de manera diferente. Por lo tanto, hacer que Podman los vea como equivalentes o incluso enumerados de forma predeterminada en podman ps comando llevaría a los usuarios a la confusión.
Compatibilidad
Podman realmente puede trabajar con estos contenedores.
Las últimas versiones de Podman ahora pueden enumerar los contenedores de almacenamiento disponibles en el sistema:
$ podman ps -a --external | grep buildah
578edf9430ee scratch buildah 13 days ago storage working-container Puede montar y desmontar estos contenedores:
# podman mount working-container
/home/dwalsh/.local/share/containers/storage/overlay/a4f596beaabdc78efc7694a67d690097e327aa12bbc59165d011e62b646e93c0/merged
# podman unmount working-container
working-container También puede eliminar estos contenedores:
$ podman rm working-container
working-container
También puede crear estos contenedores usando podman build . Por supuesto, estos contenedores solo se crean temporalmente durante la compilación. Dado que estos contenedores Buildah no tienen los mismos datos que un contenedor Podman, Podman no puede iniciarlos ni detenerlos, y podman ps no los muestra cuando se están ejecutando.
Podman también tiene una capacidad similar para trabajar con contenedores CRI-O.
[ Aprenda los aspectos básicos del uso de Kubernetes en esta hoja de trucos gratuita. ]
Resumir
Cuando se trata del término contenedor , el contexto suele ser crítico. Comprender la diferencia entre los usos es esencial. Cuando se trata de nuestras herramientas de contenedores, compartimos la mayor parte del contenido, el almacenamiento y las bibliotecas subyacentes. Pero hay razones legítimas por las que cada herramienta tiene conceptos o definiciones ligeramente diferentes o sus contenedores.