工具链和 Delivery Pipeline 的限制

资源从一个区域迁移到另一个区域受以下限制。

1. 经典管道 不被支持。
2. DevOps Insights 不支持。
3. 不会复制直接存储在工具链或 Delivery Pipeline （环境属性或触发器属性）中的秘密。 export-secrets 命令将秘密导出到一个 Secrets Manager 实例中，用 秘密引用 替换存储的秘密。 支持隐秘引用。
4. Tekton 管道 webhook 触发器密钥不会被复制，因为 webhook 触发器密钥不支持引用。 复制工具链后，您需要添加密钥。
5. Tekton 管道运行历史记录、日志和资产将不会被复制。 您可以暂时保留原始管道以保留历史记录。
6. GitHub 和 Git Repos and Issue Tracking 工具集成配置的 OAuth 类型验证将自动转换为使用执行复制的用户（API 密钥所有者）的 OAuth 身份，而不是原始用户。 此举旨在简化复制操作。 复制后，您可以重新配置工具集成以使用其他用户。
7. Git Repos and Issue Tracking 使用个人访问令牌 (PAT) 进行身份验证的工具集成将自动转换为使用 OAuth。 复制后，您可以重新配置工具集成以再次使用PAT。

Git Repos and Issue Tracking 的限制

以下限制仅适用于您迁移 Git Repos and Issue Tracking 项目的情况。

1. 个人项目不予支持。 如果在 个人命名空间下创建了项目，可以 将个人项目移动到组中，或者 将个人命名空间转换为组，然后使用新的 URL 更新工具链中的引用。 建议将项目按组存储，因为组功能支持多管理员协作，并能确保项目在长期运行中保持更好的连续性。
2. 项目复制使用 GitLab 直接传输功能，该功能有一定的 限制。
3. 复制大型项目，或包含大文件或大量资源的项目，可能需要花费时间。
4. 由于每个 Git Repos and Issue Tracking 区域都是独立的，您的项目用户可能尚未存在于目标区域中。 该 copy-project-group 命令将确保用户存在于新区域中，但可能与目标区域中的其他用户发生用户名冲突。 若发生用户名冲突，目标区域的用户名可通过添加后缀进行微调。

重要注意事项

在开始迁移之前，您必须仔细阅读以下重要注意事项。

计费注意事项

在迁移过程中，您需要在目标区域和资源组中创建一个新的 Continuous Delivery 实例，以便在目标区域启用工具链、管道和项目。 您可能还希望在完成向新区域的迁移之前，将源区域中的原始资源保留可用状态。 如果将 Continuous Delivery 服务与专业计划一起使用，请注意将根据每个实例中配置的授权用户数量对两个区域收费。 如果担心成本问题，可以在过渡到新区域后，将源区域 Continuous Delivery 实例中的计划更改为 Lite。 如果您超出了 精简版计划的限制，资源将只读。 不过，如果您想再次使用专业版，随时可以切换回去。 了解更多 关于 Continuous Delivery 计费和计划。

管道重复运行

在迁移过程中，您可以在目标区域创建新的管道。 如果这些管道中的定时触发器被设置为按计划自动运行，或 Git 触发器被配置为按 Git 事件（如 PR 或提交）自动运行，那么这些事件可能会触发重复的管道运行（一个在原管道中，一个在新管道中）。 为避免潜在干扰，复制的管道将默认禁用此类触发器。 建议管理这些触发器，确保每次仅启用一组。 当您对新管道的迁移感到满意后，即可启用该管道上的触发器，并禁用原始管道上的触发器。

硬编码假设

迁移后，您的 Git Repos and Issue Tracking 仓库（如果适用）将使用不同的 URL，您的工具链和管道将使用不同的 ID 和 URL。 在 Tekton 定义、脚本、环境属性或其他自动化中，可能会有一些关于 URL /ID 或资源位置的假设。 迁移后，您有责任更新这些内容。

macOS

运行以下命令在 macOS 上安装依赖项。

brew install node
brew tap hashicorp/tap
brew install hashicorp/tap/terraform

其他平台

• Node.js 安装说明
• Terraform 安装说明

CRN

IBM Cloud 资源通过 云资源名称（CRN） 进行唯一标识。 您需要复制目标工具链的课程注册号（CRN）。 获取工具链的CRN有以下几种方式：

1. 在“平台自动化 > 工具链”页面定位工具链，打开该工具链，点击 “详细信息”查看工具链详情，其中会显示CRN。
2. 在 资源列表 页面定位工具链，点击工具链行展开详细信息面板，该面板将显示CRN。
3. 使用 ibmcloud 命令行界面，您可以通过以下方式列出工具链及其 CRN：

   ibmcloud resource service-instances --service-name toolchain --long
   

