前情與內容提要

本文描述如何使用Docker映象構建本地Gitlab服務。本文目標讀者是掌握基本docker操作，希望通過docker映象快速搭建自己Gitlab伺服器的使用者。
前面的文章我們介紹瞭如何在本地Linux環境中部署Docker Engine。主要注意以下幾個方面：
* 儘量使用安裝源的本地映象，如阿里雲，DaoCloud等；
* 下載到本地的docker映象檔案儲存位置，如果系統根檔案所在分割槽較小，需要把本地映象的儲存位置從Docker預設的/var/lib/docker 轉移到其他地方；
* 新增docker使用者組，使用普通使用者身份操作docker。
本篇仍然會涉及到不少docker知識，尤其是docker compose相關的內容。

下載所需映象

使用docker pull分別下載 Gitlab、Redis和PostgreSQL映象：

$docker pull gitlab/gitlab-ce:latest
$docker pull sameersbn/postgresql:9.4
$docker pull redis:latest

:latest 表示下載映象的最新版本，也可以指定版本號，例如sameersbn/postgresql:9.4
gitlab使用的是其community版本：文件在此
下載映象的步驟也可以直接在docker-compose中一氣呵成，為了突出重點，我們先手動下載。

下載完成後執行

$docker images |grep -E 'gitlab|redis|postgresql'

應該能看到列表中有上述三個映象檔案

Docker Compose 大法

Docker的Logo形象地展示了docker為什麼能夠讓應用快速地以平臺無關的方式部署執行：docker容器就像是一個集裝箱，不管你的應用是Ruby on Rails寫的Gitlab還是ANSI C寫的Redis或PostgreSQL，都可以用docker“集裝箱（映象）”裝起來，以映象的形式分發，然後通過Docker Engine產生一個容器例項來執行它。

因為Docker不像傳統的虛擬化那樣包含完整的作業系統軟體棧，所以它非常“輕量級”，可以便捷地分發和部署，並且可以通過釋出方提供的Dockerfile（可以理解為配方）快速地構建出和釋出方提供的映象一模一樣的Docker映象。這就使得基於Docker的應用部署和執行變得異常便捷。

又因為Docker將每個應用都隔離在單獨的容器裡，互相通過暴露通訊埠和共享資料卷等形式進行資料交換，這就使得“微服務”的架構得以高效實施，極大地提高了應用整體的健壯性。而數以千萬計執行在容器中的“微服務”，也勢必需要一種能夠統一進行管理的手段，這就是docker compose等編排工具存在的意義。

如果容器只能在同一臺docker host上執行，那麼docker的強大還是無從體現，真正讓docker成為革命性技術手段的，是容器之間跨主機的協同工作，通過編排工具讓執行在不同主機上的容器協同工作構建應用，從而使得應用規模可以在計算和儲存資源之上任意伸縮，服務的部署和執行獲得有前所未有的靈活性。

這裡，由於我們的應用比較簡單，我們將只用三個容器在同一主機上分別執行gitlab, redis和postgresql來構建我們的Gitlab Service。而在同一主機上同時執行多個容器構建一個應用，最便捷的方式是使用docker compose。

docker compose的使用非常的簡單：撰寫docker-compose.yml檔案描述應用如何由多個映象構建並描述每個容器的執行時環境，之後一個簡單的docker-compose up命令就可以讓容器協同工作起來。

下面就是我們要使用的docker-compose.yml檔案：

# Example Docker Compose file for Gitlab service

postgresql:
    image: "sameersbn/postgresql:9.4"
    environment:
        DB_NAME: "gitlabhq_production"
        DB_USER: "gitlab"
        DB_PASS: "your_password"
    volumes:
        - /srv/work/_db/postgresql/data:/var/lib/postgresql

redis:
    image: "redis:latest"

