开发人员提交代码后会将代码转交给基础设施团队在开发/测试环境中部署，然后通过大量测试来进行验证。 开发人员的专业技能通常并不包括 Kubernetes、服务网格参数调整或 Ingress 网关的相关知识。 除了知识之外，通常还有企业级的职责分离：开发人员没有权限访问网络配置、不必要的监控工具，当然也不能访问证书等安全对象。
在传统 IT 环境中，流程会这样运行——代码已经完成，工单在变更管理系统中打开，工单被分配给 IT 人员，然后进行审查和实施。 这可能需要几个小时到几天的时间，在某些极端情况下（现实中可能会发生），甚至会花上几周。
在应用不断改进的微服务世界中，这种方案有着根本上的不足。 因此，我们的目标是让任何提交代码的开发人员都能立即查看结果。
在本文中，我们提供了一个使用 AWS 和 Tetrate Service Bridge 的 GitLab 流水线的示范案例，展示了 DevOps 方案和服务网格管理平台如何帮助企业节省时间，同时提升它们的敏捷性。
通过 TSB 部署 AWS 应用
有了 GitLab 流水线方案，一旦应用代码提交到仓库，执行阶段就开始了。 开发人员或 DevOps 工程师已预先配置了可用的流量比率模板。 这些模板已预先配置了一些列明如何在应用的稳定版本和新版本之间转移流量的规则。
服务网格平台 Tetrate Service Bridge (TSB) 负责其余的抽象化工作。 你无需再更改、添加或删除 Kubernetes 和服务网格环境中的多个对象。 ServiceRoute 的概念抽象自动化了这些对象的创建和修改过程，因此运维人员只需关心需要分配给端点的权重；其余的部分则在幕后进行配置。
这种情况下，当开发人员向流水线控制台提交代码，并在测试成功完成后选择应用部署之间的适当比率时，只需单击一下即可将所有流量转移到新版本并删除旧有应用。 开发人员可能会获取在 TSB 中启动此流量转移的权限，以便通过服务帐户进行更改，因此开发人员无需得到对基础设施的任何访问权限，只需访问 GitLab 控制台即可。
DevOps 运维人员也负责类似的任务，有时他们可能需要对（由开发人员或供应商）分派给他们的应用进行额外的测试，而不是逐一检查任务列表来确保环境中的所有设置都已正确配置。 应用会被上传到 GitLab 仓库，接着部署过程将自动开始。 细粒度设置在流水线创建阶段由 TSB 抽象化和预定义，并转换为 GitLab 界面中的单击操作。
总的来说，下面的示例以一种非常高效的方案，针对整个应用生命周期进行建模，从而节省了许多时间；否则，这些时间将花费在设置、更改和调整环境设置，以及分配工作给多个利益相关者上。 现代企业为了保持竞争力，实在无法承受如此低效的工作方式。
AWS 的 CI/CD 流水线工作是个很好的例子：https://aws.amazon.com/blogs/containers/ci-cd-with-amazon-eks-using-aws-app-mesh-and-gitlab-ci/。我们在此以它为底层，并应用于 TSB（Tetrate Service Bridge）的基础设施。
以下重点概述了本示例所实现的内容：
简化网格
现在让我们看看 Tetrate 如何通过简化服务网格为应用开发流水线创建基线的一些细节。
在这次部署中，TSB 管理和控制平面均部署在 AWS EKS 集群中。 使用 TSB 有两个好处： (a) 易于配置的环境，以及 (b) 工作负载和应用指标的更高可见性。
首先让我们快速了解 AWS、Kubernetes 和 Istio 对象之外的概念。我们必须先定义好这些概念，应用才能正常运行。 定义这些对象让用户依赖 TSB 来获取每个集群的管理实施细节。 相反，已经定义的参数从中心位置在集群之间分布开来，并整体上一致地应用于环境中。 此外，它还允许 TSB 收集有关配置和流量模式的数据，并把它们交给工程团队进行分析。
- TSB Workspace —— 一组由 TSB 管理和监控的多个集群。
- 集群——TSB 把它定义为 Kubernetes 集群； TSB 这个平台可以通过一组策略和控制来管理和监控 workspace 底下的多个集群。
- 网关和流量组——定义一组 Kubernetes namespace 以作为单个实体进行控制的逻辑概念。
- Tetrate Istio 网关——这个对象通过创建 TSB 集中式企业级平台所需的虚拟服务、网关和目标规则对象，让 TSB 动态编程 Envoy 入口网关。
注意：唯一一项 提前创建的应用组件 是简单的 Kubernetes 服务，专为测试应用而设。 （预先创建这个对象并不是硬性要求，它也可移到 CI/CD 流水线来实现统一的方案）。 此服务将应用的公共 FQDN 连接到 Kubernetes 命名空间。 所有流量模式逻辑都由服务网格（而不是 Kubernetes）控制，它可以对流量模式进行非常精细的控制。 TSB 为服务网格提供了一个管理平台。
回到我们的例子：
仓库 https://github.com/PetrMc/gitlab-aws-tsb.git 只有三个目录：
a. Src 目录 ——包含 Dockerfile 和 index.html 的应用源代码。 流水线通过下载一个简单的 HTTP 服务器，将 index.html 页面传输到服务器根目录，并创建一个 Docker 容器来启动容器创建
b. 模板目录 （只有两个模板）：
- 部署模板用于定义 Kubernetes 对象——这里使用的唯一变量是用于指定应用版本并指向在上一步中创建的容器
- ServiceRoute 模板确实是这个部署的核心——这里我们定义了流量如何在蓝绿部署之间转移，以及如何连接应用的两个版本。 基于这些定义，TSB 将配置网格内部的所有必要组件。 ServiceRoute yaml 文件是通过 tctl（Tetrate 命令行实用程序）应用的。
c. 根 目录包含两个文件：
i. gitlab-ci.yml 与 AWS 网站上的示例非常相似。 主要区别是：
-
-
- 除了 AWS、Kubernetes 和 Docker 组件之外，我们还添加并配置了上面提到的名为 tctl 的 TSB 配置实用程序，它通过 GRPC 和 Restful API 调用与 TSB 管理平面进行通信。 tctl 二进制文件是从 Tetrate Bintray 公共存储库下载的。
- 此实现仅包含两个阶段。 原始 AWS 示例定义了更细粒度的比例。 如果添加粒度的功能能派上用场的话，你会发现这是个非常简单的复制粘贴操作。 当前的两个阶段是<新部署之 20% / 稳定版本之 80% >和<最新版本之 80% / 旧版本之 20%。>
-
ii. tsb-config.sh shell 脚本再次重用了大量 AWS 材料，这里的主要区别是：
-
-
-
- 仅在应用本身（Kubernetes 部署）配置了两个定义，并通过流量模式的单个定义文件进行了配置。
- 如上所述，tctl 命令用于配置服务网格。 tctl 二进制文件通过 curl 传送到流水线。
-
-
注意：要提及的另一个细节是，除 AWS 变量外，本示例中还添加了几个 TSB 独有的变量：
- – TSB_PASS – TSB 管理员帐户的密码（即“demoblog123”）
- – TSB_TENANT – 特定的 TSB 参数（默认租户是”tetrate”）
- – TSB_URL – tctl 将通过端口 8443 访问的 TSB 编程点的 fqdn（本字段的值，如： gitlab-tsb.example.com）
我们演示的的流水线如下图可见：
d. 应用被修改（例如：使用新的主页内容更新 index.html 文件）。
e. 首先，流水线为 AWS、TSB 和 Docker 部署所需的组件。
f. 下一步是通过将公开可用的 Web 服务器与自定义主页相结合并将镜像发布到 AWS ECR 来创建简单的镜像。
g. 接着，CI/CD 流水线预期 DevOps 运维人员手动选择流向新发布的应用版本的流量。
h. 当对新版本应用的测试结束后，最后一步是将所有流量引导到新应用，并删除旧版本的部署。这是通过 tctl 命令应用修改后的 ServiceRoute 对象，并通过删除 Kubernetes 中的部署来删除之前的应用版本。
在以上所有的步骤中，TSB 动态管理流量控制规则并收集应用和入口网关两个版本的 RED 指标。
现场演示
这条视频是 AWS CI/CD GitLab 流水线的现场演示，你会见到 TSB 位于图片的中心。
后语
以下简单说明一下我们在构建这次演示时发现的几个难题，也许会对一些在自己的环境中实施类似方案的人有帮助：
- EKS 部署仅对创建集群的用户可用。 为了让 CI/CD 流水线中使用的服务帐户管理 Kubernetes 设置，需要将用户添加到 Kubernetes 配置中： https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html。
- 本示例中使用的 DynamoDB 是与区域相关的——如果表创建者的默认 AWS 区域与流水线区域不同，流水线将无法访问数据库。
- GitLab CI/CD 流水线中定义的 AWS 机密和其他变量只能由受保护的分支或标签读取。 如果未使用标签且分支未受保护，流水线将无法访问 AWS。
想了解更多如何使用 TSB 帮助你的工作吗？请访问 www.tetrate.io/tetrate-service-bridge，或与我们的专家安排咨询 。
