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