layout-3 - NVIDIA 文档layout-6 - NVIDIA 文档layout-1 - NVIDIA 文档layout-top - NVIDIA 文档
NVIDIA 文档中心chevron_right NVIDIA 网络chevron_right 网络软件chevron_right

技术指南

layout-top - NVIDIA 文档layout-6 - NVIDIA 文档layout-1 - NVIDIA 文档

定制生产就绪型自动化

本节提供关于如何定制和调整 Cumulus 生产就绪型自动化的主要组成部分，以适应您自身的需求并在您自己的环境中工作的指导。

构建一个代表您生产网络的模拟是利用下一代 NetDevOps 风格操作工作流程的第一步。理想情况下，您在网络更改到达生产环境之前，在模拟环境或暂存环境中测试所有网络更改。Cumulus VX 是一个极其轻量级且高保真的模拟平台。凭借小内存占用和与硬件上运行的 Cumulus Linux 完全相同的每个软件组件，您可以构建一个高度可扩展且稳健的模拟环境，该环境与生产环境相匹配，从接口标签到 MAC 地址。

Cumulus 生产就绪型自动化的这些主要功能相互依赖，以提供完全可操作的自动化数据中心

  • 基础模拟是 NVIDIA 参考拓扑模拟；跨许多不同可能的解决方案架构重用的通用基础拓扑。

  • 提供基础设施即代码 (IaC) 的自动化使您可以将网络配置的编码版本存储在源代码存储库中。NVIDIA 生产就绪型自动化使用 Ansible 作为其自动化引擎，并应用 Ansible 最佳实践，包括使用角色、Jinja2 模板和结构化变量文件。完整的 Ansible 配置包括 playbook、角色、模板、变量和清单。

  • 持续集成和持续部署 (CI/CD)的基础在于您可以随时随地频繁进行更改的想法。但是，在您可以集成更改以部署到生产环境之前，您必须进行测试以确保更改不会导致意外后果。在测试通过并且您从持续集成 (CI) 阶段集成更改后，您可以自动执行持续部署 (CD) 阶段。对于网络，这意味着您可以将通过自动化测试的更改自动部署到生产环境。自动化持续部署对于网络运营来说仍然不常见。

    NVIDIA 强烈建议您部署 CI 策略，但不建议使用 CD 策略。使用 CD 可能会在关键业务时间导致网络更改，并带来意外的后果。仅当您的组织拥有适当的测试和运营流程时，才考虑 CD。

系统要求

对于具有 GitLab 的稳健模拟环境和 CI/CD，NVIDIA 建议使用专用的、始终开启的企业级服务器。

在各个开发环境中使用 NetQ 服务器不是必需的，通常仅在 CI 测试中才需要，您在 CI 测试中安装了 GitLab Runner 并将其注册到启用了 CI/CD 的项目中。

硬件要求

  • 内存要求各不相同。要估算您的模拟需求，请使用以下值
    • 每个 Cumulus Linux 节点 768MB
    • 每个 Ubuntu 18.04 主机 512MB
    • oob-mgmt-server 1024MB
    • oob-mgmt-switch 768MB
    • netq-ts 8192MB
  • 磁盘要求各不相同。Vagrant 和 libvirt 使用精简磁盘映像，但一个好的参考点是
    • 256GB 磁盘，具有 64GB 或更多的可用内存
    • 建议使用 1TB 或更大的磁盘
    • 建议使用 SSD（NetQ 要求）
  • 高速宽带或宽带互联网连接，用于在模拟启动期间安装软件包
  • 至少八个 x86_64 CPU 核心

软件要求

  • 操作系统
    • Cumulus Linux 3.7.11 或更高版本
    • Cumulus NetQ 2.4 或更高版本（可选）
    • Ubuntu 16.04 或 18.04（NVIDIA 未测试过其他 Linux 发行版）
  • 软件包
    • Vagrant 2.2.4 或更高版本
    • Libvirt
    • Qemu
    • Git
  • Vagrant 插件
    • Vagrant-libvirt
    • Vagrant-scp

