Como alteramos a URL de uma instalação GitLab funcional?


89

Eu configurei e estamos executando uma instalação padrão do GitLab v6.0.1 (estamos prestes a atualizar também). Foi uma configuração de "Produção", seguindo este guia exatamente ao pé da letra:

https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/installation.md

Agora, como alteramos com segurança a URL de uma instalação funcional?

Aparentemente, nosso URL é muito longo e criamos um novo URL. Eu editei vários arquivos de configuração e o relatório "Verificações de status do aplicativo" está tudo OK. Reinicializei o servidor para garantir que as coisas ainda estejam funcionando.

Posso acessar o Nginx perfeitamente, em nosso SSL original. Posso navegar no site GitLab, criar um repositório, etc. Posso fazer um fork e fazer um commit muito bem.

Tudo parece estar bem; mas, como este não é um ambiente nativo para mim, gostaria de verificar novamente se fiz tudo para renomear um site GitLab.

Os arquivos que editei são:

/etc/hosts
  127.0.0.1  localhost
  10.0.0.10  wake.domain.com    wake
  10.0.0.10  git.domain.com     git

/home/git/gitlab/config/gitlab.yml
  production: &base
    gitlab:
      host: git.domain.com

/home/git/gitlab-shell/config.yml
  gitlab_url: "https://git.domain.com"
  ^- yes, we are on SSL and that is working, even on a new URL

