diff --git a/Tech/software-engineering/CI&CD/GitHub Actions.md b/Tech/software-engineering/CI&CD/GitHub Actions.md index 69e6b9c7..89d8855f 100644 --- a/Tech/software-engineering/CI&CD/GitHub Actions.md +++ b/Tech/software-engineering/CI&CD/GitHub Actions.md @@ -1,10 +1,15 @@ --- title: GitHub Actions -description: 描述 +description: GitHub Actions 是 GitHub 提供的持续集成和持续交付(CI/CD)平台,允许开发者自动化他们的软件项目构建、测试和部署流程。通过在 GitHub 仓库中定义 YAML 格式的工作流文件,可以响应如代码提交或发布标签等 GitHub 事件来触发任务执行。GitHub Actions 支持跨平台运行,具备事件驱动、易于编写的 YAML 配置、安全性特性,以及提供了丰富的官方和社区 Actions 来简化工作流配置。 keywords: - - 关键字 + - GitHub Actions + - CI&CD + - 自动化 + - YAML + - 跨平台 tags: - - 标签 + - 技术/软件工程 + - 软件工程/CICD author: 仲平 date: 2024-08-07 --- diff --git a/Tech/software-engineering/CI&CD/GitLab Runner.md b/Tech/software-engineering/CI&CD/GitLab Runner.md new file mode 100644 index 00000000..8fffe4b6 --- /dev/null +++ b/Tech/software-engineering/CI&CD/GitLab Runner.md @@ -0,0 +1,1103 @@ +--- +title: GitLab Runner +description: GitLab CI/CD 是一套自动化工具链,用于实现软件开发的持续集成和持续交付/部署。GitLab Runner 是执行这些 CI/CD 任务的开源服务,它根据 GitLab 项目中的 .gitlab-ci.yml 配置文件来运行任务。Runner 支持 Shell、Docker、Kubernetes 等多种执行环境,能够并行处理作业,提供日志记录和结果报告,并支持缓存和构建产物(artifacts)来优化构建过程。 +keywords: + - GitLab + - Runner + - 自动化 + - .gitlab-ci.yml + - 多环境执行 +tags: + - 技术/软件工程 + - 软件工程/CICD +author: 仲平 +date: 2024-08-09 +--- + +## GitLab CI/CD + +### 基本概念和工作原理 + +GitLab CI/CD (Continuous Integration and Continuous Delivery/Deployment) 是一种自动化工具链,用于软件开发过程中从代码提交到生产部署的全过程。它包括连续集成(CI)和连续交付/部署(CD)的实践。 + +![GitLab CI/CD](https://static.7wate.com/2024/08/09/5c741873f5bad.png) + +- **Continuous Integration (CI)**: CI 主要关注代码的频繁集成和测试。每当开发人员提交代码到版本控制系统时,CI 系统会自动触发构建和测试流程,确保代码的正确性和质量。通过频繁集成和测试,能够快速发现和修复问题,减少集成风险。 +- **Continuous Delivery (CD)**: CD 的目标是确保软件在任何时候都可以安全地部署到生产环境。它通过自动化的方式,将经过测试的代码推送到预生产或生产环境中。CD 包括自动化的部署、测试和发布过程。 +- **Continuous Deployment**: 是 Continuous Delivery 的延伸,它将经过验证的代码自动部署到生产环境中,无需人工干预。这种实践要求更高的自动化和监控能力。 + +![ci-gitlab.jpeg](https://static.7wate.com/2024/08/09/48ccee97c1a9b.jpeg) + +**GitLab CI/CD 通过 .gitlab-ci.yml 文件定义 CI/CD 流程,该文件包含了所有的构建、测试和部署步骤。** GitLab Runner 是 GitLab CI/CD 的执行者,它运行在不同的环境中,执行 .gitlab-ci.yml 文件中定义的任务。 + +### GitLab Runner + +GitLab Runner 是一个开源项目,用于运行由 GitLab CI/CD 定义的任务。它从 GitLab 服务器获取 .gitlab-ci.yml 文件中读取配置和作业,并在不同的执行环境中执行这些作业。GitLab Runner 支持多种执行模式,并能与 GitLab 实例无缝集成。 + +- 执行构建、测和部署任务 +- 支持并行作业和多平台执行 +- 提供日志记录和结果报告 +- 支持缓存和 artifacts,优化构建过程 + +#### GitLab Runner 的不同执行模式(如 Shell、Docker、Kubernetes) + +GitLab Runner 支持多种执行模式,每种模式适用于不同的使用场景: + +| **执行模式** | **描述** | **优点** | **缺点** | **适用场景** | +| ------------------ | ------------------------------------------------------ | -------------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------ | +| **Shell** | 使用主机的 Shell 环境执行作业。 | 配置简单,直接使用主机环境,开销低。 | 缺乏环境隔离,可能影响主机系统,安全性较低。 | 适用于简单的构建和测试任务,不需要复杂依赖或隔离环境的场景。 | +| **Docker** | 在 Docker 容器中执行作业,提供隔离的执行环境。 | 提供环境隔离,易于管理依赖和一致性,支持多种语言和工具。 | 需要配置 Docker,容器启动有额外开销,可能增加复杂性。 | 需要特定依赖和环境配置的任务,如使用特定版本的编译器、库或工具的构建和测试任务。 | +| **Docker Machine** | 动态创建和销毁 Docker 主机,支持弹性扩展。 | 自动化资源管理,弹性扩展能力强,适合大规模分布式系统。 | 配置和管理复杂,资源使用成本较高,创建和销毁主机耗时较长。 | 需要弹性扩展、动态分配资源的场景,适合高并发或资源密集型的 CI/CD 管道。 | +| **Kubernetes** | 在 Kubernetes 集群中运行作业,提供容器编排和管理能力。 | 强大的容器编排和管理功能,适合复杂的部署和扩展需求。 | 需要熟悉 Kubernetes 的配置和管理,初始设置和维护较为复杂。 | 适用于大规模分布式系统和云原生应用的 CI/CD 管道,特别是在微服务架构下的持续集成和部署。 | +| **Custom** | 允许用户定义自定义执行器,满足特定需求。 | 灵活性极高,能够满足特定的、非标准的需求。 | 需要自行开发和维护自定义执行器,配置复杂,调试困难。 | 需要特殊硬件或自定义环境的场景,如 FPGA 编程、特殊设备测试,或使用非标准的执行环境。 | + +#### GitLab Runner 的安装步骤和配置方法 + +安装 GitLab Runner 的过程因操作系统和执行模式不同而有所差异,**[建议参考官方文档手册](https://docs.gitlab.com/runner/install/)。** + +### .gitlab-ci.yml + +`.gitlab-ci.yml` 是 GitLab 用于定义 CI/CD(持续集成和持续部署)管道的配置文件,采用 YAML 语法编写。它位于 GitLab 项目的根目录中,描述了项目的自动化构建、测试和部署流程。每次代码提交或合并时,GitLab 会根据 `.gitlab-ci.yml` 文件中的配置自动触发相应的管道任务。基本结构包括以下部分: + +```mermaid +graph LR + A[.gitlab-ci.yml] + + A --> B[stages] + A --> C[jobs] + A --> D[scripts] + A --> E[artifacts] + A --> F[cache] + A --> G[variables] + A --> H[dependencies] + A --> I[only/except] + A --> J[include] + + B --> B1[build] + B --> B2[test] + B --> B3[deploy] + + C --> C1[build-job] + C --> C2[test-job] + C --> C3[deploy-job] + + D --> D1[build commands] + D --> D2[test commands] + D --> D3[deploy commands] + + E --> E1[build/] + F --> F1[.m2/repository] + + G --> G1[DEPLOY_ENV: production] + G --> G2[NODE_ENV: test] + + H --> H1[build-job] + H --> H2[test-job] + + I --> I1[only: master] + I --> I2[except: tags] + + J --> J1[template: Jobs/Build.gitlab-ci.yml] + J --> J2[local: 'my-custom-config.yml'] +``` + +| **元素** | **描述** | +| ---------------- | ------------------------------------------------------------ | +| **stages** | 定义 CI/CD 管道的不同阶段,按顺序执行,例如构建(build)、测试(test)和部署(deploy)。 | +| **jobs** | 定义在不同阶段中执行的具体任务,每个任务必须属于某个阶段。 | +| **scripts** | 指定每个任务执行的命令和脚本,通常包括构建、测试和部署的具体操作。 | +| **artifacts** | 定义构建产物的存储和使用,通常用于保存构建结果以供后续作业使用或为后续步骤提供数据。 | +| **cache** | 配置缓存以优化构建速度,减少重复下载或构建的时间,尤其是在使用外部依赖时。 | +| **variables** | 定义环境变量,配置不同任务的执行环境,变量可以在脚本中引用,以提供灵活的配置。 | +| **dependencies** | 指定当前作业依赖的前一阶段作业,以确保当前作业可以访问前一作业的产物或输出。 | +| **only/except** | 定义作业的执行条件,`only` 指定作业只在某些情况下执行,`except` 指定作业在某些情况下不执行。 | +| **include** | 从外部文件或模板中引入配置,便于配置的复用和管理,常用于共享公共配置或集成现有配置文件。 | + +#### 阶段(stages) + +**Stages** 是 GitLab CI/CD 管道的核心组成部分,用于定义管道的执行顺序。每个 `stage` 代表一个阶段,按顺序执行。例如,常见的阶段包括 `build`(构建)、`test`(测试)和 `deploy`(部署)。所有在同一个 `stage` 中的作业会并行执行,整个 `stage` 成功后,管道会进入下一个阶段。 + +```mermaid +graph TD + A[stages] + A --> B[build] + A --> C[test] + A --> D[deploy] +``` + +#### 作业(jobs) + +**Jobs** 是在 CI/CD 管道中实际执行的任务,每个 `job` 都属于一个特定的 `stage`。一个 `job` 通常包括编译代码、运行测试或部署应用的操作。每个 `job` 都会指定一个 `stage`,并包含执行这些操作的具体命令和脚本。GitLab 会按照 `stage` 的顺序执行相应的 `job`。 + +```mermaid +graph TB + A[jobs] + A --> B[build-job] + A --> C[test-job] + A --> D[deploy-job] + + B --> B1[stage: build] + C --> C1[stage: test] + D --> D1[stage: deploy] +``` + +#### 脚本(scripts) + +**Scripts** 是 `job` 中的核心部分,定义了在 CI/CD 管道中执行的具体命令或操作。这些脚本可以是简单的命令,如打印消息、编译代码、运行测试,或是调用外部工具。`script` 是实现构建、测试、部署等操作的关键,通过这些命令来自动化 CI/CD 流程。 + +```mermaid +graph TB + A[scripts] + A --> B[make] + A --> C[make test] + A --> D[make deploy] +``` + +#### 变量(Variables) + +变量用于在 `.gitlab-ci.yml` 文件中定义环境变量,帮助配置不同任务的执行环境。变量可以在脚本中引用,以实现动态配置。例如,环境变量 `DEPLOY_ENV` 可以用于指定部署的目标环境。 + +```mermaid +graph TB + A[variables] + A --> B[DEPLOY_ENV: production] + A --> C[NODE_ENV: test] +``` + +#### 缓存(Cache) + +缓存用于保存构建过程中生成的中间文件或依赖项,减少重复下载或构建的时间,从而加快 CI/CD 管道的执行速度。例如,可以缓存 Maven 的依赖库。 + +```mermaid +graph TB + A[cache] + A --> B[.m2/repository] + A --> C[node_modules/] +``` + +#### 构建产物(Artifacts) + +Artifacts 是作业运行后生成的文件或构建产物,可以在后续作业中使用或下载。Artifacts 通常用于保存构建结果、测试报告等内容。 + +```mermaid +graph TB + A[artifacts] + A --> B[build/] + A --> C[dist/] +``` + +#### 依赖(Dependencies) + +通过 `dependencies` 关键字,可以指定当前作业依赖于前一个阶段的某些作业。这样可以确保作业在正确的依赖产物生成后才会运行。例如,测试作业可以依赖于构建作业生成的构建产物。 + +```mermaid +graph TB + A[dependencies] + A --> B[build-job] + A --> C[test-job] +``` + +#### 执行条件(Conditions) + +通过 `only`、`except` 和 `when` 等关键字,可以指定作业的执行条件。`only` 和 `except` 用于限定作业在哪些分支或条件下执行,而 `when` 用于指定作业何时执行(例如:手动触发)。 + +```mermaid +graph TB + A[执行条件] + A --> B[only] + B --> B1[master] + + A --> C[except] + C --> C1[tags] +``` + +#### 包含(Includes) + +GitLab 提供了一些预定义的 CI/CD 模板,可以通过 `include` 关键字直接在 `.gitlab-ci.yml` 文件中引用。这些模板包含常见的构建、测试和部署任务,从而复用和共享配置。这对于大型项目或需要在多个项目间共享 CI/CD 配置时非常有用。 + +```mermaid +graph TB + A[include] + A --> B[template: Jobs/Build.gitlab-ci.yml] + A --> C[local: 'my-custom-config.yml'] +``` + +#### 示例配置 + +```yaml +# 定义不同的 CI/CD 阶段,按顺序执行 +stages: + - build + - test + - deploy + +# 定义全局变量,可在所有作业中引用 +variables: + DEPLOY_ENV: production + NODE_ENV: test + +# 使用缓存加速构建过程,避免重复下载依赖 +cache: + paths: + - .m2/repository + - node_modules/ + +# 构建作业,属于 build 阶段 +build-job: + stage: build + script: + # 运行构建命令 + - echo "Building the project..." + - make build + artifacts: + # 保存构建产物以供后续作业使用 + paths: + - build/ + tags: + # 使用带有 docker 标签的 Runner 运行作业 + - docker + +# 测试作业,属于 test 阶段 +test-job: + stage: test + script: + # 运行测试命令 + - echo "Running tests..." + - make test + dependencies: + # 指定依赖的作业,确保使用 build-job 的构建产物 + - build-job + only: + # 仅在 master 分支上执行测试作业 + - master + artifacts: + # 保存测试结果 + paths: + - test-reports/ + +# 部署作业,属于 deploy 阶段 +deploy-job: + stage: deploy + script: + # 部署到生产环境 + - echo "Deploying to $DEPLOY_ENV environment..." + - make deploy + only: + # 仅在 master 分支或带有生产标签的提交上执行部署 + - master + except: + # 排除带有 ci-skip 标签的提交 + - tags + environment: + # 定义部署的环境 + name: production + url: https://production.example.com + +# 包含外部模板配置 +include: + - template: Jobs/Build.gitlab-ci.yml +``` + +## 基础实践 + +### 创建第一个 GitLab CI/CD 管道(Pipeline) + +创建一个简单的 .gitlab-ci.yml 文件是开始使用 GitLab CI/CD 的第一步。该文件定义了管道中的作业和阶段。以下是一个简单的示例: + +```yaml +stages: + - build + - test + +build-job: + stage: build + script: + - echo "Compiling the code..." + - make + +test-job: + stage: test + script: + - echo "Running tests..." + - make test +``` + +#### 在 GitLab 中运行第一个管道 + +1. 将 .gitlab-ci.yml 文件提交到项目的根目录。 +2. 登录 GitLab,导航到项目页面。 +3. 在左侧菜单中选择 "CI / CD" -> "Pipelines"。 +4. 查看新创建的管道,点击查看详细信息。 + +**GitLab 会自动检测 .gitlab-ci.yml 文件并运行管道。你可以查看每个作业的日志,了解执行情况。** + +#### 监控和管理管道执行 + +1. **监控管道状态**: 在 Pipelines 页面查看所有管道的状态(成功、失败、进行中)。 +2. **查看作业日志**: 点击具体作业查看详细日志,了解作业的执行情况和输出。 +3. **重试失败的作业**: 对于失败的作业,可以点击 Retry 按钮重新执行。 +4. **取消进行中的管道**: 如果需要终止进行中的管道,可以点击 Cancel 按钮。 + +### 使用预定义的 GitLab CI 模板 + +GitLab 提供了一些预定义的 CI 模板,帮助用户快速上手常见的 CI/CD 流程。这些模板涵盖了多种编程语言和框架,如 Java、Node.js、Python 等。 + +- 常见模板: + + - `Jobs/Build.gitlab-ci.yml` + - `Jobs/Test.gitlab-ci.yml` + - `Jobs/Deploy.gitlab-ci.yml` + +#### 如何在项目中引用和使用预定义模板 + +你可以通过 `include` 关键字在 .gitlab-ci.yml 文件中引用预定义模板。例如下述示例中,引用了 GitLab 提供的构建模板,同时添加了一个自定义的测试作业。 + +```yaml +include: + - template: Jobs/Build.gitlab-ci.yml + +stages: + - build + - test + +test-job: + stage: test + script: + - echo "Running custom tests..." + - make test +``` + +#### 根据需求自定义和扩展模板 + +使用预定义模板后,你可以根据项目的具体需求进行自定义和扩展。例如通过自定义模板,你可以在标准流程基础上添加特定的测试和部署逻辑。 + +```yaml +include: + - template: Jobs/Build.gitlab-ci.yml + +stages: + - build + - test + - deploy + +test-job: + stage: test + script: + - echo "Running custom tests..." + - make test + +deploy-job: + stage: deploy + script: + - echo "Deploying to production..." + - make deploy + only: + - master +``` + +### 运行基本的 CI 流程(如构建、测试) + +#### 在管道中定义和运行构建作业 + +构建作业是 CI 流程的核心部分,通常包括编译代码和生成构建产物。以下是一个构建作业的示例: + +```yaml +stages: + - build + +build-job: + stage: build + # 定义构建过程中需要执行的命令。 + script: + - echo "Compiling the code..." + - make + # 定义构建产物的路径,供后续作业使用。 + artifacts: + paths: + - build/ +``` + +#### 集成单元测试和集成测试 + +测试作业用于运行单元测试和集成测试,确保代码的正确性。以下是一个测试作业的示例: + +```yaml +stages: + - test + +# 运行单元测试 +unit-test-job: + stage: test + script: + - echo "Running unit tests..." + - make test-unit + +# 运行集成测试 +integration-test-job: + stage: test + script: + - echo "Running integration tests..." + - make test-integration +``` + +#### 查看和分析测试结果 + +GitLab CI/CD 提供了详细的测试结果报告,帮助开发人员分析和解决问题。 + +1. **查看测试日志**: 在 Pipelines 页面点击具体作业,查看测试的详细日志和输出。 +2. **分析测试结果**: 使用 GitLab 提供的测试报告工具,如 JUnit 报告,查看测试通过率和失败的测试用例。 + +#### 使用 GitLab CI 的代码质量分析功能 + +GitLab CI/CD 提供了代码质量分析功能,帮助识别代码中的潜在问题和改进点。以下是一个代码质量分析的示例: + +```yaml +stages: + - code_quality + +code_quality: + stage: code_quality + script: + - echo "Running code quality checks..." + - eslint . # 使用 ESLint 等工具运行代码质量检查。 + # 生成代码质量报告并存储在 GitLab 中,供后续分析和查看。 + artifacts: + reports: + codequality: gl-code-quality-report.json +``` + +## 进阶技能 + +### 使用 GitLab Runner 执行自定义作业 + +#### 编写和配置自定义作业脚本 + +自定义作业脚本使得 CI/CD 流程能够灵活适应不同的项目需求。通过在 `.gitlab-ci.yml` 文件中定义脚本,可以执行特定任务,例如编译、测试、部署等。以下是一个示例,在 `script` 部分中,可以编写任意 Bash 命令或调用外部脚本文件,以执行具体的任务。 + +```yaml +stages: + - build + - test + - deploy + +build-job: + stage: build + script: + - echo "Compiling the code..." + - make + +test-job: + stage: test + script: + - echo "Running tests..." + - make test + +deploy-job: + stage: deploy + script: + - echo "Deploying to production..." + - make deploy +``` + +#### 在不同执行环境中运行自定义作业 + +GitLab Runner 支持多种执行环境,使得 CI/CD 管道可以在不同的操作系统和容器中运行。以下是一些常见的执行环境配置示例: + +##### Shell 执行环境 + +```yaml +build-job: + stage: build + script: + - echo "Running in shell..." + - make + tags: + - shell +``` + +##### Docker 执行环境 + +```yaml +build-job: + stage: build + image: maven:3.6.3-jdk-8 + script: + - echo "Running in Docker..." + - mvn install +``` + +##### Kubernetes 执行环境 + +```yaml +build-job: + stage: build + script: + - echo "Running in Kubernetes..." + - kubectl apply -f deployment.yaml + tags: + - kubernetes +``` + +#### 利用并行作业和矩阵构建提高效率 + +并行作业和矩阵构建使得多个作业可以同时运行,从而加快 CI/CD 管道的执行速度。以下是并行作业和矩阵构建的示例: + +##### 并行作业 + +```yaml +stages: + - test + +test-job-1: + stage: test + script: + - echo "Running test job 1..." + - make test-1 + +test-job-2: + stage: test + script: + - echo "Running test job 2..." + - make test-2 +``` + +##### 矩阵构建 + +```yaml +stages: + - test + +test-job: + stage: test + script: + - echo "Running tests..." + - make test + parallel: + matrix: + - TEST_ENV: ["python2.7", "python3.6"] + - DB: ["mysql", "postgres"] +``` + +### 使用 GitLab Secrets 进行安全管理 + +#### GitLab CI/CD 中的秘密变量和环境变量管理 + +GitLab 提供了管理秘密变量和环境变量的功能,以确保敏感信息(如 API 密钥、密码等)不会泄露。可以在 GitLab 项目或组的设置中定义这些变量。 + +**定义秘密变量:** + +1. 进入项目设置: Settings -> CI/CD -> Variables +2. 点击 "Add Variable" +3. 输入变量名称和值,并选择保护选项(如保护、掩码) + +#### 在 .gitlab-ci.yml 中安全使用秘密 + +在 `.gitlab-ci.yml` 文件中,可以通过 `${VARIABLE_NAME}` 的形式引用环境变量和秘密变量。通过这种方式,可以确保敏感信息不会暴露在代码库中。 + +```yaml +stages: + - deploy + +deploy-job: + stage: deploy + script: + - echo "Deploying to production..." + - deploy --api-key=${API_KEY} --password=${PASSWORD} +``` + +#### 配置和管理 GitLab 项目和组的秘密 + +GitLab 允许在项目和组级别管理秘密变量,便于多个项目共享相同的配置。 + +##### 项目级变量 + +1. 进入项目设置: Settings -> CI/CD -> Variables +2. 添加或编辑变量 + +##### 组级变量 + +1. 进入组设置: Group Settings -> CI/CD -> Variables +2. 添加或编辑变量 + +### 多阶段管道和依赖管理 + +#### 定义多阶段(multi-stage)管道 + +多阶段管道通过定义不同的阶段(如 build、test、deploy)来组织 CI/CD 流程。以下是一个多阶段管道的示例: + +```yaml +stages: + - build + - test + - deploy + +build-job: + stage: build + script: + - echo "Building the project..." + - make build + +test-job: + stage: test + script: + - echo "Testing the project..." + - make test + +deploy-job: + stage: deploy + script: + - echo "Deploying the project..." + - make deploy +``` + +#### 阶段之间的依赖管理和条件执行 + +**通过定义阶段之间的依赖关系,可以控制作业的执行顺序和条件执行。**例如,可以使用 `needs` 关键字定义依赖关系: + +```yaml +stages: + - build + - test + - deploy + +build-job: + stage: build + script: + - echo "Building the project..." + - make build + +test-job: + stage: test + script: + - echo "Testing the project..." + - make test + needs: ["build-job"] + +deploy-job: + stage: deploy + script: + - echo "Deploying the project..." + - make deploy + only: + - master +``` + +#### 使用 Needs 关键字优化管道执行顺序 + +使用 `needs` 关键字可以显著优化管道的执行顺序,避免不必要的等待时间: + +```yaml +stages: + - build + - test + - deploy + +build-job: + stage: build + script: + - echo "Building the project..." + - make build + +unit-test-job: + stage: test + script: + - echo "Running unit tests..." + - make test-unit + needs: ["build-job"] + +integration-test-job: + stage: test + script: + - echo "Running integration tests..." + - make test-integration + needs: ["build-job"] + +deploy-job: + stage: deploy + script: + - echo "Deploying the project..." + - make deploy + needs: ["unit-test-job", "integration-test-job"] +``` + +### 集成第三方服务(如 Docker Registry、Kubernetes) + +#### 配置和使用 GitLab 内置的 Docker Registry + +GitLab 提供内置的 Docker Registry,方便用户存储和管理 Docker 镜像。以下是配置和使用的步骤: + +1. **启用 Docker Registry**: + + - 进入项目设置: Settings -> CI/CD -> Container Registry + - 确认 Docker Registry 已启用 + +2. **登录 Docker Registry**: + + ```shell + $ docker login registry.gitlab.com + ``` + +3. **构建和推送 Docker 镜像**: + + ```yaml + stages: + - build + - deploy + + build-job: + stage: build + image: docker:latest + services: + - docker:dind + script: + - docker build -t registry.gitlab.com/your-namespace/your-project:latest . + - docker push registry.gitlab.com/your-namespace/your-project:latest + ``` + +#### 在管道中构建和推送 Docker 镜像 + +通过在管道中构建和推送 Docker 镜像,可以实现自动化的容器化部署: + +```yaml +stages: + - build + - deploy + +build-job: + stage: build + image: docker:latest + services: + - docker:dind + script: + - docker build -t registry.gitlab.com/your-namespace/your-project:latest . + - docker push registry.gitlab.com/your-namespace/your-project:latest + +deploy-job: + stage: deploy + script: + - docker pull registry.gitlab.com/your-namespace/your-project:latest + - docker run -d registry.gitlab.com/your-namespace/your-project:latest + only: + - master +``` + +#### 集成 Kubernetes 进行持续部署 + +GitLab CI/CD 可以与 Kubernetes 集成,实现自动化的持续部署: + +1. **配置 Kubernetes 集群**: + + - 在 GitLab 项目的 Kubernetes 集成页面添加集群信息 + +2. **在管道中使用 Kubernetes**: + + ```yaml + stages: + - deploy + + deploy-job: + stage: deploy + script: + - kubectl apply -f deployment.yaml + tags: + - kubernetes + ``` + +#### 使用 GitLab Kubernetes 集群管理工具 + +GitLab 提供了 Kubernetes 集群管理工具,简化集群的配置和管理: + +1. **添加 Kubernetes 集群**: + - 进入项目设置: Operations -> Kubernetes + - 添加集群信息(API URL、CA 证书、Token 等) +2. **管理集群**: + - 使用 GitLab 提供的界面管理集群中的资源,如 Pods、Services 等 + - 配置自动化的 CI/CD 管道,实现持续部署 + +## 高级实践 + +### 持续交付(CD)流程 + +#### 定义和实现持续交付(CD)管道 + +持续交付(CD)是指将代码在经过一系列自动化测试后,自动部署到预生产或生产环境。以下是一个持续交付管道的示例: + +```yaml +stages: + - build # 定义构建阶段 + - test # 定义测试阶段 + - deploy # 定义部署阶段 + +build-job: + stage: build # 指定作业所属的阶段 + script: + - echo "Building the project..." + - make build + artifacts: + paths: + - build/ # 保存构建产物供后续使用 + +test-job: + stage: test # 指定作业所属的阶段 + script: + - echo "Running tests..." + - make test + dependencies: + - build-job # 使用构建阶段的产物 + +deploy-job: + stage: deploy # 指定作业所属的阶段 + script: + - echo "Deploying to production..." + - make deploy + only: + - master # 仅在 master 分支上执行部署 + environment: + name: production # 部署环境名称 + url: https://production.example.com # 部署环境的 URL + +``` + +#### 配置环境部署策略 + +GitLab 提供了丰富的环境和部署策略配置选项,确保部署过程的安全性和稳定性。 + +##### 动态环境 + +用于临时创建环境,进行测试或演示。 + +```yaml +environment: + name: review/$CI_COMMIT_REF_NAME + url: https://$CI_COMMIT_REF_NAME.example.com + on_stop: stop_review +``` + +##### 手动部署 + +需要手动确认才能执行部署。 + +```yaml +deploy-job: + stage: deploy + script: + - echo "Deploying to production..." + - make deploy + when: manual +``` + +#### 使用 GitLab 的环境和部署管理功能 + +GitLab 提供环境和部署管理功能,帮助开发者和运维人员轻松管理不同的部署环境。 + +- **查看环境状态**: 在项目的 Environments 页面查看所有环境的状态和部署历史。 +- **手动触发部署**: 在 Environments 页面手动触发部署任务。 +- **环境保护**: 配置环境保护规则,限制谁可以部署到特定环境。 + +#### 回滚和部署策略优化 + +部署过程中可能会遇到问题,需要回滚到之前的版本。可以通过以下方式实现回滚和优化部署策略: + +**自动回滚**: 在部署失败时自动回滚到上一个稳定版本。 + +```yaml +deploy-job: + stage: deploy + script: + - echo "Deploying to production..." + - make deploy || make rollback +``` + +- **蓝绿部署**: 同时运行两个版本的应用,切换流量以实现无缝升级。 + +- **金丝雀发布**: 部分用户先访问新版本,观察其稳定性,然后逐步扩展。 + +### 使用缓存和 Artifacts 提高构建效率 + +#### 配置和使用缓存加速构建过程 + +缓存可以显著加快构建过程,通过缓存依赖和构建中间结果,减少重复工作。 + +##### 配置缓存 + +```yaml +cache: + paths: + - .m2/repository + - node_modules/ +``` + +##### 清理缓存 + +在需要时清理缓存以确保使用最新的依赖。 + +```yaml +cache: + key: "$CI_COMMIT_REF_SLUG" + paths: + - .m2/repository + policy: push +``` + +#### 定义和管理 Artifacts + +Artifacts 是管道运行过程中生成的文件,通常用于后续阶段或作为构建产物存储。并在 GitLab 界面查看和下载 artifacts。 + +```yaml +artifacts: + paths: + - build/ +``` + +#### 优化缓存和 Artifacts 的存储策略 + +为了更好地利用缓存和 artifacts,优化存储策略非常重要。 + +##### 按分支缓存 + +不同分支使用不同的缓存,避免相互影响。 + +```yaml +cache: + key: "$CI_COMMIT_REF_NAME" + paths: + - .m2/repository +``` + +##### 长期存储 + +重要的构建产物可以配置长期存储,避免被清理。 + +```yaml +artifacts: + paths: + - build/ + expire_in: 1 month +``` + +### 部署到 Kubernetes 和其他云平台 + +#### 使用 GitLab CI/CD 管道部署到 Kubernetes 集群 + +将应用部署到 Kubernetes 集群,可以利用其强大的容器编排和管理能力。 + +**配置 Kubernetes 集群**: + +1. 在 GitLab 项目的 Kubernetes 集成页面添加集群信息。 +2. 配置 `kubeconfig` 文件,用于访问 Kubernetes 集群。 + +```yaml +stages: + - deploy + +deploy-job: + stage: deploy + script: + - kubectl apply -f k8s/deployment.yaml + - kubectl apply -f k8s/service.yaml + tags: + - kubernetes +``` + +#### 配置和使用 GitLab 的 Auto DevOps 功能 + +Auto DevOps 是 GitLab 提供的自动化 CI/CD 流程,适用于常见的开发场景。启用 Auto DevOps 后,GitLab 会自动检测并运行合适的 CI/CD 管道。 + +- **启用 Auto DevOps**: + 1. 在项目设置页面启用 Auto DevOps。 + 2. 配置 Kubernetes 集群和相关的 CI/CD 设置。 +- **定制 Auto DevOps**: 可以通过自定义 `.gitlab-ci.yml` 文件来扩展和定制 Auto DevOps 流程。 + +#### 集成其他云平台进行部署 + +通过 GitLab CI/CD 管道,可以将应用部署到各种云平台。 + +##### 部署到 AWS + +```yaml +stages: + - deploy + +deploy-job: + stage: deploy + image: amazon/aws-cli + script: + - aws s3 cp build/ s3://my-bucket/ --recursive + only: + - master +``` + +##### 部署到 GCP + +```yaml +stages: + - deploy + +deploy-job: + stage: deploy + image: google/cloud-sdk + script: + - gcloud auth activate-service-account --key-file $GCP_KEY_FILE + - gcloud app deploy + only: + - master +``` + +##### 部署到 Azure + +```yaml +stages: + - deploy + +deploy-job: + stage: deploy + image: mcr.microsoft.com/azure-cli + script: + - az login --service-principal -u $AZURE_CLIENT_ID -p $AZURE_CLIENT_SECRET --tenant $AZURE_TENANT_ID + - az webapp up --name myapp --resource-group myResourceGroup --location "East US" + only: + - master +``` + +### 性能优化和故障排查 + +#### 优化管道执行时间和资源使用 + +通过以下方法可以优化 CI/CD 管道的执行时间和资源使用: + +- **并行执行**: 将作业并行化,减少整体执行时间。 +- **缓存利用**: 使用缓存减少重复工作。 +- **按需执行**: 使用 `only` 和 `except` 关键字控制作业执行条件。 + +#### 监控和分析管道性能指标 + +GitLab 提供了多种监控和分析工具,帮助优化管道性能: + +- **Pipeline Analytics**: 查看管道执行时间和成功率等指标。 +- **Job Artifacts**: 分析作业的日志和生成的报告。 +- **GitLab CI/CD Monitoring**: 使用外部监控工具(如 Prometheus、Grafana)集成 GitLab 的 CI/CD 监控。 + +#### 常见错误和问题的排查方法 + +常见错误包括作业失败、超时、依赖问题等。排查方法如下: + +- **查看日志**: 详细查看作业日志,分析错误信息。 +- **重试作业**: 对于临时性问题,可以尝试重试作业。 +- **环境检查**: 确认执行环境的配置和依赖是否正确。 + +#### 使用 GitLab CI/CD 的调试和日志功能 + +GitLab CI/CD 提供了丰富的调试和日志功能,帮助定位和解决问题: + +- **Debug 作业**: 在 `.gitlab-ci.yml` 中添加调试信息。 + + ``` + script: + - echo "Debug info:" + - env + - make test + ``` + +- **查看作业日志**: 在 GitLab 界面查看详细的作业执行日志。 + +- **使用 SSH 访问 Runner**: 在调试模式下使用 SSH 访问 Runner,进行更深入的调试。