如何在 Ubuntu 18.04 上使用 GitLab CI/CD 设置持续部署管道

作者选择了自由和开源基金作为写给捐款计划的一部分接受捐款。

介绍

GitLab是一个开源协作平台,提供超出托管代码存储库的强大功能,您可以跟踪问题,托管包和注册表,维护维基,设置连续集成(CI)和连续部署(CD)管道等。

在本教程中,您将使用 GitLab 构建一个连续部署管道. 您将配置管道来构建 Docker 图像,将其推到 GitLab 容器注册表,并使用 SSH 部署到您的服务器。

您将部署一个小,静态的网页,但本教程的重点是配置CD管道. 静态网页仅用于演示目的;您可以使用其他Docker图像来应用相同的管道配置。

完成本教程后,您可以在浏览器中访问http://your_server_IP以获取自动部署的结果。

前提条件

要完成本教程,您将需要:

一个 Ubuntu 18.04 服务器是按照 Ubuntu 18.04 初始服务器安装指南设置的,包括一个 sudo 非 root 用户和防火墙。您需要至少 1 GB RAM 和 1 CPU。
Docker 是按照如何在 Ubuntu 18.04 上安装和使用 Docker 指南在服务器上安装的。一个用户帐户是具有启用容器注册表的 GitLab 实例。 https://gitlab.com] 官方 GitLab 实例的免费计划符合要求。您也可以根据如何在 Ubuntu 18.04 上安装和配置 GitLab 指南来托管自己的 GitLab 实例。

步骤 1 – 创建 GitLab 存储库

让我们先创建一个GitLab项目并添加一个HTML文件,然后将HTML文件复制到 Nginx Docker图像中,然后将其部署到服务器上。

登录您的 GitLab 实例,然后单击 新项目。

The new project button in GitLab

给它一个正确的 项目名称.
可选地添加一个 项目描述.
请确保将 可见性级别设置为私人或公共,取决于您的要求。
最后点击 创建项目

The new project form in GitLab

您将被重定向到项目概览页面。

在您的项目概览页面上,单击 新文件。

The new file button on the project overview page

将文件名设置为index.html,并将下列HTML添加到文件体中:

1[label index.html]
2<html>
3<body>
4<h1>My Personal Website</h1>
5</body>
6</html>

点击页面底部的 ** 承诺更改 ** 来创建文件。

这个HTML将产生一个空页面,一个标题显示我的个人网站在浏览器中打开时。

Dockerfiles 是 Docker 用来构建 Docker 图像的食谱,让我们创建一个Dockerfile,将 HTML 文件复制成 Nginx 图像。

返回项目概览页面,单击 **+**按钮,然后选择 新文件选项。

New file option in the project's overview page listed in the plus button

将文件名设置为Dockerfile,并将这些指示添加到文件体中:

1[label Dockerfile]
2FROM nginx:1.18
3COPY index.html /usr/share/nginx/html

「FROM」指令指定要继承的图像,在这种情况下是「nginx:1.18」图像。「1.18」是代表 Nginx 版本的图像标签。

COPY命令将 index.html 文件复制为/usr/share/nginx/html在 Docker 图像中,这是 Nginx 存储静态 HTML 内容的目录。

点击页面底部的 ** 承诺更改 ** 来创建文件。

在下一步中,您将配置一个GitLab运行器来控制谁可以执行部署任务。

第2步:注册GitLab Runner

为了跟踪会与SSH私钥接触的环境,您将注册您的服务器作为GitLab运行程序。

在您的部署管道中,您要使用 SSH 登录到您的服务器。要做到这一点,您将 SSH 私钥存储在 GitLab CI/CD 变量中(步骤 5)。 SSH 私钥是一个非常敏感的数据,因为它是您的服务器的入口票。

在这里,情况略有变化:您希望授予一个独立的权威(GitLab CI/CD)访问您的服务器,以自动部署流程。因此,私钥需要离开它所生成的系统,并被信任给GitLab和其他相关方。