4. 使用 工具链应用程序接口

检查存储的工具链/管道秘密

工具链和 Tekton 管道可能在以下位置包含秘密，即 API 密钥或密码等敏感值：

• 工具集成属性，例如 Delivery Pipeline Private Worker 工具集成的服务 ID API Key 属性
• Tekton 管道环境特性
• Tekton 管道触发特性

配置密钥有两种方法：

1. 直接存储在工具链或管道中
2. 引用 存储在秘密存储服务（如 IBM Cloud Secrets Manager 或 IBM Cloud Key Protect.

复制工具链将自动包含 秘密引用，这些引用将在新工具链中保持不变。 不过，为了最大限度地降低泄漏敏感数据的风险，直接存储在工具链或管道中的机密将不会包含在工具链副本中。 您可以使用下一节介绍的 export-secrets 命令，也可以在复制后在复制的工具链或管道中再次手动输入秘密。 但请注意，如果不导出秘钥，在复制工具链时，某些工具集成可能会因为缺少所需的秘钥值而无法成功提供，可能需要在运行命令后手动重新创建。

首先，检查工具链或其 Tekton 管道是否包含任何运行时不引用的存储秘密：

npx @ibm-cloud/cd-tools export-secrets -c ${CRN} --check

将存储的工具链/管道秘密导出到 Secrets Manager

如果您的工具链或管道不包含任何存储的秘密，您可以跳过这一步，继续复制工具链。 将秘密导出到 Secrets Manager 会在 Secrets Manager 实例中创建秘密，同时也会修改原始工具链，将现有秘密转换为引用 Secrets Manager 中新建的秘密。 这将允许在复制工具链时保留秘密引用，是提高安全性的推荐做法。

为防止意外泄露秘密，应检查实例的 IAM 权限，确保只授予预期的读取权限。Secrets Manager 实例的 IAM 权限，确保只授予读取机密的预期访问权限。

要将存储在工具链或管道中的机密导出到 Secrets Manager，请按照以下步骤操作：

1. 如果您还没有 Secrets Manager 实例，请 创建一个。 请注意，必须在与您将使用的 API 密钥相关联的账户中创建实例。
2. 确保要使用的 API 密钥的所有者拥有在 Secrets Manager 实例中创建机密的 IAM 权限。
3. 打开工具链和 Secrets Manager 工具集成，根据提示创建授权策略，然后创建工具集成。
4. 运行 export-secrets 命令以导出密钥：

   npx @ibm-cloud/cd-tools export-secrets -c ${CRN}
   

5. 出现提示时，从工具链中选择 Secrets Manager 实例来存储秘密。 如果您没有看到您的实例在列表中，它可能在不同的账户中。 确保使用的 API 密钥与实例的账户相同。
6. 出现提示时，请为找到的每个秘密指定是否复制该秘密，以及要存储该秘密的名称和组，或按回车键接受默认值。

您可以根据需要多次运行该命令来导出所有机密。

复制工具链

要复制工具链，请运行 @ibm-cloud/cd-tools copy-toolchain 命令。 要查看可用选项，请运行

npx @ibm-cloud/cd-tools copy-toolchain -h
Usage: @ibm-cloud/cd-tools copy-toolchain [options]

Copies a toolchain, including tool integrations and Tekton pipelines, to another region or resource group.

Examples:
  export IBMCLOUD_API_KEY='...'
  npx @ibm-cloud/cd-tools copy-toolchain -c ${TOOLCHAIN_CRN} -r us-south
      Copy a toolchain to the Dallas region with the same name, in the same resource group.
  npx @ibm-cloud/cd-tools copy-toolchain -c ${TOOLCHAIN_CRN} -r eu-de -n new-toolchain-name -g new-resource-group --apikey ${APIKEY}
      Copy a toolchain to the Frankfurt region with the specified name and target resource group, using the given API key

Environment Variables:
  IBMCLOUD_API_KEY                       API key used to authenticate. Must be a user API key, with IAM permission to read and create toolchains and service-to-service authorizations in source and target
region / resource group

Basic options:
  -c, --toolchain-crn <crn>              The CRN of the source toolchain to copy
  -r, --region <region>                  The destination region of the copied toolchain (choices: "br-sao", "eu-de", "eu-gb", "jp-tok", "us-south")
  -a, --apikey <api_key>                 API key used to authenticate. Must be a user API key, with IAM permission to read and create toolchains and service-to-service authorizations in source and target
                                         region / resource group
  -n, --name <name>                      (Optional) The name of the copied toolchain (default: same name as original)
  -g, --resource-group <resource_group>  (Optional) The name or ID of destination resource group of the copied toolchain (default: same resource group as original)
  -t, --tag <tag>                        (Optional) The tag to add to the copied toolchain
  -h, --help                             Display help for command

