Esta versão do GitHub Enterprise Server foi descontinuada em 2024-03-26. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a última versão do GitHub Enterprise Server. Para obter ajuda com a atualização, entre em contato com o suporte do GitHub Enterprise.

Atualizar o cluster

Use o shell administrativo (SSH) a fim de atualizar um cluster do GitHub Enterprise Server para a versão mais recente.

Quem pode usar esse recurso?

A GitHub determina a qualificação para clustering e deve habilitar a configuração para a licença da instância. O clustering requer um planejamento cuidadoso e sobrecarga administrativa adicional. Para obter mais informações, confira "Sobre clustering".

Neste artigo

Sobre as atualizações para um cluster do GitHub Enterprise Server

O GitHub Enterprise Server está sempre em aprimoramento, com novas funcionalidades e correções de erros introduzidas por meio de recursos e versões de patch. Você é responsável por atualizações de sua instância. Para obter mais informações, confira "Sobre atualizações para novas versões".

Para atualizar uma instância, planeje e comunique a atualização, escolha o pacote apropriado, faça backup dos dados e, em seguida, execute a atualização.

Atualizar com hotpatch

Você pode atualizar o GitHub Enterprise Server para a versão mais recente do patch usando um hotpatch.

Você pode usar hotpatching para atualizar para uma versão de patch mais recente, mas não uma versão de recursos. Por exemplo, é possível atualizar da 2.10.1 para a 2.10.5 porque elas estão na mesma série de recursos, mas não da 2.10.9 para a 2.11.0 porque elas estão em séries de recursos diferentes.

Os hotpatches geralmente não exigem reinicialização. Se um hotpatch exigir uma reinicialização, as notas de versão do GitHub Enterprise Server indicarão o requisito.

Os hotpatches exigem uma execução de configuração, o que pode causar um breve período de erros ou falta de resposta para alguns ou todos os serviços em sua instância do GitHub Enterprise Server. Você não precisa habilitar o modo de manutenção durante a instalação de um hotpatch, mas isso garantirá que os usuários vejam uma página de manutenção em vez de erros ou tempos limite. Para obter mais informações, confira "Habilitar e programar o modo de manutenção". O script de instalação do hotpatch instala o hotpatch em cada nó do cluster e reinicia os serviços na sequência adequada para evitar tempo de inatividade.

  1. Faça backup de seus dados com GitHub Enterprise Server Backup Utilities.

  2. No shell administrativo de qualquer nó, use o comando ghe-cluster-hotpatch para instalar o hotpatch mais recente. Você pode informar uma URL para o hotpatch ou baixá-la manualmente e especificar um nome de arquivo local.

    ghe-cluster-hotpatch https://HOTPATCH-URL/FILENAME.hpkg

Atualizar com pacote de atualização

Atualize para a versão mais recente do cluster do GitHub Enterprise Server usando um pacote de atualização. Por exemplo, você pode atualizar de 2.11 para 2.13

Preparar para a atualização

  1. Veja em Configuração de rede do cluster a versão para a qual você está atualizando e atualize sua configuração conforme necessário.

  2. Faça backup de seus dados com GitHub Enterprise Server Backup Utilities.

  3. Programe um período de manutenção para os usuários finais do cluster do GitHub Enterprise Server, já que ele ficará indisponível para uso regular durante a atualização. O modo de manutenção bloqueia o acesso de usuários e impede alterações de dados durante a atualização do cluster.

  4. Na página de download do GitHub Enterprise Server, copie a URL do arquivo .pkg de atualização para a área de transferência.

  5. No shell administrativo de qualquer nó, use o comando ghe-cluster-each combinado com curl para baixar o pacote de versão para cada nó em uma única etapa. Como argumento, use a URL que você copiou na etapa anterior.

    $ ghe-cluster-each -- "cd /home/admin && curl -L -O  https://PACKAGE-URL.pkg"
> ghe-app-node-1:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-app-node-1:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  24.2M      0  0:00:20  0:00:20 --:--:-- 27.4M
> ghe-data-node-2:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-data-node-2:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  21.3M      0  0:00:23  0:00:23 --:--:-- 25.8M
> ghe-data-node-1:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-data-node-1:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  19.7M      0  0:00:25  0:00:25 --:--:-- 25.6M
> ghe-app-node-2:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-app-node-2:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  19.8M      0  0:00:25  0:00:25 --:--:-- 17.6M
> ghe-data-node-3:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
> ghe-data-node-3:                                  Dload  Upload   Total   Spent    Left  Speed
> 100  496M  100  496M    0     0  19.7M      0  0:00:25  0:00:25 --:--:-- 25.5M

  6. Identifique o nó MySQL primário, que é definido como mysql-master = <hostname> em cluster.conf. Esse nó será atualizado por último.

Atualizar os nós de cluster

  1. Habilite o modo de manutenção de acordo com a janela agendada conectando-se ao shell administrativo de qualquer nó de cluster e executando ghe-cluster-maintenance -s.

  2. Com exceção do nó MySQL primário, conecte-se ao shell administrativo de cada um dos nós do GitHub Enterprise Server. Execute o comando ghe-upgrade, fornecendo o nome do arquivo de pacote que você baixou na Etapa 4 de Preparação para atualizar:

    $ ghe-upgrade PACKAGE-FILENAME.pkg
> *** verifying upgrade package signature...
>  497MB 0:00:04 [ 117MB/s] [==========================================>] 100%
> gpg: Signature made Fri 19 Feb 2016 02:33:50 PM UTC using RSA key ID 0D65D57A
> gpg: checking the trustdb
> gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
> gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
> gpg: Good signature from "GitHub Enterprise (Upgrade Package Key) > <enterprise@github.com>"

  3. Assim que for concluído, o processo de atualização reinicializará o nó. Verifique se é possível usar ping em cada nó após a reinicialização.

  4. Conecte-se ao shell administrativo do nó primário MySQL. Execute o comando ghe-upgrade, fornecendo o nome do arquivo de pacote que você baixou na Etapa 4 de Preparação para atualizar:

    $ ghe-upgrade PACKAGE-FILENAME.pkg
> *** verifying upgrade package signature...
>  497MB 0:00:04 [ 117MB/s] [==========================================>] 100%
> gpg: Signature made Fri 19 Feb 2016 02:33:50 PM UTC using RSA key ID 0D65D57A
> gpg: checking the trustdb
> gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
> gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
> gpg: Good signature from "GitHub Enterprise (Upgrade Package Key) > <enterprise@github.com>"

  5. Assim que for concluído, o processo de atualização reinicializará o nó primário MySQL. Verifique se é possível usar ping em cada nó após a reinicialização.

  6. Conecte-se ao shell administrativo do nó MySQL primário e execute o comando ghe-cluster-config-apply.

  7. Quando ghe-cluster-config-apply estiver concluído, verifique se os serviços estão em um estado íntegro executando ghe-cluster-status.

  8. Saia do modo de manutenção do shell administrativo de qualquer nó executando ghe-cluster-maintenance -u.