在今天的進度，我們要來認識自行架設 GitLab 時，非常重要的 Admin Area。但如果你後續打算使用 gitlab.com，而非自架 GitLab Server，那你可以略過今天的文章，因為 gitlab.com 的使用者是碰不到 Admin Area 的。

延續昨天的文章，當你首次登入你自架的 GitLab 時，你應該已經按步驟順利修改了 root 密碼。接著只要你使用 root 登入 GitLab，就會發現比起一般使用者，root 在界面上會有一個額外的 Admin Area。

（在上方選單列，會多一個 Admin Area。）

Admin Area 概要

在 Admin Area 你會發現它如下條列，包含多個 Sections。

• Overview
• Monitoring
• Messages
• System Hooks
• Applications
• Abuse Reports
• Deploy Keys
• Service Templates
• Labels
• Appearance
• Settings

如果你架設的是 GitLab EE，還會多出另外三項 Section。

• License
• Push Rules
• Geo

在上述每個 Section 內都包含了多個分類，因此整體看下來 Admin Area 有不少資訊與參數設定是維運 GitLab Server 的管理必須要好好的認識一番的。不過好在官方有替每個參數給予基本的預設值，因此雖然我們才剛架設完 GitLab，需要急著優先確認的 Sections 並不會太多。接下來就一一看過幾項我認為要優先查看的項目。

Overview

Overview 為 GitLab 的管理者提供了一個能夠一覽 GitLab 使用現況之全貌的功能。首先我們可以先查看 Overview 的 Dashboard。在這裡你可以一覽 GitLab 的使用狀況，包含已有多少的 Project、User、Group，目前安裝的 GitLab 版本號⋯⋯等。

不過對於剛架設完 GitLab 的我們而言，在 Overview 當中，可能最先需要使用的會是 New User 即新增使用者的功能。畢竟總不好一直用最高權限的 root 帳號進行一般的操作，還是快點新增一個一般權限的 User，再繼續試用 GitLab 的其他功能。在後續的文章中，我們會單獨針對 User 及 Permissions 做更多的介紹，這裡我們就先跳過 User 的細節說明。

Monitoring

Monitoring 提供了維運角度需要的監控數據，可以為維運 GitLab 提供助益，而其中我們首先需要查看的是 Health Check。

只要是自行架設 Service，在維運上都必須解決一個老問題——你如何確保 Service 依然存活並能正常地提供服務。有的時候維運人員會透過其他的 Monitoring Tool、自行撰寫腳本或透過各種技巧來監控服務的運行狀況。而 GitLab 則貼心的提供了 Health Check 的功能，幫助維運人員可以設置一個方便的檢查點，用來確認服務的健康狀態。

進入 Health Check 的頁面，會發現 GitLab 提供了一組 Access Token 搭配三個 URL 讓我們能夠用來監控服務的健康狀態。你可以實際用瀏覽器開啟這三個 URL，即可得到一串 Json 格式的 Response。你可以自行善用這些 Json 內容，例如：自己寫一個 shell script 搭配 Cron Job，藉此固定每分鐘查看一次 Json 中的 status 是否回傳 ok 以確認 GitLab 以及相依之 Servive（db、redis⋯⋯）有沒有正常運作；當然你也可以考慮將這些 Json 餵給其他的 Monitoring Tool 以便集中監控。

總而言之，Health Check 是維運人員的好幫手，儘早利用它為你的 GitLab 設置一個監控檢查點吧。

Settings

接著就讓我們直接跳到最後一項 Settings，快速看過有哪些重要的選項與設定值是需要及早確認的。（謎之音：也跳過太多了吧！？）

在 General 中，建議需要優先確認的有：

• Account and limit 的 Maximum attachment size (MB) 與 Maximum push size (MB)，如果未來在運用 GitLab 的 Issue Tracking 功能時，有可能會附加大容量的檔案；或是有可能 Commit 大容量的檔案至版本控制系統，那這兩個參數記得要調高一些。

• Sign-up restrictions 的 Sign-up enabled。如果你不打算讓任何人都可以隨意註冊新使用者，那麼記得關閉此選項。或者你也可以改為設置 Whitelisted domains for sign-ups，限制只有吻合某些 Domain Name 的 Email 才能註冊為使用者。例如你可以限制只能使用你公司的 Email 才能註冊為使用者。

在 CI/CD 中，需要優先確認的有：

• Maximum artifacts size (MB) 一樣是和檔案容量有關的項目，如果你的程式會 Build 產生比較肥大的 Artifacts，記得把這一項開大一些。（附帶一提，gitlab.com 設定為 1G。）何為 Artifacts？以及在 GitLab CI 中 Artifacts 該如何運用？這些我們留到後續談 CI/CD 時，再詳細介紹。總之，如果你的專案最後會產生一大包大容量的程式，那這一項設定記得開大一點。
• Default artifacts expiration 另一個與 Artifacts 有關的設定值是 Artifacts 要保留多久，在 gitlab.com 預設是可以無限期保存。但自己架設的 GitLab 因為硬碟空間多半有限，恐怕就不太適合設定為「無限期」，一般建議可以配合你們軟體交付的速度去設定一個寬容值，方便你可以在 GitLab 上快速的取得最新版和往前回推 2 ~ 3 個版本的 Artifacts。而在實務作法上，則是要搭配整體的 Artifacts Management 做規劃，同樣這部分的內容我們也留到後續談 CI/CD 時，再詳細介紹。

在 Metrics and profiling 中，要優先處理的有：

• Usage statistics 之下的 Enable usage ping，如勾選了這個選項，則 GitLab 官方將會收集你所架設之 GitLab Server 的一些使用數據，供 GitLab 官方用來改善他們的產品。根據官方文件的說明，收集的資訊並不會包含重要的私密資料、Projects、Users 的內容，但如果你仍有疑慮，或不想浪費頻寬傳送這些資訊，那你可以考慮取消勾選這個選項。

最後是 Preferences 中，要優先確認的有：

• Localization 的 Default first day of the week，不要笑，這是很重要的，有些人就是覺得一週的第一天應該是 Sunday 而不是 Monday，另外你不覺得如果每一週都是從放假起始、放假結束，在心理感受上會比較愉悅嗎？

小結

今天我們快速地看過了 GitLab 的 Admin Area，了解到其中有許多重要的 Sections 是需要管理者一一去仔細設定的。我們不得不再說一次，因為 GitLab 包含的服務、功能越來越強大，這導致 GitLab Server 的維運也越來越複雜，因此當團隊正式開始運用 GitLab 一段時間之後，還是要撥點時間好好地將 Admin Area 內的每個選項都詳細確認才行；當然也不要忘記昨天提過的 Configuration，這些都是自行架設 GitLab Server 需要仔細確認的地方喔～

參考資料

• https://docs.gitlab.com/ee/user/admin_area/