Làm cách nào để thay đổi URL của bản cài đặt GitLab đang hoạt động?


89

Tôi đã thiết lập và chúng tôi đang chạy bản cài đặt mặc định của GitLab v6.0.1 (chúng tôi cũng sắp nâng cấp). Đó là thiết lập "Sản xuất", tuân theo hướng dẫn này chính xác cho bức thư:

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

Bây giờ, làm cách nào để thay đổi URL của một cài đặt đang hoạt động một cách an toàn?

Rõ ràng URL của chúng tôi rất dài và chúng tôi đã đưa ra một URL mới. Tôi đã chỉnh sửa một số tệp cấu hình và "Kiểm tra trạng thái ứng dụng" báo cáo mọi thứ đều ổn. Tôi đã khởi động lại máy chủ để đảm bảo mọi thứ vẫn hoạt động.

Tôi có thể truy cập Nginx tốt, qua SSL ban đầu của chúng tôi. Tôi có thể duyệt qua trang GitLab, tạo kho lưu trữ, v.v. Tôi có thể fork và cam kết tốt.

Tất cả dường như là OK; nhưng, vì đây không phải là môi trường gốc đối với tôi, tôi muốn kiểm tra lại xem tôi đã làm mọi thứ để đổi tên trang web GitLab chưa.

Các tệp tôi đã chỉnh sửa là:

/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
Người dùng cài đặt Omnibus: Quá trình này khác .
Jonathon Reinhart

Câu trả lời:


29

Bạn đã làm mọi thứ một cách chính xác!

Bạn cũng có thể thay đổi cấu hình email, tùy thuộc vào việc máy chủ email có phải là cùng một máy chủ hay không. Cấu hình email ở dạng gitlab.yml cho các thư do GitLab gửi và cũng là email quản trị.


Tôi đang băn khoăn về điều này, vì tôi đã đặt email Từ (và email khác) được gửi từ bí danh email của nhóm nhà phát triển toàn cầu của chúng tôi trên một miền khác. Như: devs@domain-2.com. Lý do là để cho phép các nhà phát triển nhấn Trả lời để đưa ra nhận xét về các yêu cầu Kéo hoặc các email chung khác.
eduncan911

2
Quay lại để đánh dấu đây là một câu trả lời vì GitLab đã hoạt động tốt kể từ khi tôi thực hiện những thay đổi ở trên.
eduncan911

159

GitLab Omnibus

Đối với cài đặt Omnibus, nó có một chút khác biệt.

Vị trí chính xác trong cài đặt Omnibus là:

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

Cuối cùng, bạn sẽ cần phải thực thi sudo gitlab-ctl reconfiguresudo gitlab-ctl restartcác thay đổi sẽ được áp dụng.


Tôi đã thực hiện những thay đổi ở những nơi không đúng và chúng đang bị thổi bay.

Các đường dẫn không chính xác là:

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

Hãy chú ý đến những cảnh báo có nội dung:

# 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`.

Tôi có GitLab Omnibus trên máy chủ nội bộ nhưng có thể truy cập Internet từ một URL khác. Các external_urltùy chọn trong /etc/gitlab/gitlab.rblà địa điểm chính xác để thiết lập các URL để dự án mà Git / HTTP URL sẽ là chính xác.
Matthew Clark

Ngoài ra, sau thay đổi này và sau khi chạy cấu hình lại gitlab-ctl, bạn phải khởi động lại máy chủ để quá trình cấu hình lại nginx diễn ra.
Dejv

Bạn nói đúng, đây là nơi duy nhất và tốt nhất để thay đổi các cài đặt này. Phần còn lại được tạo ra.
nguy hiểm 89

4
@Dejv bạn không cần phải khởi động lại. Khởi động lại dịch vụ nginx là đủ.
Jonathon Reinhart

Cảm ơn @JonathonReinhart công việc này cho tôi, nhưng trước tiên đừng quên làm sudo gitlab-ctl stop unicornsudo gitlab-ctl stop sidekiq
Cyberguille

7

Trên thực tế, điều này KHÔNG hoàn toàn chính xác. Tôi đã đến trang này, cố gắng tự trả lời câu hỏi này vì chúng tôi đang chuyển đổi máy chủ GitLab sản xuất từ http://sang https://hầu hết mọi thứ đều hoạt động như mô tả ở trên, nhưng khi bạn đăng nhập vàohttps://server và mọi thứ đều ổn ... ngoại trừ khi bạn duyệt đến một dự án hoặc kho lưu trữ, và nó hiển thị các hướng dẫn SSH và HTTP ... Nó cho biết "http" và các hướng dẫn nó hiển thị cũng cho biết "http".

