Si observamos de cerca los productos LEGO®, podemos ver que todos están hechos de los mismos bloques de construcción. Sin embargo, la composición de estos bloques es el diferenciador clave para si estamos construyendo un castillo o una nave espacial. Es más o menos lo mismo para Podman y sus proyectos hermanos Buildah, Skopeo y CRI-O. Sin embargo, en lugar de plástico reciclado, los componentes básicos de nuestras herramientas de contenedores están hechos de código fuente abierto. Compartir estos componentes básicos nos permite proporcionar herramientas de contenedores sólidas y de nivel empresarial. Las características se envían más rápido, los errores se corrigen más rápido y el código se prueba en batalla. Y, bueno, en lugar de alegrar las salas de juegos, las herramientas de contenedor alegran los centros de datos y las estaciones de trabajo.
El bloque de construcción más básico para nuestras herramientas de contenedores es la biblioteca de contenedores/almacenamiento, que almacena y administra contenedores e imágenes de contenedores localmente. Subiendo un nivel más, encontramos la biblioteca de contenedores/imágenes. Como sugiere el nombre, esta biblioteca trata con imágenes de contenedores y es increíblemente poderosa. Nos permite extraer y empujar imágenes, manipular imágenes (por ejemplo, cambiar la compresión de capas), inspeccionar imágenes junto con su configuración y capas, y copiar imágenes entre los llamados transportes de imágenes. Un transporte puede referirse a un almacenamiento de contenedor local, un registro de contenedor, un archivo tar y mucho más. Dan Walsh escribió una excelente publicación de blog sobre los diversos transportes que recomiendo leer.
La biblioteca de imágenes también admite varios archivos de configuración donde, sin duda, el registries.conf es el más importante para la gran mayoría de los usuarios. Quiero dedicar esta publicación de blog a registries.conf archivo de configuración, explicar sus diversas opciones y botones, y cómo podemos usarlos en producción.
Administrar registros de contenedores con registries.conf
El registries.conf la configuración está en juego cada vez que empujamos o tiramos de una imagen. O, de forma más general, cada vez que contactamos con un registro de contenedores. Esa es una regla general fácil. La ubicación en todo el sistema es /etc/containers/registries.conf , pero si desea cambiar eso para un solo usuario, puede crear un nuevo archivo en $HOME/.config/containers/registries.conf .
Así que vamos a sumergirnos en eso. En las siguientes secciones, veremos algunos ejemplos que explican las diversas opciones de configuración en registries.conf . Los ejemplos son escenarios del mundo real y pueden ser una fuente de inspiración para abordar su caso de uso individual.
Usando nombres cortos
Los humanos somos vagos, y yo no soy una excepción a eso. Es mucho más conveniente hacer un podman pull ubi8 en lugar de podman pull registry.access.redhat.com/ubi8:latest . Sigo olvidando qué imagen vive en qué registro, y hay muchas imágenes y muchos registros por ahí. Hay Docker Hub y Quay.io, además de registros para Amazon, Microsoft, Google, Red Hat y muchas otras distribuciones de Linux.
Docker abordó nuestra pereza resolviendo siempre el Docker Hub. Un docker pull alpine se resolverá en docker.io/library/alpine:latest y docker pull repo/image:tag se resolverá en docker.io/repo/image:tag (Observe el repositorio especificado). Podman y sus proyectos hermanos no querían obligar a los usuarios a usar un solo registro, por lo que los nombres cortos pueden resolverse en más de docker.io y, como es de esperar, podemos configurar eso en registries.conf de la siguiente manera:
unqualified-search-registries = ['registry.fedoraproject.org', 'registry.access.redhat.com', 'registry.centos.org', 'docker.io']
El fragmento anterior se toma directamente de registries.conf en Fedora 33. Es una lista de registros que se contactan en el orden especificado al extraer una imagen de nombre corto. Si la imagen no se puede encontrar en el primer registro, Podman intentará extraerla del segundo registro y así sucesivamente. Buildah y CRI-O siguen la misma lógica, pero tenga en cuenta que Skopeo siempre se normaliza a docker.io.
[ También te puede interesar: ¿Cuál es la próxima carga de trabajo de Linux que planeas incluir en contenedores? ]
Buscando imágenes
Al igual que en la sección anterior sobre extracción, las imágenes se buscan comúnmente por nombre. Al hacer una podman search , por lo general no sé o simplemente olvidé en qué registro vive la imagen dada. Al usar Docker, solo puede buscar en Docker Hub. Podman da más libertad a los usuarios y permite buscar imágenes en cualquier registro. Y como era de esperar, registries.conf tiene solución.
Similar a la extracción, los unqualified-search-registries también se usan cuando se usa un nombre corto con podman search . Un podman search foo buscará imágenes llamadas foo en todos los registros de búsqueda no calificada.
Las grandes corporaciones suelen tener registros de contenedores en las instalaciones. Integrar tales registros en su flujo de trabajo es tan simple como agregarlos a la lista de registros de búsqueda no calificada.
Alias de nombre corto
Las versiones más recientes de Podman, Buildah y CRI-O se entregan con una nueva forma de resolver nombres cortos, principalmente mediante el uso de alias. Los alias son una tabla TOML simple [aliases] en la forma "name" = "value" , similar a cómo funcionan los alias de Bash. Mantenemos una lista central de alias junto con la comunidad aguas arriba en github.com/containers/shortnames . Si posee una imagen y desea tener un alias, no dude en abrir una solicitud de incorporación de cambios o comunicarse con nosotros.
Algunas distribuciones, como RHEL8, planean enviar sus propias listas de nombres cortos para ayudar a los usuarios y evitar que extraigan imágenes accidentalmente del registro incorrecto.
Explicar en detalle cómo funcionan los alias de nombres cortos ampliaría significativamente esta publicación de blog, por lo que si está interesado, consulte una publicación de blog anterior sobre alias de nombres cortos.
Configuración de un registro de contenedor local
Ejecutar un registro de contenedor local es bastante común. Tengo uno funcionando todo el tiempo, por lo que puedo almacenar imágenes en caché y desarrollar y probar nuevas funciones, como actualizaciones automáticas en Podman. El ancho de banda en mi oficina en casa es limitado, por lo que agradezco los empujones y tirones rápidos. Dado que todo se ejecuta localmente, no necesito preocuparme por configurar TLS para el registro. Eso implica conectarse al registro a través de HTTP en lugar de HTTPS. Podman le permite hacer eso especificando --tls-verify=false en la línea de comandos, lo que omitirá la verificación de TLS y permitirá conexiones no seguras.
Un enfoque alternativo para omitir la verificación de TLS a través de la línea de comando es usar registries.conf . Esto puede ser más conveniente, especialmente para scripts automatizados en los que no queremos agregar indicadores de línea de comandos manualmente. Echemos un vistazo al fragmento de configuración a continuación.
[[registry]]
location="localhost:5000"
insecure=true
El formato de los registros.conf es TOML. Las llaves dobles de [[registry]] indicar que podemos especificar una lista (o tabla) de [registry] objetos. En este ejemplo, solo hay un registro donde la ubicación (es decir, su dirección) se establece en localhost:5000 . Ahí es donde comúnmente se ejecuta un registro local. Siempre que los containers/image biblioteca se conecta a un registro de contenedor con esa ubicación, buscará su configuración y actuará en consecuencia. En este caso, el registro está configurado para ser inseguro y se omitirá la verificación de TLS. Podman y las otras herramientas de contenedores ahora pueden comunicarse con el registro local sin que se rechacen las conexiones.
Bloqueo de un registro, espacio de nombres o imagen
En caso de que desee evitar que los usuarios o las herramientas se extraigan de un registro específico, puede hacer lo siguiente.
[[registry]]
location="registry.example.org"
blocked=true
El blocked=true impide las conexiones a este registro, o al menos bloquea la extracción de datos de él.
Sin embargo, es sorprendentemente común entre los usuarios bloquear solo espacios de nombres específicos o imágenes individuales, pero no todo el registro. Supongamos que queremos evitar que los usuarios extraigan imágenes del espacio de nombres registry.example.org/namespace . El registries.conf ahora se verá así:
[[registry]]]
location="registry.example.org"
prefix="registry.example.org/example"
blocked=true
Acabo de introducir una nueva perilla de configuración:prefix . Un prefijo indica solo seleccionar la configuración especificada cuando intentamos obtener una imagen que coincida con el prefijo específico. Por ejemplo, si ejecutaríamos un podman pull registry.example.org/example/image:latest , el prefijo especificado coincidiría y Podman no podría extraer la imagen. Si desea bloquear una imagen específica, puede configurarla usando lo siguiente:
prefix="registry.example.org/namespace/image"
El uso de un prefijo es una herramienta muy poderosa para cumplir con todo tipo de casos de uso. Se puede combinar con todas las perillas de un [registry] . Tenga en cuenta que el uso de un prefijo es opcional. Si no se especifica ninguno, el prefijo se establecerá de forma predeterminada en la ubicación (obligatoria).
Duplicación de registros
Supongamos que estamos ejecutando nuestra carga de trabajo en un entorno con espacio de aire. Todos nuestros servidores están desconectados de internet. Hay muchas razones para eso. Es posible que estemos corriendo al límite o en un entorno altamente sensible a la seguridad que nos prohíba conectarnos a Internet. En este caso, no podemos conectarnos al registro original pero necesitamos ejecutar un registro que refleje los contenidos de la red local.
Un espejo de registro es un registro al que se contactará antes de intentar extraer del original. Es un caso de uso común y una de las solicitudes de funciones más antiguas en el ecosistema de contenedores.
[[registry]]
location="registry.access.redhat.com"
[[registry.mirror]]
location="internal.registry.mirror"
Con esta configuración, al extraer la imagen base universal a través de podman pull ubi8 , la imagen se extraería del espejo en lugar del registro de contenedores de Red Hat.
Tenga en cuenta que podemos especificar varios espejos que se contactarán en el orden especificado. Echemos un vistazo rápido a lo que eso significa:
[[registry]]
location="registry.example.com"
[[registry.mirror]]
location="mirror-1.com"
[[registry.mirror]]
location="mirror-2.com"
[[registry.mirror]]
location="mirror-3.com"
Supongamos que estamos intentando extraer la imagen registry.example.com/myimage:latest . Los espejos se contactan en el orden especificado (es decir, de arriba hacia abajo), lo que significa que Podman primero intentará extraer la imagen de mirror-1.com . Si la imagen no está presente o la extracción falla por otros motivos, Podman se pondrá en contacto con mirror-2.com Etcétera. Si todos los espejos fallan, Podman se comunicará con el principal registry.example.com .
Tenga en cuenta que los espejos también admiten el insecure mando. Si desea omitir la verificación de TLS para un espejo específico, simplemente agregue insecure=true .
Reasignación de referencias
Como exploramos anteriormente, un prefix se utiliza para seleccionar un [registry] específico en el registries.conf . Si bien los prefijos son un medio poderoso para bloquear espacios de nombres específicos o ciertas imágenes para que no se extraigan, también se pueden usar para reasignar imágenes completas. De manera similar a los espejos, podemos usar un prefijo para extraer de un registro diferente y un espacio de nombres diferente.
Para ilustrar lo que quiero decir con reasignación , consideremos que corremos en un entorno con espacios de aire. No podemos acceder a los registros de contenedores ya que estamos desconectados de Internet. Nuestra carga de trabajo utiliza imágenes de Quay.io, Docker Hub y el registro de contenedores de Red Hat. Si bien podríamos tener un espejo local de red por registro, también podríamos usar uno con la siguiente configuración.
[[registry]]
prefix="quay.io"
location="internal.registry.mirror/quay"
[[registry]]
prefix="docker.io"
location="internal.registry.mirror/docker"
[[registry]]
prefix="registry.access.redhat.com"
location="internal.registry.mirror/redhat"
Un podman pull quay.io/buildah/stable:latest ahora, en su lugar, extraerá internal.registry.mirror/quay/buildah/stable:latest . Sin embargo, la imagen extraída seguirá siendo quay.io/buildah/stable:latest ya que la reasignación y la duplicación se realizan de forma transparente para Podman y las otras herramientas de contenedor.
Como podemos ver en el fragmento anterior, internal.registry.mirror es nuestro espejo local de red que usamos para extraer imágenes en nombre de Quay.io, Docker Hub y el registro de contenedores de Red Hat. Las imágenes de cada registro residen en espacios de nombres separados en el registro (es decir, "quay", "docker", "redhat"):truco simple pero poderoso para reasignar imágenes al extraer. Puede preguntarse cómo podemos prepoblar el espejo interno con las imágenes de los tres registros. No recomiendo hacerlo manualmente, sino usar skopeo sync en cambio. Con skopeo sync , un administrador de sistemas puede cargar fácilmente todas las imágenes en una unidad USB, llevarlas a un clúster con espacio de aire y precargar el espejo.
Hay innumerables casos de uso en los que dicha reasignación puede ayudar. Por ejemplo, cuando se usa otro registro durante las pruebas, puede resultar útil extraer de forma transparente de otro registro (de prueba o de ensayo) que no sea el de producción. No se necesitan cambios de código.
Tom Sweeney y Ed Santiago usaron la reasignación para desarrollar una solución creativa para abordar los límites de velocidad de Docker Hub. A fines de noviembre de 2020, Docker Hub comenzó a limitar la cantidad de extracciones por usuario en un período de tiempo determinado. Al principio, estábamos preocupados porque gran parte de nuestros sistemas de prueba y la integración continua usaban imágenes de Docker Hub. Pero con un simple cambio en registries.conf en nuestros sistemas, Tom y Ed encontraron una gran solución. Eso nos ahorró la tarea manual y tediosa de cambiar todas las imágenes que hacen referencia a docker.io en nuestras pruebas.
Gestión de configuración avanzada a través de archivos de configuración desplegables
Administrar configuraciones es un desafío. Nuestros sistemas se actualizan todo el tiempo, y con las actualizaciones pueden surgir cambios de configuración. Es posible que queramos agregar nuevos registros, configurar nuevos espejos, corregir configuraciones anteriores o ampliar la configuración predeterminada de Fedora. Hay muchas motivaciones, y para ciertas registries.conf lo admite a través de los llamados archivos de configuración directos.
Al cargar la configuración, los containers/image primero cargará el archivo de configuración principal en /etc/containers/registries.conf y luego todos los archivos en /etc/containers/registries.conf.d directorio en orden alfanumérico.
Usando tal drop-in registries.conf archivos es sencillo. Simplemente coloque un .conf en el directorio y Podman obtendrá la configuración actualizada. Tenga en cuenta que las tablas en la configuración se fusionan mientras que las perillas simples se anulan. Esto significa, en la práctica, que el [[registry]] La tabla se puede ampliar fácilmente con nuevos registros. Si ya existe un registro con el mismo prefijo, se anulará la configuración del registro. Lo mismo se aplica a los [aliases] mesa. Las perillas de configuración simple, como los registros de búsqueda no calificados, siempre se anulan.
[ ¿Empezando con los contenedores? Consulta este curso gratuito. Implementación de aplicaciones en contenedores:una descripción técnica general. ]
Conclusión
El registries.conf es un componente central de nuestras herramientas de contenedores. Permite configurar todo tipo de propiedades al hablar con un registro de contenedores. Si está interesado en estudiar la configuración con mayor detalle, puede hacer un man containers-registries.conf para leer la página del manual en su máquina Linux o visite la documentación original.