Migrar para o Secure Source Manager

Este guia descreve como migrar um repositório Git, incluindo todas as informações dele, do Cloud Source Repositories (CSR) do Google para o Secure Source Manager (SSM). Essa migração usa comandos Git padrão para clonar e enviar dados do repositório.

Pré-requisitos

Antes de iniciar a migração, verifique se você atende aos seguintes pré-requisitos:

  • Permissões: o usuário ou as contas de serviço precisam ter as seguintes permissões para realizar a migração:
    • source.repos.get, que está disponível na função roles/source.reader no repositório CSR de origem.
    • securesourcemanager.instances.access, disponível na função roles/securesourcemanager.instanceAccessor, e securesourcemanager.repositories.fetch, disponível na função roles/securesourcemanager.repoWriter, na instância e no repositório de destino do SSM. Se você estiver criando repositórios, consulte Criar um repositório.
  • Cliente Git: você precisa de um computador com a ferramenta de linha de comando do Git instalada.
  • SDK Google Cloud: para autenticar ao usar HTTPS, instale a versão 395.0.0 ou mais recente no mesmo computador em que você instalou a ferramenta Git. Se você não tiver o SDK Google Cloud, conecte-se ao CSR e ao SSM usando chaves SSH.
  • Instância do SSM: verifique se você consegue acessar a instância do SSM no seu computador. Se a instância estiver configurada usando o Private Service Connect, consulte Acessar uma instância particular para detalhes de acesso.
  • Armazenamento local: você precisa de espaço em disco local suficiente para armazenar temporariamente clones dos repositórios que está migrando.

Etapas da migração

O processo de migração envolve clonar o repositório completo do CSR para o computador local e enviar o clone para o repositório do SSM.

Determinar o principal e o método de acesso para repositórios de CSR e SSM

É possível se conectar ao CSR usando transportes HTTP ou SSH ao se autenticar como um principal de usuário ou por HTTP ao se autenticar como uma conta de serviço. É possível se conectar e autenticar com o SSM usando transportes HTTP ou SSH, como um usuário ou um principal de conta de serviço.

Não é necessário usar o mesmo transporte ou principal no CSR e no SSM. Determine o principal e o transporte que você vai usar em cada plataforma. Para mais informações sobre como representar contas de serviço, consulte Representação da conta de serviço.

Verificar se o repositório do CSR é somente leitura

Este guia de migração não usa espelhamento ou sincronização automática. Portanto, verifique se ninguém grava no repositório do CSR durante ou após a migração. Atualize as permissões do IAM para que nenhum usuário tenha um papel diferente de roles/source.reader no repositório. Como alternativa, coordene com seus usuários para interromper todos os commits durante a migração.

Criar repositório do Secure Source Manager

Pule esta etapa se um administrador já tiver criado o repositório para você.

Para criar um repositório vazio na sua instância do SSM, siga o guia para criar um repositório. Verifique se as seguintes condições foram atendidas:

  • Se estiver usando a UI, não selecione Inicializar repositório, porque isso cria um repositório não vazio.
  • Se você estiver usando a Google Cloud CLI, não defina as flags --gitignores, --readme e --licenses, porque isso cria um repositório não vazio.
  • Se você estiver usando a API, não defina os campos gitignores, license e readme de InitialConfig, porque isso cria um repositório não vazio.

Validar as configurações do repositório do SSM

Verifique se o repositório está vazio conferindo a UI ou clonando o repositório e executando git show-ref. A saída fica vazia se o repositório estiver vazio.

Verifique se não há regras de proteção de ramificação ativas na UI ou usando a API. Não pode haver regras, ou todas elas precisam ser desativadas para evitar o bloqueio da migração.

Verificar o espaço em disco local e remoto

Antes de clonar o repositório do CSR, encontre o tamanho total dele. Execute gcloud source repos describe <var>CSR_REPO_NAME</var>. Esse comando mostra o número total de bytes no repositório. Para avaliar o espaço em disco disponível em um sistema Linux, execute df . para conferir o número de bytes disponíveis no diretório atual.

O SSM tem um limite padrão de 100 GB de armazenamento por instância. Verifique se o repositório CSR vai caber antes de clonar.

Clonar o repositório CSR

Clone o histórico completo do repositório do CSR no seu computador local.

  1. Acesse o diretório local em que você quer armazenar temporariamente o repositório.
  2. Clone o repositório: sh git clone <var>CSR_REPO_URL</var> --mirror

Esse comando cria um clone simples, que é otimizado para enviar todo o conteúdo do repositório para outro remoto. Você vai notar que o diretório contém apenas arquivos como config e HEAD, em vez do conteúdo do repositório. Isso é esperado. Todo o conteúdo do repositório foi clonado e está presente no diretório objects e em outros, mas não há uma cópia de trabalho.

Adicionar o repositório do Secure Source Manager como um novo controle remoto

Execute este comando:

git remote add ssm <var>SSM_REPOSITORY_URL</var>

Enviar o repositório completo para o Secure Source Manager

Envie todas as ramificações, tags e referências do clone local para o SSM remoto:

git push --mirror ssm

Validação

Depois que a operação de push for concluída, clone o repositório do SSM em um diretório diferente. Em seguida, compare as cópias do repositório no CSR e no SSM:

  • Número de ramificações: execute git branch -r em cada repositório e verifique se o número de ramificações é o mesmo. Em sistemas Linux ou macOS, redirecionar o comando para wc -l conta as linhas de saída.
  • Número de tags: execute git tag em cada repositório e verifique se o número de tags é o mesmo. Em sistemas Linux ou macOS, redirecionar o comando para wc -l conta as linhas de saída.
  • Commit HEAD: execute git rev-parse HEAD em cada repositório e verifique se o hash do commit é igual.
  • Contagem de commits: execute git rev-list --all --count em cada repositório e verifique se o número de commits é o mesmo.

Limpeza

  • Se você representou uma conta de serviço durante a migração, execute gcloud config set account para redefinir suas credenciais.
  • Se você desativou as regras de proteção de ramificação, reative as Regras de proteção de ramificação no repositório do SSM.
  • Remova cópias simples do repositório CSR do computador usado para a migração.
  • Exclua o repositório original do CSR.

A seguir