GitLab tiene un proxy de dependencia incorporado que almacena en caché las imágenes de Docker ascendentes. Anteriormente una función premium, Dependency Proxy era de código abierto y estuvo disponible para todas las versiones de GitLab en noviembre de 2020 como parte de GitLab 13.6.
El proxy de dependencia actúa como un caché de extracción para las imágenes de Docker almacenadas en Docker Hub. Configurar el proxy de dependencia puede acelerar sus pipelines y ayudarlo a mantenerse dentro Límites de velocidad de Docker.
Habilitación del proxy de dependencia
La disponibilidad del proxy de dependencia se controla mediante una configuración a nivel de instancia. Habilitar el proxy de dependencia requiere la reconfiguración de GitLab. Esto provocará un breve período de inactividad.
Para habilitar la función, agregue la siguiente línea al archivo de instalación /etc/gitlab/gitlab.rb expediente:
gitlab_rails["dependency_proxy_enabled"] = true
Guarde el archivo y ejecute el siguiente comando en su terminal:
sudo gitlab-ctl reconfigure
Las instrucciones anteriores se refieren a las instalaciones de GitLab Omnibus. Si lo instaló desde la fuente, el proxy de dependencia debe estar habilitado en el interior tu config/gitlab.yml expediente.
Usando el proxy de dependencia
El proxy de dependencia solo funciona con grupos de GitLab. Actualmente no puede usarlo con proyectos personales independientes.
La funcionalidad se utiliza normalmente en scripts de canalización de CI. Al hacer referencia a una imagen dentro de una canalización, prefijo la imagen Nombre de Docker Hub con la extensión CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX variable. Esta variable se resuelve automáticamente en la URL del proxy de dependencia para su grupo activo de GitLab.
image: ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/nodejs:latest
Esta canalización hará su trabajo dentro de un archivo. nodejs:latest envase. La imagen se extraerá a través del proxy de dependencia. No será necesario que las ejecuciones posteriores de la canalización lleguen a Docker Hub a menos que la imagen ascendente realmente cambie.
También puede acceder manualmente al proxy de dependencia, fuera de GitLab CI. Necesitas autenticarte con docker login primero. Deberá utilizar su nombre de usuario y contraseña de GitLab o su nombre de usuario y un token de acceso personal.
docker login gitlab.example.com --username username --password password
Una vez autenticado, puede docker pull usando GitLab Dependency Proxy. Reemplazar example-group en la URL a continuación con el nombre del grupo que desea utilizar. La imagen extraída se almacenará en caché en el proxy de dependencia de ese grupo.
docker pull gitlab.example.com/example-group/dependency_proxy/containers/nodejs:latest
Si también usa GitLab Container Registry (para almacenar imágenes usted build), tenga en cuenta que el proxy de dependencia es completamente independiente y tiene una URL diferente. Teniendo en cuenta que Container Registry normalmente está expuesto en su propio subdominio (p. Ej. registry.example.com), Se accede al proxy de dependencia a través del mismo nombre de host que la interfaz de usuario web de GitLab.
Cómo funciona el proxy de dependencia
El proxy de dependencia parece otro registro de Docker. Cuando desee utilizar el proxy, docker login a eso y luego docker pull como normal.
Si el proxy de dependencia ya ha almacenado en caché la imagen, la devolverá directamente sin usar Docker Hub. De lo contrario, la imagen se extrae de Docker Hub, se almacena en caché en el proxy y se devuelve a la CLI de Docker.
GitLab intentará ponerse en contacto con Docker Hub para cada docker pull, incluso si hay una imagen en caché disponible. Esto se debe a que el proxy debe verificar si la imagen se ha actualizado en Docker Hub.
Este procedimiento no afecta a la limitación de velocidad de Docker. Estibador permisos gratuitos HEAD solicitudes para comparar versiones del manifiesto de imagen. Si Docker indica que la imagen en caché está desactualizada, GitLab extraerá la nueva versión (incurriendo en un límite de velocidad). De lo contrario, se devolverá la imagen en caché, sin agregar al recuento del límite de velocidad de Docker Hub.
Estas características hacen que el proxy de dependencia sea ideal para las canalizaciones de CI. Al acceder al proxy, puede docker pull en cada tramo de tubería, sin alcanzar el límite de velocidad de Docker Hub.
Configurar la configuración del proxy de dependencia
El proxy de dependencia puede utilizar una cantidad significativa de espacio de almacenamiento a lo largo del tiempo. Estás almacenando imágenes en caché de Docker Hub; esas imágenes pueden ser bastante grandes dependiendo de lo que esté utilizando.
GitLab te permite personalizar la ubicación de almacenamiento. Selecciona el dependency_proxy_storage_path establecerse /etc/gitlab/gitlab.rb si desea utilizar una unidad de almacenamiento dedicada.
gitlab_rails["dependency_proxy_storage_path"] = "/mnt/my-storage-drive"
Las instalaciones de origen deben establecer la extensión storage_path propiedad dentro de la dependency_proxy Sección de config/gitlab.yml en vez de.
También puede almacenar sus propias imágenes en caché en un objeto de almacenamiento servicio como Amazon S3. A continuación se muestra un ejemplo de una configuración de Omnibus en /etc/gitlab/gitlab.rb:
gitlab_rails["dependency_proxy_object_store_enabled"] = true # This is the S3 bucket name gitlab_rails["dependency_proxy_object_store_remote_directory"] = "gitlab-dependency-proxy" gitlab_rails["dependency_proxy_object_store_connection"] = { "provider" => "AWS", "region" => "eu-west-1", "aws_access_key_id" => "AWS_ACCESS_KEY_ID", "aws_secret_access_key" => "AWS_SECRET_ACCESS_KEY" }
Para mejorar el rendimiento, GitLab almacenará en caché las imágenes localmente y luego las cargará en S3 en segundo plano. Si prefiere cargar directamente a S3, configure el archivo dependency_proxy_object_store_direct_upload puesta en true.
Necesita reconfigurar GitLab (sudo gitlab-ctl reconfigure) después de cambiar la configuración de almacenamiento. El proxy de dependencia luego almacenará en caché las imágenes almacenadas en caché usando la nueva configuración.
Libera espacio de almacenamiento
GitLab nunca borra datos de proxy de dependencia almacenados en caché. Puede ver el contenido de un caché de grupo seleccionando Paquetes y registros> Proxy de dependencia en la barra lateral. Esta pantalla le permite habilitar o deshabilitar el proxy de dependencia para el grupo y ver el tamaño total de los datos almacenados. Sin embargo, la interfaz de usuario no se puede usar para borrar blobs antiguos.
Si necesita liberar espacio de almacenamiento, debe utilizar la API de GitLab. Hay un único punto final que le permite borrar todos los datos del proxy de dependencia almacenados para un grupo específico.
Cree un token de acceso personal haciendo clic en su perfil en la parte superior derecha, haciendo clic en "Token de acceso" en la barra lateral izquierda y agregando un nuevo token de acceso con el api objetivo.
Entonces, usa curl para borrar la caché del proxy de dependencia de un grupo:
curl --request DELETE --header "PRIVATE-TOKEN: <Access-Token>" https://gitlab.example.com/api/v4/groups/<Group-Id>/dependency_proxy/cache
Para encontrar su ID de grupo, visite la página de inicio del grupo que desea limpiar. La identificación del grupo se mostrará junto a su nombre.
Conclusión
Habilitar el proxy de dependencia es un paso simple que mejora la resistencia de la canalización. Si Docker Hub falla, el proxy seguirá proporcionando a la canalización versiones en caché de la imagen.
El proxy de dependencia también lo ayuda a mantenerse dentro de los límites de velocidad de Docker Hub. Solo necesitará extraer las imágenes de Docker Hub cuando realmente cambien. Para un equipo activo que ejecuta muchas canalizaciones todos los días, esto puede ayudarlo a evitar tener que actualizar a un plan premium de Docker Hub.
Descubre más contenido