從零開始搭建Gitlab服務器

從零開始搭建Gitlab服務器

Gitlab簡介

最近感覺就是在不斷的搭建/遷移版本服務器,而現在市面上關於版本服務器搭建的指南都流於表面,真正深入骨骼的少之又少,往往以偏概全很多關鍵點並未提及。而版本服務器的搭建往往是一個初創型或中小型公司迫切需要解決的問題。

目前市用戶量和口碑較好的Git服務提供商,屈指可數。國外的話 GitHubBitBucket 都是不錯的選擇,但國際形勢變幻莫測,需要隨時備好梯子。國內的話**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管理員賬號,缺省郵箱[email protected]是個根本不存在的地址,所以無法通過郵箱重置密碼。
這時,我們可以通過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。

備份.png

若需要修改默認的備份目錄,可以通過修改/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

恢復.png

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章