要查看用于安装软件包和环境依赖项的示例 bash 脚本，请参阅 示例安装脚本。

CI/CD 要求

  • 一个 GitLab.com 帐户或您自己的内部 GitLab 实例
  • 用于 GitLab Runner 启动和测试模拟的专用模拟环境
  • 安装在模拟主机上的 GitLab Runner 软件包（在系统上设置 GitLab Runner 用户和环境）
  • GitLab 实例上设置的项目，其中包含模拟、自动化和 IaC
  • 具有专门用于模拟的场所/站点的 NetQ Cloud 帐户

黄金标准演示项目的剖析

生产就绪型自动化的这些主要功能（基础模拟、自动化和 IaC 以及 CI/CD）相互依赖，以提供完全可操作的自动化数据中心。在 NVIDIA 官方黄金标准演示存储库中，重要的文件和文件夹按如下方式映射到三个主要功能

dc_configs_vxlan_evpnsym/
├── automation
├── cldemo2
│   ├── ci-common
│   ├── documentation
│   ├── LICENSE
│   ├── README.md
│   ├── simulation
│   └── tests
├── .git
├── .gitignore
├── .gitlab-ci.yml
├── LICENSE
├── README.md
├── start-demo.sh
└── tests

文件和文件夹描述

文件/文件夹
描述
自动化包含支持 Ansible 自动化和 IaC 的所有必需文件。
cldemo2/ci-common包含所有官方支持的黄金标准演示项目中 CI/CD 通用的通用脚本。gitlab-ci.yml 文件调用的所有在 CI 管道中执行工作的脚本都存在于此处。
simulation包含支持基础 NVIDIA 参考拓扑模拟的所有必需文件。这是 topology_converter、Vagrantfile 以及基础参考模拟拓扑的所有关联配置脚本所在的位置。
.git包含 Git 项目数据和配置。这是配置即代码的一部分，不需要修改或定制。Git 命令查找此目录以对项目文件执行工作。如果您要创建自己的自定义项目，请删除此文件夹或在 GitLab 中 Fork 该项目。
.gitignore告知 Git 要忽略哪些文件以及不作为项目的一部分跟踪哪些文件。这包括 simulation 目录内的 .vagrant 目录以及其他不实用或不打算作为项目源代码一部分的动态运行时文件。
注意：不在 .gitignore 文件中包含 .vagrant 目录可能会导致 Git 存储库不必要地过大。
.gitlab-ci.yml定义 GitLab CI 的 CI 管道阶段和作业。这是一种配置文件。Cumulus Linux 黄金标准项目中提供的示例是关于如何建模您自己的 CI 管道的起点和参考。有关更多信息，请参阅 GitLab CI 文档。
tests包含项目的 CI 测试脚本。这些脚本被复制到模拟环境中并在模拟环境内部运行。每个项目和演示都有唯一的一组测试，因此 CI 此阶段的脚本从其余通用 CI 脚本中分离出来，并保持项目独有。

这些演示模拟为如何组织您自己的项目提供了良好的基础。NVIDIA 参考拓扑为跨许多不同可能的解决方案架构重用提供了通用的基础拓扑。因此，Git 子模块包含具有自动化存储库的基础参考拓扑，以便它可以将所有内容打包在一起。对于真实世界的部署，不太可能需要或使用 Git 子模块。在不使用子模块的情况下，将 simulation 文件夹和 ci-common 文件夹放在项目根目录下而不是子文件夹内更有意义。子模块功能需要额外的 cldemo2 文件夹。

如果您不使用 Git 子模块，则需要更改 .gitlab-ci.yml 文件和 ci-common 脚本中的硬编码相对路径，以排除 cldemo2 子文件夹。

定制模拟

构建自定义模拟是转换和自动化您的网络和运营的基础。您可以使用 topology_converter 工具自动生成自定义 Vagrant 和 libvirt 拓扑。

topology_converter 处理构建、生成和维护 Vagrantfile 的复杂性。它生成 Vagrantfile 并随之带来每个关联的引导配置脚本，以提供执行简单 vagrant up 并拥有已连接的网络模拟以接收进一步网络配置的体验。

