從零開始搭建Gitlab服務器

Gitlab簡介

最近感受就是在不斷的搭建/遷移版本服務器，而如今市面上關於版本服務器搭建的指南都流於表面，真正深刻骨骼的少之又少，每每以偏概全不少關鍵點並未說起。而版本服務器的搭建每每是一個初創型或中小型公司迫切須要解決的問題。

目前市用戶量和口碑較好的Git服務提供商，屈指可數。國外的話 GitHub，BitBucket 都是不錯的選擇，但國際形勢變幻莫測，須要隨時備好*。國內的話Coding用戶體驗就作的很不錯，很切合碼農們的審美， 開源中國的碼雲**也有對應的代碼託管服務，不過自從他們家Maven倉庫鏡像下架事件後已不推薦再用，不久後被阿里收購不是沒有可能。

各個版本管理軟件各有優劣，大多數的企業和團隊爲了隱私性的須要，選擇了目前市面上功能和體驗都十分給力的Gitlab做爲非開源的代碼管理平臺。

Gitlab目前有兩種不一樣的版本，社區/我的版和企業版
GitLab社區版是徹底免費的，不但能創建免費的私有倉庫並且沒有數量上限，參與人員也沒有數量限制，還能設置成員的權限，甚至細緻到具體某條分支的權限，以及強大的工做流等等。徹底知足咱們平常開發、投產所須要的版本控制功能。
Gitlab企業版支持LDAP架構和對應功能，以達到更高的處理性能和存儲效率，並提供其餘更多模塊和服務支持

參考連接：Gitlab社區版/企業版對比

安裝前的準備

目前來講，Gitlab的發行版本並非支持全部Linux/Unix內核版本，如下幾種可能仍是須要廣大同窗們經過其開源源碼進行編譯安裝 。

• Arch Linux
• Fedora
• FreeBSD
• Gentoo
• macOS

除此以外，存儲/CPU/內存分別影響到Gitlab所能運行的效率和能支持到的性能指標，爲了避免讓開發童靴們在協做辦公中怒砸鍵盤，官方給出的硬件建議能夠結合公司和團隊規模做爲版本服務器硬件選型的重要參考。

CPU

按照CPU核心數量，官方建議大體有以下劃分：

• 單核： 能夠支持100個左右的用戶併發，可是可能會有些許卡頓，畢竟全部的先後臺處理都須要這個苦逼的核心一人包辦。
• 雙核： 約500併發用戶，這也是官方給出的建議最低配置
• 4核： 約2,000併發用戶
• 8核/16核： 約5,000/10,000併發用戶
• 32核/64核： 官方給出數據中，核心數和用戶數基本成線性增加了，可是實際使用中，發現其對CPU和內存佔用明顯過大，能維持在官方1/10的性能指標已是不錯的狀況了，因此其應該存在必定的內存泄露

內存

官方建議的內存是最好不要低於4G，否則每次push和commit都會讓你痛不欲生。8G內存就能很穩的支持1,000個併發數，因此至少選擇8G以上的內存來搭建你的版本服務器。

Gitlab安裝

基本構成

咱們以CentOs 7.4舉例，CentOs 7.x在防火牆等一系列組件上的安裝配置和6.x稍微差別，請靈活搬磚。總的來講，徹底正確的把Gitlab弄起來，大概包含如下操做和模塊支持，跳過其中某幾步安裝成功並不表明操做步驟就徹底正確；可是若是安裝出現問題，能夠回頭詳細來看看此處的描述，檢查是否遺漏了某個基礎模塊/組件支持或者忘記了某些配置項。

• 基礎操做系統(CentOs 7.4)和對應的包/依賴項
• Ruby
• Go
• 系統用戶或分配用戶(建議單獨分配)
• 數據庫(目前是postgresql)
• Redis
• Gitlab
• Web服務
• 防火牆安裝、配置

不一樣的安裝模式

1.傻瓜模式/Omnibus自動擋

GitLab官方提供了Omnibus安裝包來安裝，整合了大部分的套件（Nginx、ruby on rails、git、redis、postgresql等），讓使用者不用額外安裝這些軟件，減輕了絕大部分安裝量。
咱們通常採用這種方式來安裝，但自動擋所帶來的隱患和衝突也會較多。特別是若是以前的服務器原本就不單純，單獨安裝了nginx、redis之類的組件，再經過這種模式安裝會產生一系列的衝突和配置問題，好比反向代理配置異常、服務訪問不到等等，這個咱們之後有時間再具體說。

參考連接：Gitlab Omnibus安裝包

2.組件依賴模式/手動擋

2.1 安裝依賴包並配置postfix郵件服務

yum install curl openssh-server openssh-clients postfix > cronie
 service postfix start
 chkconfig postfix on

centos7使用systemctl命令

2.2 安裝指定版本發行包