除了GitLab之外,GitLab Runner 还有另一个系统,你的私钥会输入。对于每个管道,GitLab 使用运行器来执行沉重的工作,即执行你在CI/CD配置中指定的任务。

如果您使用未知的 GitLab 运行器(例如共享运行器)来执行部署任务,那么您将不知道系统会与私钥接触,即使 GitLab 运行器在执行任务后清理所有数据,您可以通过注册自己的服务器作为 GitLab 运行器来避免将私钥发送到未知系统。

开始登录到您的服务器:

1[environment local]
2ssh sammy@your_server_IP

为了安装gitlab-runner服务,您将添加官方的GitLab存储库。下载并检查安装脚本:

1curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh > script.deb.sh
2less script.deb.sh

一旦您对脚本的安全性感到满意,请运行安装程序:

1sudo bash script.deb.sh

它可能不显而易见,但您必须输入您的 non-root用户密码才能继续执行。

1[secondary_label Output]
2[sudo] password for sammy:   % Total    % Received % Xferd Average Speed Time Time Time Current
3                                 Dload Upload Total Spent Left Speed
4100 5945 100 5945 0 0 8742 0 --:--:-- --:--:-- --:--:--  8729

当 curl 命令完成时,您将收到以下消息:

1[secondary_label Output]
2The repository is setup! You can now install packages.

接下来安装gitlab-runner服务:

1sudo apt install gitlab-runner

通过检查服务状态来验证安装:

1systemctl status gitlab-runner

您将在输出中具有`活跃(运行):

1[secondary_label Output]
2● gitlab-runner.service - GitLab Runner
3   Loaded: loaded (/etc/systemd/system/gitlab-runner.service; enabled; vendor preset: enabled)
4   Active: active (running) since Mon 2020-06-01 09:01:49 UTC; 4s ago
5 Main PID: 16653 (gitlab-runner)
6    Tasks: 6 (limit: 1152)
7   CGroup: /system.slice/gitlab-runner.service
8           └─16653 /usr/lib/gitlab-runner/gitlab-runner run --working-directory /home/gitlab-runner --config /etc/gitla

要注册运行者,您需要获取项目代币和GitLab URL:

在您的 GitLab 项目中,导航到设置 > CI/CD > Runners.
在 设置特定 Runner 手动的部分中,您将找到 注册令牌和 GitLab URL。将它们都复制到文本编辑器;您将需要它们用于下一个命令。它们将被称为 https://your_gitlab.com 和 project_token。

The runners section in the ci/cd settings with the copy token button

回到您的终端,注册您的项目的跑者:

1sudo gitlab-runner register -n --url https://your_gitlab.com --registration-token project_token --executor docker --description "Deployment Runner" --docker-image "docker:stable" --tag-list deployment --docker-privileged

命令选项可以如下解释:

*-n'不互动地执行登记'命令(我们指定所有参数为命令选项)。 *-url'是您从 GitLab 的跑者页面复制的 GitLab URL 。 *-注册-token'是您从GitLab的跑者页面复制的标志。 *-执行者'是执行者类型。 docker在一个Docker容器中执行每个CI/CD任务(见[GitLab关于执行者的文件] (https://docs.gitlab.com/runner/executors/))。 *-描述'是跑者描述,将在GitLab出现. *-docker-image'是CI/CD工作中使用的默认多克图像,如果没有明确指定的话. *-tag-list'是指定给跑者的一个标记列表. 标记可以在管道配置中用于选择CI/CD任务的特定跑取者. " 部署 " 标记将使你能够指名道姓地执行部署任务。 *`-docker-privileged' 执行为每个 CI/CD 工作以特殊模式创建的 Docker 容器。一个享有特权的容器可以访问主机上的所有设备,并且与运行在容器外的程序几乎相同(见多克关于[运行时特权和Linux能 (https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)的文档). 在特权模式下运行的原因在于您可以使用多克-in-Docker([dind] (https://www.docker.com/blog/docker-can-now-run-within-docker/))在您的CI/CD管道中构建多克图像. 使集装箱达到所需的最低要求是良好做法。对于您来说, 要使用 Docker- in- Docker , 需要使用特殊模式运行。请注意,您只登记了这个特定项目的运行者, 您控制了在特殊容器中执行的命令。 (英语)

