Migração do armazenamento externo do GitHub Actions

Sobre a migração do GitHub Actions armazenamento externo

Você pode migrar GitHub Actions o armazenamento externo para um novo bucket, conta ou região no mesmo provedor ao consolidar contas de nuvem, atender aos requisitos de residência ou reorganizar a locação de armazenamento.

A migração funciona porque GitHub Actions identifica objetos armazenados por sua chave (caminho) dentro de um bucket ou contêiner, não pelo nome do bucket ou da conta. Desde que você preserve o layout da chave interna e atualize sua configuração para apontar para o novo local, os logs e artefatos de fluxo de trabalho existentes permanecerão acessíveis sem interrupção.

Considerações

Antes de começar, examine as restrições a seguir. Cada uma forma a abordagem de migração e várias podem causar perda de dados se ignoradas.

Somente o mesmo provedor. Esse procedimento dá suporte a migrações no mesmo tipo de provedor de armazenamento, por exemplo, Amazon S3 para Amazon S3, Azure Blob para Azure Blob, Google Cloud Storage para Google Cloud Storage ou MinIO para MinIO. As migrações entre provedores não são abordadas aqui. Para uma migração entre provedores, entre em contato com Suporte do GitHub Enterprise.
Não altere o método de autenticação durante a migração. Se você atualmente usa a autenticação baseada em credenciais, sua configuração de destino também deve usar a autenticação baseada em credenciais. O mesmo se aplica ao OpenID Connect. Alternar o método de autenticação durante uma alteração de configuração de armazenamento pode resultar em perda de dados. Para obter mais informações, consulte Atualizando as credenciais para o armazenamento do GitHub Actions. Para alterar o método de autenticação, conclua a migração de armazenamento primeiro e planeje uma alteração separada.
A estrutura da chave dentro do bucket ou contêiner deve ser preservada. As chaves de objeto (caminhos) dentro do seu bucket de origem ou contêiner devem permanecer idênticas no destino. O nome do bucket de destino, a conta de armazenamento, a região e outros parâmetros de conexão podem ser alterados. Atualize-os no Console de Gerenciamento durante a virada. A maioria das ferramentas nativas de cópia do provedor preserva automaticamente a estrutura de chaves ao copiar todo um bucket ou contêiner, mas, antes da migração, verifique se o destino corresponde à origem.
GitHub Packages tem restrições adicionais. Se você também usar GitHub Packages, consulte a seção GitHub Packages considerações abaixo antes de começar.

Pré-requisitos

Você tem acesso de administrador ao site sua instância do GitHub Enterprise Server.
Você provisionou o armazenamento de destino no mesmo provedor que a origem, na conta, na região ou no locatário desejados.
O destino está vazio.
O destino concede sua instância do GitHub Enterprise Server as mesmas permissões que a origem. Para obter as permissões necessárias, consulte o artigo de configuração relevante:
Você tem credenciais administrativas para o armazenamento de origem e de destino, suficientes para ler todos os objetos de origem e gravar no destino.
Você tem um backup recente de sua instância do GitHub Enterprise Server. Para obter mais informações, consulte Configurando backups em sua instância com utilitários de backup.
Você ensaiou a migração em um ambiente de preparo. Veja a próxima seção.

Ensaiando a migração em um ambiente de preparo

Antes de executar a migração no ambiente de produção, teste todo o procedimento em uma instância de homologação. Provisione uma instância de preparo GitHub Enterprise Server de um backup de produção recente, aponte-a para um destino descartável que espelha o destino de produção pretendido e execute cada etapa deste artigo de ponta a ponta. Para obter mais informações, consulte Configurar uma instância de testes e Usar um ambiente de teste.

Um ensaio de preparo valida que:

As permissões do lado do provedor, o acesso à rede e as políticas no destino estão corretas.
A ferramenta de cópia escolhida conclui com êxito operações com volumes representativos de dados.
A contagem de objetos esperada e o tamanho total correspondem entre a origem e o destino.
Os logs e artefatos existentes da execução do fluxo de trabalho podem ser recuperados pela interface do usuário após a migração.

