Observação: o GitHub Enterprise Server 11.10 é uma versão não compatível de 2014. Para obter uma lista das versões compatíveis, confira “Versões do GitHub Enterprise Server”.
Há suporte para migrações do GitHub Enterprise 11.10.348 e mais recentes. Não há suporte para migrações do GitHub Enterprise 11.10.348 e versões anteriores. Você deve atualizar o 11.10.348 em várias etapas de atualização. Para obter mais informações, confira o procedimento de upgrade para a 11.10.348, "Como fazer upgrade para a última versão".
Para atualizar para a versão mais recente do GitHub Enterprise, você deve migrar para a versão GitHub Enterprise Server 2.1 e só então poderá seguir o processo regular. Para obter mais informações, confira "Visão geral do processo de atualização".
Preparar a migração
-
Revise o guia de provisionamento e instalação e verifique se foram atendidos todos os pré-requisitos necessários para provisionar e configurar o GitHub Enterprise 2.1.23 no seu ambiente. Para obter mais informações, confira "Provisionamento e instalação".
-
Verifique se a instância atual está sendo executada em uma versão de atualização compatível.
-
Configure a versão mais recente do GitHub Enterprise Server Backup Utilities. Para obter mais informações, confira GitHub Enterprise Server Backup Utilities.
- Se você já configurou backups programados usando o GitHub Enterprise Server Backup Utilities, certifique-se de atualizar para a versão mais recente.
- Se você não estiver executando backups programados no momento, configure o GitHub Enterprise Server Backup Utilities.
-
Faça um instantâneo de backup completo inicial da instância atual usando o comando
ghe-backup. Se você já configurou backups programados na instância atual, não será necessário obter o instantâneo.Dica: mantenha a instância online e em uso ativo durante o instantâneo. Você fará outro instantâneo durante a parte de manutenção da migração. Como os backups são incrementais, o instantâneo inicial reduz a quantidade de dados transferidos no instantâneo final, o que pode reduzir o período de manutenção.
-
Determine o método para alternar o tráfego de rede do usuário para a nova instância. Após a migração, todo o tráfego de rede HTTP e Git será direcionado para a nova instância.
- DNS – Recomendamos esse método para todos os ambientes, pois ele é simples e funciona bem mesmo na migração de um datacenter para outro. Antes de iniciar a migração, reduza o TTL do registro DNS para cinco minutos ou menos e permita a propagação da alteração. Quando a migração for concluída, atualize o(s) registro(s) DNS de modo a apontar para o endereço IP da nova instância.
- Atribuição de endereço IP – Esse método só está disponível na migração do VMware para o VMware e não é recomendado, a menos que o método DNS não esteja disponível. Antes de iniciar a migração, você terá que desligar a instância antiga e atribuir seu endereço IP à nova instância.
-
Programe um período de manutenção. O período de manutenção deve abranger tempo suficiente para transferir os dados do host de backup para a nova instância. Esse período varia com base no tamanho do instantâneo de backup e na largura de banda de rede disponível. Durante esse período, sua instância atual ficará indisponível e em modo de manutenção enquanto você migra para a nova instância.
Realizar a migração
-
Provisione uma nova instância do GitHub Enterprise 2.1. Para obter mais informações, confira o guia "Provisionamento e instalação" da plataforma de destino.
-
Em um navegador, vá até o novo endereço IP do appliance réplica e faça o upload da sua licença do GitHub Enterprise.
-
Defina uma senha de administrador.
-
Clique em Migrar.
-
No campo de texto "Adicionar nova chave SSH", cole a chave SSH de acesso do host de backup.
-
Clique em Adicionar chave e em Continuar.
-
Copie o comando
ghe-restoreque você executará no host de backup para migrar os dados para a nova instância. -
Habilite o modo de manutenção na instância antiga e aguarde a conclusão de todos os processos ativos. Para obter mais informações, confira "Habilitar e programar o modo de manutenção".
Observação: a instância não estará disponível para uso normal deste ponto em diante.
-
No host de backup, execute o comando
ghe-backuppara criar um instantâneo de backup final. Essa ação garante a obtenção de todos os dados da instância antiga. -
No host de backup, execute o comando
ghe-restorecopiado na tela de status de restauração da nova instância para restaurar o instantâneo mais recente.$ ghe-restore 169.254.1.1 The authenticity of host '169.254.1.1:122' can't be established. RSA key fingerprint is fe:96:9e:ac:d0:22:7c:cf:22:68:f2:c3:c9:81:53:d1. Are you sure you want to continue connecting (yes/no)? yes Connect 169.254.1.1:122 OK (v2.0.0) Starting restore of 169.254.1.1:122 from snapshot 20141014T141425 Restoring Git repositories ... Restoring GitHub Pages ... Restoring asset attachments ... Restoring hook deliveries ... Restoring MySQL database ... Restoring Redis database ... Restoring SSH authorized keys ... Restoring Elasticsearch indices ... Restoring SSH host keys ... Completed restore of 169.254.1.1:122 from snapshot 20141014T141425 Visit https://169.254.1.1/setup/settings to review appliance configuration. -
Volte à tela de status de restauração da nova instância para confirmar a conclusão da restauração.
-
Clique em Prosseguir para as configurações para revisar e ajustar as informações de configuração e as configurações que foram importadas da instância anterior.
-
Clique em Salvar alterações.
Observação: você poderá usar a nova instância depois de aplicar as configurações e reiniciar o servidor.
-
Alterne o tráfego de rede do usuário da instância antiga para a nova instância usando a atribuição de endereço DNS ou IP.
-
Atualize para a última versão de patch do GitHub Enterprise Server. Para obter mais informações, confira "Visão geral do processo de atualização".