执行gitlab-runner registry命令后,您将收到以下输出:

1[secondary_label Output]
2Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

通过在 GitLab 中访问设置 >CI/CD >跑者来验证注册过程,注册跑者将出现在那里。

The registered runner in the runners section of the ci/cd settings

在下一步中,您将创建一个部署用户。

步骤 3 – 创建部署用户

您将创建一个专门用于部署任务的用户. 您将后来配置 CI/CD 管道以与该用户登录服务器。

在您的服务器上,创建一个新用户:

1sudo adduser deployer

您将通过用户创建过程进行指导,输入强有力的密码和可选的任何您想要指定的其他用户信息,最后用Y确认用户创建。

将用户添加到 Docker 组:

1sudo usermod -aG docker deployer

这允许 deployer执行docker命令,这需要执行部署。

<$>[警告] 警告: 将用户添加到 Docker 组中, 授予与根用户等同的权限. 有关这对系统安全的影响的更多细节,请参阅 Docker Daemon Attack Surface。

在下一步中,您将创建一个SSH密钥,以便能够作为 deployer登录服务器。

第4步:设置一个SSH密钥

您将为部署用户创建一个 SSH 密钥. GitLab CI/CD 将后来使用该密钥登录到服务器并执行部署过程。

让我们开始通过切换到您将生成SSH密钥的新创建的 deployer用户:

1su deployer

您将被要求使用 **deployer ** 密码来完成用户切换。

接下来,生成一个4096位的SSH密钥,重要的是正确回答ssh-keygen命令中的问题:

第一個問題:用「ENTER」來回答,這將鑰匙儲存在默認位置(本教程的其餘部分假定鑰匙儲存在默認位置)。
第二個問題:設定密碼來保護SSH私钥(用於認證的鑰匙)。如果您指定一個密碼,您將不得不每次使用私钥,輸入它。一般來說,一個密碼將會向SSH密钥添加另一個安全層,這是一種良好的做法。擁有私钥的人也會要求密碼使用密碼。為本教程的目的,重要的是你有一個空的密碼,因為CI/CD管道將不互動地執行,因此不允許輸入一個密碼。

要总结,运行以下命令并用ENTER确认两个问题,以创建一个 4096 位 SSH 密钥,并将其存储在默认位置中,使用一个空的密码句:

1ssh-keygen -b 4096

要为 deployer 用户授权 SSH 密钥,您需要将公共密钥附加到 autorized_keys 文件中:

1cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

~是Linux中的用户家用程序的缩写,该cat程序会打印文件的内容;在这里,您使用>>操作员来重定向cat的输出,并将其附加到authorized_keys文件中。

在此步骤中,您为 CI/CD 管道创建了一个 SSH 密钥对,以便登录并部署应用程序。

步骤 5 — 在 GitLab CI/CD 变量中存储私钥

您将将SSH私钥存储在GitLab CI/CD文件变量中,以便管道可以使用该密钥登录到服务器。

当 GitLab 创建一个 CI/CD 管道时,它会将所有变量发送到相应的运行器,变量将被设置为环境变量,持续工作时间。

在变量部分中,您还将为服务器 IP 和服务器用户添加变量,该变量将告知管道目标服务器和用户登录。

首先,请输入 SSH 私钥:

1cat ~/.ssh/id_rsa

将输出复制到剪辑板上,请确保在 -----END RSA PRIVATE KEY----- 之后添加一条线条:

1[label ~/.ssh/id_rsa]
2-----BEGIN RSA PRIVATE KEY-----
3...
4-----END RSA PRIVATE KEY-----

现在,在您的 GitLab 项目中导航到设置 > CI / CD > 变量,然后点击 添加变量。

密钥: ID_RSA
值: 将您的 SSH 私钥插入您的剪辑板(包括在末端的线条断)。
类型: ** 文件**
环境范围: ** 所有(默认)**
保护变量: ** 检查**
面具变量: ** 未检查**

