大早上10点,正在楼下咖啡店和小姐姐探讨什么比咖啡苦就接到了研发老哥的一通夺命连环Call。

人在哪儿?
来了没?
快点的,测试环境的gitlab仓库无法push。上个月写的bug再不更新我就凉了!!!
见我没回消息,又发了一张图片

饿......好吧。你赢了。
告别小姐姐,我拿着咖啡光速上楼。
甘!你钱早就该扣了,写的🌿🌿🌿代码坑死人。不过要是更不上去,这货估计又要分锅给我!
远程登录失败
整个gitlab网站点哪儿哪儿500错误,最麻爪的是我远程无法登录那台物理机。这画面似曾相识啊,可能是这几个月都没咋管这台机器现在又爆磁盘了
问题不大,反正机器在隔壁机房。直接物理登录呗!
果然物理机没问题,df -h
sh
gb@gitlb:/home$ sudo df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 3.2G 1.3M 3.2G 1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv 98G 98G 0G 100% /
磁盘空间已经完全用尽。磁盘空间的满载不仅会导致新的数据无法写入,还会影响到大多数系统操作,这解释了为什么GitLab服务和远程登录都会失败。
丢掉个人素质,享受缺德人生
😂上个月摸鱼太严重,忘记清理日志和无用镜像导致的这个问题。这时应该勇于担当

