使用 GitLab 持续交付 InterSystems 解决方案 – 第 6 部分：容器基础架构

在这一系列文章中，我想向大家介绍并探讨使用 InterSystems 技术和 GitLab 进行软件开发可以采用的几种方式。 我将介绍以下主题：

• Git 101
• 流程（开发流程）
• GitLab 安装
• GitLab 工作流
• 持续交付
• GitLab 安装和配置
• GitLab CI/CD
• 为何使用容器？
• 容器基础架构
• 使用容器的 GitLab CI/CD

在第一篇文章中，我们介绍了 Git 基础知识，以及为什么对 Git 概念的高层次理解对于现代软件开发如此重要，以及如何使用 Git 开发软件。

在第二篇文章中，我们介绍了 GitLab 工作流 – 一个完整的软件生命周期流程和持续交付。

在第三篇文章中，我们介绍了 GitLab 的安装和配置以及如何将环境连接到 GitLab。

在第四篇文章中，我们编写了 CD 配置。

在 第五篇文章中，我们讨论了容器与如何（以及为什么）使用它们。

在本文中，我们将探讨运行使用容器的持续交付管道所需的主要组件，以及它们如何协同工作。

我们的配置如下所示：

在这里，我们可以看到三个主要阶段的分离：

• 构建
• 传送
• 运行

构建

在之前的部分中，构建通常是增量式 – 我们计算当前环境与当前代码库之间的差异，并修改我们的环境以与代码库相对应。 使用容器时，每次构建都是完整构建。 构建的结果是一个可以通过依赖关系在任何地方运行的镜像。

传送

在我们的镜像构建并通过测试后，它会被上传到注册表 – 用于托管 docker 镜像的专用服务器。 在那里，它可以替换具有相同标签的旧镜像。 例如，由于对 master 分支的新提交，我们构建了新镜像 (project/version:master)，如果测试通过，我们可以用相同标签的新镜像替换注册表中的旧镜像，这样，所有拉取 project/version:master 的人都会获得新版本。

运行

最后，我们的镜像部署完成。 CI 解决方案（如 GitLab）可以控制此流程，也可以由专门的编排器控制，但目的都一样 – 执行一些镜像，定期检查健康状态，如果有新镜像版本可用就进行更新。

查看 docker 网络研讨会以了解这些不同阶段的解释。

或者，从提交的角度来看：

在我们的交付配置中，我们会：

• 将代码推送到 GitLab 仓库
• 构建 docker 镜像
• 测试该镜像
• 将镜像发布到我们的 docker 注册表
• 用新版本替换注册表中的旧容器

为此，我们需要：

• Docker
• Docker 注册表
• 注册域（可选但推荐）
• GUI 工具（可选）

 

Docker

首先，我们需要在某个地方运行 docker。 我建议从一台运行主流 Linux 发行版（如 Ubuntu、RHEL 或 Suse）的服务器开始。 不要使用面向云的发行版（如 CoreOS、RancherOS 等） - 它们并不适合初学者。 别忘了将存储驱动程序切换为 devicemapper。 

如果我们在讨论大规模部署，那么使用像 Kubernetes、Rancher 或 Swarm 这样的容器编排工具可以自动执行大多数任务，但我们不会探讨它们（至少在这一部分中）。

 

Docker 注册表

这是我们需要运行的第一个容器，它是一个无状态、可扩缩的服务器端应用程序，作用是存储和分发 Docker 镜像。
您应当在想要实现以下目的时使用注册表：

•  严格控制您的镜像存储位置
•  完全掌控您的镜像分发管道
•  将镜像存储和分发紧密整合到您的内部开发工作流中

此处提供了注册表的文档。

连接注册表和 GitLab

注：GitLab 包含内置注册表。 您可以运行它而不使用外部注册表。 请阅读本段中链接的 GitLab 文档。

要将您的注册表连接到 GitLab，您需要运行支持 HTTPS的注册表 – 我使用 Let's Encrypt 获取证书，并按照此 Gist 获取证书并将其传递到容器中。 在确认注册表可以通过 HTTPS 访问后（您可以从浏览器检查），请按照这些说明将注册表连接到 GitLab。根据您的需要和 GitLab 安装情况，这些说明会有所不同。就我而言，配置是将注册表证书和密钥（正确命名且具有正确的权限）添加到 /etc/gitlab/ssl 并将以下行添加到 /etc/gitlab/gitlab.rb 中：

registry_external_url 'https://docker.domain.com'
gitlab_rails['registry_api_url'] = "https://docker.domain.com"

在重新配置 GitLab 后，我可以看到一个新的注册表标签页，其中提供了如何正确为新构建的镜像添加标签以便它们会出现在这里的信息。

 

域

在我们的持续交付配置中，我们将为每个分支自动构建一个镜像，如果镜像通过测试，那么我们会将其发布到注册表并自动运行，因此我们的应用程序将在所有“状态”下自动可用，例如，我们可以访问：

• 几个功能分支，网址为 <featureName>.docker.domain.com
• 测试版本，网址为 master.docker.domain.com
• 试生产版本，网址为 preprod.docker.domain.com
• 生产版本，网址为 prod.docker.domain.com

为此，我们需要一个域名并添加一条通配符 DNS 记录，将 *.docker.domain.com 指向 docker.domain.com 的 IP 地址。 另一种选项是使用不同的端口。

Nginx 代理

由于我们有几个功能分支，需要将子域自动重定向到正确的容器。 为此，我们可以使用 Nginx 作为反向代理。 此处提供了一份指南。

GUI 工具

要开始使用容器，您可以使用命令行或 GUI 界面之一。 有许多可用工具，例如：

• Rancher
• MicroBadger
• Portainer
• Simple Docker UI
• ...

它们允许您从 GUI 而不是 CLI 创建和管理容器。 下面是 Rancher 的外观：

 

GitLab Runner

与之前相同，要在其他服务器上执行脚本，我们需要安装 GitLab 运行程序。 我在第三篇文章中探讨过这一点。

请注意，您需要使用 Shell 执行器而不是 Docker 执行器。 当您需要从镜像内部提取某些内容时，将使用 Docker 执行器，例如在 Java 容器中构建 Android 应用程序并且只需要一个 apk 时。 在我们的示例中，我们需要整个容器，因此需要使用 Shell 执行器。

 

结论

开始运行容器十分容易，并且有许多工具可供选择。

使用容器的持续交付与常规的持续交付配置在以下几个方面有所不同：

• 依赖关系的需求在构建时得到满足，并且在镜像构建后无需考虑依赖关系。
• 可重现性 – 您可以通过本地运行相同的容器轻松重现任何现有环境。
• 速度 – 由于容器仅包含您显式添加的内容，它们的构建速度更快，更重要的是，它们仅需构建一次并在需要时使用。
• 效率 – 同上，与虚拟机等相比，容器产生的开销更少。
• 可扩缩性 – 使用编排工具，您可以根据工作负载自动扩缩应用程序，并且仅消耗当前所需的资源。