<$>[注] 注: 变量不能被掩盖,因为它不符合常规表达要求(参见 GitLab关于掩盖变量的文档)。

包含私钥的文件将在每个 CI/CD 任务的运行器上创建,其路径将存储在$ID_RSA环境变量中。

使用您的服务器 IP 创建另一个变量. 点击 ** 添加变量** 并如下填写表格:

密钥: SERVER_IP
值: your_server_IP
类型: 变量
环境范围: 所有(默认)
保护变量: 检查过
面具变量: 检查过

最后,与登录用户创建变量,点击 ** 添加变量**,然后如下填写表格:

关键字: SERVER_USER
值: 部署者
类型: 可变性
环境范围: 所有(默认)
保护变量: 检查过
面具变量: 检查过

您现在已将私钥存储在 GitLab CI/CD 变量中,从而在管道执行过程中可用。

步骤 6 — 配置.gitlab-ci.yml 文件

您将配置 GitLab CI/CD 管道. 管道将构建 Docker 图像并将其推到集装箱注册表. GitLab 为每个项目提供一个集装箱注册表. 您可以通过在 GitLab 项目中访问 Packages & Registries > Container Registry来探索集装箱注册表(更多信息请参阅 GitLab 的集装箱注册表文档。

现在你要创建包含管道配置的 .gitlab-ci.yml 文件. 在 GitLab 中,前往 项目概览页面,点击 + 按钮,然后选择 新文件。

(或者,您可以克隆存储库,并在本地计算机上对 `.gitlab-ci.yml 进行所有随后的更改,然后委托并推到远程存储库。

首先,添加以下内容:

1[label .gitlab-ci.yml]
2stages:
3  - publish
4  - deploy

每个工作都被分配给一个 stage。同一阶段分配的工作并行运行(如果有足够的跑者可用)。阶段将按照它们所指定的顺序执行。在这里,发布阶段首先进行,而部署阶段第二。后续阶段只有在前一个阶段成功完成(即所有工作都完成)后才开始。

当您希望将此 CD 配置与现有 CI 管道结合起来,该管道测试和构建应用程序时,您可能希望在现有阶段后添加发布和部署步骤,以便部署仅在测试通过后进行。

接下来,添加到您的 .gitlab-ci.yml 文件:

1[label .gitlab-ci.yml]
2. . .
3variables:
4  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest
5  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHORT_SHA

变量部分定义了环境变量,这些变量将作为常见的Linux环境变量提供,也就是说,您可以在脚本中使用美元标志(如 $TAG_LATEST)进行参照。GitLab为每个工作创建了一些预定义变量,为每个工作提供特定情况的信息,例如分支名称或任务哈希(阅读更多关于预定义变量)。

CI_REGISTRY_IMAGE: 表示与特定项目相关的集装箱注册表的 URL. 这个 URL 取决于 GitLab 实例. 例如,对于 gitlab.com 项目的注册表 URL 遵循模式: registry.gitlab.com/your_user/your_project. 但是由于 GitLab 会提供此变量,您不需要知道确切的 URL。
CI_COMMIT_REF_NAME: 该项目的分支标签或名称。

这两个变量都由预定义变量组成,并将用于标记Docker图像。

「TAG_LATEST」會將「最新的」標籤添加到圖像中,這是一種常見的策略,用來提供總是代表最新版本的標籤。

另一方面,TAG_COMMIT 使用将 Commit SHA 部署为图像标签的前八个字符,从而为每个 Commit 创建一个独特的 Docker 图像。

正如你在接下来的步骤中所探索的那样,将部署回到旧的Git修订程序的过程可以直接在GitLab中完成。

$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME 指定了 Docker 图像基础名称。根据 GitLab 文档,Docker 图像名称必须遵循以下方案:

1[secondary_label image name scheme]
2<registry URL>/<namespace>/<project>/<image>

「$CI_REGISTRY_IMAGE」代表了「//」部分,是强制性的,因为它是项目的注册根。「$CI_COMMIT_REF_NAME」是可选的,但有助于托管不同分支的Docker图像。在本教程中,您只会使用一个分支,但建立可扩展的结构是很好的。一般来说,GitLab支持的图像存储名称有三个层次:

1[secondary_label repository name levels]
2registry.example.com/group/project:some-tag
3registry.example.com/group/project/image:latest
4registry.example.com/group/project/my/image:rc1

对于您的TAG_COMMIT变量,您使用了第二个选项,其中图片将被分支的名称取代。

接下来,将以下内容添加到您的 .gitlab-ci.yml 文件中:

 1[label .gitlab-ci.yml]
 2. . .
 3publish:
 4  image: docker:latest
 5  stage: publish
 6  services:
 7    - docker:dind
 8  script:
 9    - docker build -t $TAG_COMMIT -t $TAG_LATEST .
10    - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY
11    - docker push $TAG_COMMIT
12    - docker push $TAG_LATEST

发布部分是您的 CI/CD 配置中的第一个工作。

*「圖像」是用於這項工作的Docker圖像。GitLab執行器將為每項工作創建一個Docker容器,並在該容器內執行脚本。「docker:latest」圖像確保「Docker」命令可用。 *「階段」將該工作分配到「發表」階段。 *「服務」指定Docker-in-Docker──「dind」服務。

发布任务的脚本部分(https://docs.gitlab.com/ee/ci/yaml/#script)指定了该任务要执行的壳命令,当执行这些命令时,工作目录将设置为存储根。

docker build...: 基于 Dockerfile 构建 Docker 图像,并用变量部分定义的最新 commit 标签标记它.
docker login...: 登录 Docker 到项目的集装箱注册表. 您使用预定义的变量 $CI_BUILD_TOKEN 作为身份验证标记。

接下来,将部署任务添加到您的.gitlab-ci.yml:

 1[label .gitlab-ci.yml]
 2. . .
 3deploy:
 4  image: alpine:latest
 5  stage: deploy
 6  tags:
 7    - deployment
 8  script:
 9    - chmod og= $ID_RSA
10    - apk update && apk add openssh-client
11    - ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY"
12    - ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "docker pull $TAG_COMMIT"
13    - ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "docker container rm -f my-app || true"
14    - ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "docker run -d -p 80:80 --name my-app $TAG_COMMIT"

Alpine是一个轻量级的Linux发行版,足以作为一个Docker图像在这里。你将任务分配到部署阶段。部署标签确保该任务将在被标记为部署的跑者上执行,例如您在步骤 2中配置的跑者。

部署任务的脚本部分从两个配置命令开始:

chmod og= $ID_RSA:从私钥中取消所有 group和 others的权限,所以只有所有者才能使用它.这是一个要求,否则SSH拒绝使用私钥。
apk update && apk add openssh-client:更新Alpine的包管理器(apk)并安装了提供 ssh命令的 openssh-client。

四个连续的ssh命令随之而来,每个命令的模式是:

1[secondary_label ssh connect pattern for all deployment commands]
2ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "command"

在每个ssh声明中,你在远程服务器上执行命令。

选项如下:

-i 代表 身份文件, $ID_RSA 是 GitLab 变量,其中包含通往私钥文件的路径。
-o StrictHostKeyChecking=no 确保绕过问题,你是否信任远程主机。这个问题无法在不互动的环境中回答,如管道。
$SERVER_USER 和 $SERVER_IP 是你在步骤 5 中创建的 GitLab 变量。

部署最终通过在您的服务器上执行以下四个命令进行:

docker login...: 登录 Docker 到集装箱注册表.
docker pull...: 从集装箱注册表中提取最新图像。
docker container rm...: 删除现有的集装箱如果存在的话。 goda true 确保输出代码总是成功,即使没有运行名称为 my-app 的集装箱。这保证了在集装箱不存在时不打破管道的 delete if there is 流程(例如,第一次部署时)。
docker run...: 启动使用注册表中最新图像的新集装箱。集装箱将被命名为 my-app。主机上的 `80 端口将被绑定到

<$>[注] 注: 使用SSH在您的服务器上运行这些命令可能看起来很奇怪,考虑到执行命令的GitLab运行器是完全相同的服务器,但它是必要的,因为运行器在Docker容器中执行命令,所以如果您不使用SSH执行这些命令,您会部署在容器内部,而不是服务器。有人可能会认为,而不是使用Docker作为运行器执行器(https://docs.gitlab.com/runner/executors/docker.html),您可以使用Shell执行器(https://docs.gitlab.com/runner/executors/shell.html)在主机上运行命令,但这会对您的管道产生限制,即运行器必须是与您想要部署的服务器相同的服务器。这不是一个可持续和可扩展的解决方案,因为有一天您可能希望将服务器迁移到

让我们通过在您的 .gitlab-ci.yml 中添加到部署任务来继续:

1[label .gitlab-ci.yml]
2. . .
3deploy:
4. . .
5  environment:
6    name: production
7    url: http://your_server_IP
8  only:
9    - master

GitLab 环境允许您控制 GitLab 中的部署,您可以通过前往 ** Operations > Environments** 来检查 GitLab 项目中的环境。

当一个管道任务定义一个环境部分时,GitLab 每次完成任务时都会为该环境创建一个部署(在这里称为生产),这允许您跟踪 GitLab CI/CD 创建的所有部署。

还有一个可重新部署的按钮,允许您返回旧版本的软件. 在环境部分中指定的URL将打开,当您点击查看部署按钮。

‘仅’部分定义了该任务将运行的分支和标签的名称。默认情况下,GitLab将为每个推到存储库的 pipeline 启动,并运行所有任务(只要有.gitlab-ci.yml 文件)。

<$>[注] 注: 在 2020 年 10 月,GitHub 已更改其命名惯例将默认分支机构从主改为主。GitLab 和开发者社区等其他提供商开始遵循这种方法。

您的完整的 .gitlab-ci.yml 文件将看起来如下:

 1[label .gitlab-ci.yml]
 2stages:
 3  - publish
 4  - deploy
 5
 6variables:
 7  TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest
 8  TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHORT_SHA
 9
10publish:
11  image: docker:latest
12  stage: publish
13  services:
14    - docker:dind
15  script:
16    - docker build -t $TAG_COMMIT -t $TAG_LATEST .
17    - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY
18    - docker push $TAG_COMMIT
19    - docker push $TAG_LATEST
20
21deploy:
22  image: alpine:latest
23  stage: deploy
24  tags:
25    - deployment
26  script:
27    - chmod og= $ID_RSA
28    - apk update && apk add openssh-client
29    - ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY"
30    - ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "docker pull $TAG_COMMIT"
31    - ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "docker container rm -f my-app || true"
32    - ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "docker run -d -p 80:80 --name my-app $TAG_COMMIT"
33  environment:
34    name: production
35    url: http://your_server_IP
36  only:
37    - master

最后,点击 GitLab 页面底部的 ** 承诺更改** 以创建 .gitlab-ci.yml 文件. 或者,当您本地克隆 Git 存储库时,请承诺并将文件推到远程。

您已经创建了一个 GitLab CI/CD 配置来构建 Docker 图像并将其部署到您的服务器上。

步骤 7 – 验证部署

现在,您将验证在GitLab的不同位置以及在您的服务器和浏览器上的部署。

当.gitlab-ci.yml 文件被推到存储库时,GitLab 会自动检测到它并启动 CI/CD 管道。

在您的 GitLab 项目中,请访问 CI/CD > Pipelines 以查看管道的状态。如果工作仍在运行/等待,请等待工作完成。

The pipeline overview page showing a passed pipeline

让我们检查管道。在状态列中点击 passed按钮,打开管道的概述页面。

整个管道的执行时间
该管道的委托和分支执行了。
相关的合并请求. 如果负责的分支机构有一个开放的合并请求,它将出现在这里。

接下来,点击 deploy按钮,打开部署任务的结果页面。

The result page of the deploy job

在工作结果页面上,您可以看到工作脚本的壳输出. 这是在调试失败的管道时要寻找的位置. 在右侧栏中,您将找到您添加到这项工作的部署标签,并且它是在您的 部署运行器上执行的。

如果你滚到页面顶部,你会发现 ** 此工作部署到生产 ** 消息. GitLab 会识别由于工作环境部分而发生的部署。

The production environment in GitLab

您将有所有生产部署的概述. 到目前为止,只有一次部署。对于每个部署,在右侧有 re-deploy 按钮。

重新部署是否按预期工作取决于管道配置,因为它只会在相同情况下重复部署任务。

<$>[注] **注:**您的GitLab集装箱注册表可能有一个到期策略)。到期策略会定期从集装箱注册表中删除较旧的图像和标签。因此,超过到期策略的部署将无法重新部署,因为这个到期文件的Docker图像将被从注册表中删除。您可以在 Settings > CI/CD > Container Registry tag expiration policy中管理到期策略。到期时间通常设置为高点,例如90天。但是当您尝试部署由于到期政策而从注册表中删除的图像时,您可以通过重新运行该特定管道的 publish job来解决这个问题,这将重新创建并将给定到期文件的图像推到注册表

接下来,点击查看部署按钮,在浏览器中打开http://your_server_IP,你应该看到我的个人网站标题。

最后,我们想检查部署的容器在您的服务器上。转到您的终端,并确保再次登录,如果您已经关闭了连接(这对两个用户, sammy和 deployer都有效):

1ssh sammy@your_server_IP

现在列出运行的集装箱:

1docker container ls

将列出my-app容器:

1[secondary_label Output]
2CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
35b64df4b37f8 registry.your_gitlab.com/your_gitlab_user/your_project/master:your_commit_sha   "nginx -g 'daemon of…"   4 hours ago Up 4 hours 0.0.0.0:80->80/tcp my-app

阅读如何在 Ubuntu 18.04 上安装和使用 Docker 指南了解有关管理 Docker 容器的更多信息。

您现在已经验证了部署,在下一步,您将通过回滚部署的过程。

步骤 8 - 回滚部署

接下来,您将更新网页,这将创建一个新的部署,然后使用GitLab环境重新部署以前的部署。

首先,在 index.html 文件中做一个小小的更改:

在 GitLab 中,前往 项目概览,然后打开 index.html 文件.
点击 Edit 按钮,打开在线编辑器。

1[label index.html]
2<html>
3<body>
4<h1>My Enhanced Personal Website</h1>
5</body>
6</html>

保存更改,点击 ** 承诺更改 ** 页面底部。

在 GitLab 中,转到 CI/CD > Pipelines. 当管道完成后,您可以在浏览器中打开http://your_server_IP更新的网页,现在显示我的增强个人网站而不是我的个人网站。

当您移动到 **操作 > 环境 > 生产 ** 时,您将看到新创建的部署。

A list of the deployments of the production environment in GitLab with emphasize on the re-deploy button of the first deployment

通过点击Rollback按钮来确认出现。

该旧管道的部署工作将重新启动,您将被重定向到工作概述页面. 等待工作完成,然后在浏览器中打开http://your_server_IP,在那里您将看到初始标题 我的个人网站再次出现。

让我们总结一下你在本教程中所取得的成就。

结论

在本教程中,您已配置了 GitLab CI/CD 的连续部署管道,您创建了一个由 HTML 文件和 Dockerfile 组成的小型 Web 项目,然后您将 .gitlab-ci.yml 管道配置配置为:

构建 Docker 图像.
将 Docker 图像推到容器注册表.
登录服务器,拖动最新图像,停止当前容器,并启动新的容器。

GitLab现在将将网页部署到您的服务器,每次推到存储库。

此外,您还创建了第二个部署,并使用GitLab环境滚回第一个部署,这表明您如何处理缺陷的部署。

现在,您可以更频繁地与世界和/或客户共享代码更改,因此,开发周期可能会缩短,因为收集反馈和发布代码更改需要更少的时间。

作为下一步,您可以通过域名访问您的服务,并通过 HTTPS 确保通信,其中 How To Use Traefik as a Reverse Proxy for Docker Containers是一个很好的后续操作。