玩转自搭建 GitLab 社区版
本文的自搭建是基于docker容器技术而实现的，其中包括gitlab-ce和gitlab-runner两个部分。
什么是 GitLab
GitLab是一个代码仓库管理系统（它是一套开源项目），使用 Git 作为代码管理工具，集成 Web 管理的服务，GitLab被广泛用于基于 Git 代码管理平台，在很多一些结构不是复杂的组织结构中都会优先使用它。
它能做什么
GitLab是代码仓库管理系统，它实现了一个更加界面友好的交互方式来对项目代码进行管理，除此之外，它还可以集成CI/CD特性，通过部署 GitLab-Runner 来对项目代码进行持续集成和部署分发。
功能很实用，可以满足常规的项目开发工作。
对比一些大项目，其设计复杂，对于代码的管控也非常复杂，采取的管理手段也多样化，GitLab可能不一定适应这种场景，为此大多数的做法是仓库管理系统和CI/CD系统分离的结构，仓库管理系统有五花八门的，有自己开发的（或者基于其他的开源项目），而对于CI/CD系统一般都是采用Jenkins，其有更加丰富的成熟套件和流程方案。
搭建步骤
这里介绍我测试搭建这套系统的搭建步骤。
搭建 GitLab 主框架
在Docker镜像的主官网上，我们其实可以搜索到GitLab的镜像，所以我们很方便的使用Docker技术来部署我们需要的服务。
该镜像下有很多的tags，可以指定特定的版本，或者使用默认的最近版本。
GitLab的管理系统搭建，我使用编写docker-compose.yml方式来部署的，注意添加服务的时候，设置的环境变量GITLAB_OMNIBUS_CONFIG，可以为服务启动传递启动参数。
当仓库管理系统服务创建并启动后，我们就可以打开浏览器来访问自搭建部署的GitLab服务了，如下图所示：
登录管理员账号
以上步骤之后，需要登录管理员的账号，来进一步对系统进行配置，管理员的用户名是root，而密码需要从容器里面去获取，我们也可以获取容器的IP，便于后面的设置使用，如下：
据此我们得到管理员的密码来登录系统。
系统登录后进入系统配置的页面，在此页面上，我们可以完成仓库管理系统的所有配置工作。
我们弄这个GitLab绝对不是仅仅作为代码管理系统而用的，如果仅仅为了代码仓库管理，可以移步到
gogs这些代码仓库管理系统，它速度快，简洁而且美观，很有Github的界面感。
CI/CD环境部署配置
这是配置的重头戏了。
当上面的步骤都差不多了，就要进行GitLab-Runner的部署，它是CI/CD的代理节点，我们可以在管理员界面下点开Runner查看可以用的列表：
上面啥也没有，我们需要弄一个代理机器作为节点，让它去跑Runner，为此我们需要在代理机器上安装GitLab-Runner，这是常规操作。
但是，我只是测试一下GitLab的特性，把玩一下而已，所有不需要那么复杂，仍然可以通过部署Docker的GitLab-Runner服务的运行它，并把它注册到本地，这样为了便于解析IP，我需要调整一下Hosts文件的内容，增加一行解析：
1 | 192.168.176.2 gitlab.me |
上面的192.168.176.2，不一定和你的一样，需要和上面的容器内的IP对应，这样多个容器都可以正确解析到正确的IP上去。
下面是注册 Runner
（这里的token可以从上图的Registration token处复制过来），如图所示：
注册成功后，会在上面的Runners列表里面刷新出来。
注意到，我这里的
executor用的是docker，这样我可以用Docker镜像（gcc）来编译代码，这适合这种用Docker容器部署的情形，但是如果是直接把Runner安装在了实体机器上的，并且实体机器上已经存在开发环境，那么我们可以直接用shell方式来编译。如果是需要在代理节点上再次ssh登录远程机器来编译代码，那么executor就应该选用ssh的方式。具体使用哪种方式取决于实际环境。
注册成功后，在 Runners 列表刷新出刚刚新加的Runner，如下图：
上图中，点击左边的链接可以看到 Runner 的详情：
点击右边的铅笔，可以修改Runner的参数设定：
这里我把Run untagged jobs复选框勾上，并保存修改。
到这里整个Runner的配置基本就完成了。
Runner还有更多的配置，详情可以参考官方文档介绍。
创建普通用户帐号
接着我们打开一个隐私页面，进入登录界面，这次我们点击Register now来新建用户，填写完用户信息后，注册一个新的用户，然后需要管理员在用户管理界面上进行批准，批准通过后，刚注册的用户就可以正常登录系统了，如下图（图中的用户已经新建了一个仓库）：
该普通用户帐户是开发者，后面测试CI/CD系统将以该用户进行测试。
创建仓库
新建仓库非常简单，只需点击New project后，填写项目基本信息即可：
设置仓库的 gitlab-ci
设置仓库根目录下的.gitlab-ci.yml文件，添加流水线任务。
我写的非常简单，script指定编译命令，only指定在哪一个分支下进行CI部署（我指定的是：main分支），然后tags和注册Runner的tags一一对应的。
关于
gitlab-ci.yml文件的更多细节可以参考官方文档。
提交代码并进行 CI 操作
当一切都准备妥当后，下面就是写代码，并提交到远程仓库的main分支下：
刚提交了代码，系统上立即显示流水线就已经在更新了。
可以点开正在执行的流水，查看任务细节：
至此，这个GitLab的基本配置，和它的CI/CD流水配置，以及使用也已经完成，这套代码管理系统的实用性，总体来说还算不错的。
具体配置
以下两个文件是我的测试配置，仅供参考。
我的测试配置
.gitlab-ci.yml配置如下：
1 | stages: |
docker-compose.yml配置如下：
1 | version: "3.0" |
我遇到的坑
可能会碰到的坑：
docker-compose.yml文件中设置环境变量GITLAB_OMNIBUS_CONFIG中的external_url，如果域名带端口，docker的服务监听会绑定到该端口上；gitlab-runner的配置（config.toml），runner.docker节区下添加network_mode为gitlab-network以对应docker-compose.yml