解决方案
清理Docker镜像
1. 删除悬空镜像
运行以下命令以清除那些未被任何容器引用的、没有标签的悬空镜像:
bash
docker image prune
2. 删除所有未使用的镜像
要进一步释放空间,可以删除所有未被任何容器使用的镜像:
bash
docker image prune -a
GitLab容器和镜像管理
gitlab-ctl registry-garbage-collect
是一个命令行工具,用于在GitLab的容器注册表(Container Registry)中执行垃圾回收(garbage collection)。这个命令的主要目的是帮助你清理不再需要的或悬空的镜像层,释放存储空间。这在管理大量容器镜像的环境中特别有用,因为随着时间的推移,未使用的镜像层可能会占用大量的磁盘空间。
工作原理
GitLab Container Registry 是基于 Docker Distribution 项目构建的,它存储了所有的容器镜像。当你推送或更新镜像时,每个镜像层都会被存储在注册表中。如果某个镜像层不再被任何镜像标签引用,理论上这个镜像层就可以被删除,以节省空间。然而,这些未引用的镜像层并不会自动删除,这就是垃圾回收进程需要手动触发的原因。
使用gitlab-ctl registry-garbage-collect
在执行gitlab-ctl registry-garbage-collect
命令时,GitLab会扫描容器注册表中所有的镜像层,识别出那些不再被任何现有镜像标签引用的层,并将其删除。这个过程可以显著减少GitLab容器注册表所占用的磁盘空间。
执行步骤
-
备份: 在执行垃圾回收之前,强烈建议进行备份,以防万一删除了重要数据。
-
停止写入操作: 为了避免在垃圾回收过程中出现数据不一致的情况,建议在执行过程中暂停新的镜像推送操作。这可以通过停止GitLab实例或通知团队在维护期间避免推送新镜像来实现。
-
执行命令: 在GitLab服务器上执行以下命令开始垃圾回收过程:
bashgitlab-ctl registry-garbage-collect
-
监控日志: 垃圾回收过程可能需要一些时间,具体取决于容器注册表的大小。可以通过监控GitLab的日志来跟踪进度。
注意事项
-
中断风险: 如果垃圾回收过程被中断,可能会导致部分数据处于不一致状态。如果发生这种情况,可能需要重新执行垃圾回收来清理未完成的部分。
-
性能影响: 垃圾回收过程可能会占用大量的CPU和IO资源,对GitLab服务的性能产生影响。因此,建议在系统负载较低的时段执行此操作。
通过定期执行gitlab-ctl registry-garbage-collect
命令,可以有效管理GitLab容器注册表的磁盘空间使用,避免无用的镜像层积累导致的空间浪费。
进一步的磁盘空间管理
如果上述步骤后磁盘空间仍然紧张,考虑以下额外措施:
1. 清理Docker资源
- 容器 : 使用
docker container prune
删除停止的容器。 - 卷 : 使用
docker volume prune
删除未使用的卷。
2. 清理Docker构建缓存
docker builder prune
命令用于清除Docker构建过程中产生的数据,主要包括不再被任何镜像引用的构建缓存。这些构建缓存可能包括临时或中间层镜像,这些镜像在构建过程中用于缓存,以便在后续构建中重用,从而加快构建速度。然而,随着时间的推移,这些缓存可能会占用大量的磁盘空间,尤其是在频繁构建镜像的环境中。
命令格式
bash
docker builder prune [OPTIONS]
主要选项
-a
,--all
: 移除所有未使用的构建缓存,而不仅仅是悬挂的(没有标签或引用的)构建缓存。-f
,--force
: 不提示确认直接删除。--filter
: 提供过滤器以选择删除的缓存。例如,可以根据缓存的创建时间(until=<timestamp>
)来删除旧的构建缓存。
使用场景和好处
-
释放磁盘空间:最直接的好处是释放那些被旧的或不必要的构建缓存占用的磁盘空间。
-
维护和管理:定期清理构建缓存可以帮助维护Docker环境的健康,避免因磁盘空间不足而导致的构建或运行失败。
-
提高构建效率:虽然构建缓存的目的是加快构建速度,但过多的缓存条目可能会降低Docker的性能。定期清理可以确保缓存的有效利用。
示例
-
清理悬挂的构建缓存(即,没有被任何镜像引用的缓存):
bashdocker builder prune
-
强制删除所有未使用的构建缓存,不进行确认提示:
bashdocker builder prune -af
-
删除一周前的所有构建缓存:
bashdocker builder prune -a --force --filter "until=168h"
注意事项
-
在执行清理操作之前,确认不再需要这些构建缓存。虽然
docker builder prune
命令默认不会删除被标记或正在使用的镜像的缓存,但使用-a
选项会删除所有未使用的缓存,可能包括一些最近未使用但将来可能会用到的缓存。 -
对于生产环境,建议在执行此类清理操作前进行适当的评估和备份,以避免意外删除重要数据。
通过定期使用docker builder prune
命令,你可以有效管理Docker环境的磁盘空间,保持系统的整洁和高效运行。
3. 清理GitLab日志和临时文件
直接服务器安装应该会在/var/log/gitlab
目录中
docker安装的一般是自己挂载出来的,比如这种
yaml
volumes:
- './data:/var/opt/gitlab'
- './logs:/var/log/gitlab' # 这一行是你挂载的目录
- './config:/etc/gitlab'
看看有什么能删除的,直接给清了吧
但是我不建议这样做,虽然有日志可能分锅给你。但是没了日志留存锅一定是你的
4. 检查其他大文件
利用du
命令检查系统中其他可能占用大量空间的文件或目录。
流水线优化方案
优化GitLab CI/CD
通过精心设计.gitlab-ci.yml
配置文件,可以有效地减少不必要的镜像构建,节省计算资源和存储空间。以下是一些优化策略:
1. 限制构建触发条件
在.gitlab-ci.yml
中,可以通过only
和except
关键字来控制哪些分支或标签会触发构建过程。例如,你可能只希望在推送到main
或release
分支时才构建和部署镜像,而对于其他分支,则不进行这些操作。
yaml
build:
script: echo "Building the project..."
only:
- main
- /^release-.*$/
这个例子中,构建任务只会在推送到main
分支或任何以release-
开头的分支时触发。
2. 使用缓存来减少构建时间和资源消耗
GitLab CI/CD 允许你定义缓存,以便在多次构建间共享特定文件或目录。这在构建过程中需要下载依赖项或编译代码时特别有用。
yaml
build:
script: make build
cache:
paths:
- node_modules/
在这个例子中,node_modules
目录被缓存起来,这意味着如果package.json
文件没有变化,后续的构建将不需要重新下载所有的npm包,从而节省时间和带宽。
3. 利用工件(Artifacts)
工件是构建过程中产生的文件,可以在同一工作流的后续阶段或作业中使用。通过合理利用工件,可以避免重复的构建步骤。
yaml
build:
script: make build
artifacts:
paths:
- build/
在这个配置中,构建产生的文件会被保存为工件,这样在部署或测试阶段就可以直接使用这些文件,而不需要重新构建。
4. 使用Docker镜像作为缓存
如果你的CI/CD流程包括构建Docker镜像,可以利用Docker的层缓存机制来减少构建时间。这通常意味着在Dockerfile中尽可能地重用已有的层,并在.gitlab-ci.yml
中使用适当的策略来推送和拉取这些镜像。
yaml
build:
stage: build
script:
- docker build --cache-from $CI_REGISTRY_IMAGE:latest -t $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
only:
- main
这个例子中,docker build
命令使用了--cache-from
选项来指定一个已存在的镜像作为缓存源。这样,只有当Dockerfile的相应层发生变化时,Docker才会重新构建这些层。
敲重点啊,一定要@种老师看看
使用外部存储
将GitLab Container Registry配置为使用公有云存储服务,如阿里云的对象存储服务OSS或腾讯云的云对象存储COS,是一个有效的策略来减少对本地磁盘空间的依赖。
使用阿里云OSS
阿里云的对象存储服务(OSS)提供了稳定、安全、高效的云存储解决方案。它支持海量数据存储,并且具有良好的数据持久性和可靠性。通过将GitLab Container Registry配置为使用OSS,你可以轻松地扩展存储能力,同时还能享受到阿里云在国内的优质网络连接。
使用腾讯云COS
腾讯云的云对象存储(COS)同样提供了高效、安全和便捷的云端存储服务。它能够帮助用户解决大规模数据存储的需求,并且提供了灵活的访问控制和丰富的数据处理功能。将GitLab Container Registry配置为使用COS,可以让你的数据存储变得更加灵活和可靠。
使用亚马逊S3
亚马逊简单存储服务(Amazon S3)是一个广泛使用的云存储服务,提供高可靠性、高可用性和安全性。它支持数据自动备份和跨区域复制,确保数据的持久性和稳定性。配置GitLab Container Registry使用Amazon S3,可以让你的容器镜像存储在全球范围内分布式的数据中心,提高访问速度和容错能力。
这个现在好像不能白票了,有全球需要的可以看看。
不过有全球需要的公司,运研老哥也不会看我的文章。嘿嘿嘿
举例阿里云配置GitLab Container Registry
配置GitLab Container Registry以使用阿里云对象存储服务(OSS)作为存储后端的过程类似于配置其他云存储服务,但需要确保使用阿里云特定的参数。以下是一个配置示例,展示了如何在gitlab.rb
文件中为GitLab Container Registry设置阿里云OSS作为存储解决方案。
首先,请确保你已经在阿里云OSS创建了一个Bucket,并且获取了相应的访问密钥(AccessKey ID和AccessKey Secret)以及你的Bucket所在的地域信息。
然后,编辑GitLab的配置文件/etc/gitlab/gitlab.rb
,添加或修改以下配置:
dart
gitlab_rails['registry_enabled'] = true
gitlab_rails['registry_storage'] = {
's3' => {
'accesskey' => '你的阿里云AccessKeyID',
'secretkey' => '你的阿里云AccessKeySecret',
'bucket' => '你的阿里云OSS Bucket名称',
'region' => 'oss-你的Bucket地域', # 例如:'oss-cn-shanghai'
'endpoint' => '你的阿里云OSS Endpoint', # 例如:'https://oss-cn-shanghai.aliyuncs.com'
'path_style' => true
}
}
请将上述配置中的占位符(例如'你的阿里云AccessKeyID'
、'你的阿里云OSS Bucket名称'
等)替换为实际的值。特别注意以下几点:
region
:这里填写的是Bucket所在的地域前缀,如oss-cn-shanghai
等。endpoint
:这是阿里云OSS提供的访问域名,具体值取决于你的Bucket所在的地域,格式通常为https://oss-[region].aliyuncs.com
。
配置完成后,保存gitlab.rb
文件的更改,并执行以下命令来重新配置并重启GitLab,使更改生效:
arduino
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart
# docker安装的可以修配置文件后直接重启
docker restart gitlab
这个过程将GitLab Container Registry的存储后端配置为阿里云OSS,从而利用阿里云的对象存储服务来存储Docker镜像。
使用NFS作为存储
NFS(网络文件系统)是一种分布式文件系统协议,允许你将一部分服务器的文件系统挂载到网络上的另一台计算机上,使得这部分文件系统对于这台计算机就像是本地存储一样。使用NFS作为GitLab Container Registry的存储后端,可以帮助你轻松扩展存储能力,同时减少本地磁盘空间的需求。
步骤概览:
-
设置NFS服务器:首先,你需要在一台服务器上配置NFS服务,并创建一个共享目录,用于存储容器镜像。
-
配置NFS客户端:在运行GitLab的服务器上,你需要安装NFS客户端,并将NFS服务器上的共享目录挂载到本地文件系统上。
-
配置GitLab :最后,你需要修改GitLab的配置文件(
gitlab.rb
),将Container Registry的存储路径指向挂载的NFS共享目录。
示例配置:
-
在NFS服务器上:
创建共享目录并配置NFS导出。这通常涉及到编辑
/etc/exports
文件并添加类似以下的条目:bash/path/to/shared/directory <client-ip>(rw,sync,no_root_squash,no_subtree_check)
然后,重新启动NFS服务以应用更改。
-
在GitLab服务器上:
挂载NFS共享目录:
bashmount -t nfs <nfs-server-ip>:/path/to/shared/directory /mnt/gitlab-registry
配置
gitlab.rb
以使用挂载的目录作为容器注册表的存储路径:rubygitlab_rails['registry_storage_path'] = "/mnt/gitlab-registry"
应用更改后,重新配置GitLab:
bashgitlab-ctl reconfigure # docker安装的可以修配置文件后直接重启 docker restart gitlab
注意事项
-
性能和可用性:使用NFS或其他网络存储解决方案时,需要考虑网络延迟和带宽对性能的影响。此外,确保NFS服务的高可用性也非常重要,以避免成为系统的单点故障。
-
备份和恢复:虽然使用NFS可以减少对本地磁盘空间的依赖,但仍然需要定期备份NFS服务器上的数据,以防数据丢失或损坏。
-
安全性:确保你的NFS服务器配置得当,以防止未授权访问。使用网络安全组、防火墙规则和加密通信(如NFSv4 over Kerberos)来保护数据。
通过将GitLab Container Registry配置为使用NFS或其他国内文件系统,你可以有效地管理存储资源,同时保持良好的性能和可扩展性。
最终成果
sh
gb@gitlb:/home$ sudo df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 3.2G 1.3M 3.2G 1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv 98G 38G 56G 41% /

你看,他还得谢谢咱~👀