/etc/nginx/sites-available/gitlab
  server {
    server_name git.domain.com

9
Usuários de instalação coletiva: o processo é diferente .
— Jonathon Reinhart

Respostas:


29

Você fez tudo corretamente!

Você também pode alterar a configuração de e-mail, dependendo se o servidor de e-mail também é o mesmo servidor. A configuração do email está em gitlab.yml para os emails enviados pelo GitLab e também para o email admin.


Eu estava me perguntando sobre isso, porque configurei o e-mail De (e o outro e-mail) para ser enviado de nosso alias de e-mail do grupo de desenvolvedores global que está em um domínio diferente. Como: devs@domain-2.com. O motivo é permitir que os desenvolvedores cliquem em Responder para fazer comentários sobre solicitações pull ou outros e-mails gerais.
— eduncan911

2
Voltei para marcar isso como uma resposta, pois o GitLab está funcionando bem desde que fiz as alterações acima.
— eduncan911

159

GitLab Omnibus

Para uma instalação Omnibus, é um pouco diferente.

O local correto em uma instalação Omnibus é:

/etc/gitlab/gitlab.rb
    external_url 'http://gitlab.example.com'

Finalmente, você vai precisar para executar sudo gitlab-ctl reconfiguree sudo gitlab-ctl restartpara que as alterações se aplicam.


Eu estava fazendo alterações nos lugares errados e elas estavam ficando fascinadas.

Os caminhos incorretos são:

/opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml
/var/opt/gitlab/.gitconfig
/var/opt/gitlab/nginx/conf/gitlab-http.conf

Preste atenção aos avisos que dizem:

# This file is managed by gitlab-ctl. Manual changes will be
# erased! To change the contents below, edit /etc/gitlab/gitlab.rb
# and run `sudo gitlab-ctl reconfigure`.

Tenho o GitLab Omnibus em um servidor interno, mas acessível da Internet a partir de um URL diferente. A external_urlopção em /etc/gitlab/gitlab.rbera o local correto para definir a URL para que as URLs do Git / HTTP do projeto estivessem corretas.
— Matthew Clark

Além disso, após esta mudança e depois de executar gitlab-ctl reconfigure, você deve reiniciar o servidor para que a reconfiguração do nginx ocorra.
— Dejv

Você está certo, este é o único e melhor lugar para alterar essas configurações. O resto é gerado.
— hazard89

4
@Dejv você não deve ter que reiniciar. Reiniciar o serviço nginx deve ser suficiente.
— Jonathon Reinhart

Obrigado @JonathonReinhart este trabalho para mim, mas primeiro não se esqueça de fazer sudo gitlab-ctl stop unicornesudo gitlab-ctl stop sidekiq
— Cyberguille

7

Na verdade, isso NÃO é totalmente correto. Cheguei a esta página tentando responder a essa pergunta sozinho, pois estamos fazendo a transição do servidor GitLab de produção de http://para https://e a maioria das coisas está funcionando conforme descrito acima, mas quando você faz o login https://servere tudo parece bem ... exceto quando você navega para um projeto ou repositório e exibe as instruções SSH e HTTP ... Diz "http" e as instruções que exibe também dizem "http".

No entanto, encontrei mais algumas coisas para editar:

/home/git/gitlab/config/gitlab.yml
  production: &base
    gitlab:
      host: git.domain.com

      # Also edit these:
      port: 443
      https: true
...

e

/etc/nginx/sites-available/gitlab
  server {
    server_name git.domain.com;

    # Also edit these:
    listen 443 ssl;
    ssl_certificate     /etc/ssl/certs/somecert.crt;
    ssl_certificate_key /etc/ssl/private/somekey.key;

...

Obrigado Edward por seu comentário (você postou uma Resposta para esta pergunta, quando na verdade é um comentário para uma resposta diferente de @Razer acima). Você pode querer editar sua resposta (comentário) para indicar qual versão você usa para os outros. Mas, temos usado com sucesso o GitLab apenas com essas mudanças desde que postei esta pergunta. podemos navegar em repos e projetos em toda a equipe - inteiramente por SSL, exclusivamente em nossa rede corporativa.
— eduncan911

2
Eu sei, mas a outra resposta está marcada como uma resposta aceita. Então, propositalmente, não quis comentar sobre isso, pois isso não chama atenção. Postar outra resposta é um pouco mais pronunciado. Estou usando o gitlab-shell 1.8.0 e o gitlab 6.4 estável mais recentes. Também podemos trabalhar, inteiramente via https e ssh. Mas temos que nos lembrar de substituir http por https sempre que copiar e colar instruções ou URL da interface da web para o cliente git.
— Edward Ned Harvey

Parece-me que você perdeu uma URL em um dos arquivos de configuração. Nós só usamos HTTPS e desabilitamos o HTTP propositalmente antes da "mudança" na minha pergunta / descrição original aqui. Portanto, tê-lo exclusivamente como HTTPS nos permitiu mover de acordo com as instruções postadas sem problemas. Mas, se você estiver executando um ambiente http / https de modo misto, provavelmente há algumas linhas adicionais que você precisa editar.
— eduncan911

Obrigado pelo comentário, mas (a) Verifiquei duas vezes se fiz as alterações mencionadas na resposta acima. (b) Instalei o procedimento a seguir e o segui novamente para ter certeza de que alterei todos os locais em que o URL está. (c) Não mudamos apenas http para https, também mudamos o nome do host. A alteração do nome do host funcionou, o que significa que as modificações do arquivo de configuração foram bem-sucedidas. (d) Estou cético quanto à sua configuração. Você pode navegar até um projeto em seu gitlab e, na parte superior, onde ele mostra a URL SSH e HTTP, alternar entre ssh e http e ver se a URL exibida tem "http" ou "https?"
— Edward Ned Harvey

1
Essa resposta agora é ambígua. Você afirma "Na verdade, isso NÃO é totalmente correto." Mas o que é isso"? Você está se referindo a algo na pergunta? Uma das outras respostas?
— Jonathon Reinhart de

1

Existem notas detalhadas sobre isso que me ajudaram completamente, localizadas aqui .

Jonathon Reinhart já respondeu com a parte chave, para editar /etc/gitlab/gitlab.rb , alterar o external_url e depois executarsudo gitlab-ctl reconfigure; sudo gitlab-ctl restart

No entanto, eu precisava ir um pouco mais longe e os documentos vinculados acima explicaram isso. Então, o que eu acabei parece com:

external_url 'https://gitlab.toilethumor.com'
nginx['ssl_certificate'] = "/www/ssl/star_toilethumor.com-chained.crt"
nginx['ssl_certificate_key'] = "/www/ssl/star_toilethumor.com.key"
nginx['proxy_set_headers'] = {
 "X-Forwarded-Proto" => "http",
 "CUSTOM_HEADER" => "VALUE"
}

Acima, declarei explicitamente onde meus goodies SSL estão neste servidor. E é claro que é seguido por

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Além disso, quando você muda o pacote omnibus para https, o nginx agrupado só servirá na porta 443. Como todas as minhas coisas são acessadas por proxy reverso, essa parte foi potencialmente significativa.

Enquanto eu passava por isso, eu estraguei algo e foi útil encontrar os logs reais do nginx, isso me levou até lá:

sudo gitlab-ctl tail nginx
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.