Aviso

Sua instância de homologação deve usar um armazenamento diferente do da sua instância de produção. Se você não alterar a configuração de armazenamento, a instância de homologação poderá gravar dados no armazenamento de produção e causar perda de dados. Para obter mais informações, consulte Usar um ambiente de teste.

Executando a migração

Siga as etapas a seguir na ordem. GitHub Actions pode continuar atendendo o tráfego até habilitar o modo de manutenção.

Execute a cópia de dados inicial. Copie todos os objetos da origem para o destino usando uma ferramenta nativa do provedor. Novos objetos gravados na origem durante a cópia serão capturados pela sincronização delta final após a substituição.

Use os comandos de exemplo como ponto de partida. Consulte a documentação de origem para ver o conjunto completo de opções, incluindo credenciais, criptografia e ajuste de taxa de transferência.

Para Amazon S3, utilize aws s3 sync na Interface de Linha de Comando da AWS. Execute uma execução seca primeiro para validar a operação e, em seguida, execute a cópia.
```
aws s3 sync s3://SOURCE-BUCKET s3://DESTINATION-BUCKET --dryrun
aws s3 sync s3://SOURCE-BUCKET s3://DESTINATION-BUCKET
```
Para Armazenamento de Blobs do Azure, use azcopy copy com uma assinatura de acesso compartilhado na origem.
```
azcopy copy 'https://SOURCE-STORAGE-ACCOUNT-NAME.blob.core.windows.net/CONTAINER?SAS-TOKEN' 'https://DESTINATION-STORAGE-ACCOUNT-NAME.blob.core.windows.net/CONTAINER' --recursive
```
Para o Google Cloud Storage, use gcloud storage rsync na Interface de Linha de Comando do Google Cloud.
```
gcloud storage rsync --recursive gs://SOURCE-BUCKET gs://DESTINATION-BUCKET
```
Para MinIO, use mc mirror do cliente MinIO.
```
mc mirror SOURCE-ALIAS/SOURCE-BUCKET DESTINATION-ALIAS/DESTINATION-BUCKET
```
Após a conclusão da cópia, verifique a contagem de objetos e o tamanho total no destino usando as ferramentas de listagem padrão do provedor. Investigue qualquer discrepância antes de continuar.
Habilitar o modo de manutenção. Para impedir que novos objetos sejam gravados na origem durante a transição, habilite o modo de manutenção no sua instância do GitHub Enterprise Server. Isso deixa a instância indisponível por um breve período para os usuários finais. Para obter mais informações, consulte Habilitar e programar o modo de manutenção.
Execute a sincronização delta final. Com o modo de manutenção habilitado, execute o mesmo comando de cópia da etapa de cópia inicial novamente. Isso captura quaisquer objetos que foram gravados na fonte depois que a cópia inicial foi iniciada.

Por exemplo, para o Amazon S3:
```
aws s3 sync s3://SOURCE-BUCKET s3://DESTINATION-BUCKET
```
Atualize a configuração de armazenamento. Atualize sua instância do GitHub Enterprise Server para apontar para o novo local de armazenamento. Mantenha o mesmo método de autenticação de antes.
1. Faça login no Console de Gerenciamento. Para obter mais informações, consulte Acessando o Console de Gerenciamento.
2. Na barra lateral "Configurações", clique em Ações.
3. Em "Artefato & Armazenamento de Logs", atualize os campos que identificam o local de armazenamento, por exemplo, o nome do bucket, o nome da conta, a região, o ARN da função ou a string de conexão. Não altere o método de autenticação.
4. Clique em Testar configurações de armazenamento para validar a nova configuração.
  
  Aviso
  
  Se o teste falhar, não salve as configurações. Investigue a falha e teste novamente antes de continuar. Salvar uma configuração de armazenamento inválida pode causar uma interrupção.
