《UNIX/Linux系统管理技术手册-读书笔记-第二十六章

持续集成与交付（CI/CD）

1. CI/CD概述

1.1 三个核心概念

💡 组织可根据风险承受能力选择在流水线何处暂停——非所有站点都必须实现持续部署。

1.2 核心原则

1.3 环境（Environment）

环境一致性（Environment Parity） ：

• 下游环境与生产环境差异 → 测试结果不可靠 → 生产故障
• 策略：定期从生产匿名化数据快照 → 复制到测试环境
• 配置项通过配置管理统一管理，避免硬编码环境差异

1.4 特性标志（Feature Flag）

2. CI/CD流水线

2.1 流水线三个阶段

源代码提交 → 构建（Build） → 测试（Test） → 部署（Deploy） → 生产

制品类型示例（表26.1）：

• .jar/.war（Java）
• .rpm/.deb（Linux包）
• pip/gem包（Python/Ruby）
• 容器镜像（Docker）
• 虚拟机镜像（AMI/机器镜像）

2.2 测试类型

黄金规则：测试失败 → 立即修复流水线，绝不容忍“忽略”失败测试。

2.3 零停机部署技术

3. Jenkins自动化服务器

3.1 核心概念

3.2 快速启动

1
2
3
4

# 容器运行Jenkins
docker run -p 8080:8080 --name jenkins jenkinsci/jenkins
# 访问 http://localhost:8080
# 初始管理员密码在容器日志中

3.3 Jenkinsfile（流水线即代码）

核心优势：流水线定义与代码一同存储在版本控制中，可审计、可回滚。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'make'
            }
        }
        stage('Test') {
            steps {
                sh 'make test'
            }
        }
        stage('Deploy') {
            steps {
                sh 'deploy.sh'
            }
        }
    }
}

关键概念：

• pipeline：顶层定义
• agent any：任何可用构建代理执行
• stages：阶段列表（串行执行）
• stage：单个阶段（构建/测试/部署）
• steps：阶段内的具体命令
• environment：定义环境变量（可从凭证存储读取敏感数据）

4. CI/CD实战案例（UlsahGo）

4.1 流水线概览

GitHub提交 → Jenkins检出代码 → 单元测试(go test) → 构建(go build)
→ Packer构建DigitalOcean镜像 → Terraform创建单Droplet测试环境
→ 集成测试(健康检查+功能验证) → 销毁测试Droplet
→ Terraform创建生产环境(2 Droplets + 负载均衡器)
→ 生产验证 → 部署完成

4.2 工具栈

4.3 关键技术点

Jenkinsfile片段（凭证传递） ：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

pipeline {
    environment {
        DO_TOKEN = credentials('do-token')   // 从Jenkins凭证存储读取
        SSH_FINGERPRINT = credentials('ssh-fingerprint')
    }
    stages {
        stage('Create droplet') {
            steps {
                sh 'bash pipeline/testing/tf_testing.sh'
            }
        }
    }
}

Packer配置示例（DigitalOcean镜像） ：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{
  "builders": [{
    "type": "digitalocean",
    "api_token": "{{user `do_token`}}",
    "region": "sfo2",
    "size": "512mb",
    "image": "ubuntu-16-04-x64",
    "snapshot_name": "ulsahgo-latest"
  }],
  "provisioners": [
    {"type": "file", "source": "ulsahgo", "destination": "/tmp/ulsahgo"},
    {"type": "file", "source": "ulsahgo.service", "destination": "/etc/systemd/system/"},
    {"type": "shell", "script": "provisioner.sh"}
  ]
}

Terraform配置（生产环境） ：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

resource "digitalocean_droplet" "ulsahgo-a" {
  image = var.do_image
  name = "ulsahgo-a"
  region = "sfo2"
  size = "512mb"
  ssh_keys = [var.ssh_fingerprint]
}
resource "digitalocean_loadbalancer" "public" {
  name = "ulsahgo-lb"
  region = "sfo2"
  forwarding_rule {
    entry_port = 80
    target_port = 8000
  }
  healthcheck {
    port = 8000
    path = "/healthy"
  }
  droplet_ids = [digitalocean_droplet.ulsahgo-a.id, digitalocean_droplet.ulsahgo-b.id]
}

5. 容器与CI/CD

5.1 容器如何简化CI/CD

5.2 基于容器的CI/CD工作流

(1) 在构建容器中编译应用
(2) 创建包含应用+依赖的容器镜像
(3) 推送到镜像Registry
(4) 通过容器编排API部署到生产

优点：

• 构建环境隔离，无依赖冲突
• 制品（容器镜像）统一格式，跨环境一致
• 部署速度极快（容器启动<1秒）
• 回滚简单（切换镜像tag）

5.3 容器化CI/CD工具

6. CI/CD最佳实践总结

7. 本章核心命令速查表

DBA视角补充：

• 数据库变更与CI/CD：传统数据库变更（DDL/Schema迁移）常成为CI/CD流水线的瓶颈。使用迁移工具（如Flyway、Liquibase）将数据库变更纳入版本控制，并在流水线中自动执行迁移+验证，实现数据库CI/CD。
• 测试环境数据库：CI/CD测试阶段需要数据库时，使用临时容器数据库（如docker run postgres）或测试实例，避免污染共享测试数据库。
• 数据匿名化：从生产环境复制数据到测试环境时，必须匿名化敏感数据（姓名、邮箱、电话、密码等），符合合规要求（GDPR/PCI-DSS）。
• 迁移回滚策略：数据库迁移应可回滚（如Flyway的undo），与蓝/绿部署或金丝雀发布配合，确保新版本数据库变更不影响旧版本应用。
• 性能测试环境：数据库性能测试需要与生产环境接近的数据量和查询模式。使用生产数据匿名化样本或生成合成数据，确保性能测试结果可信。
• 监控数据库部署：流水线部署数据库变更后，监控慢查询日志、连接数、锁等待等指标，异常时自动触发回滚。将数据库监控指标集成到CI/CD流水线的健康检查中，可作为金丝雀发布的判断依据。
• 基础设施即代码的DBA视角：数据库服务器的配置（my.cnf/postgresql.conf、备份策略、监控Agent）应通过Terraform/Ansible等工具定义在代码中，与应用代码一同版本控制，确保数据库服务器配置可追溯和可复现。