このガイドでは、すべての情報を含む Git リポジトリを Google の Cloud Source Repositories(CSR)から Secure Source Manager(SSM)に移行する方法について説明します。この移行では、標準の Git コマンドを使用してリポジトリ データのクローンを作成し、push します。
前提条件
移行を開始する前に、次の前提条件を満たしていることを確認してください。
- 権限: 移行を実行するには、ユーザーまたはサービス アカウントに次の権限が必要です。
- ソース CSR リポジトリに対する
roles/source.readerロールで利用可能なsource.repos.get - ターゲットの SSM インスタンスとリポジトリに対する
roles/securesourcemanager.instanceAccessorロールで使用可能なsecuresourcemanager.instances.accessと、roles/securesourcemanager.repoWriterロールで使用可能なsecuresourcemanager.repositories.fetch。新しいリポジトリを作成する場合は、リポジトリを作成するをご覧ください。
- ソース CSR リポジトリに対する
- Git クライアント: Git コマンドライン ツールがインストールされているパソコンが必要です。
- Google Cloud SDK: HTTPS を使用して認証するには、Git ツールをインストールしたコンピュータにバージョン 395.0.0 以降をインストールする必要があります。Google Cloud SDK がない場合は、SSH 認証鍵を使用して CSR と SSM の両方に接続する必要があります。
- SSM インスタンス: パソコンから SSM インスタンスにアクセスできることを確認します。Private Service Connect を使用してインスタンスが構成されている場合は、プライベート インスタンスにアクセスするでアクセス方法の詳細を確認してください。
- ローカル ストレージ: 移行するリポジトリのクローンを一時的に保存するために、十分なローカル ディスク容量が必要です。
移行手順
移行プロセスでは、CSR からローカル コンピュータにリポジトリ全体を複製し、そのクローンを SSM リポジトリに push します。
CSR リポジトリと SSM リポジトリのアクセス プリンシパルとメソッドを決定する
ユーザー プリンシパルとして認証する場合は HTTP または SSH トランスポートを使用して CSR に接続できます。サービス アカウントとして認証する場合は HTTP を使用して接続できます。ユーザーまたはサービス アカウント プリンシパルとして、HTTP または SSH トランスポートを使用して SSM に接続して認証できます。
CSR と SSM で同じトランスポートまたはプリンシパルを使用する必要はありません。各プラットフォームで使用するプリンシパルとトランスポートを決定します。サービス アカウントの権限借用の詳細については、サービス アカウントの権限借用をご覧ください。
CSR リポジトリが読み取り専用であることを確認する
この移行ガイドでは、自動ミラーリングや同期は使用しません。したがって、移行中または移行後に CSR リポジトリに書き込むユーザーがいないことを確認してください。リポジトリで roles/source.reader 以外のロールを持つユーザーがいないように、IAM 権限を更新します。または、ユーザーと連携して、移行中にすべての commit を停止します。
Secure Source Manager リポジトリを作成する
管理者がすでにリポジトリを作成している場合は、この手順をスキップできます。
SSM インスタンスに空のリポジトリを作成するには、新しいリポジトリを作成するガイドに沿って操作します。以下のことを確認します。
- UI を使用する場合は、[リポジトリを初期化] を選択しないでください。このオプションを選択すると、空でないリポジトリが作成されます。
- Google Cloud CLI を使用している場合は、
--gitignores、--readme、--licensesフラグを設定しないでください。空でないリポジトリが作成されます。 - API を使用している場合は、
InitialConfigのgitignores、license、readmeフィールドを設定しないでください。設定すると、空でないリポジトリが作成されます。
SSM リポジトリの設定を検証する
UI を確認するか、リポジトリのクローンを作成して git show-ref を実行し、リポジトリが空であることを確認します。リポジトリが空の場合、出力は空になります。
UI を確認するか、API を使用して、アクティブなブランチ保護ルールがないことを確認します。移行をブロックしないように、ルールがないか、すべてのルールが無効になっている必要があります。
ローカル ディスクとリモート ディスクの空き容量を確認する
CSR リポジトリのクローンを作成する前に、その合計サイズを確認します。gcloud source repos describe <var>CSR_REPO_NAME</var> を実行します。このコマンドは、リポジトリ内の合計バイト数を表示します。Linux システムで使用可能なディスク容量を評価するには、df . を実行して、現在のディレクトリで使用可能なバイト数を確認します。
SSM のデフォルトの上限は、インスタンスあたり 100 GB のストレージです。CSR リポジトリをクローンする前に、そのリポジトリが適合することを確認します。
CSR リポジトリのクローンを作成する
CSR からローカル コンピュータにリポジトリの履歴全体を複製します。
- リポジトリを一時的に保存するローカル ディレクトリに移動します。
- リポジトリのクローンを作成します。
sh git clone <var>CSR_REPO_URL</var> --mirror
このコマンドは、リポジトリの内容全体を別のリモートに push するように最適化されたベア クローンを作成します。ディレクトリには、リポジトリの内容ではなく、config や HEAD などのファイルのみが含まれています。これは想定どおりです。リポジトリのコンテンツはすべてクローンされ、objects ディレクトリなどに存在しますが、作業コピーはありません。
Secure Source Manager リポジトリを新しいリモートとして追加する
次のコマンドを実行します。
git remote add ssm <var>SSM_REPOSITORY_URL</var>
完全なリポジトリを Secure Source Manager に push する
ローカル クローンから SSM リモートにすべてのブランチ、タグ、参照を push します。
git push --mirror ssm
検証
プッシュ オペレーションが完了したら、SSM リポジトリを別のディレクトリにクローンします。次に、リポジトリの CSR コピーと SSM コピーを比較します。
- ブランチの数: 各リポジトリで
git branch -rを実行し、ブランチの数が同じであることを確認します。Linux または macOS システムでは、コマンドをwc -lにパイプすると、出力行数がカウントされます。 - タグの数: 各リポジトリで
git tagを実行し、タグの数が同じであることを確認します。Linux または macOS システムでは、コマンドをwc -lにパイプすると、出力行数がカウントされます。 - HEAD commit: 各リポジトリで
git rev-parse HEADを実行し、コミット ハッシュが等しいことを確認します。 - コミット数: 各リポジトリで
git rev-list --all --countを実行し、コミット数が同じであることを確認します。
クリーンアップ
- 移行中にサービス アカウントを偽装した場合は、
gcloud config set accountを実行して認証情報をリセットします。 - ブランチ保護ルールを無効にした場合は、SSM リポジトリでブランチ保護ルールを再度有効にします。
- 移行に使用したコンピュータから CSR リポジトリのベアコピーを削除します。
- 元の CSR リポジトリを削除します。