gitlab:
    image: "gitlab/gitlab-ce:latest"
    ports:
        - "10022:22"
        - "10080:80"
    links:
        - redis:redisio
        - postgresql:postgresql
    volumes:
        - /srv/work/_db/gitlab/data:/srv/git/data
        - /srv/work/_db/gitlab/log:/var/log/gitlab
        - /srv/work/_db/gitlab/config:/etc/gitlab
    environment:
        GITLAB_PORT: 10080
        GITLAB_SSH: 10022
        GITLAB_BACKUPS: "daily"
        GITLAB_HOST: "gitlab.yourdomain.com"
        GITLAB_SIGNUP: "true"
        GITLAB_ROOT_PASSWORD: "your_password"
        GITLAB_GRAVATAR_ENABLED: "true"
        SMTP_ENABLED: "true"
        SMTP_DOMAIN: "gmail.com"
        SMTP_HOST: "smtp.gmail.com"
        SMTP_PORT: 587
        SMTP_STARTTLS: "true"

註釋：
這份compose“配方”指定了三個容器同時執行，分別為：postgresql, redis 和gitlab。每個容器都通過image:導語指定了從哪個映象檔案生成容器；environment: 指定了容器執行時的環境變數取值；volumes: 指定了容器所掛載的資料卷，其語法為：

Docker Host上的路徑/A : 容器內的路徑/B

意思是將Docker Host上的目錄A對映為容器內的目錄B，這樣容器內就有了一個可以和Docker host宿主環境共享資料的地方。

為什麼需要這樣做呢？ Docker的快捷分發和部署的特性源於它使用一種UnionFS檔案系統，這種檔案系統是一種分層檔案系統。每個Docker映象實際上都是由若干層這種只讀檔案系統儲存的，當映象變成容器執行時，Docker通過在只讀層上面建立一個薄薄的讀寫層來記錄容器執行時產生的各種資料。當容器銷燬時，docker會釋放該讀寫層，這樣容器所作的所有修改就都灰飛煙滅了。那麼要儲存容器執行的成果怎麼辦？就需要執行docker commit來向docker engine提交容器相對於其啟動時所脫胎的映象所作的修改。這時，docker就向映象新增一個新的只讀層，用來落實所有的變化。但這個做法最大的問題在於如果需要修改的資料量非常大，那麼久而久之，映象就會變得臃腫不堪，docker也就失去它存在的意義了。況且有些資料也是使用者不希望儲存到映象之中的。

基於以上原因，docker需要一種將資料和容器例項的生存期分離的手段，於是volumes: 資料卷對映機制應運而生。通過這種方式，使用者可以將需要持久儲存的資料對映到容器中，再通過容器去使用這些資料。本例項中，我們的Gitlab映射了三個資料夾，分別用於存放執行時產生的資料、日誌和配置，這三個資料夾對映後是雙向讀寫的，即在宿主環境中修改和容器內修改內容效果是一樣的。

理解了volumes: 就不難理解ports: 和 links: 它們有相似的語法，分別表示將宿主機上的TCP/IP埠對映到容器相應的埠上，以及指定執行在同一宿主機上的容器如何互相連線。本例項中，Gitlab分別與Redis和PostgreSQL相連線，Redis提供持久化功能，PostgreSQL提供Gitlab後端的資料庫服務。

需要特別注意的就是埠對映中A : B ，A為宿主機埠，不能指定已經被其他應用佔用的埠。連線中 A : B A為宿主環境中容器的名稱，B為該容器環境中所識別的連線到的容器名稱。例如，- redis: redisio 指定docker-compose檔案中的redis容器要連線到gitlab容器，在gitlab容器中，它所訪問到的redis服務就是redisio。

再有就是對映的路徑或是埠都需要記住，不能和一些配置檔案裡的引數衝突或者出現不一致。

最後需要說明的就是，雖然可以在命令列通過docker run命令一個一個地執行三個容器構建服務，但docker-compose.yml是更推薦的方式，它清晰明瞭，簡潔高效。命令列只有在除錯的時候特別有用。

剩下的事情就格外簡單了，只需一個簡單的命令：

$docker-compose up

我們用docker映象搭建的Gitlab服務就隨著三個容器的先後執行上線了。執行docker-compose命令的終端會成為我們Gitlab應用的控制終端，接收三個容器輸出的日誌資訊，如果一切正常。你就可以嘗試通過http://localhost:10080 來訪問你的Gitlab服務了。