NVIDIA 不建议您手动编辑和维护原始 Vagranfile。始终使用 topology_converter 工作流程来更改 Vagrantfile。

有关 topology_converter 实用程序的详细信息以及关于如何构建 .dot 文件的详细说明，请参阅 topology_converter GitLab 项目和文档。

以下是创建自定义 Cumulus VX 拓扑所需的高级步骤

  1. 考虑如何处理带外管理。最简单的选择是使用自动网络管理。为了更准确地表示您的生产网络，您可以在 topology.dot 文件中创建带外管理网络。

  2. 创建 topology.dot 文件。确保内容采用 Graphviz 格式和语法。使用 NVIDIA 参考拓扑项目中的 cldemo2.dot 文件作为模板，以定义您自己的网络节点、属性和链接集。

  3. 将所有 topology_converter 项目文件和您的自定义 topology.dot 文件放在项目的 simulation 文件夹中。运行 git clone 命令以获取所有 topology_converter 项目文件。

  4. 从您的拓扑定义创建 Vagrantfile。确保您指定 -p libvirt 选项。如果您使用自动网络管理，则必须在 topology_converter 中指定 -c 选项。例如

    python3 ./topology_converter.py ./topology.dot -c -p libvirt

定制自动化和 IaC

NVIDIA 提供了一个可扩展和可扩展的框架，用于存储或编码数据中心网络配置并使用 Ansible 自动化进行部署。IaC 使您可以将网络配置视为源代码的一种形式，就像在软件开发领域中一样。

在软件上下文中，您构建代码以生成特定于运行它的操作系统和 CPU 架构的二进制文件或可执行文件。编译器将高级人类可读代码呈现为机器可以理解的格式。在网络上下文中，最终构建产品需要是在网络设备上运行的它们可以理解的平面配置文件。用于部署到网络的自动化引擎通常驱动基础 IaC 代码的外观。对于使用 Ansible 的 NVIDIA 生产就绪型自动化，配置即代码示例是自动化文件夹中 jinja2 模板和结构化变量文件的组合。在使用 Ansible 进行部署期间，它会使用结构化变量文件中的值填充模板。从模板和变量生成最终配置的过程通常称为呈现配置。在 Ansible 部署期间呈现配置类似于在软件开发中将源代码编译和链接到可执行文件的过程。

您有许多方法可以实现网络配置或基础设施即代码。平面配置文件是代码的一种形式，因此 IaC 最原始的版本是存储设备配置文件的副本。这个原始示例甚至可以进行自动化部署；使用您的自动化工具将平面配置文件从中央存储库推送到设备。这是实现自动化和 IaC 的一种方法，但没有意识到解决方案的许多规模和效率优势。在此示例中，配置文件仍然是单独修改的，每个设备一个。

修改 Cumulus 生产就绪型自动化的各个方面以满足您的独特需求需要深入了解超出本指南范围的底层技术，例如 Ansible 和 Ansible 角色、jinja2 模板引擎以及使用 YAML 构造和表示数据的基本知识。Cumulus 专业服务可以帮助您完成此过程。请联系您的销售代表以获取更多详细信息。

有关 Ansible 和角色的信息，请参阅 Ansible 用户指南。

定制 CI/CD

在成功实施您的 IaC 版本并应用自动生成网络代码构建以进行自动化测试和验证的概念之后，CI/CD 是下一个逻辑步骤。

Cumulus 生产就绪型自动化使用 GitLab 进行 CI/CD。有关 GitLab CI 的信息，请参阅 GitLab CI/CD 文档。

  • 大多数 CI/CD 指南和参考资料都使用经典的软件开发 CI 工作流程作为背景。NVIDIA CI/CD 的用例是将网络模拟构建为代码的产品，这是一个特殊情况。
  • 大多数基于云的 CI 工具都在容器内运行，并且不支持运行 Cumulus VX。
  • 使用 Vagrant 和 libvirt 的 NVIDIA 生产就绪型自动化每个 GitLab 项目仅支持单个 GitLab Runner。

