今年 5 月 F5 完成对 NGINX 的收购后，工程部门的首要任务之一是整合控制平面开发团队并采用一套通用工具。在这篇文章中，我描述了我们对代码存储库、开发管道和工件存储所做的更改。
收购之前，NGINX Controller 团队的工具套件包括用于代码存储库的 GitHub、用于开发管道的 Jenkins，以及用于工件存储的 Nexus Repository Manager OSS、Docker Registry 和 Amazon S3。 F5 的控制平面团队使用 GitLab 及其内置持续集成功能 (GitLab CI) 来处理代码存储库和管道，并使用 JFrog Artifactory 来处理所有工件。
我们看到了为整个控制平面团队采用 F5 技术堆栈的巨大价值。首先，它比 NGINX 控制器团队使用的堆栈更简单。二、公司IT团队对其进行管理，使 DevOps 团队免于处理基础设施。
移动代码存储库
第一步是将 NGINX 控制器代码存储库从 GitHub 移至 GitLab。事实证明这很简单，只需要一些脚本化的 git 克隆和 git 推送操作。我们能够保留在 GitHub 中使用的所有分支规则和合并检查。
转换为 GitLab 管道
这是最重要的一步，因为它使集成工程团队能够构建、测试和发布代码。
我们在用 Jenkins 领域特定语言 (DSL) 编写的 Jenkinsfiles 中定义了 NGINX 控制器的管道。不过，我们试图通过以下方式使它们尽可能与 Jenkins 无关：
- 尽可能将机密存储在 HashiCorp Vault 中
- 限制插件的使用
- 在管道中显式运行大多数命令，无需包装器
- 使运行成为可能所有作业都以与 Jenkins 服务器上相同的方式在开发人员的笔记本电脑上进行本地处理
将 Jenkinsfile 转换为 GitLab CI 管道的过程主要是创建与 Jenkins 工作人员匹配的 GitLab Runner，并通过复制之前管道中的命令来创建具有相同阶段的管道。
最大的任务是将 Jenkins 环境变量更改为 GitLab CI 变量并验证所有路径和文件位置。为了避免这样做，我建议始终将路径表示为变量。我知道这是显而易见的，但有时我们会为了速度而牺牲最佳实践。
这是我们的 Jenkinsfile 阶段之一的示例：
阶段（’测试和PushToReg’）{
环境 {
NODE_ENV = ‘生产’
}
脚步 {
嘘”’
VERSION=$(git tag –contains | head -1 | tr -d v )
CTR_VERSION=${VERSION} gulp 构建
”’
sh “PLUGIN_NAME=NAME1纱线 webpack-cli –config webpack/platform/plugin.js”
sh “PLUGIN_NAME=NAME2 纱线 webpack-cli –config webpack/platform/plugin.js”
sh“docker build -t /${BRANCH}:${BUILD_NUMBER} -f docker/Dockerfile 。”
sh“回显’运行单元测试’”
sh“纱线测试”
存储包括：’test-results.xml’，名称：’utest’，allowEmpty：true
sh“码头工人推……”
}
}
这已翻译为以下 Gitlab CI 代码：
构建测试发布FE：
阶段：构建_测试_发布
图片：${BUILD_IMAGE}
标签：
– devops 跑步者
脚本：|
纱线配置集注册表 ${NPM_REGISTRY}
纱线安装 –verbose > 纱线.log
纱线自动清洁
VERSION=$(git tag –contains | head -1 | tr -d v )
CTR_VERSION=${VERSION} gulp 构建
PLUGIN_NAME=NAME1 纱线 webpack-cli –config webpack/platform/plugin.js
PLUGIN_NAME=NAME2 纱线 webpack-cli –config webpack/platform/plugin.js
# 根据分支推送到不同位置
如果 [[ ${CI_COMMIT_REF_SLUG} == “释放-“*]];然后
DOCKER_REG=${DOCKER_REGISTRY_STG}
别的
DOCKER_REG=${DOCKER_REGISTRY_DEV}
菲
docker build -t ${DOCKER_REG}/${CI_COMMIT_REF_SLUG}:${CI_PIPELINE_ID} -f docker/Dockerfile 。
echo ‘运行单元测试’
纱线测试
码头工人登录….
码头工人推….
文物：
过期时间：1 天
何时：总是
路径：
– 纱线日志
– 检测结果
报告：
Junit：测试结果.xml
存储工件
NGINX 控制器团队使用单独的工具来存储不同类型的工件：
- 用于 deb 和 rpm 软件包的 Nexus
- 用于焦油球的 Amazon S3
- 容器镜像的私有 Docker 注册表
迁移到 F5 基础设施使我们有机会整合 Artifactory 下的所有存储，因此我们全力以赴。
Artifactory 本身支持我们使用的所有存储库类型，因此我们只需要在我们的 ne 中配置存储库位置和凭据即可w 管道，我们准备开始发布。
只有一个 Artifactory 存储库具有三大优势。显然，这使得管理变得更加容易。这也意味着我们可以在一处扫描漏洞和许可证合规性。最后，访问控制是集中的。
发表回复