Docker容器化部署GitLab与Webhook配置：实现自动化构建流水线

本文是《容器化部署安装Jenkins》的后续篇章。我们将重点讲解如何使用 Docker 容器化部署 GitLab，并配置其 Webhook 功能，以实现与 Jenkins 联动的自动化构建流程，从而打造一个高效、敏捷的持续集成与持续部署（CI/CD）环境。

一、容器化运行GitLab

1. 创建运行gitlab所需环境和配置文件

首先，为 GitLab 创建独立的数据目录，以方便配置、日志和数据的持久化存储。

mkdir /opt/gitlab
cd /opt/gitlab
# 创建gitlab服务所需要的目录
mkdir {config,logs,data}

接着，创建 docker-compose.yaml 配置文件来定义 GitLab 服务。这份文件定义了容器的端口映射、环境变量以及用于数据持久化的卷。

cat > compose.yaml <<EOF
services:
  gitlab-ce:
    hostname: gitlab
    ports:
      - 8443:443
      - 8488:80
      - 2222:22
    container_name: gitlab
    environment:
      - TZ=Asia/Shanghai
    restart: always
    volumes:
      - ./config:/etc/gitlab
      - ./logs:/var/log/gitlab
      - ./data:/var/opt/gitlab
    image: gitlab/gitlab-ce:rc
networks: {}
EOF

使用 Docker Compose 进行服务编排，可以极大地简化多容器应用的管理工作，是现代 云原生 应用部署的常见实践。

2. 启动GitLab

配置文件就绪后，即可启动 GitLab 容器。

# 启动gitlab
docker compose up -d

# 检查容器状态，显示healthy就可以执行下一步
docker compose ps
docker compose logs -f gitlab-ce

启动后，容器初始化可能需要几分钟时间。通过 docker compose logs 命令可以实时查看启动日志，直到服务完全就绪。

二、配置GitLab

容器启动成功后，通过 http://你的服务器IP:8488 访问 GitLab。首次访问需要为 root 用户设置初始密码。

1. 本地化设置

登录后，为了提高使用体验，可以进入“用户偏好设置”，将语言、时区等信息调整为本地化配置。

2. 创建用户级别的SSH Keys

为了安全地进行代码拉取与推送，需要配置 SSH 密钥。

• 个人开发者操作多个仓库：优先使用用户级SSH Keys，更为便捷。
• 自动化工具/第三方服务操作单个仓库：优先使用仓库级Deploy Keys，更为安全。

本文采用用户级别的SSH Keys。进入“用户偏好” -> “SSH Keys”页面，将在上一篇文章中于 Jenkins 容器内生成的密钥对的公钥（id_rsa.pub 文件内容）粘贴添加。

这样，运行 Jenkins 构建任务的用户（在容器内）就拥有了访问 GitLab 仓库的凭证。

3. 允许来自 webhooks 和集成对本地网络的请求

Webhook 功能在调用同处内网的 Jenkins 时，可能会因安全策略被阻止。需要以管理员身份进入“管理中心” -> “设置” -> “网络” -> “出站请求”，勾选“允许来自 webhooks 和集成对本地网络的请求”，保存更改。

4. 创建GitLab项目

接下来创建一个测试项目。点击“新建项目”，项目名称设为 myproject（此名称需与上一篇 Jenkins 任务中配置的仓库名保持一致）。在项目的主分支 main 下，新建一个名为 code.txt 的文件，该文件将用于存放需要由 Jenkins 执行的脚本或指令内容。

5. 创建GitLab项目分支

我们需要一个独立的分支来存放 Jenkins 构建后的执行结果。进入 myproject 项目，创建名为 result 的新分支。这个分支将专门用于存放命令执行的结果和日志，便于后续查询和追踪。

创建成功后，可以在分支列表中看到 result 分支。

6. 在项目里配置Webhook调用外部应用(Jenkins)

这是实现自动化的核心步骤。进入 myproject 项目的“设置” -> “Webhook”页面。

在上一篇文章配置 Jenkins 任务时，系统生成了一个专属的“GitLab webhook URL”和一个“Secret token”。请将它们记录下来。

将这两个值分别填入 GitLab Webhook 配置的“URL”和“Secret令牌”字段中，并至少勾选“推送事件”作为触发器，最后点击“保存更改”。至此，一个将代码推送事件与 Jenkins 构建任务连接起来的自动化 DevOps 桥梁就搭建完成了。

三、测试和验证

1. 更改主项目里的代码触发Webhook

现在来测试整个流程。编辑 main 分支下的 code.txt 文件，做任意修改并提交。这次提交操作会立即触发我们刚刚配置的 Webhook。

2. 查看Webhook调用的Jenkins任务

提交完成后，立即切换到 Jenkins 控制台。在对应的任务构建历史中，可以看到一个新的构建被自动触发。查看构建日志，Jenkins 会展示完整的执行过程：从通过 SSH 密钥拉取 GitLab main 分支的最新代码，到执行 code.txt 中定义的指令，最后将处理结果提交回 GitLab 的 result 分支。

3. 验证GitLab项目分支里的更新内容

最后，回到 GitLab 的 myproject 项目，切换到 result 分支。你会发现该分支下自动生成了一个新文件（如 result.txt）或原有文件被更新，其内容正是 Jenkins 构建执行后的输出结果。

至此，我们已经成功验证了从代码推送（GitLab）到自动构建（Jenkins）再到结果回写（GitLab）的完整自动化 流水线。这套流程为软件项目的持续集成与持续部署奠定了坚实的基础。如需回顾 Jenkins 的容器化部署与初始配置，可参考前置文章：容器化部署安装Jenkins - GitLab webhook触发构建之一。