CI 管道包含按顺序执行或以管道方式连接（一次一个，按顺序直到完成）的阶段。CI 阶段由一个或多个可以并行执行的作业组成。作业是您设计和配置为通过或失败的单独 CI 任务。名为 GitLab Runner 的软件执行 CI 作业。

GitLab Runner

GitLab Runner 是您安装在服务器上的代理，作为专用模拟主机，用于为您的项目运行 CI/CD 的模拟和测试。GitLab Runner 的安装方式与其他软件包相同，并使用唯一的注册令牌连接并注册到您的 IaC 的 GitLab 项目。

在您将 GitLab Runner 注册到项目后，它会定期向 GitLab.com CI 作为服务轮询出站，以查看是否有任何需要运行的排队作业。如果找到作业，它将根据 gitlab-ci.yml 文件执行。

GitLab Runner 使用 shell 执行器类型。构建网络模拟和繁重的系统要求有一组独特的依赖项；因此，NVIDIA 要求为项目使用专用 Runner。您可以使用本机 bash 脚本来驱动 CI 作业。

分支策略

GitLab CI 管道动态构建，然后在您将代码推送到远程存储库（通常是 GitLab.com）时执行。不同版本的代码可以存在于不同的分支上，因为更改向上游移动到 master，并且您可以独立且唯一地控制项目中每个分支的 CI 管道。每个分支定制管道的这种能力允许在您将更改合并到上游分支时使用不同的自动化工作流程。有关 GitLab 流最佳实践的介绍，请参阅GitLab 流简介。

NVIDIA 建议以下分支策略作为简单的起点

  • master 分支表示当前部署在网络上的内容。针对此分支运行的管道可以部署到您的实时网络。这就是 CD。
  • 开发或暂存分支 (dev) 表示部署到暂存或开发网络并经过彻底测试的更改。
  • 源自 dev 分支的私有或工作分支是操作员执行其工作的位置。分支通常表示针对共同目的的更改或一组更改。例如，用于跟踪每个更改请求单的更改的分支与现有的更改控制工作流程很好地对应。在工作完成后，这些分支将合并回 dev 分支。

示例工作流程指南

  • 所有操作员都必须有权访问开发环境，在开发环境中他们可以启动自己的私有网络模拟版本，以执行其工作和本地单元测试。
  • （可选）操作员可以为其 CI 测试阶段开发测试脚本，以检查特定更改。
  • 所有操作员都从 dev 分支开始工作（克隆）。
  • 所有操作员都在其私有或工作分支中执行其所有工作。
  • 在操作员完成更改后，他们将其工作分支合并到 dev 分支中。
  • 在合并到 dev 后，CI 管道将运行以基于 dev 分支中的当前代码（包括来自合并的更改）构建、部署和测试网络。
  • 仅在 CI 管道成功且所有测试通过后，才将 dev 合并到 master 分支中。
  • 将代码从 master 分支部署到实时网络。

在 NVIDIA 生产就绪型自动化示例中手动执行最后一步。从 master 分支 CI 管道自动化部署到实时网络是完全自动化的启用 CI/CD 的网络运营工作流程的完全实现。在完全自动化的工作流程中，只有 CI 管道在合并到 master 时才对实时网络进行部署。由于强大的自动化测试以及针对 dev 分支的测试的通过结果，合并到 master 也是自动的。

完全自动化部署到实时生产网络并不常见。这是 CI/CD 范例的持续交付组件。大多数网络运营商仍然更喜欢将批量更改排队，并在定期计划中从 master 分支手动部署到实时网络。

安装和注册 GitLab Runner

所有作业都以 GitLab Runner 用户身份在服务器和环境中运行。至少在该用户下对您的 GitLab Runner 服务器执行一些手动测试和 CI 的初始开发，因为某些 vagrant 插件可能因用户而异。

