12、构建 Telnet - Server 应用的 CI/CD 管道

最新推荐文章于 2025-12-12 13:52:13 发布

web99

最新推荐文章于 2025-12-12 13:52:13 发布

阅读量69

点赞数

CC 4.0 BY-SA版权

分类专栏： DevOps生存指南文章标签： CI/CD Telnet Server Skaffold

本文链接：https://blog.youkuaiyun.com/web99/article/details/151341461

DevOps生存指南专栏收录该内容

17 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

构建 Telnet - Server 应用的 CI/CD 管道

1. CI/CD 概述

在现代应用开发中，持续集成（CI）和持续部署（CD）是至关重要的软件开发方法。CI 涵盖代码和配置更改的测试与构建，CD 则实现新代码的自动化部署。

CI 阶段 ：软件工程师通过版本控制系统（如 Git）引入新特性或修复漏洞。代码经过一系列构建和测试后，生成如容器镜像这样的工件。测试步骤通常包括单元测试、集成测试和安全扫描，确保应用按预期运行，并检查软件依赖和基础容器镜像的已知漏洞。测试通过后，新工件被构建并推送到共享仓库。
CD 阶段 ：从仓库获取工件并部署到生产环境。常见的部署策略有金丝雀发布、滚动发布和蓝绿发布，具体如下表所示：
| 名称 | 描述 |
| ---- | ---- |
| 金丝雀发布 | 仅让一小部分用户访问新代码，若无误则逐步向更多用户推广。 |
| 蓝绿发布 | 生产服务（蓝色）处理流量，同时测试新服务（绿色）。若绿色代码运行正常，绿色服务将替换蓝色服务。 |
| 滚动发布 | 逐个部署新代码，与生产中的现有代码并行，直至完全发布。 |

部署成功后，需进行监控，确保无问题漏过 CI 阶段。若发现问题，可轻松回滚到之前的安全版本，这是 Kubernetes 等容器编排器的优势之一。

2. 搭建管道所需工具

在创建管道前，需安装以下两个开源工具：
- Skaffold ：助力 Kubernetes 原生应用的持续开发，简化向本地 k8s 集群设置 CI/CD 管道的过程。若未安装，可根据操作系统，按此链接的说明完成安装。
- container - structure - test ：命令行应用，用于验证构建后的容器镜像结构。可通过验证特定文件是否存在、执行命令并验证输出，或检查元数据（如 Dockerfile 中的端口和环境变量）来测试镜像。安装说明见此链接。

3. 审查 skaffold.yaml 文件

skaffold.yaml 文件位于克隆仓库（https://github.com/bradleyd/devops_for_the_desperate/）的 telnet - server/ 目录下，它描述了应用的构建、测试和部署方式，重点关注三个主要部分：

kind: Config
build:
  local: {}
  artifacts:
  - image: dftd/telnet-server
test:
- image: dftd/telnet-server
  custom:
  - command: go test ./... -v
  structureTests:
  - ./container-tests/command-and-metadata-test.yaml
