En esta publicación, le muestro cómo usar Quay.io para alojar imágenes de contenedores y cómo evitar sobrecargar su registro de contenedores al limitar las solicitudes innecesarias de imágenes. Uso Buildah, Skopeo y Quay.io, pero los consejos para limitar las extracciones de imágenes funcionarán con cualquier registro de contenedores que pueda usar.
A fines de noviembre de 2020, Docker Hub comenzó a acelerar o limitar la cantidad de imágenes de contenedores que podía extraer de forma anónima o como Free Docker Hub usuario. Si eres anónimo usuario, solo puede extraer 100 imágenes de contenedor en cualquier período de 6 horas. Si es usuario gratuito de Docker Hub, puede extraer 200 imágenes de contenedores en cualquier período de 6 horas.
Cuando realizamos nuestras pruebas funcionales de las herramientas de contenedor en las que trabajamos, como Buildah y Podman, este límite generalmente no es un problema. Por ejemplo, cuando está creando una imagen de contenedor usando un Containerfile, y luego prueba el contenedor resultante para ver cómo se comporta después de ejecutar comandos particulares en él, generalmente extrae la imagen del contenedor principal especificada en FROM instrucción en el Containerfile una vez. Si luego reconstruye el contenedor desde cero, normalmente reutiliza la imagen del contenedor ya desplegada y, por lo tanto, no llega al mostrador. En este escenario, la limitación no causa ningún dolor, pero siempre está en el fondo de mi mente.
Reducción inicial de las interacciones de Docker Hub
Sin embargo, encontramos un lugar donde nos topamos con la limitación en Docker Hub. Ed, mi colega y uno de los líderes de QE del motor de contenedores, creó una solución muy buena para esto. Primero, un poco de historia. Hace varios meses, Ed redujo la cantidad de veces que obteníamos las imágenes de contenedor que usan las pruebas de integración continua (CI) de Buildah al reutilizar el caché que Podman ya había creado. Antes de esto, Buildah CI abusó de los pobres alpine imagen de contenedor que vive en Docker Hub en docker.io/library sin fin, junto con el fedora , busybox , y algunas otras imágenes variadas de contenedores allí, extrayéndolas multitud de veces. Este esquema de captación previa que desarrolló Ed no solo aceleró nuestras pruebas, sino que también nos permitió reducir el ancho de banda que usábamos en Docker Hub.
A pesar de estos cambios, Buildah CI comenzó a fallar varias veces al día en noviembre con este error:Ha alcanzado su límite de tasa de extracción . Alcanzar el límite de frecuencia se debió a la cantidad de veces que se ejecutaron nuestras pruebas de CI cada día. A pesar de que la captación previa había reducido la cantidad de veces que Buildah CI necesitaba extraer las imágenes, el CI aún se encontraba con la limitación de Docker Hub.
[ También le puede interesar leer: Cómo implementar un registro de imagen de contenedor de Linux personal/privado simple para uso interno]
Resolviendo el estrangulamiento
La solución que Ed entregó hace uso de la flexibilidad de Buildah y las herramientas de contenedor en el repositorio de Contenedores en GitHub. Primero, Ed creó una cuenta gratuita en quay.io, copió imágenes allí y las hizo públicas. Ed eligió quay.io porque ahí es donde almacenamos muchas de nuestras imágenes de contenedores, y es conveniente para nosotros. Aun así, podría haber sido un repositorio de imágenes de contenedores locales o el repositorio de alguna otra empresa.
Como beneficio adicional, quay.io no está limitado como Docker Hub.
Usando Skopeo para copiar la imagen inicial
Digamos que su proyecto requiere alpine y centos:8 imágenes Comenzaría creando una cuenta gratuita en quay.io, con el nombre myquayaccountname . En un host con Skopeo instalado, ejecutaría:
skopeo login -u myquayaccountname quay.io
skopeo copy --all docker://docker.io/library/alpine:latest docker://quay.io/myquayaccountname/alpine:latest
Luego repita, reemplazando alpine:latest con centos:8 , y así sucesivamente para todas las imágenes necesarias.
Configurar muelle.io
Las imágenes ahora están en quay.io, pero son privadas por defecto. Para hacerlos públicos, vuelva a iniciar sesión en la interfaz de usuario web de quay.io y haga clic en el nombre de cada imagen. Eso lo llevará a una nueva página que muestra los detalles de la imagen. Haz clic en el ícono de ajustes en la parte inferior de la barra de navegación izquierda, busca Hacer público y presiónelo. Deberá confirmar OK y luego repita para todas las imágenes que muestren un icono de candado rosa.
En nuestro caso, lo primero que hizo Ed fue extraer las imágenes del contenedor que usamos de Docker Hub y colocarlas en el repositorio de imágenes del contenedor libpod en quay.io que él había creado.
Configurarregistries.conf para duplicar
Resolvimos el problema de la aceleración moviendo esas imágenes. Sin embargo, ahora teníamos el problema de cambiar los cientos, si no miles, de las referencias de las pruebas a esas imágenes para que el CI extrajera de quay.io/libpod en lugar de docker.io/library . Este cambio necesario fue un escaparate perfecto de la flexibilidad que ofrecen las herramientas para contenedores. Ed abordó esto con un cambio relativamente pequeño en la configuración, en lugar de cambiar globalmente todas las pruebas.
Esto es lo que Ed ideó. Cuando Buildah busca una imagen de contenedor, no está codificada para simplemente extraerla de docker.io. En su lugar, lee /etc/containers/registries.conf y determina de qué repositorio de imágenes de contenedor debe extraer Buildah.
Ed simplemente cambió ese archivo de modo que quay.io/libpod es contactado cada vez que las pruebas buscaban docker.io/library . Usando nuestro ejemplo anterior, agregaría las siguientes líneas a /etc/containers/registries.conf en todos los sistemas en los que desee utilizar su caché:
toml
[[registry]]
prefix=" docker.io/library"
location=" quay.io/myquayaccountname"
Todos los podman pull alpine subsiguientes los comandos se obtendrán de su espejo. Puede ver el cambio que Ed hizo para Podman aquí en esta Solicitud de extracción.
Para resaltar aún más las capacidades de duplicación en el proyecto de contenedores/imágenes, que utiliza Buildah, puede configurar un espejo para las imágenes de contenedores que le permite obtener el nombre anterior de un registro diferente. La duplicación se agregó originalmente para admitir entornos desconectados. Los entornos sin conexión a Internet que ejecutan software como OpenShift a menudo no pueden extraer imágenes de registros no locales, por lo que permitimos a los usuarios duplicar las imágenes en registros internos sin necesidad de cambiar el software.
Aquí hay un fragmento con más información de containers-registries.conf archivo, que forma parte del container/image proyecto:
$ man containers-registries.conf
Remapping and mirroring registries
The user-specified image reference is, primarily, a "logical" image name, always
used for naming the image. By default, the image reference also directly specifies
the registry and repository to use, but the following options can be used to redi‐
rect the underlying accesses to different registry servers or locations (e.g., to
support configurations with no access to the internet without having to change
Dockerfiles, or to add redundancy). Advertencias :este procedimiento hace una copia única de las imágenes del contenedor. Su imagen almacenada en caché no recogerá mágicamente las correcciones de seguridad enviadas a docker.io. (Tampoco detectará vandalismo aleatorio, como archivos binarios eliminados u otros cambios importantes; no me hagas empezar).
Más trabajo
Dada la advertencia, el mantenimiento de la imagen depende de usted ahora, y podría considerar agregar los comandos de Skopeo para copiar la imagen al comienzo de su procedimiento de prueba. Otra posible solución es habilitar un espejo público como Google Cloud Registry (GCR) o posiblemente refinar aún más el registries.conf archivo para configurar varios espejos. Mejor aún, es probable que encaje perfectamente con el comando skopeo-sync, ya que tiene una CLI agradable y se puede usar con un archivo YAML que ofrece una amplia gama de opciones de configuración.
[ ¿Empezando con los contenedores? Consulta este curso gratuito. Implementación de aplicaciones en contenedores:una descripción técnica general. ]
Resumir
Hay varias formas de resolver la limitación que Docker Hub implementó, pero el método que usó Ed fue rápido, sencillo y logró que nuestro CI volviera a estar en línea rápidamente. Ahora que tenemos algo de espacio para respirar, podemos trabajar en una solución más completa.
Con este cambio en su lugar, las pruebas de Buildah ya no se ejecutan por encima del límite y golpean la limitación desde Docker Hub, por lo que el problema de limitación está resuelto.