Як змінити URL робочої інсталяції GitLab?

89

Я налаштував, і ми запускаємо встановлену за замовчуванням GitLab v6.0.1 (ми також збираємось оновити). Це було налаштування "Виробництво", точно дотримуючись цього посібника:

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

Тепер, як нам безпечно змінити URL-адресу робочої інсталяції?

Очевидно, наша URL-адреса дуже довга, і ми придумали нову URL-адресу. Я відредагував низку файлів конфігурації, і у звіті "Перевірка стану програми" все гаразд. Я перезавантажив сервер, щоб переконатися, що речі все ще працюють.

Я можу отримати доступ до Nginx дуже добре через наш оригінальний SSL. Я можу переглядати сайт GitLab, створювати сховище і т. Д. Я можу розгалужуватись і робити коміти просто чудово.

Здається, все в порядку; але, оскільки це не рідне середовище для мене, я хотів ще раз перевірити, чи зробив я все, щоб перейменувати сайт GitLab.

Відредаговані файли:

/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
gitlab 
— eduncan911
джерело
9
Користувачі встановлення Omnibus: Процес інший .
— Джонатан Рейнхарт

Відповіді:

29

Ви все зробили правильно!

Ви також можете змінити конфігурацію електронної пошти, залежно від того, чи є той самий сервер електронної пошти. Конфігурація електронної пошти знаходиться в gitlab.yml для листів, надісланих GitLab, а також електронної пошти адміністратора.

— Razer
джерело
Мені було цікаво з цього приводу, оскільки я встановив, що електронна пошта Від (та інша електронна пошта) надсилатиметься з нашої глобальної групи розробників, що знаходиться в іншому домені. Подобається: devs@domain-2.com. Причина полягає в тому, щоб дозволити розробникам натискати "Відповісти", щоб коментувати запити на витягування або інші загальні електронні листи.
— eduncan911
2
Повернувся, щоб позначити це як відповідь, оскільки GitLab працює нормально з тих пір, як я зробив ці зміни вище.
— eduncan911
159

GitLab Omnibus

Що стосується інсталяції Omnibus, це трохи інше.

Правильне місце в омнібус установки є:

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

Нарешті, вам потрібно буде виконати, sudo gitlab-ctl reconfigureі sudo gitlab-ctl restartтому зміни застосовуються.

Я вносив зміни не в тих місцях, і вони були здуті.

Ці неправильні шляхи є:

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

Зверніть увагу на ті попередження:

# 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`.
— Джонатан Рейнхарт
джерело
У мене є GitLab Omnibus на внутрішньому сервері, але доступний з Інтернету за іншою URL-адресою. external_urlВаріант в /etc/gitlab/gitlab.rbбуло правильне місце , щоб встановити URL , так що проект Git / HTTP URL , буде правильним.
— Метью Кларк,
Крім того, після цієї зміни та після запуску перенастроювання gitlab-ctl, вам доведеться перезавантажити сервер для реконфігурації nginx.
— Dejv
Ви маєте рацію, це єдине і найкраще місце для зміни цих налаштувань. Решта генерується.
— danger89
4
@Dejv, вам не доведеться перезапускати. Перезапуску служби nginx має бути достатньо.
— Джонатан Рейнхарт
Дякую @JonathonReinhart для мене цю роботу, але спочатку не забудьте зробити sudo gitlab-ctl stop unicornіsudo gitlab-ctl stop sidekiq
— Cyberguille
7

Насправді це НЕ зовсім правильно. Я потрапив на цю сторінку, намагаючись відповісти на це питання сам, оскільки ми переводимо виробничий сервер GitLab з http://на, https://і більшість речей працює, як описано вище, але коли ви входите вhttps://server і все виглядає нормально ... за винятком перегляду проекту або сховище, і воно відображає інструкції SSH та HTTP ... У ньому написано "http", а в інструкціях, що відображаються, також написано "http".

Я знайшов ще кілька речей для редагування:

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

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

і

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

...
— Едвард Нед Харві
джерело
Дякую Едварду за ваш коментар (ви опублікували відповідь на це запитання, коли насправді це коментар до іншої відповіді @Razer вище). Можливо, ви захочете відредагувати свою відповідь (коментар), щоб вказати, яку версію ви використовуєте для інших. Але ми успішно використовуємо GitLab лише з цими змінами з моменту розміщення цього питання. ми можемо переглядати репозиторії та проекти в команді - повністю через SSL, виключно в нашій корпоративній мережі.
— eduncan911
2
Я знаю, але інша відповідь позначена як прийнята відповідь. Тому я навмисно не хотів це коментувати, оскільки це не привертає уваги. Публікація іншої відповіді трохи виразніше. Я використовую останню версію gitlab-shell 1.8.0 та gitlab 6.4 стабільну. Ми також можемо працювати, повністю через https та ssh. Але ми повинні пам’ятати про заміну http на https кожного разу, коли копіюємо та вставляємо інструкції або URL-адреси з веб-інтерфейсу в git-клієнт.
— Едвард Нед Харві,
Мені здається, що ви пропустили URL-адресу в одному з файлів конфігурації. Ми використовуємо лише HTTPS та навмисно відключені HTTP перед "переміщенням" у моєму оригінальному запитанні / описі тут. Тож наявність його виключно як HTTPS дозволило нам рухатися відповідно до розміщених інструкцій безглуздо. Але якщо ви використовуєте змішане середовище http / https, швидше за все, є кілька додаткових рядків, які потрібно відредагувати.
— eduncan911
Дякуємо за коментар, але (а) Я ще раз перевірив, що вніс зміни, на які посилається вище відповідь. (b) Я встановив таку процедуру, і я повторив цю процедуру, щоб переконатися, що я змінив кожне місце, де знаходиться URL. (c) Ми не лише змінили http на https, ми також змінили ім'я хосту. Зміна імені хосту спрацювала, що означає, що модифікація файлу конфігурації була успішною. (d) Я скептично ставлюсь до Вашої установки. Чи можете ви переглянути проект у своєму gitlab, а вгорі, де він показує вам URL-адреси SSH і HTTP, переключити між ssh і http і подивитися, чи відображається в URL-адресі, що відображається, "http" або "https?"
— Едвард Нед Харві,
1
Ця відповідь зараз неоднозначна. Ви заявляєте "Насправді, це НЕ зовсім правильно". але що таке "це"? Ви маєте на увазі щось у питанні? Одна з інших відповідей?
— Джонатан Рейнхарт,
1

Є докладні примітки з цього приводу, які допомогли мені повністю, розташовані тут .

Джонатан Рейнхарт уже відповів ключем для редагування /etc/gitlab/gitlab.rb , змінити external_url, а потім запуститиsudo gitlab-ctl reconfigure; sudo gitlab-ctl restart

Однак мені потрібно було піти трохи далі, і документи, на які я посилався вище, пояснили це. Отже, те, чим я закінчив, виглядає так:

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

Вище я чітко заявив, де на цьому сервері знаходяться мої SSL-переваги. І це, звичайно, слідує

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Крім того, коли ви перемикаєте пакет omnibus на https, в комплекті nginx буде обслуговуватися лише на порту 443. Оскільки всі мої матеріали отримуються через зворотний проксі, ця частина була потенційно значущою.

Проходячи це, я щось зіпсував, і корисно було знайти фактичні журнали nginx, це привело мене туди:

sudo gitlab-ctl tail nginx
— Джеймс Т Снелл
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.