5. Clique em Salvar configurações e aguarde a reinicialização completa dos serviços.
Como alternativa, você pode atualizar a configuração da linha de comando usando ghe-actions-precheck a autenticação baseada em credenciais. Para obter mais informações, consulte Utilitários de linha de comando.
Valide a migração. Após a alteração da configuração, confirme que GitHub Actions pode ler a partir do novo local de armazenamento.
1. Desabilite o modo de manutenção. Para obter mais informações, consulte Habilitar e programar o modo de manutenção.
2. Na interface web do sua instância do GitHub Enterprise Server, abra uma execução recente de fluxo de trabalho concluída antes da migração. Confirme que:
  - Carregar logs da execução do fluxo de trabalho.
  - Compilar artefatos baixados com êxito.
3. Inicie uma nova execução do fluxo de trabalho e confirme que:
  - A execução é concluída com sucesso.
  - Os logs e quaisquer artefatos produzidos pela execução são visíveis.
Se qualquer uma dessas verificações falhar, mantenha o armazenamento de origem e consulte a seção Reversão abaixo.
Desativar o armazenamento de origem. Prossiga apenas depois que a validação for concluída com êxito e você tiver permitido tempo suficiente para ter certeza de que o novo local de armazenamento está íntegro. Como diretriz, mantenha o armazenamento de origem em um estado somente leitura por pelo menos um ciclo de backup completo antes de excluí-lo.

Quando estiver pronto para remover o armazenamento de origem, siga o procedimento padrão do provedor para excluir um bucket ou contêiner.

Revertendo

Se a validação falhar ou você encontrar problemas após a transição, faça a reversão apontando sua instância do GitHub Enterprise Server de volta para o local de armazenamento de origem. O armazenamento de origem é sua cópia comprovadamente íntegra. Não copie dados do destino para a origem como parte da reversão, pois os dados gravados no destino durante um cutover malsucedido podem estar parciais ou inconsistentes, e gravá-los novamente na origem pode corromper sua única cópia íntegra.

Aviso

A reversão descartará todos os dados gravados ou excluídos após a transição. Se a validação falhar, reverta imediatamente em vez de tentar uma investigação prolongada de problemas. Quanto mais tempo você aguardar, mais dados estarão em risco.

Se a validação falhar ou você encontrar problemas:

Habilite o modo de manutenção imediatamente.
Console de GerenciamentoNo , restaure os valores de configuração de armazenamento originais e clique em Testar configurações de armazenamento e, em seguida, salve as configurações.
Desabilite o modo de manutenção e execute novamente as etapas de validação com o armazenamento original.

Após uma reversão bem-sucedida, investigue a falha e planeje uma nova tentativa de migração.

Considerações sobre o GitHub Packages

Você pode aplicar a mesma abordagem de migração ao GitHub Packages armazenamento externo, com as seguintes diferenças importantes. Leia esta seção na íntegra antes de migrar o armazenamento em uma instância habilitada GitHub Packages .

O OpenID Connect não está disponível para GitHub Packages. GitHub Packages só dá suporte à autenticação baseada em credenciais para armazenamento externo. A restrição de método de autenticação neste artigo ainda se aplica: mantenha o método de autenticação inalterado durante a migração.
GitHub Packages é mais sensível às incompatibilidades de tempo. Quando os pacotes são publicados durante a janela de migração, o sistema cria novos objetos de armazenamento e registros de banco de dados. Para evitar inconsistências, mantenha o modo de manutenção habilitado continuamente desde o início da sincronização delta final por meio da validação bem-sucedida da nova configuração.
Atualize ambas as configurações em conjunto se o mesmo provedor atender a ambos os produtos. Se você tiver configurado GitHub Actions e GitHub Packages usar o mesmo tipo de provedor e estiver migrando ambos, planeje a substituição como uma única janela de manutenção e atualize ambas as configurações antes de desabilitar o modo de manutenção.
Para migrações entre provedores de GitHub Packages armazenamento, entre em contato Suporte do GitHub Enterprise. As movimentações entre provedores não são abordadas aqui.

Para obter mais informações sobre como configurar GitHub Packages o armazenamento, consulte Introdução aos pacotes de GitHub para sua empresa.

Quem pode usar esse recurso?

Neste artigo