1. 程式人生 > >直接或Docker部署Gitlab要遇到的坑

直接或Docker部署Gitlab要遇到的坑

一:直接部署:

  1. 前面幾步都是準備工作,其中只有第三部安裝Bundler Gem需要注意:執行安裝前把下面跟換源的語句先執行。
  2. 由於以前在我的伺服器上有使用過docker部署LNMP環境,所以mysql和redis都是docker 容器,直接造成了兩個問題:
    1. mysql_docker連線宿主機gitlab:
      1. 使用已部署的phpmyadmin建立資料庫gitlabhq_production備用。
        ***使用過程中發現伺服器8080埠拒絕訪問-->關閉firewall-->安裝iptable–>開啟埠8080–>再次嘗試接入8080後發現:
      2. docker整個炸了:
        1. 不斷地搜尋和手動新增、編輯iptables和嘗試docker設定依然不能復活舊docker:docker-compose up後Error:iptable fail的猩紅大字總是那麼頑強;
        2. 後來發現:docker對iptable已做相容,前提是docker一定要在iptable安裝後安裝;
        3. 為了保持原有網站和專案的執行,只好選擇屈辱的重灌docker了,好在專案的部署一直使用的是docker-compose自動化部署,原有專案在重灌docker前後並不受影響
    2. redis_docker連線主機gitlab
      1. iptable設定開啟6379;
      2. 確保redis_docker服務無問題;
      3. 順利進行部署經驗直到:
        1. 配置redis連線:# sudo -u git -H cp config/resque.yml.example config/resque.yml

        2. 一開始並沒有特別的注意這個配置,經過之後的mysql配置發現問題,config/resque.yml中的配置項:production: 

          unix:/var/run/redis/redis.sock是什麼鬼鬼鬼;

        3. 宿主機沒有安裝redis,而redis_docker並不支援(沒有找到怎麼支援)socket連結方法,宿主機安裝gitlab就此遇到第一大坑,但是在為宿主機安裝redis後該問題應該是可以解決的,如果沒有遇到以下問題的話;

        4.  安裝Gems:sudo -u git -H bundle install --deployment --without development test postgres aws,由於之前已經把源換為淘寶源,所以原以為安裝可以很順利,但事與願違: redis不能連線,因為沒有redis.sock!!需要重新配置config/resque.yml!!!!

    3. 雖然以上問題在宿主機上裝一個redis使用其他埠,應該就可以解決問題,但是,作為後端,我們永遠不向冗餘低頭!我們要乾淨簡潔的伺服器結構!於是,我們走上了使用docker映象部署gitlab的不歸路...

二:Docker部署:

  1. 已經部署了redis,所以這一步可以省略,不過有一個坑,稍後解決。
    ***如果沒有redis:
    1. 拉取映象:docker pull sameersbn/redis:latest
    2. 啟動容器:docker run --name=redis -d sameersbn/redis:latest
  2. gitlab的docker預設使用postgresql資料庫,所以我們:
    1. 拉取映象:docker pull sameersbn/postgresql:latest
    2. 為資料庫預設的表空間建立目錄以存放資料mkdir -p /home/git/gitlab_docker/postgresql/data
    3. 更改許可權:sudo chcon -Rt svirt_sandbox_file_t  /home/git/gitlab_docker/postgresql/data
    4. 啟動容器:docker run --name=postgresql -d -e 'DB_NAME=gitlabhq_production' -e 'DB_USER=gitlab' -e 'DB_PASS=password' -v '/home/git/gitlab_docker/postgresql/data:/var/lib/postgresql' sameersbn/postgresql
  3. 部署gitlab,注意了,一大波坑即將襲來:
    1. 拉取映象:docker pull sameersbn/gitlab
    2. 建立目錄以存放資料mkdir -p /home/git/gitlab_docker/gitlab/data
                                          mkdir -p /home/git/gitlab_docker/gitlab/backups
    3. 啟動容器:docker run --name='gitlab' -d --link docker_redis_1:redisio -v /home/gitlab_docker/gitlab/data:/home/git/data -p 10022:22 -p 10080:80 -e 'GITLAB_PORT=10080' -e 'GITLAB_SSH_PORT=10022' -e 'DB_HOST=127.0.0.1' -e 'DB_USER=gitlab' -e 'DB_PASS=password' -e '[email protected]' -e 'GITLAB_BACKUPS=weekly' -e 'GITLAB_HOST=120.78.137.250' -e 'GITLAB_SIGNUP=true' -e 'GITLAB_GRAVATAR_ENABLED=false' --net docker_default sameersbn/gitlab
      1. 第一個坑:資料庫連線失敗,但是不會報錯,只能反覆的檢查DB_HOST和DB_PORT兩個引數是否配置正確。
        解決辦法:沒有特別好的解決辦法,等一會兒之後發現依然是這個狀態就需要停掉容器,刪除容器並重新配置啟動一個新容器。

      2. 第二個坑:redis掛載出錯,使用引數--link docker_redis_1:redisio 並沒有辦法使用已存在的redis。
        解決辦法:去掉--link docker_redis_1:redisio,使用-e 'REDIS_HOST='以及-e ‘REDIS_PORT=’老老實實的配置redis實際服務。
      3. 第三個坑:系列坑,一些沒有預設配置的key生成方式需要在gitlab執行之初就配置好:
        解決辦法:配置一下多個引數 ‘GITLAB_SECRETS_DB_KEY_BASE’,‘GITLAB_SECRETS_SECRET_KEY_BASE’,‘GITLAB_SECRETS_OTP_KEY_BASE’。
      4. 最後我們的gitlab執行命令是這個樣子的:
        docker run --name='gitlab' -d -v /home/git/gitlab_docker/data:/home/git/data -v /home/git/gitlab_docker/log:/var/log/gitlab -p 10022:22 -p 10080:80 -e 'GITLAB_PORT=10080' -e 'GITLAB_SSH_PORT=10022' -e 'DB_TYPE=postgres' -e 'DB_HOST=172.20.0.2' -e 'DB_PORT=5432' -e 'DB_USER=gitlab' -e 'DB_PASS=password' -e 'REDIS_HOST=172.20.0.5' -e '[email protected]' -e 'GITLAB_BACKUPS=weekly' -e 'GITLAB_HOST=120.78.137.250' -e 'GITLAB_SIGNUP=true' -e 'GITLAB_GRAVATAR_ENABLED=false' -e 'GITLAB_SECRETS_DB_KEY_BASE=pwgen -Bsv1 64' -e 'GITLAB_SECRETS_SECRET_KEY_BASE=pwgen -Bsv1 64' -e 'GITLAB_SECRETS_OTP_KEY_BASE=pwgen -Bsv1 64' --net docker_default sameersbn/gitlab

三:結尾:

終於,在看到這個鏡頭的時候,我們差不多進入黎明前的黑暗了:

過一會去我們配置好的120.78.137.250:10080看一下,就可以確認是否搭建成功了。

***後記:gitlab需要四核CPU,4G記憶體才可以流暢執行,經試驗,單核加1G加2GB虛擬SWAP,讓整個阿里雲ECS趨於崩潰,卡頓非常嚴重!