除錯容器

通常你的應用搭建都不會一帆風順，當出現異常時，出現問題的容器會退出執行，這時從瀏覽器前段就無法訪問你的應用了。那麼如何來除錯應用呢？

首先，如果docker-compose up命令直接返回錯誤，說明你的docker-compose.yml檔案有語法錯誤，可以根據出錯提示資訊修改你的.yml檔案。還可以用

$docker-compose config

來檢查你的.yml檔案語法（必須在你的docker-compose.yml檔案所在路徑下執行）。
如果docker-compose up執行後有容器退出，那麼說明docker-compose.yml中指定的某些引數不能為容器所接受。需要檢查是否有資源被佔用或指定路徑不可達的問題。

如果容器能夠正常執行，但我們的Gitlab應用還是無法訪問。那麼情況就比較複雜了。這時候進入容器內一探究竟或許能有所幫助：

$docker exec -it ${YOUR_GITLAB_CONTAINER_NAME_OR_HASH_ID} /bin/bash

上面這個命令能夠attach到你所執行的Gitlab容器(被docker-compose命名為gitlab_gitlab_1，Redis容器為gitlab_redis_1，PostgreSQL為gitlab_postgresql_1)上，並開啟一個終端並在終端裡執行bash。
如果你看到你的命令列提示符變為類似

root@a_hash_id:/#           [注：a_hash_id 是當前所登入的容器的ID]

就說明你成功地通過終端登入容器中，這時候你可以使用命令列工具來檢視容器的執行情況。輸入exit 命令可以退出容器。
當然，在容器外，你還可以使用

$docker logs ${YOUR_GITLAB_CONTAINER_NAME_OR_HASH_ID}

來檢視日誌。

使用SMTP伺服器作為Gitlab的郵件傳送服務端

從上一節的docker-compose檔案中我們已經看到Gitlab容器的環境變數中有不少關於SMTP的設定了。但實際執行時發現這些設定都是可以被覆蓋的，那麼比較保險的做法就是在gitlab_rails配置檔案：gitlab.rb中進行SMTP設定。配置檔案如下，放在volumes: 指定的config目錄下，可以在宿主機環境中編輯，也可以進入容器在/etc/gitlab/ 目錄下編輯：

# gitlab SMTP configurations
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.gmail.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "[email protected]"
gitlab_rails['smtp_password'] = "[email protected]#"
gitlab_rails['smtp_domain'] = "gmail.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_tls'] = false
gitlab_rails['smtp_openssl_verify_mode'] = 'peer'

# If your SMTP server does not like the default 'From: [email protected]' you
# # can change the 'From' with this setting.
gitlab_rails['gitlab_email_from'] = '[email protected]'
gitlab_rails['gitlab_email_reply_to'] = '[email protected]'

本例使用的Gmail作為SMTP服務端，注意smtp_user_name和smtp_password就是你的Gmail郵箱帳號。郵箱設定可以參考Gmail的幫助文件，或者gitlab_rails的配置文件。

配置檔案寫好後，需要重新應用該配置更新gitlab：

$docker exec -it ${YOUR_GITLAB_CONTAINER_NAME_OR_HASH_ID} /bin/bash
# 以下為容器內操作
root@a_hash_id:/# gitlab-ctl reconfigure
# 也可以重啟一下
root@a_hash_id:/# gitlab-ctl restart

完成後一切正常的話你的gitlab.rb中的配置就應該生效了。
手動測試一下郵件傳送的效果，也可以先用telnet嘗試登陸smtp伺服器，測試一下與smtp伺服器的連通性:

root@a_hash_id:/# gitlab-rails console
#以下為gitlab-rails console下的操作
irb(main):001:0> Notify.test_email('[email protected]', 'Test mail frm gitlab', 'Hello').deliver_now

如果能收到郵件，說明設定的Gmail SMTP帶發能正常工作。如果收不到，就要根據gitlab-rails console上Notify的執行回覆分析問題所在了。

Next ==>使用Ngrok內網穿透遠端訪問Gitlab私服