Mặc dù vậy, tôi đã tìm thấy một số thứ khác cần chỉnh sửa:

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

...

Cảm ơn Edward vì nhận xét của bạn (bạn đã đăng Câu trả lời cho câu hỏi này, trong khi đó thực sự là một nhận xét cho một câu trả lời khác của @Razer ở trên). Bạn có thể muốn chỉnh sửa câu trả lời (bình luận) của mình để cho người khác biết bạn đang sử dụng phiên bản nào. Tuy nhiên, chúng tôi đã sử dụng thành công GitLab chỉ với những thay đổi này kể từ khi tôi đăng câu hỏi này. chúng tôi có thể duyệt qua các kho và dự án trong toàn nhóm - hoàn toàn qua SSL chỉ trong mạng công ty của chúng tôi.
eduncan911

2
Tôi biết, nhưng câu trả lời khác được đánh dấu là câu trả lời được chấp nhận. Vì vậy, tôi cố ý không muốn bình luận về nó, vì điều đó không gây chú ý. Đăng một câu trả lời khác rõ ràng hơn một chút. Tôi đang sử dụng gitlab-shell 1.8.0 mới nhất và gitlab 6.4 ổn định. Chúng tôi cũng có thể làm việc, hoàn toàn thông qua https và ssh. Nhưng chúng ta phải nhớ thay thế http bằng https mỗi khi sao chép và dán các hướng dẫn hoặc URL từ giao diện web sang ứng dụng khách git.
Edward Ned Harvey

Tôi nghe có vẻ rằng bạn đã bỏ lỡ một URL trong một trong các tệp cấu hình. Chúng tôi chỉ sử dụng HTTPS và cố tình vô hiệu hóa HTTP trước khi "di chuyển" trong câu hỏi / mô tả ban đầu của tôi tại đây. Vì vậy, việc có nó độc quyền dưới dạng HTTPS cho phép chúng tôi di chuyển theo các hướng dẫn đã đăng một cách dễ dàng. Tuy nhiên, nếu bạn đang chạy môi trường http / https ở chế độ hỗn hợp, rất có thể bạn cần chỉnh sửa một số dòng bổ sung.
eduncan911

Cảm ơn bạn đã nhận xét, nhưng (a) Tôi đã kiểm tra lại xem tôi đã thực hiện các thay đổi được đề cập trong câu trả lời ở trên chưa. (b) Tôi đã cài đặt quy trình sau và tôi đã thực hiện lại quy trình đó để đảm bảo rằng tôi đã thay đổi mọi vị trí của URL. (c) Chúng tôi không chỉ thay đổi http thành https, chúng tôi còn thay đổi tên máy chủ. Thay đổi tên máy chủ đã hoạt động, có nghĩa là sửa đổi tệp cấu hình đã thành công. (d) Tôi nghi ngờ về thiết lập của bạn. Bạn có thể duyệt đến một dự án trong gitlab của mình và ở trên cùng nơi nó hiển thị cho bạn URL SSH và HTTP, chuyển đổi giữa ssh và http và xem liệu URL mà nó hiển thị có "http" hay "https?"
Edward Ned Harvey

1
Câu trả lời này bây giờ là tham vọng. Bạn nói "Thực ra, điều này KHÔNG hoàn toàn chính xác." Nhưng cái này là gì"? Bạn đang đề cập đến điều gì đó trong câu hỏi? Một trong những câu trả lời khác?
Jonathon Reinhart

1

Có ghi chú chi tiết về điều này đã giúp tôi hoàn toàn, nằm ở đây .

Jonathon Reinhart đã trả lời bằng key bit, để chỉnh sửa /etc/gitlab/gitlab.rb , hãy thay đổi external_url và sau đó chạysudo gitlab-ctl reconfigure; sudo gitlab-ctl restart

Tuy nhiên, tôi cần phải đi xa hơn một chút và các tài liệu tôi liên kết ở trên đã giải thích điều đó. Vì vậy, những gì tôi kết thúc với trông giống như:

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

Ở trên, tôi đã khai báo rõ ràng vị trí của các phần mềm SSL của tôi trên máy chủ này. Và tất nhiên sau đó là

sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Ngoài ra, khi bạn chuyển gói omnibus sang https, nginx đi kèm sẽ chỉ phân phát trên cổng 443. Vì tất cả nội dung của tôi được truy cập thông qua proxy ngược nên phần này có khả năng quan trọng.

Khi tôi xem xét vấn đề này, tôi đã gặp phải vấn đề gì đó và thật hữu ích khi tìm thấy nhật ký nginx thực tế, điều này dẫn tôi đến đó:

sudo gitlab-ctl tail nginx
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.