请参阅示例安装脚本以查看涵盖基线依赖项的基本 shell 脚本。

  1. 安装 GitLab Runner 软件。

  2. 创建 GitLab Runner 用户并设置用户环境

    1. 以 root 用户身份，将 GitLab Runner 用户添加到 libvirtd 组
    user@host:~# adduser gitlab-runner libvirtd

    1. 切换到 GitLab Runner 用户

      user@host:~# sudo su - gitlab-runner

    2. 将 /usr/sbin 附加到 $PATH 变量并将其放入 .bashrc

      user@host:~# echo 'PATH=/usr/sbin:$PATH' >> ./.bashrc

    3. 安装 GitLab Runner 用户运行 CI 作业所需的 vagrant 插件

      user@host:~# vagrant plugin install vagrant-libvirt vagrant-mutate vagrant-scp

  3. 找到您的项目的 GitLab Runner 注册令牌。您可以在 GitLab.com 上找到您的项目的注册令牌。在左侧面板上，浏览设置 -> CI/CD，然后展开Runner 部分。向下滚动到手动设置特定 Runner 部分。注册令牌在步骤 3 中。它看起来类似于这样：zLZLhVDkfJPq7eWXV6rw

  4. 执行 GitLab Runner 注册。GitLab Runner 注册参数为

    GitLab 参数设置
    Gitlab-ci 协调器 URLhttps://gitlab.com
    Gitlab-ci 令牌来自上面的步骤 3。
    此 runner 的 Gitlab-ci 描述此服务器的任何信息性描述。
    Gitlab-ci 标签无。留空。按回车键。
    执行器shell
    user@host:~# gitlab-runner register
Runtime platform                         arch=amd64 os=linux pid=143019 revision=4c96e5ad version=12.9.0
Running in system-mode.

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
https://gitlab.com
Please enter the gitlab-ci token for this runner:
<Registration-token-from-step#3>
Please enter the gitlab-ci description for this runner:
[host]: <any-description-here>
Please enter the gitlab-ci tags for this runner (comma separated):
<Leave this blank! Just press enter here for NO TAGS>
Registering runner... succeeded                     runner=qfzmHDDk
  Please enter the executor: docker+machine, parallels, virtualbox, docker-ssh, shell, ssh, docker-ssh+machine, kubernetes, custom, docker:
shell
Runner registered successfully. Feel free to start it, but if it is running already the config should be automatically reloaded!

  5. 启动 GitLab Runner

    user@host:~# gitlab-runner start
Runtime platform                    arch=amd64 os=linux pid=145596 revision=4c96e5ad version=12.9.0
user@host:~#

  6. 在 GitLab.com 上确认 runner 状态。在 GitLab.com 上的项目中，浏览左侧面板上的 设置|CI/CD，然后展开Runner 部分。向下滚动到为此项目激活的 Runner 部分。检查以确保您注册的 runner 在此列表中，并带有绿色就绪指示器。

Gitlab CI 变量

GitLab CI 提供了许多内置环境变量，用于 CI 脚本中。有关 GitLab 提供的所有可用变量的列表，请参阅预定义变量。

包含的 ci-common 和 test 脚本依赖于以下内置变量

$CI_COMMIT_SHORT_SHA
$CI_COMMIT_BRANCH
$CI_PROJECT_NAME

GitLab 还提供了一种方法，供您为该项目的 runner 定义自定义环境变量。要查看、更改或添加变量，您需要对项目具有开发人员或维护者权限，并且可以访问项目设置。

由于 NetQ 安装需要唯一的配置和访问密钥，因此这些密钥作为掩码变量与 GitLab 项目一起存储（您可以将密钥配置为仅在受保护的分支上有效）。这些变量在 NetQ 配置 CI 作业期间被调用，以允许在自动化 CI 管道中以编程方式配置 NetQ。

最佳实践是在 NetQ Cloud 用户管理中配置专用或虚拟 CI 和 CLI 用户。这允许从此帐户生成的访问密钥和密钥更易于处理，以防您需要撤销或更改它们。有关设置 NetQ 用户和生成身份验证密钥以与启用 CI/CD 的 GitLab 项目一起存储的更多信息，请参阅NetQ 文档。

如果您想使用未经修改的参考 ci-common 和 test 脚本，请在 GitLab 中项目的 设置|CI/CD|变量 区域中配置以下变量

