2017-04-18 55 views
1

我無法讓gitlab在我的服務器上工作。
的environnment是:
的Ubuntu 16.04.1 LTS
的Apache 2.4gitlab與Apache連接被拒絕

我通過綜合腳本安裝gitlab,編輯gitlab.rb,使其與Apache的工作,取得了虛擬主機專用,掙扎與小SSL證書,得到它的工作,但我堅持一個我無法解決的錯誤。

當我去https://gitlab.mydomain.com/users/sign_in我有一個漂亮的503 錯誤日誌中說:

[Tue Apr 18 16:58:56.556702 2017] [proxy:error] [pid 31966] (111)Connection refused: AH00957: HTTPS: attempt to connect to 127.0.0.1:8181 (*) failed 
[Tue Apr 18 16:58:56.556722 2017] [proxy_http:error] [pid 31966] [client 93.182.244.38:60339] AH01114: HTTP: failed to make connection to backend: 127.0.0.1, referer: https://gitlab.mydomain.com/users/sign_in 

下面是使用虛擬主機:

<VirtualHost *:443> 
    ServerName gitlab.mydomain.com 
    ServerSignature Off 
    SSLEngine on 
    SSLCertificateFile /etc/letsencrypt/live/mydomain.com/fullchain.pem 
    SSLCertificateKeyFile /etc/letsencrypt/live/mydomain.com/privkey.pem 

    ProxyPreserveHost On 

    # Ensure that encoded slashes are not decoded but left in their encoded state. 
    # http://doc.gitlab.com/ce/api/projects.html#get-single-project 
    AllowEncodedSlashes NoDecode 

    <Location /> 
    # New authorization commands for apache 2.4 and up 
    # http://httpd.apache.org/docs/2.4/upgrading.html#access 
    Require all granted 

    #Allow forwarding to gitlab-workhorse 
    ProxyPassReverse https://127.0.0.1:8181 
    ProxyPassReverse https://gitlab.mydomain.com/ 
    </Location> 

    # Apache equivalent of nginx try files 
    # http://serverfault.com/questions/290784/what-is-apaches-equivalent-of-nginxs-try-files 
    # http://stackoverflow.com/questions/10954516/apache2-proxypass-for-rails-app-gitlab 
    RewriteEngine on 

    #Forward all requests to gitlab-workhorse 
    RewriteRule .* https://127.0.0.1:8181%{REQUEST_URI} [P,QSA] 

    # needed for downloading attachments 
    DocumentRoot /opt/gitlab/embedded/service/gitlab-rails/public 

    #Set up apache error documents, if back end goes down (i.e. 503 error) then a maintenance/deploy page is thrown up. 
    ErrorDocument 404 /404.html 
    ErrorDocument 422 /422.html 
    ErrorDocument 500 /500.html 
    ErrorDocument 503 /deploy.html 

    # It is assumed that the log directory is in /var/log/httpd. 
    # For Debian distributions you might want to change this to 
    # /var/log/apache2. 
    LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b" common_forwarded 
    ErrorLog ${APACHE_LOG_DIR}/gitlab_error.log 
    CustomLog ${APACHE_LOG_DIR}/gitlab_forwarded.log common_forwarded 
    CustomLog ${APACHE_LOG_DIR}/gitlab_access.log combined env=!dontlog 
    CustomLog ${APACHE_LOG_DIR}/gitlab.log combined 
</VirtualHost> 

我做了什麼錯?

謝謝你的幫助。

回答

0

gitlab-workhorsedoesn't support SSL connections

馱馬可以處理,而不涉及的Rails都有些要求: 例如,JavaScript文件和CSS文件是從磁盤直接 服務。

馱馬可以修改的Rails發送的響應:例如,如果你在Rails中使用 由send_file然後gitlab,主力將打開 磁盤上的文件和發送它的內容作爲響應體到客戶端。

在徵得Rails許可後,主力可以接管請求。 示例:處理git clone。

Workhorse可以在將請求傳遞給Rails之前修改請求。例如: 當處理Git LFS上傳時,Workhorse首先請求來自 Rails的權限,然後它將請求正文存儲在一個臨時文件中,然後它發送一個修改的請求,包含temp文件路徑到Rails。

工作人員可以管理Rails的長期WebSocket連接。例如:處理終端websocket的環境。

Workhorse不連接到Postgres,只連接到Rails和(可選)Redis。

我們假設所有到達Workhorse的請求都首先通過 上游代理(如NGINX或Apache)。

主力不接受HTTPS連接。

工作人員不清理空閒的客戶端連接。

我們假設所有對Rails的請求都通過了Workhorse。