deploy:
  kubectl:
    manifests:
    - kubernetes/*

build 部分 ：使用默认的 docker build 命令在本地创建容器镜像，镜像名为 dftd/telnet - server。Skaffold 会根据当前 Git 提交哈希预计算容器镜像标签，并自动追加到镜像名后，还会将其设置为环境变量 $IMAGE 。
test 部分 ：可对应用和容器镜像运行测试。这里使用为 telnet - server 应用提供的单元测试，通过 go test 命令运行所有测试文件，此步骤需要安装 Go 语言。若未安装，可按此链接的说明进行安装。此外，还会运行 structureTests 检查最终容器镜像的缺陷。
deploy 部分 ：使用 kubernetes/ 目录下的 Kubernetes 清单文件部署 telnet - server 应用。Skaffold 会对正在运行的部署进行补丁操作，用新生成的容器镜像和标签替换当前的。

4. 审查容器测试

容器测试位于 telnet - server/ 目录下的 container - tests/ 子目录中，包含一个测试文件 command - and - metadata - test.yaml。

commandTests:
  - name: "telnet-server"
    command: "./telnet-server"
    args: ["-i"]
    expectedOutput: ["telnet port :2323\nMetrics Port: :9000"]
metadataTest:
  env:
    - key: TELNET_PORT
      value: 2323
    - key: METRIC_PORT
      value: 9000
  cmd: ["./telnet-server"]
  workdir: "/app

commandTests ：执行 telnet - server 二进制文件，传递 -i 标志输出应用监听的端口。输出应与 expectedOutput 匹配，以确保二进制文件在容器构建阶段编译正确。
metadataTest ：检查容器镜像是否按照 Dockerfile 中的预期指令构建，验证环境变量、命令和工作目录。

5. 模拟开发管道

可使用 skaffold 命令的 run 或 dev 子命令启动管道。
- run 子命令：一次性构建、测试和部署应用后退出，不监控代码更改。
- dev 命令：执行 run 的所有操作，并监控源文件的更改。一旦检测到更改，将触发 skaffold.yaml 文件中描述的构建、测试和部署步骤。

为模拟开发管道，使用 dev 子命令，并添加 --cleanup=false 标志，避免退出时清理 telnet - server 部署和服务。在 telnet - server/ 目录下，且 Kubernetes 集群运行时，执行以下命令：

$ skaffold dev --cleanup=false

命令执行过程如下：
1. 设置容器标签，构建 Docker 镜像。
2. 触发测试部分，运行单元测试和容器基础设施测试。
3. 若所有测试通过，尝试将容器部署到 Kubernetes。

若容器镜像和标签已存在，Skaffold 将跳过构建和测试部分，直接进入部署步骤。若仓库有未提交的更改，标签后会添加 -dirty 标识。

graph LR
    A[开始] --> B[设置容器标签]
    B --> C[构建 Docker 镜像]
    C --> D[触发测试]
    D --> E{测试是否通过}
    E -- 是 --> F[部署到 Kubernetes]
    E -- 否 --> G[报错]
    F --> H[监控]
    G --> I[排查问题]
    I --> B

6. 进行代码更改

管道设置完成后，可进行代码更改以测试工作流。例如，更改连接到 telnet - server 时显示的 DFTD 横幅颜色。
1. 在运行 skaffold dev 命令的不同终端中，使用编辑器打开 telnet/ 子目录下的 banner.go 文件。
2. 在第 26 行，将 colorGreen 替换为 colorYellow ：

// 原代码
return fmt.Sprintf("%s%s%s", colorGreen, b, colorReset)
// 修改后
return fmt.Sprintf("%s%s%s", colorYellow, b, colorReset)

保存并关闭文件。回到运行 skaffold dev 命令的终端，应看到类似首次运行的输出，所有步骤将再次触发。

7. 测试代码更改

为确保新代码已部署到 Kubernetes 集群，需验证 DFTD 横幅颜色是否从绿色变为黄色。
1. 若 minikube tunnel 命令未运行，在新终端中运行该命令。
2. 获取 telnet - server 服务的 IP 地址：

$ minikube kubectl -- get services telnet-server

使用 telnet 客户端命令访问应用：

$ telnet <EXTERNAL - IP> 2323

若横幅颜色未变为黄色，需检查代码更改是否正确保存，并查看 skaffold dev 命令的输出以排查错误。

构建 Telnet - Server 应用的 CI/CD 管道

8. 部署策略的深入理解

在前面提到了三种常见的部署策略：金丝雀、滚动和蓝绿，下面进一步详细了解它们的优缺点和适用场景。

部署策略	优点	缺点	适用场景
金丝雀	- 能以最小风险测试新代码，仅影响少量用户。 - 可快速收集反馈，若有问题能及时停止推广。	- 推广过程相对较慢，需要多次验证。 - 对监控系统要求较高，需精准捕捉少量用户的问题。	- 新功能发布初期，不确定是否稳定时。 - 对用户体验要求高，不希望大量用户受影响的情况。
滚动	- 部署过程平滑，对现有服务影响小。 - 可逐步替换旧版本，降低风险。	- 部署时间相对较长。 - 若新版本有问题，可能已影响部分用户。	- 对服务可用性要求高，不能长时间中断的场景。 - 代码更新频繁，但每次更改较小的情况。
蓝绿	- 切换迅速，可快速回滚。 - 测试环境与生产环境完全一致，测试结果更可靠。	- 需要双倍资源，成本较高。 - 切换过程中可能出现短暂服务中断。	- 对系统稳定性要求极高，需要严格测试的重大版本更新。 - 对服务中断时间有严格限制的场景。

9. 监控与回滚机制

部署成功后，监控是确保系统稳定运行的关键环节。Kubernetes 提供了丰富的监控工具，如 Prometheus 和 Grafana 等。通过监控指标，如响应时间、错误率、资源利用率等，可以及时发现潜在问题。

当监控到异常情况，如高延迟、错误率突然增加等，需要及时进行回滚操作。Kubernetes 使得回滚操作变得简单，只需要将部署的容器镜像和标签切换回之前的安全版本即可。以下是一个简单的回滚命令示例：

$ kubectl rollout undo deployment/telnet-server

graph LR
    A[部署成功] --> B[监控指标]
    B --> C{指标是否正常}
    C -- 是 --> D[继续运行]
    C -- 否 --> E[触发回滚]
    E --> F[切换镜像和标签]
    F --> G[验证回滚结果]
    G --> H{回滚是否成功}
    H -- 是 --> D
    H -- 否 --> I[排查回滚问题]
    I --> E

10. 持续集成与持续部署的最佳实践

为了确保 CI/CD 管道的高效运行，以下是一些最佳实践：
- 自动化测试 ：编写全面的单元测试、集成测试和安全扫描，确保代码质量。测试应覆盖各种边界情况，减少潜在的错误。
- 版本控制 ：使用 Git 等版本控制系统，确保代码的可追溯性和协作性。遵循良好的分支管理策略，如 GitFlow 或 GitHub Flow。
- 环境一致性 ：确保开发、测试和生产环境的一致性，避免“在我机器上能运行”的问题。可以使用容器化技术，如 Docker，来保证环境的一致性。
- 监控与日志 ：建立完善的监控和日志系统，及时发现和解决问题。监控指标应包括性能指标、业务指标等，日志应详细记录系统的运行状态。
- 自动化部署 ：使用自动化工具，如 Skaffold，减少人工干预，提高部署效率和准确性。

11. 总结与展望

通过搭建 Telnet - Server 应用的 CI/CD 管道，我们了解了持续集成和持续部署的基本概念和操作步骤。CI/CD 不仅提高了软件开发的效率和质量，还降低了部署风险，使得开发团队能够更快地响应市场需求。

在未来的开发中，可以进一步优化 CI/CD 管道，如引入更多的自动化测试工具、优化部署策略、加强监控和日志系统等。同时，随着技术的不断发展，如人工智能和机器学习的应用，CI/CD 也将迎来更多的创新和变革。

希望本文能帮助你更好地理解和应用 CI/CD 技术，提升软件开发的能力和水平。

graph LR
    A[开始 CI/CD 之旅] --> B[搭建管道]
    B --> C[代码更改与测试]
    C --> D[部署与监控]
    D --> E[优化与创新]
    E --> F[持续改进]
    F --> G[实现高效开发]