变量名称描述
CONCURRENCY_ID一个整数值，用于帮助模拟主机支持并发项目的并发模拟。如果您的 GitLab Runner 支持可以并发运行模拟的多个项目，则必须指定此变量。
例如
1
NETQ_ACCESS_KEY从 NetQ Cloud 用户管理页面生成的有效访问密钥。
例如
bf5802fd59456d7be723d85f99c303b5c943c536f75b86e1da8fb94a48a18dfa
NETQ_BOOTSTRAP_TARBALLnetq-ts 上 NetQ 引导程序 tarball 的 URL。有关更多信息，请参阅NetQ 文档。由于路径中存在斜杠字符 (/)，您必须将此变量以 base64 编码格式存储在 GitLab 中。
例如
L21udC9pbnN0YWxsYWJsZXMvbmV0cS1ib290c3RyYXAtMi40LjEudGd6
NETQ_CONFIG_KEY来自 Cumulus NetQ Cloud Onboarding 流程电子邮件的用于 CI 和模拟的专用场所的配置密钥。
例如
CXx0Dh1zY3XucHJXZDMubmV0cx5jdX11bHVzbmV0d29Ya3MuYd9tGLsD
NETQ_OPTA_TARBALLNetQ OPTA 安装 tarball 的 URL。由于路径中存在斜杠字符 (/)，您必须将此变量以 base64 编码格式存储在 GitLab 中。
例如
L21udC9pbnN0YWxsYWJsZXMvTmV0US0yLjQuMS1vcHRhLnRneg==
NETQ_PREMISE_NAME此专用 CI/CD 模拟环境的场所名称字符串。
例如
netq-demo-dc-6
NETQ_SECRET_KEY关联的访问密钥的有效密钥，也随附提供。仅在 NetQ Cloud 用户管理中生成时可用一次。
例如
hxXoSwlcJqKVyu7V/FT7eHpSKrz4jKIr15OMX9Z9MTI=

定制 CI 管道

GitLab CI 使用项目文件中的配置文件来定义管道。管道由一系列顺序阶段组成。一个阶段包含一个或多个可以并行运行的作业。.gitlab-ci.yml 文件定义了阶段、作业、每个作业中发生的事情以及阶段执行的顺序。

网络即代码的 CI/CD 与传统的软件代码工作流程略有不同。NVIDIA 首先构建和配置代表生产环境的模拟网络。从头开始构建模拟是当前用于黄金标准配置的范例。在创建新的模拟后，部署包含更改的 IaC。然后，使用这些更改，测试阶段开始以确保网络满足您的需求。如果所有配置、部署和测试都成功，您可以确信，在生产设备上，相同的过程也会获得相同的成功。

也可以为始终在线模式下的模拟环境构建 CI/CD 管道，其中暂存和开发模拟不会在每次管道运行后销毁。但是，这会带来额外的挑战，例如在运行失败后回滚完整性。

示例 GitLab CI 阶段

阶段描述
lint执行基本的 YAML 语法检查，以帮助捕获可能导致后续阶段失败的基本语法和格式错误，并确保良好的格式。
准备模拟环境为管道阶段的其余部分准备环境。检查后续阶段中 CI 管道作业的特殊依赖项，并在此阶段选择性地安装或修复。
带外管理启动启动带外管理网络中的设备（oob-mgmt-server、oob-mgmt-switch 和 netq-ts）。此阶段还将演示项目中的 automation 文件夹和 tests 文件夹复制到 oob-mgmt-server 和 netq-ts。automation 文件夹包含配置网络的 Ansible playbook、角色和清单。tests 文件夹包含稍后在 test simulation 阶段中使用的测试脚本。
网络启动由两个彼此不相关的作业组成，可以并行运行（如果您为 GitLab Runner 配置了足够多的 worker）以帮助加快管道运行速度。network bringup 作业使用 vagrant 构建带外管理网络之外的其余模拟网络。NetQ 配置作业步骤简单，但耗时最长。此阶段从其两个组件 tarball 文件安装 NetQ Cloud。首先启动带外管理网络，使您可以在创建和构建其余网络的同时立即开始配置 NetQ Cloud 服务器。
配置模拟在 oob-mgmt-server 上运行 Ansible playbook，以使用对分支所做的更改来配置网络。
测试模拟由两个并行运行的作业组成。您使用 NetQ 执行测试，然后从 oob-mgmt-server 执行其他网络测试。
清理模拟清理下一个模拟的 NetQ Cloud 场所并销毁模拟。