Advanced options:
  -d, --terraform-dir <path>             (Optional) The target local directory to store the generated Terraform (.tf) files
  -D, --dry-run                          (Optional) Skip running terraform apply; only generate the Terraform (.tf) files
  -f, --force                            (Optional) Force the copy toolchain command to run without user confirmation
  -S, --skip-s2s                         (Optional) Skip creating toolchain-generated service-to-service authorizations
  -T, --skip-disable-triggers            (Optional) Skip disabling Tekton pipeline Git or timed triggers. Note: This may result in duplicate pipeline runs
  -C, --compact                          (Optional) Generate all resources in a single resources.tf file
  -v, --verbose                          (Optional) Increase log output
  -q, --quiet                            (Optional) Suppress non-essential output, only errors and critical warnings are displayed

copy-toolchain 的工作原理是首先将工具链转换为 Terraform (.tf) 文件，然后应用 Terraform 在目标区域创建新的工具链。 该命令将显示 Terraform 输出，并在创建工具链之前提示确认。 您可以在创建新工具链副本前查看 Terraform 输出。

export IBMCLOUD_API_KEY='<your_api_key>'
npx @ibm-cloud/cd-tools copy-toolchain -c 'crn:v1:bluemix:public:toolchain:au-syd:a/9d5d528aa786af01ce99593a827a05f0:69e8d78b-0d1a-49ed-9a46-3b4c1bb4f24a::' -r jp-tok

npx @ibm-cloud/cd-tools copy-toolchain -c "${CRN}" -r eu-de --apikey '<your_api_key>'

export IBMCLOUD_API_KEY='<your_api_key>'
npx @ibm-cloud/cd-tools copy-toolchain -c "${CRN}" -r us-south -n 'toolchain-dallas'

for i in $(ibmcloud resource service-instances --service-name toolchain --location ca-tor --all-resource-groups -o json | jq -r '.[].crn'); do
    npx @ibm-cloud/cd-tools copy-toolchain -c ${i} -r us-south --dry-run -f
done

for i in $(ibmcloud resource service-instances --service-name toolchain -g my-resource-group -o json | jq -r '.[].crn'); do
    npx @ibm-cloud/cd-tools copy-toolchain -c ${i} -r eu-de -q
done

for i in $(ibmcloud resource service-instances --service-name toolchain --all-resource-groups -o json | jq -r '.[] | select(.name | startswith("test-")) | .crn'); do
    npx @ibm-cloud/cd-tools copy-toolchain -c ${i} -r jp-tok
done

$ cd output-1764102115772
$ terraform apply
var.ibmcloud_api_key
  Enter a value: {api_key}
...

核实资源

将工具链、Tekton 管道和 Git Repos and Issue Tracking 项目（如适用）复制到新区域后，应在禁用或删除原始资源前验证它们是否已正确复制并正常运行。 请注意：

• Tekton 管道定时触发器和 Git 触发器未在复制管道中默认启用，以防止新管道和原始管道之间重复运行。 一旦您觉得满意，就可以启用新管道中的触发器，并禁用原管道中的触发器。
• 如果有任何 Webhook 类型的 Tekton 管道触发器，则需要重新配置触发器并重新输入密文。 该密文不支持 密文引用，也不会随管道一起复制。
• 在复制的 Git Repos and Issue Tracking 项目中拥有个人访问令牌的用户需要重新创建新的令牌，因为这些令牌没有被复制。
• Git Repos and Issue Tracking repos 的工具集成将转换为使用执行复制的用户的 OAuth 身份。 如果您想使用不同的身份，请使用该用户登录并重新保存工具集成，或改用个人访问令牌。
• 在 Tekton 定义、脚本、环境属性或其他自动操作中，可能会假设资源的 ID、URL 或位置。 建议您查看这些内容，以确保使用新的 ID、URL 和位置。

禁用原始资源

在确认复制的资源运行正常后，可以禁用原来的资源，以避免冲突或混乱。

• 对于 Tekton 管道，您可以禁用触发器，以避免不必要的管道运行，并向其他用户发出不再使用这些触发器的信号。
• 对于 Continuous Delivery 服务实例，如果您使用的是专业计划，您可以切换到精简版计划，以避免对原有资源的进一步收费。 如果您超出了精简版计划的限制，这可能会导致您的资源变成只读资源，但如果您需要再次使用这些资源，可以随时切换回专业版。
• 对于 Git Repos 和问题跟踪项目 （如果适用），可以归档原始项目，使其成为只读项目，防止用户进一步更改，还可以选择更新项目说明或 readme，以指明新项目的位置。

即使不打算保留原始资源，也可能希望保留原始资源一段时间作为备份，以防日后发现问题。 一旦您觉得满意，就可以删除原始资源。