ツールチェーンおよび Delivery Pipeline の制限事項

リソースの地域間移動には、以下の制限が適用されます。

1. 従来のパイプラインは サポートされていません。
2. DevOps Insights サポートされていません。
3. ツールチェーンや Delivery Pipeline （環境プロパティやトリガープロパティ）に直接保存されたシークレットはコピーされません。 シークレットを Secrets Manager インスタンスにエクスポートし、保存されているシークレットを 参考文献 に置き換えるために、 export-secrets コマンドが提供される。 シークレット参照がサポートされています。
4. Tekton パイプラインの Webhook トリガーのシークレットはコピーされません。Webhook トリガーのシークレットでは参照がサポートされていないためです。 ツールチェーンをコピーした後、シークレットを追加する必要があります。
5. Tektonパイプラインの実行履歴、ログ、およびアセットはコピーされません。 履歴を保持するため、しばらくの間は元のパイプラインを維持することができます。
6. GitHub および OAuth タイプ認証で構成された Git Repos and Issue Tracking ツール統合は、元のユーザーではなく、コピーを実行するユーザー（API キーの所有者）の OAuth ID を使用するように自動的に変換されます。 これはコピー操作を簡略化するためです。 ツールの統合は、コピー後に別のユーザーで使用するように再構成できます。
7. Git Repos and Issue Tracking 認証に Personal Access Tokens (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 に変更することができます。 Liteプランの制限を 超えた場合、リソースは読み取り専用になります。 ただし、再びご利用になりたい場合は、いつでもプロフェッショナルプランに戻すことができます。 Continuous Delivery 課金とプランの詳細は こちら。

パイプラインの重複運転

移行中に、移行先のリージョンで新しいパイプラインを作成できます。 これらのパイプラインに、スケジュールで自動的に実行されるように設定されたタイムドトリガーや、PRやコミットのような Git イベントで自動的に実行されるように設定された Git トリガーがある場合、これらのイベントは、重複したパイプラインの実行（元のパイプラインと新しいパイプラインで1つずつ）をトリガーする可能性があります。 潜在的な混乱を避けるため、コピーされたパイプラインでは、これらの種類のトリガーはデフォルトで無効化されます。 これらのトリガーは、一度に1セットのみが有効になるように管理することを推奨します。 新しいパイプラインへの移行に慣れたら、そのパイプラインのトリガーを有効にし、元のパイプラインのトリガーを無効にすることができます。

ハードコードされた前提

移行後、 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 CLI を使用すると、ツールチェーンとその CRN を一覧表示できます

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

4. Toolchain APIを 使用する。

保存されているツールチェーン/パイプラインの秘密をチェックする

ツールチェーンとTektonパイプラインは、以下の場所にAPIキーやパスワードのような機密値を含むことができます：

• ツール統合プロパティ、例えば Delivery Pipeline Private Worker ツール統合の Service ID API Key プロパティなど
• テクトンパイプライン環境特性
• テクトンパイプラインのトリガープロパティ

シークレットの設定には、次の2つの方法があります：

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. プロンプトが表示されたら、見つかった秘密ごとに、秘密をコピーするかどうか、秘密を保存する名前とグループを指定するか、Enterキーを押してデフォルトを受け入れる。

すべての秘密をエクスポートするために必要な回数だけコマンドを実行することができます。

ツールチェーンをコピーする

ツールチェーンをコピーするには、 [@ibm-cloud/cd-tools](https://www.npmjs.com/package/@ibm-cloud/cd-tools){: external} 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 レポのツール統合は、コピーを実行したユーザーの OAuth ID を使用するように変換されました。 別のIDを使用したい場合は、そのユーザーでログインしてツールの統合を保存し直すか、Personal Access Tokensの使用に切り替えてください。
• Tektonの定義、スクリプト、環境プロパティ、またはその他の自動化には、リソースのID、 URL、または場所に関する前提があるかもしれません。 新しいID、URL、ロケーションが使用されていることを確認するために、これらを見直すことをお勧めします。

オリジナルのリソースを無効にする

コピーしたリソースが正しく機能していることを確認したら、コンフリクトや混乱を避けるために、元のリソースを無効にすることができます。

• Tektonパイプラインでは、トリガーを無効にすることで、不要なパイプラインの実行を回避したり、他のユーザーにトリガーを使用しないように通知したりすることができます。
• サービス・インスタンス Continuous Delivery サービス・インスタンスについては、プロフェッショナル・プランを使用していた場合、 ライト・ プランに切り替えることで、元のリソースに対する追加料金を回避することができます。 このため、Liteプランの制限を超えた場合、リソースが読み取り専用になることがありますが、再度使用する必要がある場合は、いつでもProfessionalに切り替えることができます。
• Git Repos と Issue tracking プロジェクト (該当する場合) については、元のプロジェクトをアーカイブして読み取り専用にし、ユーザーがそれ以上変更できないようにすることができます。オプションで、プロジェクトの説明や readme を更新して、新しいプロジェクトの場所を示すこともできます。

元のリソースを保管するつもりがない場合でも、後で問題が見つかった場合に備えて、バックアップとして元のリソースをしばらく保管しておきたい場合があります。 問題がなければ、元のリソースを削除することができる。