通用过程

使用 GitLab CI，.gitlab-ci.yml 文件描述 CI 管道、其作业以及每个作业的作用。本节介绍如何重用 NVIDIA 生产就绪型自动化软件包中的 .gitlab-ci.yml 文件以供您自己使用。

包含的示例 .gitlab-ci.yml 文件是专门创建和定义的，用于将每个作业的复杂逻辑与管道和作业定义分开。在 .gitlab-ci.yml 示例中，每个作业都有一行 script: 行。每个 script: 行都是对另一个 shell 脚本的调用。这使得 .gitlab-ci.yml 文件更整洁、更清晰，并且更容易开始使用。

使用来自黄金标准演示拓扑之一的 .gitlab-ci.yml 文件作为你的 .gitlab-ci.yml 文件的起点。来自 NVIDIA 参考拓扑 (cldemo2) 的 .gitlab-ci.yml 文件不包含调用 Ansible playbook 来部署网络配置的 provision 阶段。

GitLab 上的示例使用 git submodules 来打包基础 CI/CD 脚本和 NVIDIA 参考拓扑本身 (Vagrantfile)。这仅仅是出于重用的需要，但在生产网络中，你可以将所有这些都打包在同一个项目中。除非你在多个项目之间共享代码，否则 NVIDIA 不建议使用 submodule。

当项目中未使用 Git submodules 时，你可以删除作业中的 variables: 键，该键仅在项目使用 submodule 时才需要。例如

prep:
  stage: prep simulation environment
  variables:
    GIT_SUBMODULE_STRATEGY: recursive
  script:
    - bash ./cldemo2/ci-common/prep.sh
  only:
    - /^dev.*$/

如下修改上述 YAML 输出

prep:
  stage: prep simulation environment
  script:
    - bash ./cldemo2/ci-common/prep.sh
  only:
    - /^dev.*$/

如果你的项目未使用任何 submodule，则在使用 .gitlab-ci.yml 示例时，请为每个作业删除这两行。

对于 .gitlab-ci.yml 文件中定义的每个作业，检查 script: 行以确保每个 shell 脚本的路径正确。在发布的 Production Ready Automation 示例中，shell 脚本的路径位于 cldemo2 submodule 内部。

将 CI/CD 添加到你现有的 GitLab 项目

以下步骤提供了关于如何通过为每个作业调用离散且模块化的 bash 脚本，为你的项目实施和启用 CI 的高级概述

  1. 规划一台永久专用的 GitLab Runner 模拟主机。查看系统要求和软件包依赖项。
  2. 安装 GitLab Runner 和软件包依赖项（请参阅示例安装脚本）。
  3. 将 GitLab Runner 注册到项目。暂停项目中的 GitLab Runner，直到其余支持 CI/CD 的脚本就位。禁用项目的共享和公共 runners。
  4. 评估示例 CI 管道设计和阶段。使用 .gitlab-ci.yml 文件作为示例。
  5. 将你的 .gitlab-ci.yml 文件放在项目的根目录中。
  6. 从你的 .gitlab-ci.yml 文件中确定每个作业所需的 CI 脚本。
  7. 创建一个文件夹来包含你的 CI 作业的 CI 脚本。这是 cldemo2 项目中的 ci-common 脚本目录。
  8. 在你的项目的 CI scripts 文件夹中，填充由 .gitlab-ci.yml 文件作业调用的脚本（在 script: 块中）。
  9. 恢复项目中的 GitLab Runner，并通过提交和推送到你的项目来开始测试你的 CI 管道。

    版权所有 © 2025  NVIDIA 公司