Gitlab CICD在使用Docker执行器和缓存时,运行在本地实例上,存储空间不足。

huangapple go评论66阅读模式
英文:

Gitlab CICD on-premise instance running out of storage when using docker runners and cache

问题

我已配置在本地安装上的Docker运行程序来执行CICD作业。

几天后,我们注意到磁盘在以下路径中迅速填满:

/lib/docker/volumes/_data
/var/lib/docker/overlay2

是否有自动清除这些信息的方式?

英文:

On an on-premise installation I've configured docker runners to execute the CICD jobs.

After some days we've noticed that the disk fills up quickly in the following paths:

/lib/docker/volumes/_data
/var/lib/docker/overlay2

Is there an automated way to purge that info?

答案1

得分: 1

占用空间的内容

随着时间的推移,GitLab Runner 将会积累在其运行的所有作业的 image: 键中使用的各种图像版本,以及如果启用了缓存,则还会积累缓存卷。有时,Runner 也可能无法清理容器(这也会阻止它们的图像/卷被清除)。因此,为了防止存储的积累,您需要定期清理容器、图像和卷。

如何进行清理

您可以使用以下命令执行所需的清理操作:

docker container prune -f && docker image prune -af && docker volume prune -f

清理不会影响任何正在使用的容器/图像/卷,因此可以随时运行。您可以使用 crontab 或其他自动化方式定期运行此命令。

您还可以通过添加 清理筛选器 来增强此命令的健壮性,以确定要清理哪些图像。例如,您可以选择仅清理较旧的图像,以使最近创建的图像保留在缓存中以提高性能,例如:

... docker image prune -af --filter "until=240h" ...

另一种解决方案是使用 gitlab-runner-docker-cleanup 实用程序容器,它让您实现类似的功能,但具有一些方便的动态控制选项,以确定何时运行清理(例如,仅在磁盘空间低于阈值时清理)。这是一个意图在 Runner 主机系统上永远后台运行的容器:

docker run -d \
    -e LOW_FREE_SPACE=10G \
    -e EXPECTED_FREE_SPACE=20G \
    -e LOW_FREE_FILES_COUNT=1048576 \
    -e EXPECTED_FREE_FILES_COUNT=2097152 \
    -e DEFAULT_TTL=10m \
    -e USE_DF=1 \
    --restart always \
    -v /var/run/docker.sock:/var/run/docker.sock \
    --name=gitlab-runner-docker-cleanup \
    quay.io/gitlab/gitlab-runner-docker-cleanup

关于本地 Docker 卷缓存

另外一点需要注意的是,当您拥有一组共享 Runner 并分布在不同的 Runner 上时,启用缓存通常不是特别有帮助,部分原因是 Docker 卷缓存(与全局缓存或分布式缓存 分开的)是本地的,当您的构建落在不同的 Runner 上时,这个本地缓存将不会产生任何效果,因为各个 Runner 的本地缓存是相互隔离的。

虽然不是必需的,但如果您拥有多个共享 Runner,我建议在您的 Runner 配置的 [runners.docker] 部分 中将 disable_cache 设置为 true。根据我的经验,这将显著减少存储积累的速度;您的情况可能会有所不同。

英文:

What takes up space

Over time, the runner will accumulate various versions of images used in the image: key of all the jobs it runs as well as cache volumes if caching is enabled. At times, the runner may also fail to cleanup containers (which also prevent their images/volumes from being pruned). So, to prevent this accumulation of storage, you need to periodically cleanup containers, images, and volumes.

How to clean it up

You can perform the required cleanup with the following command:

docker container prune -f && docker image prune -af && docker volume prune -f

The prune won't interfere with any containers/images/volumes that are actively in use, so it should be OK to run at any time. You can set this command to run periodically using crontab or other automated means.

You could also make this command a bit more robust by adding prune filters to what images are pruned. For example, you may wish to only prune older images the most recently created images remain in cache and improve performance -- e.g.,:

... docker image prune -af --filter "until=240h" ...

Another solution is the gitlab-runner-docker-cleanup utility container, which lets you accomplish something similar, but with some convenient dynamic controls for when the cleanup is run (e.g., cleanup only when disk space is below a threshold). This is a container that is intended to keep running in the background forever on the runner host system:

docker run -d \
    -e LOW_FREE_SPACE=10G \
    -e EXPECTED_FREE_SPACE=20G \
    -e LOW_FREE_FILES_COUNT=1048576 \
    -e EXPECTED_FREE_FILES_COUNT=2097152 \
    -e DEFAULT_TTL=10m \
    -e USE_DF=1 \
    --restart always \
    -v /var/run/docker.sock:/var/run/docker.sock \
    --name=gitlab-runner-docker-cleanup \
    quay.io/gitlab/gitlab-runner-docker-cleanup

On local docker volume caching

As a side note, I've also found that enabling caching is not particularly helpful when you have a distributed fleet of shared runners, in part because the docker volume cache (which is separate from the global cache or distributed cache) is local and won't have any effect when your builds land on different runners whose local caches are partitioned from one another.

Although not necessary, if you have multiple shared runners, I would recommend setting the disable_cache setting to true in the [runners.docker] section of your runner configuration. In my experience, this significantly reduces the rate of storage accumulation; YMMV.

huangapple
  • 本文由 发表于 2023年5月24日 23:33:38
  • 转载请务必保留本文链接:https://go.coder-hub.com/76325205.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定