【Gitlab】Mac M1芯片利用Docker Desktop快速搭建GitLab开发环境

1. 为什么选择在Mac M1上本地搭建GitLab？

如果你是一名在Mac M1/M2/M3芯片上开发的程序员，尤其是做全栈或者后端开发，我猜你肯定遇到过这样的场景：公司项目在GitLab上，你想在本地复现一个bug，或者想测试一下CI/CD流水线，但每次都要推送到远程仓库、等流水线跑完，这个过程太慢了，严重打断了你的开发节奏。又或者，你手头有一些个人项目，不想公开到GitHub或Gitee，但又需要一个带完整项目管理、代码审查、CI/CD功能的私有仓库。这时候，在本地搭建一个GitLab服务就成了一个非常“香”的选择。

你可能会问，为什么不直接用Docker Hub上现成的GitLab镜像跑一个容器就完事了？问题就出在芯片架构上。Mac M1系列用的是ARM架构的Apple Silicon芯片，而Docker Hub上官方提供的gitlab/gitlab-ce镜像是基于x86_64架构的。如果你直接docker pull gitlab/gitlab-ce，然后在M1 Mac上运行，Docker Desktop会通过Rosetta 2进行转译，虽然能跑起来，但性能损耗非常大，启动慢、运行卡，内存占用也高得吓人，完全失去了本地部署“快速轻便”的意义。

所以，我们的核心目标就变成了：为ARM64（也就是aarch64）架构的Mac M1，找到一个原生兼容的GitLab镜像，并用最省事的方式把它跑起来。 经过我自己的实测和对比，目前最稳定、最省心的方案就是通过Docker Desktop来操作。它提供了图形化界面，配置端口、挂载目录一目了然，特别适合不想在命令行里折腾的开发者。接下来，我就手把手带你走一遍这个流程，从零开始，在喝杯咖啡的时间里，把你的本地GitLab服务搭建起来。

2. 搭建前的准备工作：安装与检查

工欲善其事，必先利其器。在开始拉取镜像和配置容器之前，我们需要确保手头的工具是齐全且版本合适的。这一步做扎实了，后面能避免至少80%的坑。

2.1 确保Docker Desktop已就位

首先，打开你的Mac，检查是否已经安装了Docker Desktop。打开“终端”应用，输入以下命令：

docker --version

如果显示了类似 Docker version 24.0.7, build afdd53b 的信息，并且版本号比较新（建议使用较新的稳定版），那说明Docker命令行工具已经存在。但这还不够，我们还需要确认Docker Desktop这个“后台大管家”本身正在运行。

更直接的方法是，看看屏幕顶部菜单栏有没有一个鲸鱼图标。如果有，点击它，如果菜单里显示“Docker Desktop is running”，那就完美了。如果没有这个图标，或者图标上有个感叹号，你需要去官网下载并安装Docker Desktop for Mac（Apple Chip版本）。

这里有个关键点： 安装时，务必从Docker官网选择 “Mac with Apple Silicon” 的版本下载。安装过程很简单，拖拽到应用程序文件夹即可。第一次启动时，系统可能会要求你授权一些权限，全部允许就好。启动成功后，菜单栏会出现鲸鱼图标，终端里的docker命令也就真正可用了。

2.2 为GitLab准备好“家”（数据目录）

Docker容器本身是无状态的，一旦删除，里面的所有数据（代码仓库、用户信息、配置）都会消失。所以我们必须把重要的数据“映射”到宿主机（也就是你的Mac）的硬盘上，这个过程叫做“挂载卷”（Volume）。

按照最佳实践，我们为GitLab创建三个主要的目录，分别存放配置、日志和数据。打开终端，执行以下命令来创建这些目录：

mkdir -p ~/docker/gitlab/config
mkdir -p ~/docker/gitlab/logs
mkdir -p ~/docker/gitlab/data

解释一下这三个目录的用途：

• ~/docker/gitlab/config： 这个目录会映射到容器内的/etc/gitlab。GitLab所有的主配置文件gitlab.rb就放在这里。以后你想修改GitLab的访问地址、邮箱设置、集成参数等，都是直接修改这个目录下的文件，然后让容器重新加载，非常方便。
• ~/docker/gitlab/logs： 映射到容器内的/var/log/gitlab。所有GitLab组件（如nginx, postgresql, redis, sidekiq等）的运行日志都在这里。当你的GitLab服务出现问题时，这里是排查故障的第一现场。
• ~/docker/gitlab/data： 映射到容器内的/var/opt/gitlab。这是最核心的目录，Gi