¿Cómo cambiamos la URL de una instalación de GitLab en funcionamiento?


He configurado y estamos ejecutando una instalación predeterminada de GitLab v6.0.1 (también estamos a punto de actualizar). Fue una configuración de "Producción", siguiendo esta guía precisamente al pie de la letra:

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

Ahora, ¿cómo cambiamos con seguridad la URL de una instalación en funcionamiento?

Aparentemente nuestra URL es muy larga y hemos creado una nueva URL. He editado una serie de archivos de configuración y el "Verificación del estado de la aplicación" informe todo está bien. He reiniciado el servidor para asegurarme de que las cosas sigan funcionando.

Puedo acceder a Nginx muy bien, a través de nuestro SSL original. Puedo navegar por el sitio de GitLab, crear un repositorio, etc. Puedo bifurcarme y comprometerme muy bien.

Todo parece estar bien; pero, ya que este no es un entorno nativo para mí, quería comprobar que he hecho todo lo posible para cambiar el nombre de un sitio GitLab.

Los archivos que he editado son:

/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
 74
Author: Peter Mortensen, 2013-10-18

4 answers

Hiciste todo correctamente!

También puede cambiar la configuración de correo electrónico, dependiendo de si el servidor de correo electrónico es también el mismo servidor. La configuración del correo electrónico está en gitlab.yml para los correos enviados por GitLab y también el admin-email.

 25
Author: Razer,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-07-04 19:06:25

[5]} GitLab Omnibus

Para una instalación Omnibus, es un poco diferente.

El lugar correcto en una instalación Omnibus es:

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

Finalmente, necesitará ejecutar sudo gitlab-ctl reconfigure y sudo gitlab-ctl restart para que se apliquen los cambios.


Yo estaba haciendo cambios en los lugares equivocados que estaban pasmados.

Los caminos incorrectos son:

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

Presta atención a las advertencias que dicen:

# 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`.
 135
Author: Jonathon Reinhart,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-10-30 21:14:19

En realidad, esto NO es totalmente correcto. Llegué a esta página, tratando de responder a esta pregunta yo mismo, ya que estamos haciendo la transición del servidor GitLab de producción de http:// a https:// y la mayoría de las cosas funcionan como se describió anteriormente, pero cuando inicias sesión en https://server y todo se ve bien ... excepto cuando navega a un proyecto o repositorio, y muestra las instrucciones SSH y HTTP... Dice: "http" y las instrucciones que muestra también decir "http".

Encontré algunas cosas más para editar aunque:

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

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

Y

/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;

...
 7
Author: Edward Ned Harvey,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-07-04 19:07:44

Hay notas detalladas sobre esto que me ayudaron completamente, ubicadas aquí.

Jonathon Reinhart ya ha respondido con el bit clave, para editar /etc/gitlab/gitlab.rb , altere el external_url y luego ejecute sudo gitlab-ctl reconfigure; sudo gitlab-ctl restart

Sin embargo, necesitaba ir un poco más allá y los documentos que vinculé anteriormente lo explicaron. Así que lo que terminé con parece:

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"
}

Anteriormente, he declarado explícitamente dónde están mis golosinas SSL en este servidor. Y eso es, por supuesto, seguido por

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Además, cuando cambia el paquete omnibus a https, el nginx incluido solo servirá en el puerto 443. Dado que todas mis cosas se alcanzan a través de proxy inverso, esta parte era potencialmente significativa.

Mientras pasaba por esto, arruiné algo y fue útil encontrar los registros de nginx reales, esto me llevó allí:

sudo gitlab-ctl tail nginx
 1
Author: James T Snell,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-10-02 16:45:02