rpm -ivh gitlab-ce-10.2.2-ce.0.el7.x86_64.rpm vim /etc/gitlab/gitlab.rb # external_url 'http://127.0.0.1' gitlab-ctl reconfigure gitlab-ctl restart gitlab備份管理 在配置文件中加入 # vim /etc/gitlab/gitlab.rb
gitlab_rails['manage_backup_path'] = true gitlab_rails['backup_path'] = '/data/backup/gitlab' # 備份目錄,自動建立 gitlab_rails['backup_keep_time'] = 604800 # 保留時間 gitlab-ctl reconfigure 若是自定義備份目錄須要賦予git權限 mkdir /data/backup/gitlab chown -R git.git /data/backup/gitlab /usr/bin/gitlab-rake gitlab:backup:create # 執行備份 # 定時任務Crontab中執行 0 2 * * * /usr/bin/gitlab-rake gitlab:backup:create 中止數據寫入服務 gitlab-ctl stop unicorn gitlab-ctl stop sidekiq gitlab-rake gitlab:backup:restore BACKUP=15112711475_2018_12_14_10.2.2 # 恢復數據 gitlab-ctl restart
gitlab-ctl status:查看gitlab組件狀態 gitlab-ctl start:啓動所有服務 gitlab-ctl restart:重啓所有服務 gitlab-ctl stop:中止所有服務 gitlab-ctl reconfigure:使配置文件生效(通常修改完主配置文件/etc/gitlab/gitlab.rb,須要執行此命令) gitlab-ctl show-config :驗證配置文件 gitlab-ctl uninstall:刪除gitlab(保留數據) gitlab-ctl cleanse:刪除全部數據,重新開始 gitlab-ctl tail <service name>查看服務的日誌
nginx:靜態Web服務器 gitlab-shell:用於處理Git命令和修改authorized keys列表,咱們的gitlab是以Git作爲最層的,你操做實際上最後就是調用gitlab-shell命令進行處理。 gitlab-workhorse:輕量級的反向代理服務器 logrotate:日誌文件管理工具 postgresql:數據庫 redis:緩存數據庫 sidekiq:用於在後臺執行隊列任務(異步執行) unicorn:GitLab Rails應用是託管在這個服務器上面的
/var/opt/gitlab/git-data/repositories:庫默認存儲目錄 /opt/gitlab: 應用代碼和相應的依賴程序 /var/opt/gitlab:gitlab-ctl reconfigure命令編譯後的應用數據和配置文件,不須要人爲修改配置 /etc/gitlab: 配置文件目錄 /var/log/gitlab:此目錄下存放了gitlab各個組件產生的日誌 /var/opt/gitlab/backups/:備份文件生成的目錄
因爲咱們Gitlab系統是私有倉庫,通常用戶都是由管理員建立和分派的,因此咱們須要關閉註冊。
group(項目)下面能夠建立subgroup,建立project(項目下的具體工程),添加user。group就是把相關的project或者user放在一塊兒,進行統一的權限管理。 咱們建立一公司網站的項目web-site,項目下面有兩個工程,一個是前臺pro-frontend, 一個是後臺管理pro-backend。 visibility Level:選擇誰能夠訪問該組:咱們默認選擇private,由於我建設的是私有倉庫 Private:只有受權的用戶才能夠看到 Internal:只要是登陸gitlab的用戶就能夠看到 Public:只要能夠訪問gitlab web頁面的人就能夠看到 點擊group名稱進去,咱們在web-site下面建立project: 此時咱們已經建立了一個frontend的project,是一個空的工程。咱們暫時先無論其餘的,使用一樣的方法建立backend project。 subgroup建立同group一樣,在此咱們再也不詳細說明。
咱們主要建立這兩類用戶,一類是項目經理PM(用來管理項目),另外一類是開發DEV(項目功能的實現)。 注:1、郵件不能重複; 2、新建用戶不能設置密碼,須要咱們在添加完用戶名,編輯用戶併爲用戶設置一個初始密碼,用戶第一次登陸時系統要求用戶更改密碼; 3、去掉勾選,普通用戶咱們通常不須要create group。 重複以上步驟,咱們建立dev,dev1,dev2用戶。
建立完user後,咱們須要將user添加到組或者project上,並選擇不一樣的role。 首先咱們add user to group 咱們將選擇dev1用戶,角色選擇Developer,過時日期不設置爲永遠不過時。 用一樣的方法添加dev2,pm(角色Master),添加到group. 將用戶添加到組後,咱們發現組裏的每一個project下自動添加了咱們剛纔添加的用戶。 咱們將dev用戶添加到backend中, 咱們切換到frontend project看一下:發現沒有dev用戶。 如今咱們可使用用戶模擬的功能看一下每一個用戶的權限。 具體每一種角色的權限,能夠參考以下地址: http://192.168.56.12/help/user/permissions ,地址換成你的Gitlab地址便可。
咱們使用dev1賬號登陸到Gitlab,而後切換到一個具體的project下: 咱們爲dev1用戶添加一個SSH Key,SSH Key可讓我以SSH的方式連接到代碼倉庫,而後就能夠在本地和Gitlab倉庫之間拉取和推送代碼。SSH Key全局惟一。 咱們在node1節點上生成SSH Key: [root@node1 ~]# ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: SHA256:eEoexwPCixJX99Gr7H3Sn29BS4RIJ4IBIbnr2fGme1M root@node1 The key's randomart image is: +---[RSA 2048]----+ | .oo+.+o.o... | | +.. o .o.o. . | |. . + . . . . | | o o o + . o | |. . o +.S. o .| | . . + =oE o | | . o =... . .| | o . =. o o ..| | o= . o .oo.| +----[SHA256]-----+ [root@node1 ~]# ll .ssh/ total 12 -rw------- 1 root root 1679 Dec 4 15:17 id_rsa -rw-r--r-- 1 root root 392 Dec 4 15:17 id_rsa.pub -rw-r--r-- 1 root root 803 Dec 1 13:26 known_hosts [root@node1 ~]# cat .ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDnWbgoAKbW5nCTnRo4IfAJ0KrEdbhiyEea2NTROP5QVsIZo8B7iIcoq78XfIZWscGkDypWRa1HTAGrdem0d28ihqrcFsepnKhRpiXC4ZbycZ7DIU1LXtCBioNrCJdm7fGOse/pUGt
8qpmeFProrkwFeUG5nxUBOChjYRqpwUQm4Nq5Z+fRGYVGiTngHyQ7L1d67Eqs4xuFjlTi72c0sySiOhk0lu4gFFyE9WuXBdiFGsNdOz504ypKxI2uMws6vj9k28ETykx5RC/0Uyk+xJMwoJE9L4xB+ihtMCQBGw1UG6T4djsoDn
iTp++PGpMxePieZQ88cB1dIJMqhTV0y0mv root@node1 咱們將公鑰id_rsa.pub的內容添加到Gitlab dev1用戶的SSH Key中。 至此,咱們已經完成打通了dev1的本機與Gitlab倉庫之間的通道。 咱們再將咱們的windows的SSH Key添加到Gitlab,首先咱們要安裝Git GUI(參考gitlab安裝文檔): 在窗口中重複執行咱們在linux中建立SSH Key的過程 而後根據提示找到id_rsa.pub,將該文件中的內容添加到Gitlab中dev2的SSH Key。 因爲SSH Key全局惟一,因此我只要任何一個用戶中添加均可以。
剛纔咱們建立的前臺和後臺兩個project如今仍是空的,本次教程咱們只使用其中的frontend,如今咱們首先對這兩個倉庫進行初始化,並建立兩個分支master,dev。咱們使用pm用戶對frontend進行初始化操做。
接下來咱們自動建立dev分支:
咱們能夠mster分支是默認的分支,並且是受保護的。
在實際的開發過程當中,master分支通常用來版本發佈,dev分支用於存放開發代碼。
前面咱們已經建立了frontend的遠程倉庫,如今咱們分別在linux下和windows下鏈接遠程倉庫,實現代碼的摘取與推送。 linux: 使用git clone 命令克隆遠程frontend倉庫到本地 [root@node1 ~]# git clone git@192.168.56.12:web-site/frontend.git Cloning into 'frontend'... The authenticity of host '192.168.56.12 (192.168.56.12)' can't be established. ECDSA key fingerprint is SHA256:SjPoetHYvGBI08VxTdzYOys+QpjR5vLNbU9Obs2Lx9Q. ECDSA key fingerprint is MD5:39:3e:52:a1:45:9b:3e:23:72:e6:0d:0e:76:00:17:55. Are you sure you want to continue connecting (yes/no)? yes /*第一次鏈接時會出現該提示 Warning: Permanently added '192.168.56.12' (ECDSA) to the list of known hosts. remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0) Receiving objects: 100% (3/3), done. Checking connectivity... done. [root@node1 ~]# ll total 4 -rw-------. 1 root root 1374 Nov 27 00:14 anaconda-ks.cfg drwxr-xr-x 3 root root 94 Nov 30 22:28 demo drwxr-xr-x 3 root root 32 Dec 4 21:02 frontend drwxr-xr-x 3 root root 97 Dec 2 19:48 git-test drwxr-xr-x 4 root root 49 Nov 30 15:53 web-site [root@node1 ~]# cd frontend/ [root@node1 frontend]# ll total 4 -rw-r--r-- 1 root root 16 Dec 4 21:02 README [root@node1 frontend]# git branch * master [root@node1 frontend]# git remote -v origin git@192.168.56.12:web-site/frontend.git (fetch) origin git@192.168.56.12:web-site/frontend.git (push) 從遠程倉庫拉下dev分支到本地 [root@node1 frontend]# git pull origin dev From 192.168.56.12:web-site/frontend * branch dev -> FETCH_HEAD Already up-to-date. 切換到dev分支 [root@node1 frontend]# git checkout dev Branch dev set up to track remote branch dev from origin. Switched to a new branch 'dev' [root@node1 frontend]# git branch * dev master 在dev分支下添加linux.txt文件,而後commit。 [root@node1 frontend]# echo "this is linux agnet" >> linux.txt You have new mail in /var/spool/mail/root [root@node1 frontend]# git add . [root@node1 frontend]# git commit -m "add linux.txt file" [dev cdd58d8] add linux.txt file 1 file changed, 1 insertion(+) create mode 100644 linux.txt 推送本地dev分支到遠程倉庫的dev分支 [root@node1 frontend]# git push origin dev Counting objects: 3, done. Delta compression using up to 2 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 291 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) remote: remote: To create a merge request for dev, visit: remote: http://192.168.56.12/web-site/frontend/merge_requests/new?merge_request%5Bsource_branch%5D=dev remote: To 192.168.56.12:web-site/frontend.git 8a36a7f..cdd58d8 dev -> dev 而後咱們在Gitlab上查看: windows: 第一次鏈接會出現此對話框,請輸入yes。 拉取遠程dev分支,而後切換 咱們在frontend文件夾裏添加windows文件 上面的兩個過程咱們都是從本地的dev推送到Gitlab倉庫的dev分支,那我是否是能夠直接在本地合併到master分支,而後推送master分支到Gitlab呢?這個問題留給你們課後實際操做一下。 實驗結果: [root@node1 frontend]# git checkout master Switched to branch 'master' [root@node1 frontend]# git merge dev Updating 8a36a7f..cdd58d8 Fast-forward linux.txt | 1 + 1 file changed, 1 insertion(+) create mode 100644 linux.txt [root@node1 frontend]# ll total 8 -rw-r--r-- 1 root root 20 Dec 4 21:50 linux.txt -rw-r--r-- 1 root root 16 Dec 4 21:02 README [root@node1 frontend]# git push origin master Counting objects: 3, done. Delta compression using up to 2 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 291 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) remote: GitLab: You are not allowed to push code to protected branches on this project. To 192.168.56.12:web-site/frontend.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'git@192.168.56.12:web-site/frontend.git'
在開始咱們的講解前,咱們先爲咱們的frontend項目作一個開發計劃:html
v1.0版本:開始時間爲12月5日,結束時間爲12月11,工期5天node |
||||
模塊linux |
開發者nginx |
完成日期git |
|
|
首頁web |
dev1redis |
7sql |
|
|
新聞docker |
dev1shell |
8 |
|
|
產品 |
dev2 |
9 |
|
|
關於咱們 |
dev2 |
10 |
|
|
里程碑計劃是一個目標計劃,它代表爲了達到特定的里程碑,去完成一系列活動。根據frontend的開發計劃,咱們爲frontend創建一個v1.0的里程碑。
Issue能夠有不少的做用:1、闡述一個新的想法;2、提交功能建議;3、報告bugs等。 根據咱們frontend的開發計劃,咱們使用Issue來分派計劃中的任務: 使用一樣的方法,添加剩下的三個計劃。完成後以下: 咱們使用dev2用戶登陸,能夠看到: 而後咱們模擬dev2用戶在本地開發about功能,並將開發的代碼上傳gitlab,而後合併到dev分支。本地編輯文件並上傳部分請參考前面(4.7章節),完成後gitlab上4-about分支的狀態以下: 而後咱們發送一個合併請求給pm,請咱們的about功能合併到開發分支。 而後咱們使用pm用戶登陸: 檢查正確後,點擊merge 咱們能夠看about.html文件已經合併到了dev分支,而且生成了一次Merge branch的commit記錄。而後咱們就能夠關閉about 的issue。咱們可使用一樣的方法完成其餘幾個模塊的開發,並最後合併到dev分支。當全部的開發工做完成後,
由PM將dev分支合併到mster分支,而後咱們能夠在Master分支建立一個發佈版本進行發佈。
gitlab-ci全稱是gitlab continuous integration的意思,也就是持續集成。中心思想是當每一次push到gitlab的時候,都會觸發一次腳本執行,而後腳本的內容包括了測試,編譯,部署等一系列自定義的內容。 GitLab CI是 GitLab 提供的持續集成服務,只要在你的倉庫根目錄 建立一個.gitlab-ci.yml 文件, 併爲該項目指派一個Runner,當有合併請求或者 push的時候就會觸發build。 這個.gitlab-ci.yml 文件定義GitLab runner要作哪些操做。 默認有3個[stages(階段)]: build、test、deploy。 因此簡單的說,要讓CI工做可總結爲如下幾點: 在倉庫根目錄建立一個名爲.gitlab-ci.yml 的文件 爲該項目配置一個Runner 完成上面的步驟後,每次push代碼到Git倉庫, Runner就會自動開始pipeline。
GitLab-CI 這個是一套配合GitLab使用的持續集成系統,是GitLab自帶的,也就是你裝GitLab的那臺服務器上就帶有的。無需多考慮。.gitlab-ci.yml的腳本解析就由它來負責。 GitLab-Runner 這個是腳本執行的承載者,.gitlab-ci.yml的script部分的運行就是由runner來負責的。GitLab-CI瀏覽過項目裏的.gitlab-ci.yml文件以後,根據裏面的規則,分配到各個Runner來運行相應的腳本script。這些腳本有的是測試項目用的,有的是部署用的。 由於 GitLab Runner 能夠安裝到不一樣的機器上,因此在構建任務運行期間並不會影響到 GitLab 的性能 .gitlab-ci.yml 這個是在git項目的根目錄下的一個文件,記錄了一系列的階段和執行規則。GitLab-CI在push後會解析它,根據裏面的內容調用runner來運行。
安裝GitLab-CI 這個不用安裝了,裝好GitLab就自帶了 安裝GitLab-Runner [root@node1 src]# cd /usr/local/src/ [root@node1 src]# wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ci-multi-runner/yum/el7/gitlab-ci-multi-runner-9.5.1-1.x86_64.rpm [root@node1 src]# rpm -ivh gitlab-ci-multi-runner-9.5.1-1.x86_64.rpm
向gitlab-CI註冊這個runner [root@node1 src]# gitlab-ci-multi-runner register Running in system-mode. Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/): http://192.168.56.12 gitlab地址 Please enter the gitlab-ci token for this runner: WUsLpmDFu6q4snDSqmds project的token Please enter the gitlab-ci description for this runner: [node1]: node1 runner的描述 Please enter the gitlab-ci tags for this runner (comma separated): node1-runner runner標籤 Whether to run untagged builds [true/false]: [false]: true Whether to lock Runner to current project [true/false]: [false]: false Registering runner... succeeded runner=WUsLpmDF Please enter the executor: docker, docker-ssh, virtualbox, kubernetes, parallels, shell, ssh, docker+machine, docker-ssh+machine: shell 選擇runner的類型 Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded! [root@node1 src]# gitlab-ci-multi-runner list Listing configured runners ConfigFile=/etc/gitlab-runner/config.toml node1 Executor=shell Token=bcb3699e350002b905bcfead2f3f6d URL=http://192.168.56.12 [root@node1 src]#
[root@node1 src]# gitlab-ci-multi-runner start
咱們先介紹幾個基本概念: Pipeline 一次 Pipeline 其實至關於一次構建任務,裏面能夠包含多個流程,如安裝依賴、運行測試、編譯、部署測試服務器、部署生產服務器等流程。 Stages Stages 表示構建階段,說白了就是上面提到的流程。 咱們能夠在一次 Pipeline 中定義多個 Stages,這些 Stages 會有如下特色: 全部 Stages 會按照順序運行,即當一個 Stage 完成後,下一個 Stage 纔會開始 只有當全部 Stages 完成後,該構建任務 (Pipeline) 纔會成功 若是任何一個 Stage 失敗,那麼後面的 Stages 不會執行,該構建任務 (Pipeline) 失敗 Jobs Jobs 表示構建工做,表示某個 Stage 裏面執行的工做。 咱們能夠在 Stages 裏面定義多個 Jobs,這些 Jobs 會有如下特色: 相同 Stage 中的 Jobs 會並行執行 相同 Stage 中的 Jobs 都執行成功時,該 Stage 纔會成功 若是任何一個 Job 失敗,那麼該 Stage 失敗,即該構建任務 (Pipeline) 失敗 基本寫法 # 定義 stages stages: - build - deploy # 定義 job job1: stage: deploy script: - echo "I am job1" - scp web.tar.gz /tmp - pwd # 定義 job job2: stage: build script: - echo "I am job2" - tar czf web.tar.gz ./* 用 stages 關鍵字來定義 Pipeline 中的各個構建階段,而後用一些非關鍵字來定義 jobs。 每一個 job 中能夠能夠再用 stage 關鍵字來指定該 job 對應哪一個 stage。 job 裏面的 script 關鍵字是最關鍵的地方了,也是每一個 job 中必需要包含的,它表示每一個 job 要執行的命令。
對gitlab進行備份將會建立一個包含全部庫和附件的歸檔文件。對備份的恢復只能恢復到與備份時的gitlab相同的版本。將gitlab遷移到另外一臺服務器上的最佳方法就是經過備份和還原。 gitlab提供了一個簡單的命令行來備份整個gitlab,而且能靈活的知足需求。 備份文件將保存在配置文件中定義的backup_path中,文件名爲TIMESTAMP_gitlab_backup.tar,TIMESTAMP爲備份時的時間戳。TIMESTAMP的格式爲:EPOCH_YYYY_MM_DD_Gitlab-version。 若是自定義備份目錄須要賦予git權限 配置文件中加入 gitlab_rails['backup_path'] = '/data/backup/gitlab' gitlab_rails['backup_keep_time'] = 604800 備份保留的時間(以秒爲單位,這個是七天默認值), mkdir /data/backup/gitlab chown -R git.git /data/backup/gitlab 完成後執行gitlab-ctl reconfigure
執行:gitlab-rake gitlab:backup:create生成一次備份。 [root@node2 ~]# gitlab-rake gitlab:backup:create Dumping database ... Dumping PostgreSQL database gitlabhq_production ... [DONE] done Dumping repositories ... * web-site/frontend ... [DONE] * web-site/frontend.wiki ... [SKIPPED] * web-site/backend ... [SKIPPED] * web-site/backend.wiki ... [SKIPPED] * devops/accout ... [DONE] * devops/accout.wiki ... [SKIPPED] * devops/user ... [DONE] * devops/user.wiki ... [SKIPPED] * web-site/accout ... [DONE] * web-site/accout.wiki ... [SKIPPED] done Dumping uploads ... done Dumping builds ... done Dumping artifacts ... done Dumping pages ... done Dumping lfs objects ... done Dumping container registry images ... [DISABLED] Creating backup archive: 1512811475_2017_12_09_10.2.2_gitlab_backup.tar ... done Uploading backup archive to remote storage ... skipped Deleting tmp directories ... done done done done done done done done Deleting old backups ... skipping [root@node2 ~]# ll /var/opt/gitlab/backups/ total 272 -rw------- 1 git git 276480 Dec 9 17:24 1512811475_2017_12_09_10.2.2_gitlab_backup.tar
在定時任務裏添加: 0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1 環境變量CRON=1的做用是若是沒有任何錯誤發生時, 抑制備份腳本的全部進度輸出。
只能還原到與備份文件相同的gitlab版本。 執行恢復操做時,須要gitlab處於運行狀態,備份文件位於gitlab_rails['backup_path']。 [root@node2 ~]# ll /var/opt/gitlab/backups/ total 272 -rw------- 1 git git 276480 Dec 9 17:24 1512811475_2017_12_09_10.2.2_gitlab_backup.tar 中止鏈接到數據庫的進程(也就是中止數據寫入服務),可是保持GitLab是運行的。 [root@node2 ~]# gitlab-ctl stop unicorn ok: down: unicorn: 0s, normally up [root@node2 ~]# gitlab-ctl stop sidekiq ok: down: sidekiq: 0s, normally up 確認: [root@node2 ~]# gitlab-ctl status run: gitaly: (pid 1497) 0s; run: log: (pid 540) 0s run: gitlab-monitor: (pid 1507) 0s; run: log: (pid 543) 0s run: gitlab-workhorse: (pid 1517) 0s; run: log: (pid 508) 0s run: logrotate: (pid 14405) 1564s; run: log: (pid 510) 0s run: nginx: (pid 1532) 0s; run: log: (pid 507) 0s run: node-exporter: (pid 1538) 0s; run: log: (pid 525) 0s run: postgres-exporter: (pid 1543) 0s; run: log: (pid 530) 0s run: postgresql: (pid 1551) 0s; run: log: (pid 492) 0s run: prometheus: (pid 1559) 0s; run: log: (pid 535) 0s run: redis: (pid 1567) 0s; run: log: (pid 491) 0s run: redis-exporter: (pid 1572) 0s; run: log: (pid 547) 0s down: sidekiq: 121s, normally up; run: log: (pid 500) 0s down: unicorn: 133s, normally up; run: log: (pid 502) 0s [root@node2 ~]# 接下咱們進行恢復,指定時間戳你要從那個備份恢復: [root@node2 ~]# gitlab-rake gitlab:backup:restore BACKUP=1512811475_2017_12_09_10.2.2 Unpacking backup ... done Before restoring the database, we will remove all existing tables to avoid future upgrade problems. Be aware that if you have custom tables in the GitLab database these tables and all data will be removed. Do you want to continue (yes/no)? 將移除咱們自建的表。回答yes Restoring uploads ... done Restoring builds ... done Restoring artifacts ... done Restoring pages ... done Restoring lfs objects ... done This will rebuild an authorized_keys file. You will lose any data stored in authorized_keys file. Do you want to continue (yes/no)? 將移除全部的認證Key。回答yes .... Deleting tmp directories ... done done done done done done done done 完成後重啓GitLab服務 [root@node2 ~]# gitlab-ctl restart ok: run: gitaly: (pid 18194) 0s ok: run: gitlab-monitor: (pid 18204) 0s ok: run: gitlab-workhorse: (pid 18209) 1s ok: run: logrotate: (pid 18224) 0s ok: run: nginx: (pid 18231) 1s ok: run: node-exporter: (pid 18237) 0s ok: run: postgres-exporter: (pid 18242) 0s ok: run: postgresql: (pid 18314) 0s ok: run: prometheus: (pid 18317) 1s ok: run: redis: (pid 18326) 0s ok: run: redis-exporter: (pid 18330) 0s ok: run: sidekiq: (pid 18345) 0s ok: run: unicorn: (pid 18354) 0s 檢查GitLab的服務 [root@node2 ~]# gitlab-rake gitlab:check SANITIZE=true Checking GitLab Shell ... GitLab Shell version >= 5.9.4 ? ... OK (5.9.4) Repo base directory exists? default... yes Repo storage directories are symlinks? default... no Repo paths owned by git:root, or git:git? default... yes Repo paths access is drwxrws---? default... yes hooks directories in repos are links: ... 2/3 ... ok 2/4 ... repository is empty 7/5 ... ok 7/7 ... ok 2/8 ... ok Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Check GitLab API access: OK Redis available via internal API: OK Access to /var/opt/gitlab/.ssh/authorized_keys: OK gitlab-shell self-check successful Checking GitLab Shell ... Finished Checking Sidekiq ... Running? ... yes Number of Sidekiq processes ... 1 Checking Sidekiq ... Finished Reply by email is disabled in config/gitlab.yml Checking LDAP ... LDAP is disabled in config/gitlab.yml Checking LDAP ... Finished Checking GitLab ... Git configured correctly? ... yes Database config exists? ... yes All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... yes Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory exists? ... yes Uploads directory has correct permissions? ... yes Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet) Init script exists? ... skipped (omnibus-gitlab has no init script) Init script up-to-date? ... skipped (omnibus-gitlab has no init script) Projects have namespace: ... 2/3 ... yes 2/4 ... yes 7/5 ... yes 7/7 ... yes 2/8 ... yes Redis version >= 2.8.0? ... yes Ruby version >= 2.3.5 ? ... yes (2.3.5) Git version >= 2.7.3 ? ... yes (2.13.6) Git user has default SSH configuration? ... yes Active users: ... 5 Checking GitLab ... Finished