技术文章
谷歌云上的SAP:创建CI/CD管道(第3页)
在这篇文章中,我们将继续我们的CI/CD之旅。我们已经探讨了主要的概念(第1部分-包括什么是CI/CD)和我们的示例应用程序背后的想法,以及当HANA参与进来时管道的设计原则(第2部分).现在,我们将向您展示其中一个微服务管道的管道外观。
上图显示了我们将实现的CI/CD流程。当应用程序开发人员提交代码时,它将被Cloud Build中的触发器拾取。然后它将构建、测试和部署我们的应用程序。让我们首先关注单个环境管道,因为稍后将其扩展到多个环境非常简单。
演示应用程序概述
在我们深入管道之前,让我们快速回顾一下我们的应用程序是什么样的:
作为露西娅Subatin在第2部分中,应用程序有四个主要组件:
- 前端:web界面,允许用户访问应用程序。
- 后端:翻译服务
- DAL:数据访问层
- 数据库:SAP HANA -存储我们的数据。
上图显示了这些组件是如何相互作用的。有关更多详细信息,请参阅本系列的第2部分。
我该从哪里开始呢?
现在你可能会想:太棒了!我们从哪里开始呢?我如何选择成为第一个微服务CI / CD的?(是的,我刚刚发明了一个词……诗意许可!!)
当第一次为现有应用程序启动CI/CD管道时,知道如何开始解剖这个庞然大物可能是一个挑战。在服务中寻找以下特征:
- 相当独立,这意味着它不需要在同一个应用程序中调用许多其他服务(它可以是其他服务的依赖项)
- 一个对单元、功能和集成测试有良好测试覆盖的服务(是的——它们都很重要)
- 整体复杂度相对较低
再看一下上面的图表,您认为哪个服务最适合成为第一个?猜猜看!
我们从后端服务开始,因为它是相当独立和经过良好测试的。在自动化部署时,总是尝试改进测试以确保应用程序的可靠性——未来的自己会感谢你的。
建立集装箱
后端依赖于谷歌翻译API SDK的Golang;这意味着我们总是需要安装SDK去
才能构建。我们还想跑去测试
而且去兽医
作为我们测试过程的一部分。
Cloud Build中的管道步骤在容器中运行;这意味着我们可以通过使用所需的所有工具创建一个自定义容器来简化构建。让我们继续为后端创建一个构建容器,并将其存储在容器注册表中,以供以后在管道中使用。
你会问,为什么要麻烦?最终,你会想要每天运行10个甚至100个构建——所以那几秒钟会被放大;这推动了尽可能快地构建的需求。构建容器允许我们跳过下载和安装构建依赖项的步骤-节省时间。
下面是我们的后端构建容器Dockerfile的样子:
# build stage FROM golang:alpine RUN apk - no-cache add build-base git bzr gcc RUN go get -u cloud.google.com/go/translate ENTRYPOINT [" /bin/ash "]
额外提示:您可以通过实现Kaniko Cache进一步减少构建时间。
管道配置
现在我们有了环境,让我们检查一下管道是什么样的:
对于主分支,我们将:
- 使用以下命令运行静态测试
去兽医
- 运行单元测试
去测试
- 运行功能测试(同样
去测试
) - 构建容器(
码头工人
) - 将容器推至注册表(
码头工人
) - 将容器部署到环境(
gcloud
) - 运行集成测试(
去测试
)
Cloud Build管道是通过名为cloudbuild.yaml
详情如下(要点):
当然,为了实现其他技术的管道,细节将会改变;然而,总体流量将保持不变。例如,当使用NodeJS测试DAL层时,该命令将为npm测试
而不是去测试
;等等。
这里有一些重要的考虑:
- 每个微服务都有一个单独的管道(cloudbuild.yaml)
- 每个微服务将独立地生成其工件
- 每个微服务都应该测试与其依赖项的集成。
还记得Lucia在第二部分中解释的这个图像吗?
看看云构建。靠近Yaml,你会看到一个dir:翻译
在指向后端微服务的每个步骤上,因此只有当我们在该文件夹中进行更改时才会运行。有许多方法可以做到这一点,所以请选择最适合您的发布和开发需求的版本。另外,请注意云是如何构建的。Yaml文件位于相关微服务的文件夹中。
创建触发器
一旦我们创建了YAML文件,在Cloud Build中创建触发器是非常简单的:
请注意,我们配置了glob模式,以匹配应用于后端微服务文件夹中的更改翻译/ * *
.这可以防止在repo中的其他文件夹中提交该触发器。
还可以查看regex如何匹配名为主
;对于非主分支,你可以勾选“反转正则表达式”复选框;最后,云构建配置文件还专门指向我们的微服务管道定义翻译/ cloudbuild.yaml
到现在为止,你已经可以很清楚地看到如何为其他微服务创建管道了!
要在正确的文件夹中运行管道提交到存储库,您还可以手动运行它。构建日志可以通过到控制台查看构建执行情况,如下所示:
HANA构件的管道
部署HANA构件的管道基本相同,但又有所不同……但仍然基本相同。
正如您在第2部分中看到的,这个管道依赖于一个HDI容器和一个具有正确工具的特殊构建容器,以允许我们连接和部署到实例。实际的cloudbuild.yaml
文件相当简单:
注意它是如何只有一个步骤的(目前)。它主要依赖于准备好的构建环境和工具hana-cli
和HDI连接上下文通过环境。所有这些都是通过创建一个特定的构建容器来完成的(很像我们的后端构建容器)。
这是构建容器Dockerfile的样子(要点):
顺便说一句,这个Dockerfile没有经过优化,在使用之前可能需要稍微调整一下。
请注意我们如何使用所需的工具来设置容器,以便通过HDI连接到HANA。您可以使用与创建后端构建容器相同的方式构建此容器。这一步很重要,因为它本质上允许我们准备好通过HDI连接和部署db-things。
另一个重要的区别是如何npm开始
命令。我们添加了退出标志,所以它不会等待人类按下Ctrl + C
否则,管道将挂起并超时。
这些是常规微服务管道和使用HDI容器的HANA部署管道之间的主要区别。
现在你应该可以为你的微服务和HANA构件构建自己的管道了!享受吧!
(原载于Medium.com)
好文章!
谢谢你!