*下載並安裝gitlab的yum源*

curl -sS http://packages.gitlab.cc/install/gitlab-ce/script.rpm.sh | sudo bash

 *自動安裝最新版本*

yum install gitlab-ce

 *安裝指定版本*

gitlab-ce-11.2.3-ce.0.el7.x86_64

3.純手動模式/原始擋

固然，你也能夠手動來安裝Gitlab所須要的各種組件，結合其源碼安裝來達到一樣的目的。固然，目前官方已經再也不建議使用這種模式安裝，身爲Geek能夠嘗試一番刷刷成就感。這一步驟比較繁瑣複雜，稍有不慎就可能會燒腦。
若是你打算使用這樣的方式來安裝的話，你可能須要作好屢次失敗重來的準備

參考連接：Gitlab源碼編譯安裝

Gitlab經常使用命令

以上主要是詳細描述了Gitlab從選型、安裝都基本配置的過程，基本能知足一個項目團隊協做平臺的基礎任務，如下爲整理後的gitlab經常使用命令，能更有效的幫助運維人員來進行gitlab服務器的管理。

1.運維管理

查看版本

cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

實時查看日誌

gitlab-ctl tail

數據庫關係升級

gitlab-rake db:migrate

清理redis緩存

gitlab-rake cache:clear

升級GitLab-ce 版本

yum update gitlab-ce

升級PostgreSQL最新版本

gitlab-ctl pg-upgrade

2.服務控制命令

啓動/中止/重啓全部 gitlab 組件：

gitlab-ctl start/stop/restart

啓動指定模塊組件：

gitlab-ctl start redis/postgresql/gitlab-workhorse/logrotate/nginx/sidekiq/unicorn

中止指定模塊組件：

gitlab-ctl stop 模塊名

查看服務狀態

gitlab-ctl status

生成配置並啓動服務

gitlab-ctl reconfigure

3.日誌相關

實時查看全部日誌

gitlab-ctl tail

實時各個模塊日誌

gitlab-ctl tail redis/postgresql/gitlab-workhorse/logrotate/nginx/sidekiq/unicorn

Gitlab配置

不論是經過上述三種方式之中的哪一種安裝，在Gitlab安裝完成以後，咱們是能夠直接經過gitlab-ctl命令來啓動gitlab服務的。

Gitlab服務構成

GitLab由主要由如下服務構成，他們共同承擔了Gitlab的運做須要

nginx: 靜態web服務器
gitlab-shell: 用於處理Git命令和修改authorized keys列表
gitlab-workhorse: 輕量級的反向代理服務器
logrotate：日誌文件管理工具
postgresql：數據庫
redis：緩存數據庫
sidekiq：用於在後臺執行隊列任務（異步執行）
unicorn：HTTP服務，GitLab Rails應用是託管在這個服務器上面的。

主要配置文件目錄

若是不是經過純手工的方式安裝，通常來講Gitlab的各個模塊配置文件存放目錄是固定的，手動編譯安裝出來的全部配置文件理論上會存放與手動置頂的編譯安裝目錄。在平常的配置中，咱們能夠經過修改如下配置文件之中的參數來調節Gitlab的功能

主配置文件: /etc/gitlab/gitlab.rb
文檔根目錄: /opt/gitlab
默認存儲庫位置: /var/opt/gitlab/git-data/repositories
Nginx配置文件: /var/opt/gitlab/nginx/conf/gitlab-http.conf
Postgresql數據目錄: /var/opt/gitlab/postgresql/data

通常來講咱們的常規配置均可以經過修改/etc/gitlab/gitlab.rb這一配置文件來達到目的

基礎配置/常見問題

1.默認管理員和密碼

咱們可使用默認的管理員root來登陸控制檯，管理員首次登陸時會要求咱們重置登陸密碼。進入控制檯以後，你能夠從新修改密碼。但這時你會發現GitLab管理員帳號，缺省郵箱admin@example.com是個根本不存在的地址，因此沒法經過郵箱重置密碼。
這時，咱們能夠經過Gitlab服務器控制檯命令來從新設置管理員或指定帳戶的登陸密碼。
切換到root用戶，執行

gitlab-rails console production

等待控制檯執行完畢，刷出等待輸入界面以後，執行

[root@mail .ssh]# gitlab-rails console production
-------------------------------------------------------------------------------------
 GitLab:       11.2.3 (06cbee3)
 GitLab Shell: 8.1.1
 postgresql:   9.6.8
-------------------------------------------------------------------------------------
Loading production environment (Rails 4.2.10)
irb(main):001:0> user = User.where(id: 1).first
=> #<User id:1 @root>
irb(main):002:0>  user.password = '88888888'
=> "88888888"
irb(main):003:0> user.password_confirmation = '88888888'
=> "88888888"
irb(main):004:0> user.save!
Enqueued ActionMailer::DeliveryJob (Job ID: 56cdcd6c-0af6-43c5-9b04-642d7f94cd3d) to Sidekiq(mailers) with arguments: "DeviseMailer", "password_change", "deliver_now", gid://gitlab/User/1
=> true
irb(main):005:0> exit

這樣咱們就成功重置了管理員的登陸密碼，不過請慎用哦！

2.綁定域名/IP

在Gitlab啓動以後，在不修改主配置的狀況下，咱們能夠經過訪問http://ip來經過瀏覽器訪問Gitlab管理平臺。通常來講咱們直接經過這種方式已經能知足咱們平常的版本管理須要，並不須要強制綁定域名。
可是在使用中，若是咱們使用默認的配置來建立了一個項目，那麼Gitlab會使用默認配置做爲.git文件的版本地址，致使咱們經過客戶端clone時沒法訪問到對應的域名和真實的IP地址。

如咱們暫時沒有域名也不想解析，而單純想使用服務器IP地址來做爲git索引路徑，那麼咱們能夠修改配置文件/etc/gitlab/gitlab.rb之中的綁定域名

external_url '[http://gitlab.bjwf125.com'](http://gitlab.bjwf125.com')

這一行修改成服務器的對應IP地址(內網示例)

external_url 'http://192.168.1.10'

再從新加載配置文件

gitlab-ctl reconfigure

咱們就能夠看到項目中的地址已經變成了IP地址的索引，而且能被咱們客戶端正常訪問了

3.使用SMTP來發送郵件通知

若是你不想用Gitlab服務器自帶的postfix服務來發郵件，能夠改用SMTP服務。一樣是修改/etc/gitlab/gitlab.rb中的郵件服務配置，使用SMTP服務器來做爲郵件通知的發送方

gitlab_rails['smtp_address'] = "smtp.yourdomain.com"
 gitlab_rails['smtp_port'] = 25
 gitlab_rails['smtp_user_name'] = "xxx"
 gitlab_rails['smtp_password'] = "xxx"
 gitlab_rails['smtp_domain'] = "smtp.yourdomain.com" 
 gitlab_rails['smtp_authentication'] = 'plain'
 gitlab_rails['smtp_enable_starttls_auto'] = true

4.配置Gitlab訪問方式爲HTTPS

Gitlab安裝後，默認是使用HTTP方式訪問，若咱們想使用更爲安全的HTTPS方式，須要進行一些額外的設置

4.1 建立SSL證書存放目錄

mkdir -p /etc/gitlab/ssl
chmod 0700 /etc/gitlab/ssl

經過Sftp等方式上傳證書gitlab.xxx.com.crt，修改對應證書訪問權限

chmod 600 /etc/gitlab/ssl/gitlab.xxx.com.crt

4.2 修改主配置，支持SSL訪問

仍然是修改/etc/gitlab/gitlab.rb主配置文件

external_url "[https://gitlab.bjwf125.com](https://gitlab.bjwf125.com)"
nginx['redirect_http_to_https'] = true
 nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.xxx.com.crt"
 nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.xxx.com.key"

經過修改主配置而且gitlab-ctl reconfigure後，nginx服務的配置文件/var/opt/gitlab/nginx/conf/gitlab-http.conf會被自動修改成

server {
 listen *:80;
 server_name gitlab.bjwf125.com;
 server_tokens off; ## Don't show the nginx version number, a security best practice
 return 301 [https://gitlab.xxx.com:443$request_uri](https://gitlab.bjwf125.com:443%24request_uri);
 access_log /var/log/gitlab/nginx/gitlab_access.log gitlab_access;
 error_log /var/log/gitlab/nginx/gitlab_error.log;
 }

已經支持了HTTPS的訪問和解析

4.3 開啓防火牆

接下來，咱們須要開啓服務器的443端口，以容許HTTPS訪問。

centos 7.x

firewall-cmd --zone=public --add-port=443/tcp --permanent

至此，咱們的Gitlab已經支持了HTTPS方式的訪問

備份/恢復

1.備份

gitLab備份的默認目錄是/var/opt/gitlab/backups，若想要主動執行備份操做，能夠經過

gitlab-rake gitlab:backup:create

命令會在備份目錄下建立一個以時間戳開頭的xxxxxxxx_gitlab_backup.tar的壓縮包，這個壓縮包包括整個完整的gitlab。

若須要修改默認的備份目錄，能夠經過修改/etc/gitlab/gitlab.rb主配置文件來設置

gitlab_rails['backup_path'] = '/data/backups'

2.恢復

指定恢復文件，gitlab會自動去查找備份目錄。
指定文件名的格式相似：1535861590_2018_09_02_11.2.3，文件名後綴_gitlab_backup.tar不須要添加」

gitlab-rake gitlab:backup:restore BACKUP=1535861590_2018_09_02_11.2.3